王的教室：VoLTE里面的RLC流程，然并卵？！

燚先生

RLC层属于LTE协议架构中的层二，位于PDCP层之下，MAC子层之上，主要负责数据的传送，而数据的传送又主要有三种模式，分别为TM（透传模式），UM（无应答模式）以及AM（应答模式），这些传输模式的调用与高层所传内容是息息相关的，在协议里是有明确对应关系的。例如对于控制面（即RRC信令）一般选取TM或AM模式，而对于用户面（数据业务）则采用UM或AM模式进行相应的承载。一般来说，例如MIB，SIB1，SIB2等在逻辑信道BCCH下发的系统消息都采用TM模式，因为都是针对小区中的所有用户在下行信道采取广播式的下发，因此无所谓应答，直接透传的方式即可。而诸如RRCConnectionRequst，RRCConnectionSetup，Paging，RRCConnectionReestablishment，RRCConnectionReestablishmentComplete，RRCConnectionReestablishmentReject，RRCConnectionReestablishmentRequest，RRCConnectionReject,RRCConnectionReestablishmentRequest这样在逻辑信道CCCH发送的信令一般采取TM模式传输，AM模式只有在专属逻辑信道DCCH才生效，而且这些在公共传输信道传输的信令或可以通过后续信令的“握手”应答来确保传递成功，或可以通过定时器的超时来进行响应的保障处理，因此不需要RLC底层的AM模式进行确认。而对于RRCConnectionSetupComplete，SecurityModeCommand，SecurityModeComplete，RRCConnectionReconfiguration，RRCConnectionReconfigurationCompletemessage，RRCConnectionRelease，MobilityFromEUTRACommand，MeasurementReport这些在DCCH专属逻辑信道传递的信令则采取AM模式进行信令传递的保障，因此，一般这些信令也不需要定时器进行收发信令的保障。相对于控制面对RRC层三信令的保障，用户面数据业务如果对时延比较敏感的业务采用UM模式进行快速信息传送，例如VoLTE业务，而一般数据业务对于丢包很敏感的则采用AM模式保障信息的有效传递。

为了有效传递数据，RLC实体通过重排序（AM和UM），复制检测（AM和UM），级联、分片和组合（AM和UM），重分片（AM），RLC SDU丢弃（AM和UM），RLC重建，ARQ方式进行错误修正（AM），协议错误检测（AM）等功能手段确保数据的有效传递。

TM模式没有什么新鲜的，就是透传模式，高层来什么样的消息RLC层直接不加任何改动的传递下层，而下层来什么样的消息，RLC也进行同样的处理。

UM模式相对复杂一点，发送端只有一个状态变量VT(US)，接收端有三个状态变量VR(UH)，VR(UR)，VR(UX)，一个常量UM_Window_Size和一个定时器t-Reordering。当SN采用5bit结构时，UM_Window_Size长度为16，当SN采用10bit结构时，UM_Window_Size长度为512，大家以SN为5bit进行说明。

VT(US)即为发端发出的SN序列号的编号，初始值为0；

VR(UR)为接收状态变量，该变量指示了初始需要进行reordering的SN的编号，初始值为0；

VR(UX)为t-Reordering状态变量，指示了触发t-Reordering之后紧随的SN编号；

VR(UH)为最高接收状态变量，该变量指示了接收到最高SN之后紧随的SN编号，初始值为0；

假设发端首先发出的SN为0，通过计算（计算方法详见3GPP36332），该SN=0属于落在了重排序的窗外，假设该SN=0之前并没有被收到过，而且该SN=VR（UR）=0，因此需将该SN=放入接收缓存。该SN=0纳入接收缓存后，更新VR（UH）=1，该SN=0经映射计算（15）属于落入重排窗内0<=x<16之内且VR（UR）=0经映射计算也落入重排窗内，所以暂时不改变；

接收缓存目前有SN=VR（UR）=0，将VR（UR）更新为目前>VR(UR)还没有接收到SN序号，大家暂时设为1，这样大家将小于1的UMD PDU按增序排列上传高层，即SN=0被上传到了高层。这时候VR(UR)=0，VR(UH)=1，

