（一）、控制面

● 层三

• NAS：会话管理、用户管理、安全管理、计费。
• RRC：系统消息、准入控制、安全管理、测量与上报、切换和移动性、NAS消息传输、无线资源管理。

● 层二

对不同的层三数据进行区分标识，并提供不同的服务

• PDCP（分组数据汇聚协议层）：传输用户面和控制面数据、维护PDCP的SN号、路由和重复（双连接场景）、加密/解密和完整性保护、重排序、支持乱序递交、 重复丢弃、ROHC（用户面）。
• RLC（无线链路控制层）：检错、纠错ARQ（AM实体）；分段重组（UM实体和AM实体）；重分段（AM实体）；重复包检测（AM实体）。
• MAC（媒体接入层）：逻辑信道和传输信道之间的映射、复用/解复用、调度、HARQ、逻辑信道优先级设置。

● 层一

物理层为高层的数据提供无线资源及物理层的处理

PHY（物理层）

• 场景编码：控制信道Polar码，业务信道LDPC码；
• 调制：QPSK、16QAM、64QAM、256QAM；
• massiveMIMO：详见第1部分-massiveMIMO概述

（二）、用户面

● 层二增加SDAP层(Service Data Adaptation Protocol,服务数据适配协议)

在SA组网下，4G网络中的无线承载的概念依然被沿用，但5G核心网为了使业务实现更加的精细化，5G的基本业务的传输单位从4G时代承载的概念细化到以QoS Flow。SDAP协议栈功能就是完成无线侧的承载（DRB）与5GC中的QoSFlow进行映射

RRC（Radio Resource Control，无线资源控制）层，是整个无线通信协议栈接入层的消息配置中心及控制中心，其重要性不言而喻。RRC层的主要作用是给其下层（PDCP,RLC,MAC,PHY）控制和配置所有无线资源，从而可以使UE与基站之间进行通信。

（一）、功能

RRC层位于PDCP层之上，功能和LTE基本一致

• 系统消息
• 准入控制
• 安全管理
• 测量与上报
• 切换和移动性
• NAS消息传输
• 无限资源管理

（二）、RRC状态

● Connected/IDEL

LTE时仅有这两个状态，用户要传数据必须在RRC_C0NNECTED状态，因为该状态下各个节点之间的通道都需要打通；IDEL状态是与基站的资源（DRB承载、S1承载）都要释放，而核心网资源保留。两种状态通过寻呼和RRC释放转换。5G两种状态与LTE一致。

● Inactive

相对于LTE，NR新增了Inactive状态。在该状态下UE存储AS上下文信息，监听寻呼以及执行小区重选流程。在RRC Inactive状态下，UE和gNB只会维持RRC和PDCP层的链接，gNB和UE会释放C-RNTI上下文；为了标识用户，gNB和UE侧会新建立I-RNTI用于用户的标识。仅释放空口资源，简化了RRC状态转换的流程，节省了用户返回链接态的时延，减少了信令开销，但现网尚未启用。

（三）、定义RNA（RAN-Based Notification Area）

RNA可以覆盖一个基站或者多个基站，但一定要在核心网配置的注册区范围内 当UE的RNA定时器超时或者UE移动出了RNA范围时，UE都要发起RANU（RAN-based notification area update）流程

关于如何配置RNA有几种不同的选择：

1. -小区列表：
   1. –gNB给UE提供一个明确的小区列表作为RNA。
2. -RAN area列表：
   1. –gNB给UE提供一个RAN area ID列表作为RNA，这里提供的RAN area是CN Tracking Area的一个子集或者等于CN Tracking Area，一个RAN area对应一个RAN area ID，一个RAN area由TAI和一个可选的RAN area Code组成。
   2. –一个小区会在其系统消息广播它的RAN area ID。 参考：TS23.501、TS38.413

● 当UE处于RRC_INACTIVE时，如果最后一个服务gNB收到来自UPF的下行数据或者来自AMF的下行信令，则该gNB在RNA的所有小区寻呼UE，如果RNA的小区属于邻gNB的，则通过Xn口给对应的邻gNB发送XnAP-RAN-Paging消息。如果RAN寻呼失败，则【见于TS23.501 5.3.3.2.5】：

• 如果NG-RAN有NAS PDU要发给UE，则RAN节点应该发起AN Release流程释放UE的N2口连接，将UE的CM状态迁移到CM_IDLE状态。
• 如果NG-RAN仅仅只有用户面数据要发送给UE，则NG-RAN节点可以继续保留N2连接或者发起AN Release流程释放N2口连接，如何选择取决于NG-RAN的本地配置。
• 注：在RAN寻呼失败时触发RAN寻呼的用户面数据包可能会丢失。

