NR PDCP(一) overview

这篇开始理下NR PDCP的内容，上图是38.300有关PDCP的服务和功能概括截图。PDCP功能包括对user plane或control plane data的传输；维护PDCP SN；使用ROHC和EHC协议进行header压缩和解压缩；加密(防止窃听)和解密；完整性保护和完整性验证(确保数据的正确性)；对split bearers进行路由。

NR系统对数据的重排序功能由RLC层全部迁移到PDCP层，由PDCP层负责执行重排序功能，保证向高层进行按序递交；但是，如果某些场景需要按序传输时，就可以交由PDCP实现。在NR场景中很多时候，数据包的快速交付比按序传输更重要，PDCP层还支持乱序递交配置，一旦开启了该配置，则PDCP层不对数据进行重排序，直接将PDCP SDU立即递交给高层。乱序递交配置应用于对时延特别敏感的业务或者一些有特殊需求的业务。PDCP支持重传，其操作类似于RLC ARQ ，只是不支持分段。 PDCP会将一个count与每个SDU相关联，count是PDCP sn和HFN的组合。count用于识别丢失的 SDU以及请求重传；如果配置了reordering，则在传送到上层之前要将收到的SDU进行重新排序在送到上层。 reordering在处理buffer中的SDU时，需要将lower count的SDU有序传输到上层后，之后才能传递higher count的SDU。 PDCP还可以为每个 PDCP SDU 配置discard timer；当discard timer expires时，相应的 SDU 会被丢弃不进行传输；当然对重复的data也需要进行丢弃操作。另外重复传输是NR为应对低时延高可靠性传输需求引入的一项重要技术，详见NR PDCP duplication。

由于PDCP不允许COUNT在DL和UL中出现wrap around，因此需要网络侧具体实现来防止上述现象发生，例如，通过release和添加相应的RB或通过full configuration(38.331 5.3.5.11)避免。

上图是PDCP 子层的一种可能结构。

PDCP需要根据RRC层参数配置。 PDCP用于将RB映射到 DCCH、DTCH、SCCH 和 STCH 类型的逻辑信道，PDCP不会用于除上述4种逻辑信道外的其他逻辑信道。

每个RB(除Uu interface的SRB0外)会与一个 PDCP entity相关联。基于RB特性(例如单向/双向或split/non-split)或 RLC mode的不同，每个PDCP entity可能会与1/2/3/4/6/8个 RLC entity相关联，具体如下：

(1)split bearers，每个PDCP entity会于与两个 UM RLC entity(同一方向)、四个UM RLC entity(每个方向对应两个RLC entity)或两个 AM RLC entity相关联；

(2)对于配置有 PDCP duplication的RB，每个 PDCP entity会与 N UM RLC entity(相同方向)、2 × N UM RLC entity(每个方向对应N个)或 N 个AM RLC entity相关联，其中 2 <= N <= 4；详见PDCP duplication描述。

(3)对于 DAPS bearers，每个PDCP entity会与两个 UM RLC entity(同一方向上，一个用于source小区，一个用于target小区)，四个UM RLC entity(source小区和target小区每个方向对应2个)，或2个AM RLC entity(一个用于source小区，一个用于target小区)；

(4)其他情况，每个 PDCP entity与一个 UM RLC entity、两个 UM RLC entity（每个方向各1个)或一个AM RLC entity相关联。

上面这段UM RLC entity和AM RLC entity的数量关系，可能看起来会比较迷惑，就拿(4)来说，正常情况下，一个PDCP entity只要关联一个AM RLC entity(不考虑方向)，而却可能关联 1～2个UM RLC entity(考虑方向)？接着看下面这段RLC中的描述。

UM RLC entity可以被配置为transmitting UM RLC entity或receiving UM RLC entity。 transmitting UM RLC entity从PDCP 接收 RLC SDU，并通过MAC将 RLC PDU 发送到其对等 receiving UM RLC entity。 receiving UM RLC entity将 RLC SDU 传送到PDCP，并通过MAC从其对等传输 transmitting UM RLC entity接收RLC PDU。

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。

从上面这段话可以看出，UM RLC entity的UL和DL传输是分别需要transmitting UM RLC entity和receiving UM RLC entity，分别对应UL和DL，也就是2个UM RLC entities；而AM RLC entity由transmitting side和receiving side组成，也就是一个AM RLC entity就可以完成UL 和DL 的传输。

