5G NR PDCP协议（二）

一、切换

1.1 移动性概述

• 移动通信的核心技术是终端的可移动性，根据终端是否处于连接态，移动性可分为两种，非连接态和连接态。
• 其中非连接态又可分为两种，小区选择和小区重选，在这两种情况下，终端都没有做通信业务，终端自己检测到更好的信号，决定移动到目的小区。
• 连接态的移动性只有一种——切换，终端做业务期间根据网络设置的测量策略，周期性上报测量结果，网络侧根据测量报告作出切换判决。

小区重选和小区切换在本质上是一样的，都是手机从当前驻留的小区更换到另一个信号质量更好的小区。它们的区别主要是手机做重选时协议状态处于空闲态，手机做切换时协议状态处于连接态（手机正在做通信业务，打电话、上网等）。小区切换技术是移动通信系统的关键技术，它实现了用户在通话或者上网过程中，手机和网络之间的无线链路自动的从一个小区到另外一个小区的转接，且不会中断通话或数据业务，从而真正的实现了无线覆盖的连续性。切换的目的和小区选择/重选的一样，都是是选择最优的无线通信资源块，从而提供更好的通信质量，它也是无线链路的重要控制手段，能够保持手机在穿越不同的蜂窝小区时通话的连续性，减小掉话率，并且能提供更好的上网体验。

1.2 切换概述

从LTE开始，根据无线承载（Radio Bearer）的QoS要求的不同，切换过程可以分为无缝切换(Seamless handover)和无损切换(lossless handover)。

• 无缝切换，应用于对于时间延迟有严格要求，而对误包率（丢包率）具有相对容忍度的一些应用（比如，语音VoIP）。无缝切换在LTE中可以降低切换的复杂度和时间延迟，但同时可能引起某些数据包的丢失。无缝切换主要应用于控制面的无线承载（SRB）以及用户数据面RLC UM模式的无线承载。

在无缝切换的模式下，对于下行的数据传输，源gNB将尚未进行传输的PDCP SDU转发给目标gNb，对于经N3接口转发下来，尚未进行PDCP处理的下行数据，源gNb也同样转发给目标gNb。已经完成 PDCP SDU传输的下行数据， 则无需转发给目标gNb。对于已经进行了部分PDCP SDU的传输，但尚存部分RLC PDU的数据，源gNb会将剩余的RLC PDU丢弃，也就是说，在无缝切换模式下，源gNb不会将下行数据的RLC 上下文 （RLC Context）转发给目标gNb，这样，这部分PDCP SDU的数据将会丢失。目标gNb侧，会将PDCP的SN和HFN重新置为零。同时，目标gNb在传输经由N3接口的下行数据之前，会优先传输源gNb通过Xn接口转发过来的下行数据。我们知道，UPF在将下行通道切换到目标gNb之前会向源gNb发送“End Marker”数据包。源gNb会将此数据包转发给目标gNB。目标gNb据此可以获知源gNb转发数据的结束。

在无缝切换的模式下，对于上行的PDCP SDU数据， 同样，对于已经在源gNb中完成传输的数据，UE不会在目标gNb中重新发送。相反， 在目标gNb中，UE 将传输那些尚未在源gNb中传输的PDCP SDU数据，源gNb将所有接收到的PDCP SDU上行数据递交给UPF，其中可能包括有失序的PDCP SDU。对于无法组装成PDCP SDU的部分RLC PDU分段，源gNb将把他们丢弃。也就是说，无缝模式下源gNb并不将上行数据的RLC 上下文转发给目标gNb，这部分对应的PDCP SDU上行数据将会丢失。

• 无损切换主要用于RLC AM模式的无线承载，典型的例子如FTP上下载，PDCP SDU传输的丢失可能对上层协议（TCP）的吞吐量有较大的影响，相反，对于时间延迟不象实时应用那样敏感。

在无损切换中，对于上行数据，切换到目标gNb后，UE会从第一个尚未在源gNb中得到确认的PDCP SDU开始，重传该序号以后的PDCP SDU包（其中可能包括源gNb收到，但UE没有收到确认的PDCP SDU或UE虽收到确认，但失序的PDCP SDU），除非目标gNb通过PDCP 状态报告包确认收到其中的某些SDU（源gNb转发给目标gNb）。

