5G 现网信令参数学习(3)

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码本。