假设VR（UX）=0，此时

如果，t-Reordering在运行，

VR（UX）=0<= VR(UR)=0，停止并重置t-Reordering；

如果，t-Reordering没有在运行，发现此时VR(UH)=1> VR(UR)=0，启动t-Reordering，同时将VR（UX）设置为1，

此时，状态变量VR(UR)=0，VR(UH)=1，VR(UX)=1，定时器t-Reordering在运行；

一旦t-Reordering超时后，更新VR（UR）=1，（因为此时SN=1包还没有收到），此时VR(UH)=1=VR（UR）=1，当后续VR(UH)改变后，才会重新启动t-Reordering，否则t-Reordering不运行。

假设VR（UX）=1，此时

如果，t-Reordering在运行，

VR（UX）=1落在在了重排序窗外，且等于VR（UH）=1，因此该定时器持续运行，直到超时后

更新VR（UR）=1,（因为此时SN=1包还没有收到），当后续VR(UH)改变后，才会重新启动t-Reordering，否则t-Reordering不运行；

此时，状态变量VR(UR)=0，VR(UH)=1，VR(UX)=1，

如果，t-Reordering没有在运行，发现VR（UH）=1>VR（UR）=0，因此启动t-Reordering，并将VR（UX）设置为VR（UH）=1，这样确保t-Reordering不再终止；

假设VR（UX）=2，此时

如果，t-Reordering在运行，

VR（UX）=2落在在了重排序窗外，且不等于VR（UH）=1，该定时器终止并被进行重置；

如果，t-Reordering没有在运行，发现VR（UH）=1>VR（UR）=0，因此启动t-Reordering，并将VR（UX）设置为VR（UH）=1，一旦t-Reordering超时后，更新VR（UR）=1，（因为此时SN=1包还没有收到），此时VR(UH)=1=VR（UR）=1，当后续VR(UH)改变后，才会重新启动t-Reordering，否则t-Reordering不运行。

综合这三个例子来看，VR（UX）起到了一个调整t-Reordering启动的开关作用，如果小于VR（UH）会终止，同时进行参数调整，重启t-Reordering；如果等于VR（UH），要么一直运行，要么重新启动定时；如果大于VR（UH），终止定时器，同时调整参数适配到VR（UH），重新启动定时，因此，看来，不论VR（UX）初始值如何设置，通过这样一套机制，始终进行VR（UX）与VR（UR）的值的对标，同时在没有更新UR（UH）之前始终进行定时的启动调整。
接下来有几种情况，一种是收到了重复的SN=0，收到了期待SN=1，收到了SN>1

当t-Reordering在运行，收到了重复的SN=0，

SN=VR（UR）=0，因此将SN=0放置在接收缓存中，这样属于在接收缓存中存在了SN=VR（UR）=0这种情况，将VR（UR）更新为还未收到SN=1，因此VR（UR）=1，并将缓存中SN<VR（UR）的包上传高层，因此，SN=0就被上传了。 当t-Reordering不在运行，收到了重复的SN=0，

此时，VR(UH)= VR（UR）=1，当收到重复的SN=0时，发现之前SN=0收到过，因此将该SN=0丢弃；

可以看出对于收到重复的包，如果t-Reordering在运行中收到重复包会放入缓存再进行上传，而在t-Reordering不运行的时候会直接丢弃；

当t-Reordering在运行，收到了期待的SN=1，

SN=1不在重排序窗内，因此将SN=1放入接收缓存中，由于SN=1落在了重排序窗外，将VR（UH）更新为1+1=2，此时VR（UR）=0，而缓存中没有SN=0的包，因此在t-Reordering运行期间并不进行上传而是等待下一个顺序包，当t-Reordering超时之后，将VR（UR）更新为大于VR（UX）的第一个包，根据上述初始流程的说明，此时将VR（UR）设置为2，并将接收缓存中的包SN=1上传，

当t-Reordering不在运行，收到了期待的SN=1，

