1. 写在前面的话
诚如通信著名博客sharetechnote作者Jaeku Ryu在其LTE RLC笔记的开场白时说：
Personally to me, RLC layer is one of the trickest area to understand in very detail. At the beginning it seems to be simple, but as I getting deeper and deeper into this layer I get more and more confused. Another difficulties is that I don‘t find any books or other training material explaining very detail on this area, whereas you would find a lot of books and materials digging very deeply into other layer.
RLC初看觉得简单，因为协议一共也就33页，只有RRC的三十分之一，甚至比看起来更简单的PDCP协议还少了接近20页，但实际上要理解其各种细节并非易事，Jaeku Ryu提到一个重要原因是几乎没有书籍或资料详细讲解RLC. 但我发现还是有极少数书籍的RLC章节讲得很不错。另外我觉得这方面资料少并不是因为RLC专家不愿意写，而是很难从理论层面写得太详细，原因可能有几点：
1. RLC协议本身内容不多，单从理论上没法写太细
2. 理解RLC需要理解很多关联的概念和逻辑，这些概念和逻辑分布在RLC之外的领域，比如用户面，L2, RB, 逻辑信道，HARQ, MAC调度…
3. RLC真正难的部分不是理解协议，而是具体实现和处理现实中的复杂问题
因此要更深入理解RLC，一是要对用户面有比较清晰的总体认识(比如数据如何从QoS Flow一步步通过SDAP下发到空口)，二是要多动手，多处理具体问题。
若既没有详细解析RLC的书籍/资料，又没有实践机会(开发RLC和处理bug)，怎样的学习方式比较高效？我最初看LTE RLC协议亦是剪不断理还乱，因为状态变量(State Variables)太多，而且名字全然不具备启发性，比如AM接收变量VR(MR), VR(MS), VR(R), VR(X), VR(H), 光是看到这5个‘VR’就已晕头转向，勿论混杂这些变量(通常还结合几个定时器)的各种处理了！NR有所改善：变量名具备一定启发性了(比如，将LTE的VR(X)改成了RX_Next_Status_Trigger)，但是光看不动手，仍会被那些处理流程弄得一头雾水，因此我试图在阅读RLC协议时边看边根据协议处理流程在纸上画出对应的收发包实例，如下图，这样理解就稍微深一点：
2. Big Picture
在OTA消息中，我们见得较多的一个名词是RB – Radio Bearer(无线承载)，比如RRC Setup和RRC Reconfiguration消息里的SRB/DRB配置。如其名，RB用来在空口(Radio)承载(Bear)数据，凡是基站发往UE的数据(无论是RRC消息 - SRB数据，还是网络来的QoS flow映射到DRB的数据)都扔给RB，至于数据如何通过RB发送到UE，需要基站进行一系列处理，UE发给基站也一样。RB并非是一个实际的通道，而是对应于一套空口资源(RLC信道，逻辑信道，传输信道，物理信道，电磁波)和协议软件实体(PDCP, RLC, MAC, PHY)的抽象概念， 也就是说数据通过某个RB传输，实际上是先映射到逻辑信道(这里由于PDCP处理较简单，主要是头压缩和安全处理 - 加密和完整性保护，其与RB是一对一的映射关系，因此我们先忽略PDCP和RLC Channel，于后续PDCP笔记专门讲解)，而逻辑信道同样是抽象概念，需要进一步映射到传输信道，传输信道再映射到物理信道，最终通过电磁波发射出去。那RB的数据是直接扔给逻辑信道吗？当然不是，上面提到的一系列映射都要经过协议实体处理，其中用于处理RB到逻辑信道映射过程的实体就叫做 - RLC – Radio Link Control(无线链路控制)。如下图(38.300: Figure 6.1-1)，我们可以看到RLC在L2(SDAP+PDCP+RLC+MAC)架构中的位置：
3. RLC功能
从RLC全称Radio Link Control可以看出，其用于无线链路控制，主要是保证数据传输的可靠性(把错误率控制在一定范围)，其融合了OSI七层协议的数据链路层和传输层(TCP)的功能/机制(比如ARQ，滑动窗口等等)。
了解RLC的功能前，我们要先了解两个最最基本的概念SDU和PDU以及RLC三种传输模式(因为每个功能有其适用的mode).
1) SDU和PDU
在协议体系里，下层协议是为上层协议提供服务(service)的，因此凡是上层发过来的或者发往上层的数据都叫SDU(Service Data Unit)。而上层协议(Protocol)实体对数据进行处理后，通过下层协议提供的服务继续往后面发送，因此凡是发给下层或从下层收到的数据叫做PDU(Protocol Data Unit)，通过下图可以得到一个直观的认识：
2) 三种传输模式
TM - Transparent Mode
transparent, 顾名思义，就是透传，发送端不对RLC SDU做分段(segementation)操作，也不添加RLC Header，只是缓存数据，然后在MAC层通知传输机会时发送给底层，接收端收到数据后直接发给上层。
适合的逻辑信道：BCCH, DL/UL CCCH, PCCH, andSBCCH
UM - Unacknowledged Mode
无响应模式，类似于UDP，发送端可以对数据进行分段处理，但不需要接收端反馈接收状态。
适合的逻辑信道：DL/UL DTCH, SCCH, and STCH
AM - Acknowledged Mode
响应模式，接收端通过RLC status report反馈包接收状态，发送端根据status report决定是否重传数据。
适合的逻辑信道：DL/UL DCCH, DL/UL DTCH, SCCH,and STCH
3) RLC功能overview
如下是RLC各功能概览，各功能细节会穿插在后面系列笔记中：
- 添加RLC序列号(Sequence Numbering)
给上层发过来的每个SDU添加序列号并作为RLC PDU header的一部分，适用于AM和UM, 这个序列号独立于PDCP层的序列号。
- 纠错(Error Correction)
AM模式下，通过ARQ(自动重传请求)机制纠错，也就是基于接收端反馈的RLC status reports重传RLC PDU或PDU分段(segments)。
- 分段和重分段(Segmentation and Re-segmentation)
MAC根据调度的TB大小通知RLC可发送的PDU大小，当预处理(pre-processing, 这是NR对LTE的区别之一，会在下篇讲解)的RLC PDU或需要重传的PDU Segment大于MAC层指示的大小时，就需要对RLC PDU进行分段(适用AM和UM)或对PDU Segment重分段(适用AM)。
- 重组 SDU(Reassembly of SDU)
既然发送端有分段(segement)，那么接收端就要将这些分段重新组合成SDU才能发送给上层。
- 重复包检测(Duplicate Dectection)
如果在接收窗口内收到的PDU所包含的全部内容或部分内容之前已经收到过，那么就丢弃整个PDU或PDU中跟之前已收到的内容有重复的部分。
- RLC SDU丢弃(RLC SDU discard)
比如在reassembly window之外的SDU或者PDCP指示需要丢弃的SDU.
- RLC实体重建(RLC Re-establishment)
比如UE发送切换(handover)时。
- 协议错误侦测(Protocol Error Detection)
比如当ARQ重传次数达到最大值时。仅适用AM.
4. 与RB和逻辑信道的关系
一个RB对应一个逻辑信道，反之亦然。
一个RLC实体对应一个RB或逻辑信道，但反之不一定：
- TM和UM，由于发送和接收RLC实体是独立的，一个RB或逻辑信道可以对应两个RLC实体
- AM, 由于发送和接收在同一个RLC实体，一个RB或逻辑信道对应一个RLC实体
可以通过一个AM实例看一下：
----- clip ----
rlc-BearerToAddModList
{
{
logicalChannelIdentity 4, //一个逻辑信道
servedRadioBearer drb-Identity : 4, //一个RB
rlc-Config am : //一个传输模式为AM的实体
{
ul-AM-RLC
{
...
},
dl-AM-RLC
{
...
}
},
----- clip ----
————————————————
版权声明：本文为CSDN博主「yu_yuan_hong」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/travel_life/article/details/123867117
标签：SDU,逻辑,Overview,PDU,RLC,信道,RB,5G From： https://www.cnblogs.com/beilou310/p/16969449.html