注意：本章视频讲解部分已经更新为课程，发布在B站的课堂模块。后续的其他章节的课程也大多数以这种形式正式地和集中地在课堂发布，请大家支持。
本章5G RLC层课程全名是：网页链接。课程链接：
第十四章 5G RLC层用户面数据流程详解
课程导引部分视频：
数据在PDCP之上都经历了些什么？
数据在RLC的上面协议层都经历了些什么？
为啥叫RLC Radio Link Control？
RLC层到底要为数据在空中接口传输做哪些贡献？
是否考虑到：
· 对于上层PDCP层更低协议层需要做的那些流程
· QoS，不同DRB和SRB
· 更低一层的可靠性传输——ARQ
· 数据缓存
· 流控
· 数据分段级联及顺序，是否需要reordering
· 是否需要重建与恢复
· ……
Figure 4.2.2-1: PDCP layer, functional view
14.1 数据到达RLC层实体
14.1.1 RLC的实体与实体的建立
RLC Entity （包含只承载某些控制面信息的TM实体）:
在 5G 中，RLC实体通常与给定用户的特定 DRB相关联。 每个DRB代表一个用于具有特定特征的数据通信的逻辑通道，例如QoS要求和安全参数。
正常情况下，5G RLC层中的RLC实体一次处理单个DRB的AM或UM数据。
14.1.2用户数据从PDCP实体分别到达RLC实体
14.1.1.1 DRB的建立及区分
依据每一个PDCP的PDU所属的DRB，将其送到相对应的RLC实体当中。
如何区分和标识属于不同DRB的PDCP的PDU或RLC的SDU呢？
在5G F1-U接口中，与用户DRB关联的每个GTP-U隧道在上行链路和下行链路方向上具有相同的TEID，以确保正确的双向数据传输和路由。
14.1.1.2 为什么需要多个SRB和多个DRB
在5G PDU Session和RRC建立过程中，使用多个SRB，有时甚至使用多个DRB可确保各类数据的高效可靠通信，同时每一个SRB或DRB在层二中可能具有一个单独的entity按照特定的参数设置单独地处理。
14.1.3 RLC实体（Entity）中的Buffer以及流控的考虑
RLC Buffer
DDDS
RLC SDU的discard
14.2 RLC层的SN编号
14.2.1 为什么在PDCP SN基础上还需要重新编号
RLC层的SN主要作用就是用来在接收端对分段进行重组，以及实现ARQ和重传。
分段（segmentation）之后要进行重新编号，但是对于AM和UM的编号方式是不同的：
一个跟4G不同的方式，这里分段在RLC层进行，但是级联（Concatenation）却是在MAC层实现
主要原因是针对5G的低延时业务如uRLLC需要更低的时延，放到MAC层。涉及到复杂的讨论，不做深究，但是明确一点是MAC层的Concatenation更接近于物理层，在网络侧，可以直接与MAC层的复用和TB生成结合在一起，减少跟RLC层与此相关的信息传递的开销，具有实时性和硬件处理优势。
14.2.2 针对不同的SRB和DRB单独编号（没有优先级之分）
因为是不同的entity，先到先送，优先级要在MAC层的priority模块进行排序。
14.2.3 RLC PDU SN编号的策略
14.2.3.1 TM
不增加任何字段，不做任何处理，但是存在TMD的RLC实体和buffer，应该是做流控的需要。（相对而言，TMD根本不经过PDCP这一层）
14.2.3.2 UM
UM模式，同一个原RLC的SDU拆分成一个或多个SDU，SN号相同
对于不分段的UM SDU，不加SN
14.2.3.3 AM
AM模式，不论分段或不分段，都按照RLC SDU为单位进行编号。也就是说，不分段一个SN，分段的SDU的每一个拆分后的小段SN相同；
14.2.3.4 SN长度的考虑
AM用12或18bit
UM用6（sidelink等场景）或12bit
14.3 RLC PDU在发送阶段的处理流程
14.3.1 RLC层数据量的匹配和流控
14.3.1.1 负责向PDCP层提供数据量信息
14.3.1.2 计算来自于MAC层的数据资源信息
14.3.1.3 RLC层的流控
14.3.2 TM数据
针对BCCH, DL/UL CCCH, PCCH
BCCH和PCCH可看成是公共信道，不需要在PDU session建立和RRC建立之后才能出现，不需要对应的针对于特定用户实体来。但是有对应的RLC TM实体，面向公共用户。
没有RLC SN （也没有PDCP SN）
14.3.3 UM数据
14.3.3.1 发送端RLC UMD SDU数据特征
一般场景只能是DTCH，包括上行和下行。但是DTCH当然也可以是AM， 不可能是TM。
典型场景就是，VoNR，DTCH分为普通的数据业务（比如DRB1，UM或AM），语音数据（DRB2, UM）和VoNR的SIP消息数据（DRB3, AM）。
UM模式不需要反馈确认和重传，在发送端不存在超时的情况，不需要考虑PDU的优先级问题，所以相对简单。
14.3.3.2 接收PDCP PDU数据并存入buffer
PDCP entity到RLC entity的对应
PDCP PDU也就是RLC SDU，目的是要提交到MAC层，变成RLC PDU或者叫做RLC data PDU （相对于Control PDU而言）
受到DDDS的影响
14.3.3.3 RLC UM SDU的分段 (segmentation)与SN编号
来自与下层（MAC）的分段通知，MAC的调度结果。
不需要重分段，因为没有重传。
SN针对RLC UM PDU长度一般就使用12bit。
分段的与不分段的处理方式不同。
14.3.4 AM数据
14.3.4.1 发送端RLC AMD数据的整体过程
典型的逻辑信道或RB是DTCH和DCCH，属于这些类型的都属于AMD。用户信令相对于用户数据来说始终是具有更高优先级的。
发送端有可能需要分段，在接收端需要把需要分段的PDU重新组合成原来的RLC SDU。重组是这些SN编号的主要目的。
分段和重组是分别在发送端和接收端的相对应的过程。
分段的目的：是针对底层资源的分配可能不够的方案。有分段的可能，就还有级联的可能，但是级联需要下移到MAC层来实现。
针对不需要进行分段的RLC SDU, 在接收端也可以叫做重组。
14.3.4.2 接收到PDCP AM PDU数据并存入buffer
PDCP entity到RLC entity的对应
PDCP PDU也就是RLC SDU，目的是要提交到MAC层，变成RLC PDU或者叫做RLC data PDU ，或者叫做AMD，（相对于Control PDU而言）
受到DDDS的影响
一个关于AM模式的案例
14.3.4.3 RLC AM SDU的分段与SN编号
来自与下层（MAC）的分段通知，MAC的调度结果。
对于某个RLC PDU有可能发生重传和重分段。
SN针对RLC UM PDU长度一般就使用12bit或者18bit，跟PDCP SN类似，但分别进行编号。
14.3.4.4 AM PDU编号的具体流程
14.3.4.6 RLC的PDU的ARQ及重传处理
14.3.4.6.1 检测来自对端的状态报告
对端在一定的条件下对相关的PDU进行判决和反馈。（在AM接收端部分介绍）
14.3.4.6.2 Polling的作用和规则
考虑到重传和RLC ARQ， 在RLC PDU最终形成之前，在某些PDU的头的字段中需要添加相应的信息，即P字段
14.3.4.6.3 重传
NACK反馈可能随时都能到来，一旦到来，由此触发的重传相对于新数据的初传来说具有更高的优先级。但是，并不是所有的NACK都可以得到重传，重传受到重传窗口、最大重传次数等参数的约束。
14.4 RLC PDU在接收端的处理流程
14.4.1 RLC接收端的 TM 数据
接收端不做任何处理，但是仍然有接收端的RLC实体，只是不需要buffer。而发送端有buffer。
14.4.2 RLC接收端UM数据
14.4.2.1 总体目标和一般规则
总体目标就是在接收端的buffer中对于在发送端做过分段的PDU进行重组，并尽可能按原来顺序完整递交到PDCP层。如果出现乱序的情况，在一定的PDU窗口范围内和一定的重组定时器的时间周期内也达到重组的目的，万一出现严重乱序或丢包的情况，则考虑丢弃，从而确保下面的其他PDU能够继续进行重组的处理流程。
14.4.2.2 没分段的RLC PDU的处理
首先通过判断该PDU的类型，知道了其不包含SN，也就是没进行分段。然后立刻递交到上层，PDCP层，并不需要先存到buffer中。理论上在RLC实体中没有延迟。
14.4.2.3 经过了分段的RLC PDU的处理
· - 考虑重组窗口及超范围丢弃discard
· - 重组的过程
具体的重组过程是按照PDU进入buffer中的先后顺序在buffer中进行的。
· - 重组定时器t-Reassembly超时的处理
当t-Reassembly超时，意味着本次重组没完成（大概率是因为该PDU的某个分段在规定的时间内没有到来），但是时间已经超过了定义的时间范围了。那么，将放弃此次重组，转入下一个PDU的重组流程。
14.4.3 RLC接收端AM数据
14.4.3.1 总体目标、规则和流程（14.3.4.1节已经介绍）
先处理ARQ的结果评估和处理，再进行重组流程，或者说ARQ评估和重组流程是同步进行的。
14.4.3.2 RLC AMD或Control PDU到达RLC层的有效性评估
接收端每一个RLC AM PDU的到来都要解析其头，获得相应的信息，比如SN、P等字段。
14.4.3.3 进入buffer中的RLC的PDU的处理
进入buffer中的PDU并不表示就不存在丢失和乱序的情况，只能表示这些PDU都是在接收窗之内。所有后续在buffer中的PDU就要经过对RLC层的乱序和丢包的检测和调整。
14.4.3.3.1 针对乱序和有分段的AM PDU的处理举例
14.4.3.3.2 针对丢包和t-Reassembly超时的情况的AM PDU的处理举例
14.4.3.3.3 STATUS report的生成
14.4.3.3.4 STATUS report的递交间隔需要进行限制——t-StatusProhibit
也就是说，在t-StatusProhibit运行的时候是不能发送新的STATUS report的，直到超时，才有可能向底层递送。
14.4.3.4 RLC层的ARQ于MAC层的HARQ的简单对比
RLC层的ARQ依靠检测RLC的PDU的SN号来判断在接收端的PDU的乱序和丢包，从而通过STATUS report这样的Control PDU（业务信道）来进行反馈；采用polling机制来通过一定的间隔进行类似于周期性的反馈，这样可以避免频繁的反馈报告的开销。
14.5 RLC层的相关参数汇总
14.5.1 内部临时参数
TX_Next_Ack
TX_Next
POLL_SN
PDU_WITHOUT_POLL
BYTE_WITHOUT_POLL
RETX_COUNT
RX_Next
RX_Next_Status_Trigger
RX_Highest_Status
RX_Next_Highest
TX_Next
RX_Next_Reassembly
RX_Timer_Trigger
RX_Next_Highest
14.5.2 可配置的常量和变量
AM_Window_Size
UM_Window_Size
t-PollRetransmit
t-Reassembly
t-StatusProhibit
maxRetxThreshold
pollPDU
pollByte
14.6 RLC层必要性探讨
14.6.1 对TM data而言直接忽略
14.6.2 对UM data而言主要时进行分段重组和流控
14.6.3 对AM data而言需要进行分段重组、流控和ARQ
14.6.3.1 分段是因为从底层来的资源状态信息
14.6.3.2 流控也是因为底层来的资源状态信息
14.6.3.3 相对于MAC层的HARQ，ARQ的必要性
1.RLC层的ARQ是对HARQ的弥补
HARQ的结果也会有失败的情况
2.HARQ快速重传和纠错
包括FEC
而ARQ是个polling机制，重传时延大，而且对数据本身不错错误检测
14.7 RLC层其他话题预告
RLC重建和恢复
切换时RLC层的关联流程
RLF相关的RLC流程
RRC重建的RLC流程