此时VR（UR）=VR（UH）=1，依据算法规则，将SN=1放入接收缓存中，更新VR（UH）=2，接收缓存中此时存有SN=VR（UR）=1，因此将VR（UR）更新为2，并将SN=1包上传至高层。因此这里可以看出，如果t-Reordering设置过小，会造成频繁的包的上传，而且当话音接续过程中，会造成定时器频繁、周期性的超时/重启，而该定时如果设置过大的话，会造成缓存过大，这样接收缓存上传的包时延较大，对话音音质有一定的影响（jitter）。

当t-Reordering在运行，收到了超前的SN>1，假定SN=3

SN=3不在重排序窗内，因此将SN=3放入接收缓存中，由于SN=3落在了重排序窗外，将VR（UH）更新为3+1=4，此时VR（UR）=0，而缓存中没有SN=0的，因此在t-Reordering运行期间并不进行上传而是等待下一个包，当t-Reordering超时之后，将VR（UR）更新为大于VR（UX）的第一个包，根据上述初始流程的说明，此时将VR（UR）设置为1，此时将接收缓存里面的SNVR（UR）=1，启动t-Reordering定时，并将VR（UX）设置为VR（UH）=4，而该定时器再一次超时后，将VR（UR）设置为VR（UH）=4，并且将缓存中SN<VR(UR)=4的包全部上传，遇到超前的情况，通过定时器T-REORDERING将缓存中的包分批次全部进行了上传，这样处理的好处是保证没按预期收到的包之前的所有包是全部按顺序上传，而如果在第二次定时超时前收到了预期的SN=1包，则在第二次定时器超时之后重组增序上传到高层，这也是重排序窗和重拍序定时器共同的结果

当t-Reordering没在运行，收到了超前的SN>1，假定SN=3

SN=3不在重排序窗内，因此将SN=3放入接收缓存中，由于SN=3落在了重排序窗外，将VR（UH）更新为3+1=4，此时VR（UR）=1，而缓存中没有SN=1的，SN=3并不进行上传，而VR（UH）=4>VR(UR)=1，启动t-Reordering定时，同时将VR（UX）设置为VR（UH）=4，如果在定时超时前收到了SN=1，将SN=1放入接收缓存，此时缓存中除了存在SN=3还有SN=VR（UR）=1，因此将VR(UR)更新为2，并且将SN=1<VR(UR)=2的包上传高层，SN=3仍存在接收缓存中，等待定时超时后，将VR（UR）更新为VR（UX）=4，而将SN=3上传高层；如果定时超时前没有收到SN=1，那么将VR（UR）更新为VR（UX）=4，将SN=3<VR(UR)=4的包上传高层。综上所述，无论t-Reordering定时器是否运行，当接收到了乱序的包时，会尝试对希望接收到顺序包进行一次t-Reordering的等待，当该次定时超时后，如果后续才收到了希望接收到的顺序包则进行丢弃，这样的好处是传递到上层的包保证是顺序的（因为PDCP不对包的顺序进行纠偏）。当SN长度一定的前提下，t-Reordering设置较小容易造成无谓的丢包，设置较大，可以减少丢包，但是传递时延较长；反之，在t-Reordering设置一定的情况下，SN长度较小（5bit）相对而言更容易造成包的错传。

以下是一个实际的VoLTE主叫起呼的现网测试案例

可以看到基于QCI1的VoLTE话音承载，上下行均采用UM模式，SN的长度为10bit

  

这里t-Reordering设置为50ms,协议规定（36.331）该取值在0～200ms, 50ms相对比较适中。

随便举个UE侧上行RLC UM的例子

可以看到当前最后已发出的包是SN=32，并将VT（US）设置为33

张阳，英国布鲁内尔大学（Brunel Univ.）设计与工程学院电子与计算机工程博士，高级工程师，博士阶段主要进行LTE物理层、处理优化算法研究。主要从事TD-LTE/TD-SCDMA网络优化工作。曾参加中国移动无线网络优化技术高级培训，荣获优秀学员称号，参加中国移动LTE维护优化技能竞赛，荣获一等奖。长期关注跟踪一线实际优化工作，具有丰富的理论基础及实践经验。在国内外通信期刊发表学术论文数十篇，并合著有《TD-LTE无线网络优化与应用》一书。