注意：本章视频讲解部分已经更新为课程，发布在B站的课堂模块。后续的其他章节的课程也大多数以这种形式正式地和集中地在课堂发布，请大家支持。
本章5G PDCP层课程全名是：网页链接。课程链接：
第十三章 用户数据到达PDCP层
课程导引部分视频：
数据在PDCP之上都经历了些什么？
Figure 6.2.2.2-1: DL SDAP Data PDU format with SDAP header
为啥叫PDCP-Packet Data Convergence Protocol？
PDCP层到底要为数据在空中接口传输做哪些贡献？
是否考虑到：
· QoS
· 数据缓存
· 流控
· 数据顺序
· 数据到达确认
· 安全性
· 重建与恢复
· ……
Figure 4.2.2-1: PDCP layer, functional view
13.1 数据到达PDCP实体
13.1.1 SDAP到PDCP的信息传达
数据到达PDCP之后，由于没有了隐藏了QF概念了，每个PDCP实体就对应于一个DRB，不管这个DRB是来自与同一个或不同的PDU session。
但是SDAP中的entity对应于每个PDU session， 就是说，如果某个用户有多个PDU Session的话，就会有多个SDAP实体。 另外，每个PDU session一般也对应N3接口的一个GTP-U的隧道，用不同的TEID来标识。而同一个TEID可以对应多个QFI不同的QF。
13.1.2 PDCP实体（Entity）的映射
DRB和QFI：SDAP的PDU中只有QFI，并没有DRB ID，如何体现SDAP的贴标的作用？
1. SDAP和PDCP之间没有开放接口，但却定义了标准的SAP和PDU结构，就是说PDCP的SDU即SDAP的PDU中仅仅携带QFI；
2. 实际上在RRC建立或重建或承载修改的过程中，就定义好了在PDCP层QFI和DRB的对应关系。逻辑上，PDCP的所有SDU都有一个隐形的DRB的标签，也就是说都携带了相应的DRB的信息；这个信息没有直接包含在PDCP SDU中，但是通过CUUP内部的通信实现。（规范中没有明确的定义）
3. PDCP层根据这个隐形的DRB标签，按照之前DRB建立时候的所有上下文信息，把来源于SDAP层的PDU在PDCP中进行相应处理。比如不同的DRB对应到不同的PDCP实体中。
13.2 受限的数据传递（delivery）
13.2.1 按序递送（in-order delivery）
Figure 6.2.2.2/3-1: PDCP Data PDU format with 12 /18 bits PDCP SN
13.2.2 PDCP PDU的编号SN （Sequence numbering）
· SN长短考虑的因素
· HFN是什么，COUNT是什么
13.3 PDCP PDU递送的基本流程
数据in-order按序进入PDCP和按序递送到RLC。对于同一个PDCP实体内的没有优先级划分，而对于不同实体，同时到达PDCP层的数据也可能不用考虑优先级，因为不同的实体是单独处理各自的数据到达和发送的。
13.3.1 刚进入流水线的还是SDAP PDU即PDCP SDU
13.3.2 首先贴上一个动态计时器——discardTimer
每一个PDCP SDU一进入PDCP流水线就会被贴上一个“秒表”——discardTimer。
每一个PDCP SDU的discardTimer的运行以及PDCP层处理和递送并不能影响下一个PDCP SDU进入这一流水线乃至PDCP PDU的形成和递送。
当 PDCP 层被告知丢失某个 PDU 时，其操作取决于数据类型和网络配置。例如，在实时数据的情况下，由于时间限制，重传可能没有用。而且PDCP 层本身不会触发重传。相反，如果discardTimer过期，它可能会丢弃数据，表明数据不再相关或不及时。
13.3.3 再in-order进入buffer，把该PDU关联上COUNT和PDCP实体中的TX_NEXT
首先是明确每一个PDCP实体新建立的时候，就有一个具有初始值的TX_NEXT参数，初始值一般是0。
COUNT值实际上包含PDCP的SN和HFN：
13.3.4 头压缩
13.3.4.1 基本概念
ROHC是一种压缩各种IP数据包报头的算法。 在 IPv4 的情况下，未压缩的 IP 标头的大小为 40 字节，在 IPv6 的情况下，未压缩的 IP 标头的大小为 60 字节。
13.3.4.2 5G规范定义的ROHC算法
13.3.4.3 ROHC的优缺点
ROHC在5G中的优点：
· 带宽效率
· 改进的网络性能
· 增强对小数据包的支持
· 更低的延迟
· 能源效率
5G 中 ROHC 的缺点：
· 实施的复杂性
实施和维护 ROHC 会增加网络设备的复杂性。 它需要额外的处理来压缩和解压缩标头。
· 潜在错误
如果实施不当，标头压缩可能会导致错误。 不正确压缩的标头可能会导致数据包丢失或需要重传，从而影响性能。
· 资源利用率
压缩和解压过程会消耗CPU资源。 在处理能力有限的设备上，这可能会影响整体性能。
· 兼容性和互操作性问题
确保与所有类型的网络设备和协议的兼容性可能具有挑战性，可能会导致互操作性问题。
· 压缩和解压延迟
虽然由于数据包大小较小，可以减少整体延迟，但压缩和解压缩标头的过程本身会引入一些延迟。
13.3.4.4 如何配置和生效
· 由RRC层管理配置-CUCP
· 在CUUP中实现
· 针对相应的不同QoS的业务类型
· 在RRCReconfig消息中下发
13.3.5 完整性保护和验证
13.3.5.1 为什么要做完整性保护
在 5G 网络中，完整性保护是一项至关重要的安全功能，旨在确保传输数据的真实性和完整性。 这种保护在控制平面中尤其重要，其中关键信令数据在用户设备（UE - 用户设备）和网络之间交换。所以，5G中对控制面的完整性保护是强制的，而对于用户面则是可选的，一般不选。
完整性保护在 5G 中的作用：
· 验证数据真实性：
· 维护数据完整性：
· 防止重放攻击：
· 确保控制平面通信的安全：
13.3.5.2 完整性保护算法选择
· 定义
目前主要定义了3种Integrity Protection算法：NIA1，NIA2和NIA3，当然算上不进行完整性保护的类型NIA0，共4类。
https://www.bilibili.com/video/BV1wQ4y1i7Rf
13.3.5.3 完整性保护key
（TS 33.501）
· 包含CK和IK
· 包含NAS IK和AS IK
· AS IK包含RRC IK和UP IK
13.3.5.4 完整性保护实现方式
· MAC-I的生成要素
· 分别在NAS和RRC消息中下发——两次SMC
· 在什么时机生效
13.3.5.5 完整性保护的验证（Verification）
在传输端时，UE 计算 MAC-I 字段的值；而在接收端，UE 通过基于上述指定的输入参数计算 X-MAC 来验证 PDCP 数据 PDU 的完整性。 如果计算出的X-MAC与接收到的MAC-I相对应，则完整性保护验证成功。见上图
13.3.6 加密（Cyphering或者Encryption）
13.3.6.1 为什么需要加密
5G 系统中的加密是确保UE与5G网络之间通信安全的一个重要方面。 它确保通过空中和网络传输的数据不会轻易被未经授权的实体拦截和理解。 在 5G 中，与前几代移动网络一样，加密应用于不同层，包括 NAS（非接入层）和 AS（接入层）。
13.3.6.2 加密算法选择
与完整性保护属于同样的方法选择加密算法。
13.3.6.3 加密使用的Key
（TS 33.501）
· 包含CK和IK
· 包含NAS IK和AS IK
· AS IK包含RRC IK和UP IK
13.3.6.4 加密的实现方式
完整性保护之后进行。
根据 5G 的 3GPP TS 38.323 规范，其中 MAC-I和 PDCP数据 PDU的数据部分均经过加密，该过程通常会将这两部分作为一个整体进行加密，而不是单独加密。
13.3.6.5 解密
在接收端，加密过程的逆过程
13.3.7 通过PDCP实体中的动态值TX_NEXT计算出SN添加到PDCP的SDU，更新TX_NEXT
13.3.7.1 什么是TX_NEXT
前面提到过，实际上我们可以理解TX_NEXT是DL PDCP实体中一个动态的参量，它的变化的数值反过来用来计算每个刚刚进入PDCP实体的buffer的SN值 （实际上是HFN+SN，即COUNT），而这个SN对于每个PDCP SDU来说是静态的。这也是TX_NEXT这个内部参数的作用之一。
13.3.7.2 如何动态变化并影响到PDDCP SN
总结起来，TX_NEXT没什么特别的功能，就是在PDCP实体中维护SN和COUNT。
13.3.8 形成PDCP PDU并交付到RLC层
13.3.9 接收端PDCP PDU的接收和恢复
13.3.9.1 PDCP PDU丢失和乱序
PDCP PDU在到达对端之后，经过MAC层的HARQ和RLC层的AM模式的ARQ之后，有些PDU经过了HARQ或ARQ的重传，有些没有。 有些经过了最大的重传之后，仍然检测错误，那就只能在MAC层或在RLC层就放弃掉，这样PDCP实体就能够通过检测SN号的顺序和一定的规则，判断出该PDU为丢失；有些虽然经过重传之后，最终通过了，但这样就打乱了在发送端的in-sequence顺序发送之后到达对端的PDCP层时的时序。这就是乱序。
13.3.9.2 解出PDCP PDU的SN并计算出HFN和COUNT
1. 在接收端的几个相关参数：
2. 先直接从PDCP PDU中的未加密的头部接触SN， 目的是：
为了能够在解密，完整性保护之前能够得到这个刚进入PDCP实体的PDU的COUNT数值。
3. 计算COUNT的方法：
13.3.9.3 解密和完整性保护验证
· 知晓包括COUNT在内的所有参数
· 解密和验证失败的处理
13.3.9.4 RX_NEXT及其作用
13.3.9.5 重排序Reordering的具体实现流程
当PDCP PDU从RLC层实体送达PDCP实体，并且计算出了其COUNT值，即RCVD_COUNT，正常情况下，没有重传，没有局部时延，则此时RCVD_COUNT肯定要比上一次更新的RX_NEXT要大1，那么，在这个PDCP PDU进入下一步处理之前，就会立即把这个RX_NEXT动态值加1，以便对下一个来自于RLC层的PDCP的PDU继续进行这样的动态数值维护。
但是对于正常数据递送的计算并不是RX_NEXT的真正目的，其真正的目的是要对于“非正常”的PDCP PDU进行COUNT的维护以及对其进行Reordering的支撑。
Reordering流程：
13.4 PDCP数据（PDU）的异常递送（Delivery）和传输（Transmission）
13.4.1 发送端的SDU discard和discardTimer
13.4.1.1 SDU discard的发生条件
前面提到过，PDCP的SDU丢弃满足条件是要么discardTimer超时，要么收到来自于对端PDCP层的PDCP status report。而如果存在这种情况，PDCP status report的触发是有条件的，通常在PDCP实体重建或者PDCP数据恢复的时候才发送。
13.4.1.2 PDCP Status Report的内容
PDCP Status Report
如果PDCP控制PDU中没有用于PDCP状态报告的Bitmap，则该控制PDU仅通过FMC值报告第一个丢失的PDCP PDU； 如果用于PDCP状态报告的PDCP控制PDU中只有一个Bitmap，则该Bitmap表示的是FMC所表示的PDU的下一个PDU，以此类推。
13.4.1.3 PDCP实体的重建
13.4.1.4 PDCP数据的恢复
13.4.2 PDCP的流控和DDDS
Downlink Data Delivery Status，主要作用是在发送端对PDCP实体数据传输的流控，Flow Control
但DDDS不在PDCP规范38.323中，而是在38.425中进行定义。
13.4.2.1 PDCP层的流控
上层数据来到PDCP需要进行Packet Data Convergence，这个聚合就包括流控
流控是通过于底层RLC层的交互进行的
13.4.2.2 DDDS的作用
DBS：Desired Buffer Size
· RLC层的buffer已经不足
· RLC层已经腾出了更多的buffer
· PDCP主动要求对RLC层buffer进行查询
13.4.2.3 具体的PDCP流控的流程
13.5 PDCP层参数汇总及参数设置
13.5.1 一般参数
· PDCP SN 和 COUNT
针对于安全性，添加HFN和使用COUNT相对于仅仅使用PDCP SN能确保安全过程中更长时间的标识的唯一性。 对于安全操作，特别是加密和完整性保护，每个 PDU 都需要一个唯一的标识符。 这对于防止重放攻击至关重要，重放攻击中攻击者重新发送捕获的数据包以产生未经授权的效果。
比如SN Wrap-around绕回的问题：如果仅使用PDCP SN来保证安全，一旦SN绕回，相同的SN将被重用。 在高速网络中，这种环绕可能会相对较快地发生，导致重复使用相同的加密和完整性保护计数器，这是一种安全风险。
COUNT中包含的SN包含在PDCP的PDU当中，但是HFN并不包含在其中。HFN是在接收端间接地计算出来。
· FMC
· MAC-I
13.5.2状态变量（State variables）
· TX_NEXT
· RCVD_COUNT, RCVD_SN, RCVD_HFN
· RX_NEXT
· RX_DELIV
· RX_REORD
13.5.3 常量（Constants）
· Window_Size
13.5.4 定时器（Timers）
· discardTimer
· t-Reordering
