欢迎关注同名微信公众号“modem协议笔记”。

实网下VOLTE通话时常会出现通话无声或者断续的情况，通常的做法是通过检查MO/MT UL发送和DL接收，进一步排查问题原因，modem就避免不了要查看RLC的收发情况，而voice配置一般都是RLC UM mode，极少情况下也见过配置为AM mode的场景，VONR也是类似的情况。结合LTE RLC 36.322 UM RLC 接收端和发送端规定的描述，通过检查LTE RLC可以比较直观的看出UE tx/rx的问题；在NR RLC(一)和(二)中或多或少提及了LTE和NR RLC的一些区别，那VONR出现无声或断续问题时，通过NR RLC是否也能比较直观的看出问题？NR RLC UM mode传输情况对应到实际log是什么样的？下面就重点看下NR RLC UM mode的过程。这篇主要内容是RLC UM mode的具体过程，外加RLC TM mode，RLC entity相关的建立，重建及release过程的描述，最后是NR RLC UM mode log的简单分析过程。先看RLC entity的建立，重建及release过程的内容。

 当上层请求建立 RLC entity时，UE 要建立一个RLC entity；将 RLC entity对应的状态变量设置为初始值；然后按照配置进行对应的data传输。

sidelink 场景，TM 用于 SBCCH； AM和UM都可以用于unicast传输；UM可用于broadcast和groupcast传输，但是只能是单向传输。

对于NR sidelink groupcast和broadcast，当从 LCID 的 source Layer 2 ID和Destination Layer 2 ID pair 接收到第一个 UMD PDU时，但还没有相应的RB接收RLC entity的情况下，UE 要建立接收 RLC entity；将 RLC 实体的状态变量设置为初始值；然后进行相应的data传输。而SL-SRB0和SL-SRB1的接收RLC entity可以用于NR sidelink groupcast和broadcast。 

 

RLC entity re-establishment

 当上层请求RLC entity re-establishment时，UE要丢弃所有RLC SDU、RLC SDU segments和 RLC PDU，如果有的话；停止并重置所有计时器；将所有状态变量重置为其初始值。

什么情况下会引起RLC entity re-establishment？那场景就多了比如T300超时，进行RRC Reestablishment过程等等，筛选下38.331中的内容就可以知道，但是有个场景，之前一直没怎么关注过，就是配置reestablishRLC的情况，如下。

 配置reestablishRLC时表示UE应该重新建立RLC。至少每当用于RLC entity相关联的radio bearer的安全密钥发生变化时，网络就会将其设置为true。对于SRB2和DRB，除非使用full configuration，否则在RRC connection resume期间或reestablishment后的第一次reconfiguration时也设置为true。对于SRB1，在恢复RRC连接时，或者在RRC连接重建后的第一次重新配置时，网络不会将该字段设置为true。

 而fullConfig会出现在RRCReconfiguration或者RRCResume中，fullConfig对应的是适用于intra-system intra-RAT HO的full configuration 。对于从 E-UTRA 到 NR 的 inter-RAT HO，fullConfig 指示来自source RAT 的 SDAP/PDCP 增量信令是否适用。如果配置了任何 DAPS 承载，或者当RRCReconfiguration消息在 SRB3 上传输时，以及在 SCG 的 RRCReconfiguration 消息中包含在另一个 LTE RRCReconfiguration 消息在 SRB1 上传输，则该字段不存在。

 当upper layers要求RLC entity release时，UE应该discard all RLC SDUs,RLC SDU segments和RLC PDUs(有的话)；release RLC entity。

下面就是TM和UM mode的内容，主要是UM，TM mode本来就没有什么好说的。

 

TM data transfer

 在将新的TM PDU传递给MAC 层时，TM RLC entity的发送端应该将不做任何修改的RLC SDU传递给MAC；在从MAC 层接收新的TMD PDU时，TM RLC entity的接收端应该将不做任何修改的TMD PDU传递给PDCP。TM mode下，RLC任务小，啥也不用做，直接把data丢走就行了。

相比TM mode，UM mode 涉及的过程要多些内容，尤其是接收端操作，但是远没有AM mode复杂。

 

UM data transfer

发送端

 UM RLC entity的发送端在将UMD PDU传递给MAC时，如果UMD PDU对应的是一个RLC SDU 的segment，TX_Next=UMD PDU 的SN；

如果UMD PDU包含的segment是某个RLC SDU的last byte，即当前RLC SDU都发送出去了，TX_Next++。