换而言之，对于UM mode ，进行UL和DL传输，是需要2个UM RLC entities的，分别进行UL和DL传输，而AM mode，只需要一个AM RLC entity就可以完成UL和DL传输。

如上面的截图38.322里就这样写的，我也就这么一说，具体实网中的几个SRB 和DRB的配置放在这里。

除此之外R16之后的版本增加了sidelink的内容，除了Uu口外，UE之间还可以通过PC5 interface实现通信，sidelink的简单图示如下。

PC5 interface是车的模组和车、路侧设备、人交互的接口。使用V2X业务的UE之间用户面进行D2D

(Device to Device)直接通信的接口。PC5可以作为没有无线网络覆盖时直接车车通信的途径，因而uu 和PC5可以共存。

当UE处于NG-RAN 覆盖范围内时，无论UE处于哪种 RRC 状态或者当UE 处于 NG-RAN 覆盖范围之外时，都支持通过PC5 interface进行的sidelink传输和接收。

NR sidelink PC5 UE间通信相关架构图示如上，和常规的架构一样，PDCP介于RRC和RLC之间。

为了支持5G ProSe UE-to-Network Relay(U2N Relay)功能，R17 引入Sidelink relay，以便为U2N remote UE提供网络连接；L2 U2N Relay架构的用户面和控制面的协议栈图示如上，这里PDCP和RLC之间多了个SRAP sublayer，主要用于Uu relay RLC和 PC5 relay RLC之间承载的映射。

具体地说，PDCP entity位于PDCP子层。可以为UE定义多个PDCP entity。每个PDCP entity负责传输一个RB的data。PDCP entity可以与control plane或user plane相关联，具体取决于PDCP关联的是SRB还是DRB。

下图是PDCP entity的功能图；对于split bearer和DAPS bearer在发送数据时，需要发送PDCP entity进行data routing。

与DRB关联的PDCP entity可以根据RRC配置使用headerCompression，接收端可以配置具有相应解压缩功能的headerCompression，以便减少传输的bit数，这种机制特别适用于小负载，例如 IP 语音和 TCP确认场景。R16之后版本的PDCP支持ROHC和EHC的header压缩协议。header压缩是为了压缩 IP数据包而开发的，因此，它仅应用于数据部分，而不应用于 SDAP header和SDAP Control PDU。值得注意的是，每个header compression协议会针对DRB进行独立配置。

下面是headerCompression IE的解释，

headerCompression:如果配置了 rohc，则 UE 应在UL和DL中应用配置的 ROHC 配置文件。如果配置了uplinkOnlyROHC，UE 应在UL中应用配置的 ROHC 配置文件，在DL就不需要headerCompression。 ROHC 可以为任何RB配置。而ROHC和EHC可以同时为一个DRB 配置。网络仅在涉及 PDCP重建的重配置时才会重新配置 headerCompression，并且不会配置任何drb-ContinueROHC。当配置outOfOrderDelivery 时，网络会将headerCompression 配置为notUsed。

drb-ContinueROHC：指示 PDCP entity在 PDCP 重建期间是继续还是重置ROHC 标头压缩协议。该字段仅在恢复 RRC 连接或reconfiguration with sync的情况下配置，同时PDCP终止点未更改且未指示fullConfig的情况。如果承载被配置为DAPS承载，则网络在配置时不包括该字段。

另外，上面提到的DAPS HO属于NR 移动性增强的内容，为了减少HO期间中断时间而提出的解决方案，在DAPS HO中，UE 在会持续从source gNB接收DL data直到release source cell，在上行也会继续发送UL data直到成功完成target gNB的RA。对于 DAPS HO 来说，当收到HO command 时 UE 应该创建一个target cell 的MAC entity；对于target 建立RLC entity 及相关DTCH logical channel；对于DRB , 对于source 和target 应该配置独立的PDCP entity及ROHC RLC entity；保持剩余的source 配置，直到release掉source。当HO失败时，如果源链路仍然有效，则UE可以使用源链路进行恢复而不是重建。

上图对应的就是DAPS bearer关联的PDCP entity的功能图；参照上面的描述，对于DAPS Bearer，PDCP entity就需要配置两套安全功能和密钥，两套header compression协议用于source和target cell的传输。

PDCP层向RRC或SDAP 层提供服务包括用户和控制平面数据的传输；header compression，加密及完整保护。

