之前或多或少有对PHY，MAC及PDCP部分进行了总结，现在开始的是NR RLC部分的学习笔记总结，RLC是很重要的一层，在实际UE问题处理中，常常会查看RLC的收发状况，而NR RLC对应38.322，整本spec不多(30多页)，最早2019年的时候就研究过，现在再温故知新下(也忘差不多了)…..
这篇就从大体功能的角度看下RLC，具体细节后面慢慢再说。先看下NR user plane DL协议架构，大概看下RLC的作用，如下图，许多sub layer与LTE类似，但是也有差异，NR 中QoS的处理就是差异之一，当连接到 5G 核心网后，SDAP 层会收到一个或多个QoS flow的配置，然后收到对应的IP packet。 而NSA场景，UE会连接到EPC的 user plane，这时候就不会用到 SDAP。NR中，不是所有的场景都会用到下图中的每一个功能，例如，加密就不会用于系统消息。 NR user plane UL协议架构与DL类似，但是或多或少也存在一些差异……
各层的功能简单总结如下。
SDAP：这个协议层是NR中新增的，处理负责将QoS flow映射到对应的DRB上及在DL和UL packet中对QoS flow ID进行marking。
PDCP： 执行 IP 报头压缩、加密、和完整性保护。 它还处理重传、按顺序传送和移交时删除重复内容。 对于DC场景，PDCP 还可以提供duplication功能，提高传输可靠性。
RLC：负责segment和重传处理。 RLC以RLC channel的形式向PDCP提供服务。 每个RLC channel配置一个 RLC entity， 与LTE相比，NR RLC不支持按顺序将数据传输到PDCP的功能，这种变化主要是从减少延迟方面考虑的。
MAC：处理逻辑信道的多路复用，HARQ重传，以及调度和调度相关的功能。 MAC 以逻辑信道的形式向 RLC 提供服务。
PHY ：处理编码/解码、调制/解调、多天线映射和其他典型的物理层功能。 物理层通过不同传输信道向 MAC 层提供服务。
下面就着重看下NR RLC。
而在5G系统中，为了满足不同的业务要求，符合业务传输的特征，RLC支持3种传输模式：TM、UM和AM模式。RLC的配置基于逻辑信道的粒度进行的，不依赖底层的SCS和传输时间间隔（Transmission Time Interval，TTI）的长度。RLC可以处理在逻辑信道配置的任意SCS和TTI长度等条件的数据分组。TM模式主要用于寻呼消息、系统信息广播以及SRB0信令的传输；其他SRB信令用AM模式传输；用于传输用户数据的DRB可以根据业务类型，采用AM模式或UM模式传输，例如voice DRB 一般会使用UM模式，降低时延。
RLC 的主要服务和功能与传输模式相关，包括：对PDCP PDUs的传输；独立于 PDCP 进行自己的序列编号(UM 和 AM)；AM可以通过ARQ进行纠错；AM和UM支持RLC SDU 的segmentation，AM还支持re-segmentation；AM和UM可以重新组装 SDU；AM支持duplicate detection；AM和UM可以对RLC SDU进行丢弃操作；RLC重建；AM支持Protocol error detection。
其中RLC的ARQ具有以下特点：(1)ARQ 会根据 RLC status reports对RLC SDU或 RLC SDU segments进行重传；(2)根据场景触发RLC status report 进行polling；(3)RLC receiver在检测到某些RLC SDU或 RLC SDU segements丢失后也可以触发RLC status report。
RLC entities
RLC 配置参数是通过RRC层信令带下来，通常包含在RRC setup及RRC Reconfig中。
RLC sub layer的功能是由 RLC entities执行。 gNB配置的 RLC entity会和UE侧的RLC entity 配对存在，例如gNB侧是UL发送RLC entity，UE侧对应的就是DL 接收RLC entity，反之亦然。 RLC entity和PDCP间会进行RLC SDUs的交互，同样RLC会通过底层和对端RLC 进行RLC PDUs交互。
如上图是所有协议层的DL数据流的例子，其中包含三个 IP packet，两个在一个RB x上，一个在另一个RB y。右侧的RLC SDU 被分段并在两个不同的TB中传输。SDAP将 IP packet映射到不同的RB； 在这个例子中IP数据包n和n+1被映射到RB x，IP数据包m被RB y。 通常来自或传递到更高协议层的data称为SDU，相应地来自或传递到较低协议层data称为PDU。 因此，PDCP的输出是一个PDCP PDU，等同于RLC SDU。
IP packet进入SDAP后增加了SDAP的header，生成了SDAP的PDU，此PDU是PDCP的SDU，经过PDCP的处理，增加了PDCP的header，生成了PDCP的PDU。而此PDU则是RLC的SDU，经过RLC的处理，增加了RLC的header，生成了RLC的PDU。右侧RB Y对应的RLC对PDCP的PDU进行了segment，生成了两个RLC的SDU。在MAC层对多个RB的RLC PDU进行处理，然后将多个MAC PDU放到同一个TB中进行传输。
RLC 协议在必要时会对PDCP PDU进行segment，并添加包含用于处理重传的序列号的 RLC header。 和LTE不同，NR RLC 不提供按顺序将数据包传送到PDCP的功能， 原因是重新排序机制会引起的额外延迟，延迟对需要极低延迟的服务不利。例如LTE RLC在进行按序传送时，除非所有先前的RLC SDU都已正确接收，否则 SDU无法转发到PDCP。 由于瞬时干扰突发，引起单个丢失的 SDU，会造成接收窗卡住，即使这些 SDU 对上层十分有用，这种情况在一段时间内会导致后续SDU不能及时向PDCP的传送。因而NR从RLC中移除按序传送有助于减少总体延迟，这样后面的数据包就不必像LTE一样等待之前丢失的数据包收到后，才能上传到PDCP，NR在收全对应SN的RLC SDU后就可以立即上传到PDCP。
但是如果需要按序传输，NR可以由 PDCP 层提供按顺序传输的功能。RLC PDU 转发到MAC 层后，MAC 层将多个RLC PDU 附加 MAC header后放在同一个传输块传输。如上图，MAC header是分布在 MAC PDU中的，这样 MAC header相关的某个 RLC PDU 会紧接在另一个RLC PDU之前。
这也是与LTE不同的地方，LTE会在RLC层会进行 concatenation操作，生成一个header，然后再传递到LTE MAC 层，而参照NR中的结构，NR RLC 不会进行concatenation，MAC PDU 可以“即时”组装，不需要对RLC进行concatenation，直接对RLC PDU生成对应的MAC header即可， 这样也会大大减少处理时间以及整体延迟。
RLC PDU分为RLC data PDU或RLC control PDU。 如果 RLC entity从PDCP 接收到 RLC SDU，这里是通过RLC和PDCP之间的单个 RLC信道接收，从接收到的RLC SDU形成RLC data PDU之后，RLC entity通过单个逻辑通道再将RLC data PDUs往MAC传。 如果RLC entity从MAC 接收 RLC data PDUs，这里也是通过单个逻辑信道接收，将接收到的 RLC data PDUs 形成 RLC SDU 之后，RLC entity再通过 single RLC 信道将 RLC SDU 传递给PDCP。 如果RLC与MAC 层进行的是RLC control PDUs的传输，要用和传输RLC data PDU 的相同逻辑信道进行。
RLC entity可以配置AM/TM/UM三种模式之一进行数据传输。 因此，根据 RLC entity配置传输模式，RLC entity分为 TM RLC entity、UM RLC entity或 AM RLC entity。
TM RLC entity被配置为transmitting TM RLC entity或receiving TM RLC entity。 transmitting TM RLC entity从PDCP 接收 RLC SDU，并通过MAC将 RLC PDU 发送到其对等 receiving TM RLC entity。 receiving TM RLC entity将 RLC SDU 传送到PDCP，并通过MAC从其对等传输 transmitting TM RLC entity接收RLC PDU。
UM RLC entity 和上面的TM RLC entity内容相同。
AM RLC entity由transmitting side和receiving side组成。 AM RLC entity的transmitting side从PDCP接收 RLC SDU，并通过MAC将 RLC PDU 发送到其对等 AM RLC entity。 AM RLC entity的receiving side将RLC SDU传送到PDCP，并通过MAC从其对等AM RLC entity接收RLC PDU。上图对应的就是RLC sub layer的三种传输模式的简图。
其实spec上面这段对于TM AM UM的描述的是大概过程，没有涉及细节，所以内容基本是一样的，多少有点重复废话。
RLC SDUs的大小可变，但是size需要是8 bits的倍数，所有 RLC entity types (TM、UM和AM RLC entity)都支持可变大小的 RLC SDUs。
每个RLC SDU无需等待来自 MAC的UL grant的通知，就可以进行RLC PDU的构造。如果UL grant不够发送生成的RLC PDU时，对于UM和AM RLC entity，可以将RLC SDU进行segment，根据来自MAC的ul grant将RLC SDU用2个或多个RLC PDUs进行传输；只有当MAC通知有UL grant时，RLC PDU才会提交给MAC。UE在生成多个MAC PDU时，要避免一个MAC PDU中包含过多的非连续RLC PDU的情况。
下面具体看下每种RLC entity具体功能的描述。
TM RLC entity
TM RLC entity可以通过BCCH、DL/UL CCCH、PCCH和SBCCH等逻辑信道发送或者接收的RLC PDUs；TM RLC entity发送或接收的RLC data PDU是TMD PDU。上图对应的是两个TM peer entity的模型，对应的就是开头TM模式主要用于寻呼消息、系统信息广播以及SRB0信令的传输的描述。
当transmitting TM RLC entity将RLC SDUs 构造成 TMD PDU时，不会对 RLC SDU进行分段；也不会在 TMD PDU 中包含任何 RLC headers，就是啥也不做，直接对RLC SDU进行转发。当receiving TM RLC entity接收到 TMD PDU 时，就会将 TMD PDU(RLC SDU)传送到PDCP。
UM RLC entity
UM RLC entity可以通过DL/UL DTCH、SCCH 和 STCH等逻辑信道发送/接收 RLC PDU，SCCH和STCH对应V2X，到手机这方面对应的就是DTCH，具体的可以是voice 或video等业务；UM RLC entity发送和接收的RLC data PDU对应的是UMD PDU。
一个 UMD PDU可以包含一个完整的RLC SDU或一个RLC SDU segement。上图对应的是两个UM peer entity的模型。
Transmitting UM RLC entity会为每个 RLC SDU生成UMD PDU；在UMD PDU中应该包含相关的 RLC headers。 当MAC通知有UL grant时，transmitting UM RLC entity应根据需要对 RLC SDU 进行segment，同时也需要更新 RLC headers，以便相应的UMD PDU可以满足RLC PDU的对应UL grant的大小。
当一个receiving UM RLC entity接收到 UMD PDU 时，RLC需要检测MAC层的 RLC SDU segment是否有丢失；根据接收到的 UMD PDU进行RLC SDU的重组，并在适当时刻将 RLC SDU传送到PDCP；当MAC层丢失属于特定RLC SDU的UMD PDU而无法重组时，就要对这样的UMD PDUs做discard处理，UM更注重实时性，比如voice业务，丢掉一两个包不会对voice有特别大的影响，当然前提是不会大量丢包，出现大量丢包的现象，肯定是传输上出现问题，需要具体问题具体分析。
AM RLC entity
AM RLC entity可以通过DL/UL DCCH、DL/UL DTCH、SCCH 和 STCH逻辑信道收发RLC PDU，AM RLC entity发送和接收的RLC data PDU就是AMD PDU；一个AMD PDU包含一个完整的RLC SDU 或一个 RLC SDU segment。
AM RLC entity还可以收发RLC control PDU即STATUS PDU。
AM RLC entity的transmitting side会为每个 RLC SDU 生成 AMD PDUs。 当MAC通知有UL grant时，transmitting AM RLC entity会在需要时对 RLC SDU 进行分段，也要根据需要更新 RLC 标头，以便相应的AMD PDU可以满足RLC PDU的对应UL grant的大小。
AM RLC entity的transmitting side支持通过ARQ 重传 RLC SDU 或 RLC SDU segment，如果要重传的RLC SDU 或 RLC SDU segment(包括 RLC header)大于MAC通知的UL grant size时，AM RLC entity要将RLC SDU 或RLC SDU segment再重新分段，而且重新分割的次数不受限制。
当AM RLC entity的transmitting side要将RLC SDU 或 RLC SDU segment生成AMD PDU时，也应该在AMD PDU中包含相关的RLC header。
当 AM RLC entity的receiving side接收到 AMD PDU 时，就要检测是否有重复接收到相同的AMD PDU，如果有就丢弃重复的AMD PDU；还要检测MAC的AMD PDU丢失并请求其对等AM RLC entity进行重传；还要将收到的 AMD PDU 进行 RLC SDU的重组，然后在满足条件后将RLC SDU传送到PDCP。
Services
RLC可以向PDCP提供TM/UM/AM等方式的数据传输，其中AM传输时还包括PDCP PDU成功传送的指示。
RLC也可以通过MAC进行数据传输；MAC在有UL grant时，会通知RLC并告知对应的UL grant大小，以便RLC确定是否进行segment操作。
最后RLC 支持的功能总结如下：RLC 可以传输PDCP PDU；在AM传输时，可以通过 ARQ 进行纠错；还会在UM和AM场景进行RLC SDU 的分段和重组；AM传输场景，还能对RLC SDU segment进行re-segmentation，也要进行duplicate detection，有重复AMD PDU要做discard处理，还要进行Protocol error detection；UM传输场景，也可以进行RLC SDU discard的操作；还需要进行RLC re-establishment。
上述功能具体怎么做，下一篇开始再慢慢展开慢慢说。