就如上篇TX_Next的描述，只有RLC SDU 的segment 才有SN，TX_Next 指向的就是RLC SDU segment 的SN，Tx_Next有序增加，代表的是RLC SDU segment的有序增加。这样做的原因是由于NR RLC不再需要进行reodering，reordering放在了NR PDCP，而RLC SDU有segement 就要包含SN的原因也主要是RLC需要将RLC SDU进行重组后，才能传递到PDCP，所以需要对segment增加SN，以便后续重组操作。

另外，如上篇那一坨modulus base的描述，要注意SN存在翻转的情况，例如12bit SN，SN取值范围为[0，4095]，当SN达到4095时，下一个值为0，这就是SN翻转。

 

接收端

 UM RLC entity接收端应该根据RX_Next_Highest保持 reassembly window，reassemble window的大小对应[RX_Next_Highest-UM_Window_Size，RX_Next_Highest)。

当UM RLC entity接收端从MAC 层收到UMD PDU时，可能会将对应的UMD PDU removing RLC header后传递给PDCP，或者discard 该UMD PDU或者将其放在接收buffer中；如果在接收buffer中放置有收到的UMD PDU时，还要更新相关的状态变量，对其进行重组然后上传给PDCP，并根据需要开启或stop t-Reassembly。

当t-Reassembly 超时，UM RLC entity接收端要更新相关的状态变量，discard RLC SDU segments 并根据需要开启t-Reassemebly。

 

下面具体看下UM 接收端的具体过程。

从MAC收到UM PDU时

 当UE从MAC 层收到UMD PDU时，UM RLC entity接收端要做一下处理

(1) 如果UMD PDU header没有包含SN，就直接remove RLC header并将RLC SDU 传给PDCP；

(2) 如果UMD PDU header包含的SN且处于[RX_Next_Highest-UM_Window_Size，RX_Next_Reassembly)区间，因为RX_Next_Reassembly之前的SN已经完成重组过程，再收到的话，是没有利用价值，所以要discard接收的UMD PDU；否则就放置在接收buffer中，等待后面收全对应RLC SDU所有segment后再进行重组。

这里SN的处理方式，主要和UM RLC SN的规定有关系，如前述，UMD PDU可能没有SN，具体原因上面也有提到；对于UM RLC，segment RLC SDU才会有sn，sn也是逐一递增的，完整的RLC SDU没有SN。所以这里UM RLC entity接收端在处理数据时，要考虑UM PDU没有SN的情况。

 

接收buffer中有UMD PDU时

 对于放在接收buffer中的UMD PDU的SN=x，UM RLC entity的接收端要分情况处理

(1) 如果SN=x的所有byte segment 都收到了，将其进行RLC SDU的重组，进行remove RLC header 操作后传递给 PDCP；如果这时候x恰巧=RX_Next_Reassembly，就将RX_Next_Reassembly设置为下一个还没有完成重组的SN的值。

(2)其他情况，reassembly window的大小对应[RX_Next_Highest-UM_Window_Size，RX_Next_Highest)，即以上边界RX_Next_Highest为驱动因素，RX_Next_Highest的更新就会引起reassembly window的变化，如果x超出了reassembly window，将RX_Next_Highest取值x+1，discard任何不在reassemble window中sn对应的UMD PDUs；如果RX_Next_Reassembly不在reassembly window内，就要RX_Next_Reassembly设置为第一个大于等于(RX_Next_Highest-UM_Window_Size)且还没有完成重组的SN。

从上面的描述可以看出，UM 接收窗会根据收到的UMD PDU SN 更新RX_Next_Highest，进而接收窗发生变化后，可能会有即使某些SN没有收到，但是也要discard的情况。

 比如，UM_Window_Size=6，当前RX_Next_Highest=7，则UM 接收端目前接收到的SN是1~6，其中SN=3和4还没有收到，RX_Next_Reassembly=3；假如下一个收到的UMD PDU SN =9，那就要更新reassembly window，新的RX_Next_Highest=10，新的reassembly window内的SN是 4~9，其中4/7/8还没收到，RX_Next_Reassembly=4；如果紧接着UE收到了SN=3的UMD PDU ，即使UE之前没有收到过这个segment，UE也会做discard处理。          