在无损切换的过程中，对于下行的PDCP SDU，如果UE已经在源gNb中完成PDCP SDU的确认， 源gNb无需将它们转发给目标eNodeB （包括连续的和失序的PDCP SDU）。源gNb需要将尚未传输完毕（包括已有部分传输和尚未进行传输的。注意，与无缝切换中不同，无缝切换中转发的是尚未进行传输的SDU）的PDCP SDU转发给目标gNb，包括经N3接口转发下来，尚未进行PDCP处理的下行数据。对于已经进行了部分PDCP SDU的传输，但尚存部分RLC PDU的数据，源gNb会将RLC PDU丢弃，也就是说，在无损切换模式下，源gNb不会将RLC 上下文 （RLC Context）转发给目标gNb（源gNb丢弃的只是RLC的上下文，并非是PDCP SDU的数据，PDCP SDU的数据仍会转发给目标gNb，因为他们属于尚未传输完毕的PDCP SDU）。

1.3 切换处理流程图

下图是UE做基站间切换的总的流程图，这里主要分析切换过程的用户面处理。另外，PDCP协议是基于UE进行定义的，这里需要根据协议对UE的行为描述分析基站的处理流程。

二、压缩

2.1 背景

从LTE开始，移动通信网络不再支持电路交换域(CS)传输的语音业务，为了在分组交换域(PS)提供语音业务且接近常规电路交换域的效率，需要对IP/UDP/RTP报头进行压缩，这些报头通常用于VoIP业务。对于一个含有32Byte有效载荷的VoIP分组传输来说，IPv6 报头增加 60Byte， IPv4 报头增加40Byte， 即存在188%和 125%的开销。为了解决这个问题，用户面的PDCP子层采用了ROHC报头压缩技术，通过报文头压缩，这一开销可被降低为4～6个字节，即只有12.5%～18.8%的相对开销，从而提高了信道的效率和分组数据的有效性。

2.2 压缩流程

PDCP的ROHC的工作流程如图所示，PDCP从上层收到VOIP数据经过RTP/UDP/IP协议栈处理后，整个报文头已经变得冗长。其实数据流中的IP头及其他协议头的许多部分在传输中是静态（static）的并且从不改变，ROHC就是利用这些不同IP包中的固定性，不必每次都传输这些冗余信息，在压缩至解码的过程中把它们存储为关联信息（context）称之为推理域（inferred），这些信息可以由其他的报头信息得到，由此可以看出，压缩方法的关键就是如何处理改变了的部分（changing fields）。ROHC将利用基于包序列号的线性函数得到报头动态变化的部分。

2.3 压缩原理

下图是一个典型的RTP/UDP/IP语音包，整个报文头可以分为8个区域，用不同颜色标注：

• Static：即静态域。在同一IP数据流中变化几率很小，只是偶尔才会发生，所以，压缩端和解压缩端之间传输了一次信息头之后，就不需要再次进行传输了。如果静态域发生变化，那么重新传输变化之后的静态域数值即可。
• Semistatic：半静态域。这些字段的值通常是静态不变的，只是偶尔发生改变，很快它又会恢复成原始值。
• Static-Def：即静态定义域。这些域往往代表了一些固定的信息，比如源地址、目标地址等。同静态域相似，但是静态定义域在同一IP数据流中是不会发生变化的，只在第一次传输即可，之后不需再次进行传输处理。
• Static-Known：即静态已知域。域的数值是已经定义好的，压缩端和解压缩端都不需要去进行压缩处理，也不需要进行传输。
• Changing：变化域。顾名思义，即是发生变化的域。这些域是必须要进行压缩处理进行传输的。
• Rarely Changing：和半静态字段类似，偶尔发生变化，只是不会恢复到原始值，而是保留新值。
• Alternating：这些字段的值在少数几个不同的数值之间交替变化。
• Inferred：推测域。推测域是可以通过其他一些域的数值进行计算得到的，所以在传输处理中，并不需要对推测域进行处理。只需要将其相关域和变化规律进行压缩处理即可。

我们在进行数据传输的开始阶段，将一个完整的信息头发送给对方，之后则根据各个域的类型，只对发生变化的域进行传输处理。而且也不一定需要把域的所有比特都进行压缩处理，按照WLSB算法，我们只需要处理发生变化的比特，这样就可以实现减少传输数据量的压缩目的了。

2.4 协议处理

1、发送侧处理

如果配置了头压缩参数，并且开关打开，则头压缩模块就会启用，生成两种报文：
(1)压缩后的报文，和一个PDCP SDU相关联。
(2)独立的报文，不关联任何PDCP SDU，比如ROHC feedback报文。ROHC反馈报文不会关联任何PDCP SDU，也不分配PDCP SN，整个报文也不会加密。