● AMF给NG-RAN提供RRC Inactive Assistance Information，以供NG-RAN用于决定UE是否可以进入RRC_INACTIVE状态；这个RRC Inactive Assistance Information信息包括：配置给UE的注册区、UE特定的DRX、周期注册定时器、MICO指示、UE id index值等。

● RNA更新流程

● UE触发的RNA更新过程，包括在Xn接口上的上下文检索。这个过程可能会在UE移动出所配置的RNA时触发，或者周期性地触发。

1. UE从RRC_INACTIVE状态恢复，提供由最后服务的gNB分配的I-RNTI和适当的原因值，例如RNA更新。

2. 如果gNB能够解析I-RNTI中包含的gNB标识，则请求最后服务的gNB提供UE上下文，提供步骤1中接收到的原因值。

3. 最后服务的gNB可以提供UE上下文(如下所述)。另外,最后服务gNB可能决定把问题转移到RRC_IDLE(且程序遵循步骤3和图9.2.2.5-3之后),或者如果问题仍在前面配置的RNA,使问题过去服务上下文gNB和保持问题RRC_INACTIVE(且程序遵循步骤3和图9.2.2.5-2之后)。

4. gNB可以将UE转移到RRC_CONNECTED状态，或者使UE重回RRC_IDLE态(这种情况下，gNB发送一条RRCRelease消息)，或者使UE返回RRC_INACTIVE，如下假定。

5. 如果要防止在最后服务gNB中缓冲的下行用户数据的丢失，则接入的gNB给最后服务gNB提供下行数据转发地址

6/7. gNB进行路径切换（向服务AMF发路径切换请求消息，AMF回复路径切换响应消息 ）

8. gNB通过发送带有挂起指示的RRCRelease来使终端处于RRC_INACTIVE状态

9. 通知最后服务的gNB释放UE上下文

● 当UE仍然在所配置的RNA，并且最后服务的gNB判定不重新定位UE上下文，并保持UE在RRC_INACTIVE的情况下的RNA更新过程

1. UE从RRC_INACTIVE状态恢复，提供由最后服务的gNB分配的I-RNTI和适当的原因值，例如RNA更新。

2. 如果gNB能够解析I-RNTI中包含的gNB标识，则请求最后服务的gNB提供UE上下文，提供步骤1中接收到的原因值。

3. 最后提供服务的gNB存储接收到的用于下次尝试恢复的消息(例如与要恢复小区相关的C-RNTI和PCI)，并以检索UE上下文失败消息(包括封装的RRCRelease消息)响应gNB。RRCRelease消息包括暂停指示。

4. gNB将RRCRelease消息转发到UE。

● 当最后服务的gNB决定移动终端到RRC_IDLE的情况下的RNA更新过程

1. UE从RRC_INACTIVE状态恢复，提供由最后服务的gNB分配的I-RNTI和适当的原因值，例如RNA域更新。

2. 如果gNB能够解析I-RNTI中包含的gNB标识，则请求最后服务的gNB提供UE上下文，提供步骤1中接收到的原因值。

3. 最后服务的gNB提供一条RRC Release消息，使UE转换到RRC_IDLE状态，而不提供UE上下文。

4. 最后服务的gNB删除UE上下文。

5. gNB发送RRC Release消息，触发转换到RRC_IDLE状态。

（四）、状态转换

RRC_CONNECTED 和 RRC_INACTIVE可以互相转换 ；RRC_CONNECTED 和 RRC_IDLE可以互相转换 ；RRC_INACTIVE 只能单向释放资源转换到RRC_IDLE

参考：TS38.300、TS38.331

● RRC_CONNECTED to RRC_INACTIVE

• 通过定时器超时触发（T380）

● RRC_INACTIVE to RRC_IDLE

• 通过定时器超时触发（一般是1500s）

● RRC_INACTIVE to RRC_CONNECTED

• UE发起：UE上下文检索成功状态下：UE触发从RRC_INACTIVE到RRC_CONNECTED的转换

1.UE从RRC_INACTIVE恢复，提供由最后服务gNB分配的I-RNTI

2.如果能够解析I-RNTI中包含的gNB身份，则gNB请求最后服务gNB提供UE上下文数据

3.最后服务gNB提供UE上下文数据

4/5.gNB完成RRC连接的恢复 注意:如果授权允许，用户数据也可以在步骤5中发送

6.如果要防止在最后服务gNB中缓冲的下行用户数据的丢失，则接入的gNB给最后服务gNB提供下行数据转发地址