PDCP SDU支持的最大size为9000 bytes， PDCP control PDU 的支持的最大size也为9000 bytes。

PDCP entity需要RLC entity提供的service包括AM mode的数据传输，在成功传输PDCP PDU后需要反馈成功指示；UM mode数据传输服务。

最后一部分看下加密解密和完整性保护的内容。

Ciphering and deciphering

加密是保护数据的重要手段。加密的作用是保障信息被截获后不能获取其内容，从而保护数据的隐秘性。加密功能包括加密和解密两部分。在加密功能被激活后，发送端根据每个PDCP data SDU对应的COUNT值和上层指定的加密算法及密钥对其对应的PDCP data PDU进行加密。接收端接收到PDCP数据PDU后，首先确定该PDU对应的COUNT值，然后采用上层指定的算法和密钥进行解密。需要加密的内容是MAC-I和PDCP data PDU(除了SDAP header和SDAP control PDU)。加密功能不应用于PDCP control PDU。

PDCP实体所使用的加密算法和密钥由高层RRC进行配置，加密功能由RRC消息激活。在安全性激活后，加密功能就可以用于上层指示的所有DL/UL的PDCP data PDU。

PDCP加密所需要的参数包括COUNT值、数据传输方向。加密算法根据这些参数对数据进行加密/解密操作。

需要高层提供的参数包括Bearer(取值由RB id减1得到)和加密密钥(用于控制平面和用户平面的完整性保护密钥分别为KRRCenc和KUPenc)。

对于 DAPS bearers，要基于PDCP SDU 的去向决定，例如和source cell进行传输，就用source cell的加密算法和密钥对 PDCP SDU 执行；与target cell进行传输，就要用为target cell配置的加密算法和密钥对 PDCP SDU 执行。

NR sidelink，PDCP实体使用的加密算法和密钥由NAS进行配置，通过RRC消息激活PC5 unicast link的sidelink SRBs或DRBs的加密功能。作为加密和解密算法所需的输入包括 KEY (NRPIK)、COUNT、BEARER和 DIRECTION。加密和节目不用于MRBs和sidelin SRB4。

Integrity protection and verification

PDCP层执行的完整性保护功能包括完整性保护和完整性验证。完整性保护对PDCP PDU中未经加密的data部分以及PDCP PDU header进行保护。完整性保护对于SRB的PDCP data PDU总是开启，也可以用于DRB的PDCP data PDU，但不用于PDCP control PDU；同时也适用于sidelink SRB1 SRB2和SRB3。但是完整性保护和验证不用于MRBs和sidelin SRB4。

在完整性保护功能激活后，发送端根据完整性保护算法计算出SRB/DRB对应的每个PDCP PDU的消息验证码(MAC-I)，并将MAC-I填充在PDCP PDU对应的MAC-I域中，如上图示。在接收端接收到该PDCP PDU时，基于相应的输入参数计算出一个X-MAC，通过比较X-MAC与MAC-I是否一致来验证所接收PDCP PDU的完整性。如果计算得到的X-MAC与接收到的MAC-I一致，那么证明接收到的数据是完整的、没有被篡改的，否则向高层指示完整性验证失败。

PDCP实体使用的完整性保护算法和密钥由RRC进行配置，并通过RRC消息激活。在安全性激活后，完整性保护功能将应用到所有UL/DL的PDU，包括用于激活完整性保护的PDU在内。用于激活完整性保护的RRC消息本身采用该消息所携带的完整性保护配置进行完整性保护。因此，在对该消息进行完整性验证之前应该先将其发送给RRC实体，由RRC对该消息进行解码，然后PDCP实体根据RRC提供的完整性保护配置信息完成对消息的完整性验证。

PC5-S message也是同样的道理。

PDCP完整性保护所需要输入的参数包括COUNT值和data传输方向，完整性保护算法根据这些参数执行对数据的完整性保护。需要RRC提供的参数包括Bearer(取值由RB id减1得到)和完整性保护密钥-Key(用于控制平面和用户平面的完整性保护密钥分别为KRRCint和KUPint)。

对于 DAPS bearers，要基于PDCP SDU 的去向决定，例如和source cell进行传输，就用source cell的完整性保护算法和密钥对 PDCP SDU 执行完整性保护或验证；与target cell进行传输，就要用为target cell配置的完整性保护算法和密钥对 PDCP SDU 执行完整性保护或验证。