如果建立的协议压缩上下文（ROHC contexts）个数已经达到了最大值MAX_CID个，此时如果要处理一个新的IP flow，并且已建立的ROHC context都不匹配该IP flow，则compressor此时应该分配一个已存在的压缩流（覆盖旧内容），或者发送未压缩的IP数据流。

头压缩模块产生了一个interspersed ROHC feedback报文后，PDCP实体会把该报文构造一个PDCP Control PDU，不关联PDCP SN，也不进行加密，然后提交给下层。

2、接收侧处理

如果控制面配置了用户面压缩，则PDCP收到PDU进行解密后需要进行解压缩处理。头解压缩协议不适用于SDAP头，也就是说SDAP头不参与压缩/解压缩，被当作压缩模块当作净荷处理。

PDCP实体收到了一个interspersed ROHC feedback报文后，直接把报文递交给头压缩模块，不经过解压缩处理。

三、加密和完整性保护

3.1 概述

3GPP的3G、4G、5G的加密和完保算法都是采用继承和继续发展的模式，下一代通信系统的安全算法一般都是从上一代通信系统标准继承下来，然后再增加新的算法进去。完保和加密的各种秘钥由信令面生成和分发，用户面只是使用秘钥根据协议对数据进行加密完保算校验。

3.2 加密原理

• COUNT：32bits，由HFN和PDCP SN组成，共32bit。
• BEARER：5bits，对于信令数据——“RB identity'，对于业务数据――“DRB identity”
• DIRECTION：1bit，0——“上行”，1——“下行”
• KEY：128bits，对于信令数据――“KRRCenc”，对于业务数据――“KUPenc”
• LENGTH：16bits，Keystream block长度，在加密算法中，利用Keystream block对未加密的数据的消息字段进行操作。
  （1）对于EIA1和EIA3，采用流密码加密方式：LENGTH取值为Keystream block的bit数；
  （2）对于EIA2，采用块密码加密方式：LENGTH取值为Keystream block的字节数。

对于信令数据――加密数据为PDCP DATA和MAC-I，长度为PDCP DATA长度加上MAC-I长度；而PDCP DATA即为未压缩的PDCP SDU。
对于业务数据――加密数据为PDCP DATA，长度为PDCP DATA长度；而PDCP DATA可以为压缩的PDCP SDU，也可以为未压缩的PDCP SDU。

3.3 完保原理

COUNT：32bits， 由HFN和PDCP SN组成，共32bit。
BEARER：5bits，对于信令数据――“RB identity'，对于业务数据――“DRB identity”，特例——对于EIA1算法，输入为32bit，高27bit填零，低5bit为BEARER
DIRECTION：1bit，0——“上行”，1——“下行”
MESSAGE：RRC消息内容，即PDCP SDU
KEY：128bits，对于信令数据――“KRRCenc”，对于业务数据――“KUPenc”
LENGTH：16bits
（1）对于EIA1和EIA3，采用流密码加密方式，LENGTH取值为MESSAGE的bit数；
（2）对于EIA2，采用块密码加密方式，LENGTH取值为MESSAGE的字节数。

3.4 加密和完保处理流程

1）完保(数字签名)保护的是加密之前的PDU头和PDU数据。
2）SRB一直都使用完保，PDCP Control PDU不需要完保，PDCP Data PDUs of DRB完保可选。
3）发送侧UE计算出MAC-I，接收侧UE使用同样的参数计算X-MAC，如果MAC-I和X-MAC相一致则完保成功。
4）加解密只适用于用户数据，不包括SDAP头、SDAP Control PDU、MAC-I。此外PDCP Control PDU也不用加密。
5）加密算法和加密Key全部由上层（RRC）配置，并且上下行都有独立的开关控制是否加密。

加密和完保处理流程图：

RRC信令、完整性保护结果需要进行加/解密：
对于发送方：先进行完整性保护（MAC-I计算），后进行加密。
对于接收方：先进行数据解密，再进行完整性验证（MAC-I校验）。

注：RRC信令的处理方式正好与NAS信令的处理方式相反。NAS信令先加密，后进行完整性保护，完整性保护信息不进行加密。

PDU加密和完保针对三种类型的PDU：

（1）控制平面SRB数据的PDCP Data PDU：首先对信令数据进行完整性保护，然后对信令数据和认证码一起加密。

（2）使用12bit SN值的PDCP Data PDU：此格式适用于携带映射到RLC AM（应答）或RLC UM（非应答）的DRB的数据的PDCP Data PDU，对数据进行加密。

（3）使用7bit SN值的PDCP Data PDU：此格式适用于携带映射到RLC UM的DRB的数据的PDCP Data PDU，对数据进行加密。