7/8.gNB执行路径切换（向服务AMF发路径切换请求消息,AMF回复路径切换响应消息 ）

9.通知最后服务gNB释放UE的资源

• UE发起：UE上下文检索失败状态下：UE触发从RRC_INACTIVE到RRC_CONNECTED的转换

\1. UE从RRC_INACTIVE恢复，提供I-RNTI，由最后服务的gNB分配。

\2. 如果gNB能够解析I-RNTI中包含的gNB标识，就请求最后服务的gNB提供UE上下文数据。

\3. 最后一个服务的gNB无法检索或验证终端上下文数据。

\4. 最后一次服务的gNB向gNB返回失败信息。

\5. gNB执行回退，通过发送RRCSetup来建立新的RRC连接。

\6. 建立新的RRC Connection。

• 网络拒绝：终端试图从RRC_INACTIVE恢复连接时，网络拒绝的情况

\1. UE尝试从RRC_INACTIVE恢复连接。

\2. gNB无法处理这个流程，例如由于拥塞。

\3. gNB发送RRCReject(带有等待时间信息)来保持UE处于RRC_INACTIVE状态。

• 网络发起：网络触发的从RRC_INACTIVE到RRC_CONNECTED的转换

1.发生RAN寻呼触发事件（收到下行用户面数据，来自5GC的下行信令等） 2.触发RAN寻呼，寻呼范围是RNA 3.使用 I-RNTI寻呼UE 4.如果UE被寻呼到，则后续流程同上面的“UE发起：UE触发从RRC_INACTIVE到RRC_CONNECTED的转换”

(Service Data Adaptation Protocol,服务数据适配协议层)属于层二，只存在于用户面，位于PDCP层以上，直接承载IP数据包。 负责QoS流与DRB（数据无线承载）之间的映射 为数据包添加QFI（QoS flow ID）标识

（一）、承载

● 4G基于EPS承载

● 特点：

• QoS控制的基本粒度是EPS承载(Bearer)；
• 需要通过建立多个专用承载为UE提供具有不同QoS保障的业务。

● 局限：

• LTE QoS机制更适用于运营商内部应用；
• 基于承载的QoS管理机制粒度较粗，无法实现业务流粒度的QoS控制；
• 承载建立信令开销大、较慢，无法跟踪TCP session变化。

● 5G承载基于QoS架构：

5GC会为每个UE建立一个或多个PDU（协议数据单元）会话（PDU session），PDU会话可能会建立一个或多个QoS流，NG-RAN会为拥有不同需求的QoS流建立不同的DRB，或将属于同一PDU会话的多个QoS流映射到同一个DRB上

● 5G QoS模型基于QoS流，QoS流是PDU会话内区分QoS差异的最佳粒度，并且由QoS流ID（QFI）唯一标记，每个QoS流都把其相关联的QoS属性进行集合。

● 一个QoS规则包含：关联的QoS流的QFI、数据包过滤器集（一个过滤器列表）、优先级。一个QoS流可以有多个QoS规则。

● UE和UPF（用户平面功能）通过Packet Filter Set将业务和QoS流关联，RAN侧将QoS流映射到DRB上，来确保服务的质量

● 5G QoS 架构只用于SA组网

● 一个QoS流的QoS配置包含的QoS参数如下：

• 每条GBR QoS流的QoS配置可能还会包含：指示控制、最大丢包率。
• 每条GBR QoS流的QoS配置还会包含参数：保证流比特率(GFBR)、最大流比特率(MFBR)、AMBR（Aggregate Maximum Bit Rate，用来钳制Non GBR总带宽）。
• 每条Non-GBR QoS流的QoS配置可能还会包含参数：反射QoS属性（RQA）。
• 每条QoS流的QoS配置都会包含的QoS参数：5QI（定义QoS等级：时延、误块、优先级）、ARP。

（二）、SDAP层处理流程

是否添加SDAP头取决于UE上行的QoS流的映射方法，如果采用反射式映射，则gNB必须添加SDAP头，用于标识该数据包的QoS流。若果采用基于配置的映射，则gNB无需添加SDAP包头

数据分流的节点；Cloud RAN中CU,DU分离的节点

（一）、功能

● LTE原有

• 传输用户面和控制面数据
• 维护PDCP的SN号
• 加密/解密和完整性保护（5G：用户面和控制面；4G：仅控制面 ）
• 重复丢弃
• RoHC头压缩（用户面，需基站和UE均支持）

● NR新增