这种处理方式看似不合理，但是结合使用场景的话，恰恰又是最合理的；例如voice DRB 一般会使用UM模式，考虑更多的是实时性，UE不会因为UM RLC有几个SN 没收到就停止不前，会根据实际接收的SN，实时更新reassembly window，在信号状况不好的情况下，UE可能会出现某个SN收不到的情况，但是只要reassembly window在更新，DL就能将收到语音数据包实时往上送，即使丢失某些数据包，也能保证UE可以有voice可以放出来。

t-Reassembly

 RX_Timer_Trigger 代表UM t-Reassembly状态变量，保存的是触发t-Reassembly SN的下一个SN的值。

t-Reassembly 在running，RX_Timer_Trigger<=RX_Next_Reassembly 或者RX_Timer_Trigger不在reassemble window中且不等于RX_Next_Highest或者RX_Next_Highest=RX_Next_Reassembly+1且RX_Next_Reassembly对应的RLC SDU所有接收段最后一个字节之前的segment都收到了，那就要stop 并reset t-Reassembly，如下图示举例，假设UM_Window_Size=5。

 t-Reassembly 没有running，如果RX_Next_Highest>RX_Next_Reassembly+1 或RX_Next_Highest=RX_Next_Reassembly+1且RX_Next_Reassembly对应的RLC SDU最后字节前有segment没有收到，UE要start t-Reassembly，并将RX_Timer_Trigger赋值为RX_Next_Highest的SN value，如下图示举例。

 

t-Reassembly expires

 当t-Reassembly 超时，UM RLC entity接收端要将RX_Next_Reassembly 更新到第一个大于等于RX_Timer_Trigger 且还没有完成reassemble的SN的位置；discard 小于更新后的RX_Next_Reassembly值的SN 的所有 segment；

如果此时RX_Next_Highest>RX_Next_Reassembly+1 或RX_Next_Highest=RX_Next_Reassembly+1且RX_Next_Reassembly对应的RLC SDU的segment未收全，UE要start t-Reassembly，并将RX_Timer_Trigger赋值为RX_Next_Highest的SN value。

 

最后看一个RLC UM mode传输的例子。

 

这是一个实网下的VONR的log，在voice DRB建立之初 ，通过PDU session modification command 在pdu session id =2下配置了5qi=1的qos flow 2以及其qos rule，5qi=1对应voice 。

 在此之前网络侧有配置对应的DRB 信息，如上图，对应DRB 3 LCID 5 以及UM RLC参数。 

 

通过上图的打印也可以看出voice 对应的DRB配置信息打印，和空口中的配置信息一致。

 

在通话建立之后，通过上图可以看到UM RLC在进行voice data的传输，UM RLC 发送只有一个参数TX_Next，指向新生成UMD PDU(对应RLC SDU segment)的SN，初始值为0。

 

换个角度，从UL Data PDU的角度看，相关的DRB 具体data 发送信息，例如在SFN 492 slot 4 新传了 SI =00 的RLC data，SI=00，代表发送的是一个完整的RLC SDU，UM模式下，完整的RLC SDU 是没有SN 的，因而没有SN信息的打印。上面Tx Next 一直为0，也说明了UE一直在发送完整的RLC SDU，没有进行segment。

 

通过上图，可以看到DL 有不断的收到新的data pdu，由于网络状态很好的缘故，对端UL grant充足，因而UE DL收到的RLC PDU 也是SI=00，没有SN信息，这种情况下，RLC直接remove掉 header并将其传递给PDCP。

通过上面的例子，可以看出在UL grant充足的情况下，UM RLC 一直在传输完整的RLC SDU，因而通过log只能知道UE有在收发data，并不能像LTE似的通过SN去判断UE DL data是否有序接收以及实际接收状况，这种情况下查看RLC 显得有些多余，这时候就需要通过检查PDCP DL接收(COUNT)来进一步确认上述问题，如下图，PDCP DL接收很流畅。

 反过来看，网络状态不佳的情况下，会出现UL grant不足的情况，UE会产生大量的segement，这时候UMD PDU 就会有SN，reassembly window对应的参数RX_Next_Reassembly ，RX_Next_Highest 等参数才会有赋值，进而才可能从RLC的角度看出些UE的收发问题。

其实结合UM mode发送端TX_Next的更新机制也可以看出，UM mode场景下，UM mode下的Tx_Next，并不能连续的记录voice data的发送情况，进而DL接收端也是类似的情况，所以如果要检查UM mode的数据传输情况，通过NR RLC并不能全面的看出问题，这种情况下，就需要检查PDCP的收发去进一步确认问题。 

那具体到NR RLC AM mode又是什么样的情况，下一篇再接着看。