目录
1. rlc-BearerToAddModList
1.1 rlc-Config
1.1.1 ul-AM-RLC
1.1.2 dl-AM-RLC
1.2 mac-LogicalChannelConfig
2. mac-CellGroupConfig
2.1 schedulingRequestConfig
2.2 bsr-Config
2.3 tag-Config
2.4 phr-Config
2.5 skipUplinkTxDynamic
3. physicalCellGroupConfig
3.1 p-NR-FR1
3.2 pdsch-HARQ-ACK-Codebook
RRCSetup消息主要包含radioBearerConfig和masterCellGroup两个IE,其中radioBearerConfig包含了SRB1的配置
radioBearerConfig
{
srb-ToAddModList
{
{
srb-Identity 1,
pdcp-Config
{
t-Reordering ms3000
}
}
}
},
masterCellGroup则包含了较为复杂的内容,下面重点描述这个IE。
masterCellGroup在RRC协议中的IE类型是CellGroupConfig,这个IE可以用于配置主小区组(master cell group ,MCG)或者辅小区组(secondary cell group,SCG)。该IE可以由一个MAC实体、逻辑信道集、一个主小区(SpCell)以及一个或多个辅小区(SCells)构成。
其中,cellGroupId用于标识这个小区组,取值范围0~maxSecondaryCellGroups。在当前协议版本中(R18),maxSecondaryCellGroups = 3。示例中,该参数的值为0
cellGroupId 0,
1. rlc-BearerToAddModList
示例中,这个list只有一个RLC-BearerConfig,即SRB1的无线承载配置。
logicalChannelIdentityBearer
无线承载对应的逻辑信道ID,示例中为1
servedRadioBearer
对应的无线承载,可以是SRB或者DRB,示例中为SRB1
logicalChannelIdentity 1,
servedRadioBearer srb-Identity : 1,
1.1 rlc-Config
RLC配置可以分为AM或者UM两种模式。示例中的SRB1必然是一个AM配置。
rlc-Config am :
{
ul-AM-RLC
{
sn-FieldLength size12,
t-PollRetransmit ms40,
pollPDU infinity,
pollByte infinity,
maxRetxThreshold t32
},
dl-AM-RLC
{
sn-FieldLength size12,
t-Reassembly ms40,
t-StatusProhibit ms0
}
},
1.1.1 ul-AM-RLC
sn-FieldLength
指示RLC PDU的序列号(长度)。对于RLC AM而言,仅有size12和size18两种,见38.322 6.2.2.4。示例中为size12,表示序列号长度为12比特,因此序列号取值范围为0~4095。
t-PollRetransmit
RLC AM中用于Poll机制的一个定时器,单位:ms。示例中的值为40ms。
Poll机制是RLC AM中一种用于检测接收端是否正确地收到了数据包的机制,它是一种反馈机制。大致如下:
- 发送端发送一个带有poll bit的RLC PDU,其中polling bit设置在RLC header中
- 接收端收到这个poll bit时,会反馈一个Status PDU,包含所有已经ACK或者NACK的PDU。其中ACK表示正确地接收了这个PDU,NACK表示错误或者丢失的PDU
- 发送端接收这个Status PDU,并决定是否对所有NACK的PDU进行重传
pollPDU
该参数用于在poll机制中、决定是否设置一个Poll,见38.322 5.3.3.2
该参数如果取值p4则对应4个PDUs,p8对应8个PDUs;示例中的infinity则对应无限个PDUs,即不通过PDU_WITHOUT_POLL的计数来添加Poll。
pollByte
和前面的参数pollPdu作用类似,只是门限值为bytes。
该参数如果取值kB25则对应25 kBytes,kB50对应50 kBytes;示例中的infinity则对应无限bytes,即不通过BYTE_WITHOUT_POLL的计数来添加Poll。
maxRetxThreshold
该参数用于在发送端限制一个RLC SDU的重传次数。当重传次数达到这个最大值门限时,RLC会向上层报告重传次数达到最大(见38.322 5.3.2),上层一般会Call drop。
该参数的值tx表示有x次重传,示例中t32表示最大32次重传。
1.1.2 dl-AM-RLC
sn-FieldLength
同ul-AM-RLC中的sn-FieldLength
t-Reassembly
重新组装(Reassembly)的定时器,单位ms。
在RLC层,分段(Segmentation)和组装(Reassembly)是一对互逆的过程。RLC层其中一个职能是负责数据有序地发送,因此,在接收端,当收到的数据出现顺序错乱时,RLC会等待直到所有有序数据都收到为止,再将所有这些数据段组装(Reassembly)然后提交给上层。有时候,RLC可能一直等不到所有有序数据都到达,为了防止RLC接收端无限制地等下去,因此设置了这个t-Reassembly定时器。当这个定时器超时的时候,即使没有等到所有有序数据到达,RLC也会将受到的数据提交个上层,并更新相关参数。
RLC AM和UM都存在分段(Segmentation)和组装(Reassembly),因此两种模式均有对应的t-Reassembly。示例中的t-Reassembly为ms40,表示定时器超时时长为40ms。
RLC AM的t-Reassembly用法见38.322 5.2.3.2
t-StatusProhibit
该定时器用于AM RLC接收端、决定是否禁止STATUS PDU的发送。只有在该定时器超时的时候,才会产生并发送STATUS PDU。该定时器的详细用法见38.322 5.3.4
示例中的ms0表示该定时器不会运行,即这个定时器不会阻止STATUS PDU的产生和发送。
1.2 mac-LogicalChannelConfig
mac-LogicalChannelConfig
{
ul-SpecificParameters
{
priority 3,
prioritisedBitRate infinity,
bucketSizeDuration ms300,
logicalChannelGroup 0,
schedulingRequestID 0,
logicalChannelSR-Mask FALSE,
logicalChannelSR-DelayTimerApplied FALSE
}
}
LogicalChannelConfig IE中主要包含ul-SpecificParameters这个IE,包含以下参数:
priority
逻辑信道优先级,取值范围1~16,该参数的值越大,优先级越低。见38.321 5.4.3.1.1
prioritisedBitRate
即PBR,MAC层根据上行grant、分配上行数据的令牌桶算法参数之一。该参数表示单位时间内应该给某个逻辑信道分配的数据量(比特数),因此该参数实际上相当于这个逻辑信道的一个保证速率。每个逻辑信道都具有自己的PBR。
示例中,PBR为infinity,表示对当前逻辑信道的保证速率无限大,即尽可能满足。由于该PBR所属的逻辑信道对应的是SRB1,优先级很高(值为3),实际上infinity就是优先且最大满足。另外,按照38.331的描述,对于SRB,prioritisedBitRate也只能设置为infinity。
bucketSizeDuration
即BSD,和PBR一样、也是MAC层令牌桶算法参数之一。该参数表示PBR持续增加的最大时长,即令牌桶的桶深。(PBR x BSD)表示的含义就是当前逻辑信道可以分配的最大比特数。这个当前即指MAC执行当前Logical Channel Prioritization过程的时候。和PBR一样,每个逻辑信道都具有自己的BSD。
示例中,BSD=300ms,由于PBR=infinity,所以这个参数的值在算法中并不是很重要,因为(PBR x BSD)相当于还是“infinity"。
关于令牌桶算法的讲解,可以参考LTE MAC层令牌桶算法_prioritisedbitrate-CSDN博客,协议部分可以参考38.321 5.4.3.1。
logicalChannelGroup
逻辑信道组ID。取值范围0~maxLCG-ID,R18协议下,maxLCG-ID=7。
schedulingRequestID
指示这个逻辑信道的调度请求(SR)配置。这个ID是一个SR配置集合的索引,这个SR配置集合在后面的IE schedulingRequestToAddModList中给出。
logicalChannelSR-Mask
该参数用于控制配置的上行grants(CUG)是否可以触发调度请求(SR)。其中配置的上行grants是指预先配置好的上行grant,比如半持续调度(SPS)。CUG分为type1和type2两种,type1是指通过RRC配置的上行grant,type2是指通过PDCCH配置的上行grant(见38.321 5.8.2)。type1最典型的就是LTE中的SPS,常用于voice等业务;type2用于突发的上行数据。
示例中参数的值为false,表示该逻辑信道没有SR masking,即允许触发SR。
logicalChannelSR-DelayTimerApplied
该参数指示当前逻辑信道在准备触发SR发送的时候,使用应用一个延迟定时器,即logicalChannelSR-DelayTimer。
示例中参数的值为false,表示不应用这个延迟定时器,一旦有SR触发,则立即发送SR。
2. mac-CellGroupConfig
2.1 schedulingRequestConfig
schedulingRequestConfig
{
schedulingRequestToAddModList
{
{
schedulingRequestId 0,
sr-ProhibitTimer ms16,
sr-TransMax n32
}
}
},
该IE包含一个schedulingRequestToAddModList和一个schedulingRequestToReleaseList,示例中没有release list。其中,schedulingRequestToAddModList包含了一个由SchedulingRequestToAddMod构成的list。SchedulingRequestToAddMod中的IE如下说明。
schedulingRequestId
当前SR配置的索引,对于某个逻辑信道而言,其对应的SR配置中会携带这个索引(见mac-LogicalChannelConfig中的schedulingRequestID),以便映射到这里对应的SR配置。
示例中,该参数的值为0,且前面mac-LogicalChannelConfig中的schedulingRequestID也为0
sr-ProhibitTimer
这个定时器的作用是,当UE发送一个SR之后,至少在这个定时器给出的时间范围内,不能再次发送SR。
示例中的值ms16,表示16毫秒。
sr-TransMax
表示一个SR的最大发送次数,当超过这个次数后,UE一般会call drop。
一个SR一定会有其对应的MAC PDU,如果这个MAC PDU发送了,则这个SR就会被cancel,SR_COUNTER就会从0开始计数。
示例中的值n32,表示32次。
2.2 bsr-Config
bsr-Config
{
periodicBSR-Timer sf5,
retxBSR-Timer sf320
},
BSR(Buffer Status Report)配置。
periodicBSR-Timer
周期BSR(Periodic BSR)的定时器,顾名思义即周期性发送的BSR。参数值中的"sf"表示子帧。
示例中sf5表示5个子帧。和LTE一样,5G中一个子帧也是1ms,区别是一个子帧包含的slot数不同,和numerology有关。
retxBSR-Timer
我的理解,这个timer的作用是为了给BSR引入“重传”机制。见下面38.321 5.4.5中的描述:
上面这段协议的描述,意思就是当发送了一个BSR之后,就会启动retxBSR-Timer这个定时器。
再看下面这段:
当retxBSR-Timer这个定时器超时之后,MAC实体会认为这个BSR对应的逻辑信道具有最高优先级。
将上面两点结合起来,就是一个典型的“重传”机制。
既然有了周期BSR,为什么还要引入BSR重传机制?
需要注意的是,BSR是MAC CE,是需要UL grant才能发送的。如果没有ul grant,即使是周期BSR,也是无法发送的。另一方面,当没有ul grant、同时又有BSR需要发送的时候,只有Regular BSR可以触发SR(调度请求)以期待获取ul grant。
而retxBSR-Timer超时后触发的BSR正好是Regular BSR
因此,周期BSR和重传BSR其实是不会互相冲突的。周期BSR用于数据量比较大、且数据流比较平稳的一段时期,此时,由于有稳定和持续不断的ul grant,可以供UE提供周期BSR上报。而重传BSR用于偶发的数据,通过SR/Regular BSR的机制上报,当首次触发了Regular BSR之后,也依然无法获取ul grant进行BSR的上报之后,一旦retxBSR-Timer超时,便会再次触发这个BSR(即重传BSR),和首次触发BSR不同的是:此时重新触发的BSR对应的逻辑信道具有最高优先级。
示例中,值sf320即320个子帧,320ms。
2.3 tag-Config
tag-Config
{
tag-ToAddModList
{
{
tag-Id 0,
timeAlignmentTimer infinity
}
}
},
TAG-Config包含两个list
示例中仅有tag-ToAddModList。该list包含一组TAG的配置参数
tag-Id
指示当前SpCell或者SCell的TAG的索引。该值在一个小区组(MCG或者SCG)中是唯一的。
timeAlignmentTimer
该timer定义在38.321中,表示在多长时间范围内MAC实体认为属于该TAG的服务小区是上行时间对齐的。当这个定时器超时时,UE一般会call drop。
示例中,infinity表示该定时器不会超时。
2.4 phr-Config
phr-Config setup :
{
phr-PeriodicTimer sf100,
phr-ProhibitTimer sf100,
phr-Tx-PowerFactorChange dB1,
multiplePHR FALSE,
dummy FALSE,
phr-Type2OtherCell FALSE,
phr-ModeOtherCG virtual
},
该IE用于配置UE的功率余量上报(Power Headroom Report,PHR)的相关参数。
phr-PeriodicTimer
周期PHR的定时器,该定时器超时后,会触发PHR。
示例中sf100表示100个子帧,即100ms。
phr-ProhibitTimer
PHR的禁止定时器,该定时器超时后,如果满足一定条件,会触发PHR。其中,“一定条件”是指对功率余量的影响因素改变了、且达到一定的门限,具体见38.321 5.4.6。
示例中sf100表示100个子帧,即100ms。
phr-Tx-PowerFactorChange
前面提到的“一定条件”中的“门限”,具体见38.321 5.4.6。
示例中的dB1表示1dB。
multiplePHR
指示功率余量是使用Single Entry PHR MAC CE上报还是使用Multiple Entry PHR MAC CE上报。对于MR-DC以及NR UL CA,网络会配置这个参数为true;否则为false。
示例中,FALSE表示使用Single Entry PHR MAC CE上报。
phr-Type2OtherCell
指示是否为其它MAC实体的SpCell配置type 2的PHR。如果没有E-UTRA MAC实体,网络会设置这个参数为false。
Type 2 PH:UE在其它MAC实体的SpCell上的名义最大发送功率和其UL-SCH/PUCCH发送功率之间的差别。而Type 1PH则是指当前服务小区上的名义和实际发送功率之差。
Type 2 PH用于EN-DC、NE-DC、以及NGEN-DC(4G主站,5G核心网)中的E-UTRA MAC实体。
示例中的FALSE表示没有配置Type 2的PHR,因为示例是一个5G SA的信令。
phr-ModeOtherCG
当配置了DC时,指示其它小区组(MCG或SCG)中激活小区使用的PHR模式(real或者virtual)。如果没有配置DC,即只有一个小区组时,该字段会被忽略。
从38.321中对于此参数的描述来看,只有当该参数的值为real时才会有意义,协议中没有virtual对应的行为。
示例中的值为virtual,表示没有特别的行为,当前由于示例为SA的信令,该字段本身也会被忽略。
2.5 skipUplinkTxDynamic
skipUplinkTxDynamic FALSE
该参数指示在某些条件满足的情况下、是否跳过上行发送。这些条件定义在38.321 5.4.3.1.3中,
简单来说,就是当UE获得了ul grant之后,如果没有A-CSI请求、且没有用户数据、且没有重要的MAC CE(仅有周期BSR或者padding BSR),则UE会跳过此次上行发送。
示例中,该参数的值配置为FALSE,表示不会跳过上行发送。
3. physicalCellGroupConfig
physicalCellGroupConfig
{
p-NR-FR1 23,
pdsch-HARQ-ACK-Codebook dynamic
},
3.1 p-NR-FR1
在FR1频段、在当前NR小区组中的所有服务小区中、UE最大的发送功率。UE最大发送功率同时也会收到p-Max(配置在FrequencyInfoUL中)、以及p-UE-FR1(FR1上UE在所有服务小区上的总功率)的限制
示例中23表示23dBm。
3.2 pdsch-HARQ-ACK-Codebook
该参数指示PDSCH的HARQ-ACK码本、是半静态还是动态产生的。
- Semi-Static:半静态码本, 也称为Type-1 HARQ-ACK codebook。即UE根据RRC层PDSCH相关半静态配置, 生成需要发送的半静态的HARQ-ACK码本。
- dynamic:动态码本, 也称为Type-2 HARQ-ACK codebook。即UE根据DCI下行动态调度的情况, 生成需要发送的动态HARQ-ACK码本。
关于semi-static和dynamic码本的具体含义,比较复杂,详见38.213 9.1。
示例中参数的值为dynamic,指示使用动态HARQ-ACK码本。