• 路由和重复（双连接场景时）
• 重排序（从RLC层移至PDCP层）
• 支持乱序递交

（二）、参数

● 在RoHC的框架下，针对不同协议的数据流，有不同的头部压缩算法。5G RFC定义了如下一些Profile用于RoHC压缩

● RoHC（RObust Header Compression)是一种专为无限连路设计的数据包头压缩机制，以适应无线链路高误码率和长环回时间的链路特性。

• 可靠性高：由于RoHC提供了反馈机制，因此它在高误码高时延东无线链路中具有更高的可靠性
• 压缩效率高：最小可将包头压缩成1个字节

● 安全流程算法

• NIA0/NEA0：不进行完整性保护
• 128-NIA1/NEA1：128-bit SNOW 3G 欧洲
• 128-NIA2/NEA2：128-bit AES 美国
• 128-NIA3/NEA3：128-bit ZUC 中国

位于PDCP层以下 实体分为TM实体、UM实体、AM实体，AM数据收发共用一个实体，UM和TM收发实体分开 不同于LTE，NR RLC层组装RLC层PDU时，不需要底层MAC通知是否有发送机会，可先行封装PDU包，RLC也没有串联功能（下移到MAC层），但RLC PDU要真正发送出去同样需要等待MAC层指示

（一）、实体

• TM：透传，不做任何处理
• AM：确认，需要ACK/NACK
• UM：非确认，没有纠错机制，时延低（VoIP业务）

（二）、功能

• 检错、纠错ARQ（AM）
• 分段重组（UM,AM）
• 重分段（AM）
• 重复包检测（AM）
• 取消了串联功能

● 六、MAC层

MAC层用于逻辑信道到传输信道的映射 UE和基站侧都有MAC层实体,但存在DC（双连接）时，终端则会存在多个MAC实体

● 调度

关键功能

● UE调度请求

• PRACH：当手机空口IDEL态
• SR-PUCCH：RRC链接还在，只是没有上行资源

● gNB授权

● UE状态报告

● gNB上下行调度PDCCH

● UE解时频资源位置，数据传输，HARQ

● 逻辑信道和传输信道之间的映射（信道的复用和解复用）

● HARQ控制

• 同步HARQ：一个HARQ进程发生在固定的时刻，接收端预先知道重传的时刻。
• 异步HARQ：一个HARQ进程可以发生在任何时刻，接收端预先不知道重传的时刻
• 根据重传的数据特征是否发生变化（重传的MCS与初始的一致为非自适应，不一样则为自适应），可以分为自适应和非自适应。目前NR上下行全部采用异步自适应重传。
• （1）上行采用异步自适应的HARQ,基站侧不需要反馈ACK/NACK,所以5G取消了PHICH,节省了信道资源。在下次调度时，通过NDI（新老数据指示，0为重传，1为初传）字段，间接通知UE上行数据解调是否成功。

• （2）下行采用异步自适应的HARQ，需要指示UE反馈ACK/NACK的时域位置

● 逻辑信道优先级控制

（一）、物理层处理流程

物理层是空口协议栈最复杂的一层，如图所示的是物理层的典型流程，但不同信道的处理过程会有所变化。

• TB（Transport Block，传输块）：1个TB包含1个MAC PDU的数据块
• CW（Code Word，码字）：首先对每个TB添加CRC，然后进行码块分段生成若干CB（Code Block，码块），对每个码块增加CRC、信道编码、速率匹配之后，得到码字

• 层：也就是流，码字通过层映射到不同的流上，实现串行到并行的转换。流越多，速率就会越高。
• 调制：更高阶的调制方式使每符号携带的比特数更大，从而实现更高的传输速率。

• 天线端口：天线的逻辑端口，每个端口号上有自己独立的DMRS信号。取代了LTE中CRS参考信号，节省了功率的开销，缓解了MOD 3干扰。
• 编码：eMBB场景，控制信道使用Polar码编码，业务信道使用LDPC码编码
• 层映射：把码字映射到多个层并行发送的过程
• 预编码：经过加权，使数据流映射到天线端口
• 波束：各层数据通过赋型加权后映射到天线上发送，在权值的作用下，波束指向UE。波束的个数与流的个数相同。

（二）、准共址（QCL,Quasi Co-Location)

● 功能：5G数据通过波束的方式发送，每个信道在空口的波束上如何发送写一种没有定义，终端通过两个信号的QCL关系可以从某已知信号的传播特征中推导出未知信号的传播特征，进而提高终端对未知信道的解调能力。

● QCL类型：由于不同信号的波束发送方式不同，特性可能存在差异，所以有QCL类型之分。