这篇看下PDCP的data transfer过程，如NR RLC(三) TM and UM mode所述，在UL grant充足的情况下，UM RLC 一直在传输完整的RLC SDU，通过log只能知道UE有在收发data，并不能像LTE似的通过SN去判断UE DL data是否有序接收以及实际接收状况，这时候就检查PDCP的接收和发送就显得十分重要。由于NR RLC的变动，检查NR L2时，直接看PDCP也是比较直接的方式。

 

这篇主要内容是PDCP data transfer的具体过程，外加PDCP entity相关的建立，重建及release过程的描述，最后是PDCP data recovery和Data volume calculation的规定。先看PDCP entity的建立，重建及release过程的内容。

 

PDCP entity establishment

 

当上层请求为 Uu 或 PC5 接口或对用于groupcast和broadcast的NR sidelink的RB建立PDCP entity，当接收到第一个 PDCP PDU还没有对应的 PDCP entity时，UE就要为RB建立对应的PDCP entity，并将相关的状态变量设置为初始值，之后按照实际情况进行数据的收发。

 

PDCP entity re-establishment

PDCP重建是移动通信系统中伴随切换的一个典型过程，在安全和头压缩功能需要reset或重建等等情况，均可以启动PDCP重建过程。当上层请求PDCP entity进行重建时，如果此时是sidelink场景，那进行重建时，需要额外执行一次PDCP重建过程(对应Uu和PC5 interface)，之后才能进行正常data传输。

 

上图是一些具体但又繁琐的规定，当RRC层请求PDCP entity re-establishment时，发送PDCP entity应：

(1)对于 UM DRB 和 AM DRB，如果RRC层未收到drb-ContinueROHC的配置，则要reset UL的ROHC协议并初始状态重新开始(以U-mode下的 IR 状态开始)；

(2)对于 UM DRB 和 AM DRB，如果 RRC层未收到drb-ContinueEHC-UL的配置，则重置UL的 EHC 协议；

(3)对于UM DRBs和SRBs，设置TX_NEXT为初始值；

(4)对于SRB，丢弃所有存储的 PDCP SDU 和 PDCP PDU(旧的配置已经失效，重建完成之后无须再传输)；

(5)在 PDCP 实体重建过程中应用上层提供的加密算法和密钥；

(6)在 PDCP 实体重建过程中应用上层提供的完整性保护算法和密钥；

(7)对于 UM DRB，对于已经与 PDCP SN 相关联但之前尚未将相应的 PDU 提交给较低层的每个 PDCP SDU，以及对于 Uu 接口被suspend的AM DRB，从第一个 PDCP SDU 开始，其对应的 PDCP data PDU 的成功交付尚未被下层确认，对于每个已经与PDCP SN关联的 PDCP SDU：认为这些PDCP SDU如同从高层接收到的一样，无须重启动discardTimer，在PDCP重建之前按照与PDCP SDU关联的 COUNT 值的升序执行PDCP SDU的传输；

(8)对于未suspend的AM DRB，如果PDCP SDU 对应的PDCP datd PDU 还没有收到底层的成功传输的指示，则就从第一个这样的PDCP SDU开始，在 PDCP entity重建之前，按照与PDCP SDU相关联的COUNT 值的升序，对所有已经与PDCP SN相关联的 PDCP SDU 执行重传或传输，其中过程如下：要使用相关的ROHC和EHC执行 PDCP SDU 的header压缩；用与该 PDCP SDU 关联的 COUNT 值执行 PDCP SDU 的完整性保护和加密，然后将生成的 PDCP数据PDU提交给下层。

 

如RFC3095所述，ROHC方案具有三种操作模式，分别称为Unidirectional,Bidirectional Optimistic, 和Bidirectional Reliable mode。ROHC的压缩必须从U-mode开始，根据情况进行状态转换。

对于ROHC压缩，有三个states 分别是Initialization and Refresh(IR)，First Order(FO)和Second Order(SO) states如上图示。压缩机会从最低压缩状态(IR statue)启动逐渐过渡到更高的压缩状态。 在解压缩器有足够信息可以解压缩的情况下，压缩机会尽可能在最高的压缩状态运行。 

 

当RRC层请求PDCP entity re-establishment时，接收PDCP entity应：

(1)按照正常流程处理由于低层重建而从低层接收到的 PDCP data PDU，

(2)对于 SRB，丢弃所有存储的 PDCP SDU 和 PDCP PDU(旧的配置已经失效，重建完成之后无须再传输)；

(3)对于 SRB 和UM DRB，如果 t-Reordering 正在运行：停止并重置 t-重新排序；对于UM DRB，在执行头解压缩后，将所有存储的 PDCP SDU 以关联的 COUNT 值的升序顺序传递到上层；

(4)对于Uu接口的AM DRB，如果RRC层中未配置 drb-ContinueROHC，则使用 ROHC对所有存储的 PDCP SDU 执行header解压缩；

(5)对于PC5 接口的 AM DRB，使用 ROHC 对所有存储的 PDCP IP SDU 执行header解压缩；

(6)对于 Uu 接口的AM DRB，如果RRC层中未配置 drb-ContinueEHC-DL，则使用 EHC 对所有存储的 PDCP SDU 执行header解压缩；

(7)对于 UM DRB 和 AM DRB，如果 RRC层未配置 drb-ContinueROHC ，则要reset DL 的ROHC protocol并以U-mode下的NC state开始；

(8)对于 UM DRB 和 AM DRB，如果RRC层中未配置 drb-ContinueEHC-DL，则重置DL的 EHC 协议；

  如果RRC配置了开启drb-ContinueROHC和drb-ContinueEHC-DL=true，则意味着header压缩可以连续进行，不需要上述复位操作；  

(9)对于UM DRBs和SRBs，设置RX_NEXT和RX_DELIV为初始值；

(10)在 PDCP 实体重建过程中应用上层提供的加密算法和密钥；

(11)在 PDCP 实体重建过程中应用上层提供的完整性保护算法和密钥。

 

值得注意的是在sidelink SRB/DRB 上重建 PDCP后，UE要参照33.536的规定确定何时使用新密钥发送和接收并丢弃旧密钥。

 

对于解压缩，也有3个状态，如上，解压缩器以其最低压缩状态“No context”开始，并逐渐过渡到更高状态。 解压缩器状态机一旦进入该状态，通常永远不会离开“full context”状态。详见RFC3095。

当上层要求对Uu或 PC5 接口的RB release PDCP entity时，UE 应丢弃所有存储的 PDCP SDU以及在发送 PDCP entity中的PDCP PDU；对于UM DRB和AM DRB，如果之前没有解压，则在执行header解压后，将存储在接收PDCP entity中的PDCP SDU按关联 COUNT 值的升序顺序向上层传递；最后要release对应RB的 PDCP entity。对于groupcast和broadcast的 NR sidelink场景，SLRB接收PDCP entity的release由UE 实现，协议不做规定。

 当上层要求PDCP entity suspend时，发送PDCP entity应设置 TX_NEXT为初始值并丢弃所有存储的PDCP PDU；

当上层要求PDCP entity suspend时，接收PDCP entity：如果 t-Reordering 正在运行，停止并重置 t-reordering；在执行header解压缩后，将所有存储的 PDCP SDU以关联 COUNT 值的升序顺序传递到上层；最后将 RX_NEXT 和 RX_DELIV设置为初始值。

suspend后PDCP data传输重置为初始状态，一切重新开始。

 

PDCP entity reconfiguration

 当上层要为DAPS重新配置 PDCP entity 时，UE 应为RB建立加密函数，并应用上层为加密函数提供的加密算法和密钥；为RB建立完整性保护功能，应用上层为完整性保护功能提供的完整性保护算法和密钥；为RB建立header压缩协议，并应用上层为header压缩协议提供的header压缩配置。

 

当上层要重新配置PDCP entity以release DAPS时，UE 应释放掉与已经release RLC entity RB相关的加密功能；释放掉与已经release RLC entity RB相关的完整性保护功能；释放掉与已经release RLC entity RB相关的header压缩协议。但是控制发送和接收操作的状态变量不应被重置，包括 t-Reordering 和 discardTimer 在内的定时器在 PDCP entity重配置过程中仍然保持运行。在释放header压缩协议之前，如何处理从释放的RLC entity接收到的所有存储的 PDCP SDU取决于UE具体实现，协议不做规定。

对于没有安全密钥更改的DAPS切换过程可能出现的潜在问题(例如密钥流重用)，也没有针对header压缩协议定义特殊的处理。

 

数据发送处理

数据处理包括数据发送处理和数据接收处理两部分。NR PDCP为不同的RB以及不同RLC层传输模式设计了完全统一的数据处理流程，以下内容以UE侧的数据处理过程为例进行说明，网络侧实现可参考UE侧的处理过程。

为了进行正确的发送操作，发送PDCP entity需要维护TX_NEXT状态变量，该变量用于记录下一个传输的PDCP SDU对应的COUNT值，初始值为0。在从upper layer收到PDCP SDU时，发送 PDCP entity应启动与此PDCP SDU关联的 discardTimer(有配置的话)；对于从upper layer收到的PDCP SDU，发送 PDCP entity应将TX_NEXT指向关联到这个PDCP SDU的COUNT，COUNT值由SN和HFN两部分组成，是完整性保护的输入参数之一。

如果有配置ROHC和EHC，就用指定的ROHC 和EHC执行PDCP SDU的header压缩(SDAP header和SDAP Control PDU不用header压缩)；使用 TX_NEXT 执行完整性保护和加密(如NR PDCP(一) overview中所述，完整性保护需要用到COUNT值和data传输方向，Bearer(取值由RB id减1得到)和完整性保护Key等参数做输入参数)；更具体地需要将PDCP Data PDU的PDCP SN设置为 TX_NEXT modulo 2^[pdcp-SN-SizeUL]，即取TX_NEXT的低位部分作为PDCP PDU的SN值，例如SN长度配置为12bit，则取低12位；如果SN长度配置为18bit，则取低18位；之后将TX_NEXT加一；最后将生成的 PDCP 数据PDU提交给下层，往RLC层传递的具体步骤如下。

 UE将PDCP data PDU发往RLC层的判断逻辑比较多，涉及PDCP duplication的激活与否以及是否是DC场景等，具体地说：

(1)如果发送PDCP entity仅关联了一个RLC entity，则发送PDCP PDU到这个关联的RLC entity；

(2)如果发送PDCP entity至少关联了两个RLC entity，当有激活PDCP duplication传输且传输的是PDCP data PDU，则复制该PDU发送到关联的RLC entity；如果有激活PDCP duplication传输但发送的是PDCP control PDU，则仅将PDU发送到 primary RLC entity；

(3)如果没有激活PDCP duplication传输，此时split second RLC有配置的话，当两个关联的RLC entity属于不同的cell group，即DC场景，且PDCP和RLC的待传数据等于或者高于门限(ul-DataSplitThreshold)时，可以将PDCP PDU发往任意一个RLC entity；

如果传输PDCP entity与DAPS bearer相关联，此时没有要求进行UL data switching， 就将PDCP PDU传至与source cell关联的RLC entity，如果是PDCP data PDU，要传至与target cell关联的RLC entity；如果是与source cell相关的PDCP control pdu，要传到与source cell关联的RLC entity；如果是与target cell相关的PDCP control pdu，要传到与target cell关联的RLC entity；

其他情况就将PDCP PDU发送到primary RLC entity。

整体来说PDCP data发送操作还是比较简单的，只是判断逻辑多，而PDCP接收操作就要稍微麻烦点。

 

数据接收处理

每个PDCP SDU都与一个COUNT值相关联，COUNT值由PDCP SDU在PDCP层分配的PDCP SN和PDCP SDU对应的超帧号(Hyper Frame Number，HFN)两部分组成。SN维护的主要任务是在PDCP SDU的PDCP SN翻转时使收发两端的HFN保持同步，进而实现PDCP SDU在接收端能够获得与发送端一致的COUNT值的目的，并用于解密和完整性验证。

接收PDCP entity接收到的data packet中仅仅会携带PDCP PDU SN值，而接收端本地进行的窗口维护操作和接收判断操作用到的是COUNT值，下图显示了SN、HFN和COUNT值三者之间的关系。

 

COUNT(32 bits)由HFN和PDCP SN组成，其中DRB 的PDCP SN的bit数由RRC层配置的参数pdcp-SN-sizeUL/DL得到，UM和AM DRB可以配置为12 或18 bits(通过pdcp-SN-size配置)，而SRBs只能是12 bits，所以配置SRB时不会带pdcp-SN-size，默认就是12 bits。HFN占用的bits数就由32-SN占用的bits得到。

PDCP data PDU format设计是只包含PDCP SN进行传输，这样PDCP的计数只能由SN的大小决定，假设SN的取值范围为10时，在传输时，UE来回只能收到10不同编号的包，这对于PDCP来说是不够的，因而增加了HFN，假如第一轮的10个包，对应的HFN=0，第二轮的10个包，对应HFN=1，进而UE用COUNT=[HFN,PDCP SN]来对PDCP packet进行计数，这样没改变PDCP data PDU format SN的设计，还可以将PDCP的缓存增大。

更进一步的说，接收PDCP entity为了进行正确的数据接收和窗口维护操作，需要维护的动态变量和常量简单记录如下(具体描述见NR PDCP(二))。

(1)RX_NEXT：该变量记录下一个期望接收PDCP SDU的COUNT值，初始值为0。

(2)RX_DELIV：该变量记录第一个未递交给高层仍在等待的PDCP SDU对应的COUNT值，即re-ordering window的下边界，初始值为0。

(3)RX_REORD：该变量记录触发re-ordering timer的PDCP data PDU紧接着的下一个COUNT值，仅在re-ordering timer启动时有效。

(4)Window_Size：这个常量代表re-ordering window大小，等于SN取值空间的一半，当SN长度配置为12bit时，窗口大小为2048，当SN长度配置为18bit时，窗口大小为131072。

 

从RLC收到PDCP Date PDU

先看几个参数：

(1)HFN(State Variable)：State Variable的HFN部分（即最高有效位的个数等于HFN长度）；

(2)SN(State Variable)：State Variable的SN部分（即最低有效位的个数等于PDCP SN长度）；

(3)RCVD_SN：接收到的PDCP data PDU的PDCP SN，包含在PDU header中；

(4)RCVD_HFN：接收PDCP data PDU的HFN，这个值不会在空口传输，由接收PDCP entity计算得到，另外根据PDCP data PDU的结构也可以看出，并没有一个field是HFN；

(5)RCVD_COUNT：接收到的 PDCP data PDU 的COUNT，由 [RCVD_HFN, RCVD_SN]组成，同样是需要计算得到HFN，才能知道的值。

上述几个参数，只有RCVD_SN可以通过PDCP data PDU header 确定，RCVD_HFN和RCVD_COUNT需要结合RCVD_SN经过下面的方式确定：

 

在从RLC接收到 PDCP data PDU 时，接收PDCP entity首先要判断接收PDU的COUNT值：

(1)如果 RCVD_SN < SN(RX_DELIV) – Window_Size，RCVD_HFN = HFN(RX_DELIV) + 1。

(2)否则如果 RCVD_SN >= SN(RX_DELIV) + Window_Size，RCVD_HFN = HFN(RX_DELIV) – 1。

(3)其他情况，RCVD_HFN=HFN(RX_DELIV)，新接收PDU的HFN等于当前重排序窗口下边界的HFN。

最后RCVD_COUNT = [RCVD_HFN, RCVD_SN]。

上面描述的大意就是接收PDCP entity收到一个PDCP data PDU后，首先需要通过header存储的RCVD_SN和PDCP本地的RX_DELIV计算出这个包的HFN，并用RCVD_HFN记录，然后计算出对应的COUNT，用RCVD_COUNT记录。

为方便理解举几个例看下上面的描述。

 

如上图接收窗为绿色部分没有SN翻转的情况，对于RCVD_SN<SN(RX_DELIV)-Window_Size的条件是不成立的，因为成立的话，RCVD_SN就肯定是小于0的情况，不合理；RCVD_SN >= SN(RX_DELIV) + Window_Size代表接收包处于橙色部分，可以认为是上次窗口中SN翻转前的情况，即接收的PDU的SN值超出接收窗口的边界，位于前一个SN空间中，所以HFN(RX_DELIV)-1；其他情况HFN不变，然后算出HFN作为RCVD_COUNT。

 后面接收窗口(绿色部分)包含了SN翻转的情况，RCVD_SN<SN(RX_DELIV)-Window_Size表示接收包处于上图中的紫色2区域，这个区域对应的就是SN发生翻转的区域，所以HFN(RX_DELIV)+1；那对于RCVD_SN >= SN(RX_DELIV) + Window_Size，是不成立的；其他情况HFN保持不变。

针对这种情况再举个例子，假如现在RX_DELIV 值为 FFFFEFFF。 在 PDCP 接收端操作开始时，接收到的PDCP SDU的 RCVD_COUNT要根据上面的方法确定，假设UE有序收到了RCVD_SN = 0 的数据包(对应12 bits PDCP SN的场景)，使用十六进制表示法，RX_DELIV = FFFFEFFF，那HFN(RX_DELIV) = FFFFE，而SN(RX_DELIV) = FFF。 然后根据上面的算法，这里应该RCVD_HFN = FFFFE + 1，但是实际上这里要对2[32 - pdcp-SN-Size]进行模运算，即RCVD_HFN = (FFFFE + 1)模2^20 = FFFFF。因而只有第一种情况下的计算(即RCVD_HFN = HFN(RX_DELIV) + 1)是正确的，它与RX_DELIV的当前值和之后的PDCP SDU接收有关。

 

 

计算得到RCVD_COUNT后，就要用RCVD_COUNT进行解密以及完整性校验，在确定收到PDCP data PDU的COUNT值 即 RCVD_COUNT后，接收 PDCP entity应该使用 COUNT = RCVD_COUNT 执行 PDCP data PDU 的解密和完整性验证，如果完整性验证失败：向上层指示完整性验证失败并丢弃 PDCP Data PDU 并认为它没有收到；

如果RCVD_COUNT < RX_DELIV(说明落在接收窗之外)或之前已经接收到 COUNT = RCVD_COUNT 的 PDCP data PDU，也要做丢弃处理。

 

如果接收到COUNT 值 = RCVD_COUNT 的 PDCP data PDU 在经过上面的判断后，没有丢弃，接收 PDCP entity：

(1)将生成的 PDCP SDU存储在接收缓冲区中；

(2)如果 RCVD_COUNT >= RX_NEXT，将 RX_NEXT 更新为 RCVD_COUNT + 1。

(3)如果配置了 outOfOrderDelivery(需要UE上报支持这个能力，才有可能配置)，在使用 EHC 执行header解压缩后，将生成的 PDCP SDU 传递给上层。

(4)如果 RCVD_COUNT = RX_DELIV，如果之前没有解压过，在执行header解压后，按照关联的COUNT值的升序传递给上层，即所有存储的从 COUNT = RX_DELIV 开始的连续COUNT 值的PDCP SDU；然后再将RX_DELIV 更新为第一个大于当前RX_DELIV且尚未交付给上层的 PDCP SDU 的 COUNT 值；

(5)如果t-Reordering正在运行并且RX_DELIV >= RX_REORD，停止并重置 t-reordering。

(6)如果 t-Reordering 未运行(包括 t-Reordering 由于上述操作而停止的情况)，并且RX_DELIV<RX_NEXT，将RX_REORD更新为RX_NEXT，同时开启t-Reordering。

RX_NEXT表示预期接收的下一个 PDCP SDU 的 COUNT 值， 初始值为 0。

 

假如RX_DELIV=8，RX_NEXT=11，只有收到了数据包10(放在buffer中)，下面收到了数据包8，根据上面的描述要进行解压操作后将数据包8传递给上层(传给上层的PDCP 数据包是从8开启的连续的PDCP SDU，由于9还没收到，只能传8)，下面RX_DELIV指向下一个未传递为上层的数据包9；如果后面收到了数据包12，RX_NEXT指向下一个预期收到的数据包13。

 

当 t-Reordering 超时时，接收PDCP entity应：

(1)对于关联的 COUNT值 < RX_REORD的所有已存储的PDCP SDU，以及COUNT 是从RX_REORD 开始的连续COUNT值的所有存储的PDCP SDUs，如果之前没有进行解压操作，执行header解压后，按照关联 COUNT值升序顺序传递给上层：

(2)将RX_DELIV 更新为第一个尚未交付给上层的 PDCP SDU 的 COUNT 值，其COUNT 值 >= RX_REORD；

(3)如果RX_DELIV<RX_NEXT，将 RX_REORD 更新为 RX_NEXT并开始t-reordering。

 

假如RX_DELIV=8，RX_NEXT=11 RX_REORD=10，其中只收到了数据包10；之后收到了数据包8，11和12，14(没有收到9)，此时t-reordering超时，要将所有存储在buffer中的COUNT小于10 的PDCP SDU以及从10开始的连续的COUNT关联的数据包传递到上层，即将8，10，11，12 传递到上层，之后RX_DELIV=13，RX_NEXT=15， RX_DELIV < RX_NEXT，之后RX_REORD=15并开启t-reordering，由于数据包COUNT =9 的PDCP SDU小于RX_REORD=10，根据上面的描述接收处理上就是不管了，不然延迟会增大，这也是t-Reordering的比较明显的作用之一。

 

当t-Reordering的值在 t-Reordering 运行期间被上层重新配置时，接收 PDCP entity应将RX_REORD更新为RX_NEXT；停止并重新启动t-Reordering。

 

RX_DELIV=8，RX_NEXT=11 RX_REORD=10，此时t-reordering被重配置，UE就要更新RX_NEXT= RX_REORD=11，并重启t-reordering。

 当PDCP SDU的discardTimer超时或者通过PDCP status report确认PDCP SDU已经成功发送时，发送 PDCP entity将丢弃PDCP SDU以及相应的 PDCP data PDU。 如果相应的PDCP Data PDU已经提交给下层，则告知下层要丢弃对应PDCP SDU的指示。

对于SRB，当上层请求 PDCP SDU 丢弃时，PDCP entity应丢弃所有存储的 PDCP SDU 和 PDCP PDU。

丢弃已经与PDCP SN关联的PDCP SDU会导致传输的 PDCP data PDU中出现 SN 间隙，这样会增加接收PDCP entity中的 PDCP reordering延迟，比如SN 8～15已经关联到PDCP SDU，这时候要丢弃SN 10～13对应的PDCP SDU，如果不采取措施，对端接收PDCP entity肯定会收到影响，比如可以将后面的PDCP SUD SN依次递补，补上SN gap等等。

 

Status reporting

PDCP status report机制只应用于映射到RLC AM的DRB，用于通知发送端在PDCP重建完成或者数据恢复时接收端已接收到的data packet信息，以减少PDCP重建完成或者数据恢复后不必要的重复数据分组传输。到R17，这块针对DAPS场景增加了2个触发条件，还延伸到了AM MRB场景。

以下为UE侧的PDCP status report收发处理过程，网络侧可参考UE侧的过程进行。

 

status reporting 发送操作

具体需要RRC层配置statusReportRequired=true 才能发送PDCP statue report，且只能对AM DRBs, AM MRBs 和DAPS UM DRBs配置statusReportRequired，具体如下。

 

根据RRC层配置 statusReportRequired=true(需要在UL中发送PDCP status report)，AM DRB 就要在UL发送 PDCP status report，接收 PDCP entity需要在以下几种情况下触发PDCP status report：

1 上层请求PDCP entity re-establishment；

2 上层请求PDCP data recovery；

3 上层请求UL data switching；

4 上层重新配置 PDCP entity释放DAPS并且RRC层有配置daps-SourceRelease时。

其中daps-SourceRelease的配置结构及具体描述如上。

 

对于UM DRB 在UL发送 PDCP status report(statusReportRequired=true)，接收 PDCP entity应在上层请求UL data swithcing的情况下会触发 PDCP status report。

对于sidelink场景中的AM DRB，接收PDCP entity会在上层请求 PDCP entity重建时触发 PDCP status report。

MRB指用于R17 中Multicast/Broadcast Service的RB，对于AM MRBs在UL发送 PDCP status report(statusReportRequired=true)，接收 PDCP entity应在上层请求PDCP entity重建或上层请求PDCP data recovery时触发PDCP status report。 

 

PDCP status report的生成规定，具体如下。

如果触发了 PDCP status report，接收 PDCP entity要生成一份 PDCP status report：

1 将 FMC(First Missing COUNT)字段即第一个丢失SDU的COUNT值设置为 RX_DELIV(re-ordering window的下边界)；

2 如果RX_DELIV < RX_NEXT：

(1)针对PDCP SDU的接收情况整理一个bitmap字段，其长度等于从第一个丢失PDCP SDU到最后一个乱序的PDCP SDU的COUNT数量减1(不包括第一个丢失的PDCP SDU)，bitmap的长度除了能将SDU的状态完整上报外，还需要凑足8bit的整数倍或者等于最大的PDCP control SDU上限(9000Bytes)，这两者以先达到者为准。

(2)bitmap中的“0”代表对应PDCP SDU没有接收，bitmap中的“1”代表PDCP SDU已经接收到；将所有未接收到的 PDCP SDU的bitmap字段设置为“0”，可选的PDCP SDU接收到但是头解压缩失败也可以置为“0”；将所有已接收到的 PDCP SDU 的bitmap字段设置为“1”；

 

3 将PDCP status report作为第一个要传输的PDCP PDU提交给下层进行传输(优先传输)。

 

如上图，RX_DELIV=8，RX_NEXT=13 ，收到了COUNT 10和12 对应的PDCP SDU，FMC对应32 bits，bitmap只需要4 bits就能表示现有的接收状态，按规定要对应 8bits的倍数，因而需要补齐其余bit，通常PDCP field 最高有效位是表格第一行最左边的bit，最低有效位是最后一行最右边的bit，对于此例，从左至右为00001010，最右边4 bits，分别代表COUNT 9～12的情况，bit value =0代表COUNT=(FMC+bit position)mod 2^32 的PDCP SDU 丢失，bit value =1代表COUNT=(FMC+bit position)mod 2^32 的PDCP SDU 被正确接收。

 

接下来简单看几个log。

RX_DELIV=RX_NEXT=8090，对此生成PDCP status report的情况如上图，D/C=0，FMC=8090，不需要bitmap。

 

换个角度看DL接收，这时候RX_DELIV=RX_NEXT=8109，通过下面的log打印 DELIV_DIRECT，可以看出 COUNT 8090～8108的PDCP SDU都被正常接收。而如果是DELIV_REORD_EXP/DROPPED_OOW的情况则代表有某些异常，比如DELIV_REORD_EXP对应的就是T-reordering 超时引起的RX_DELIV更新，DROPPED_OOW是因为out of reordering window导致的丢弃等等。

 

status reporting 接收操作

 对于 AM DRB，当在DL或sidelink中接收到 PDCP status report时，发送 PDCP entity认为每一个PDCP SDU的bitmap位置为1或者相应COUNT值小于第一个丢失SDU的COUNT值(FMC field)都已经正确传输，然后可以删除这些PDCP SDU。

 UL UE PDCP 新传PDCP 数据包对应的COUNT 分别为4097/4098， 后面的的PDCP data PDU SN field 对应的也是4097/4098，说明HFN =0；那对端有没有收到这些数据包，就需要通过PDCP status report确定；如上PDCP status report显示FMC =4099，即说明UE之前发送的COUNT为4097/4098的PDCP 数据包对端有正常收到。

对于传输voice或video的RLC UM DRB，在UL grant充足的情况下，UM RLC一直在传输完整的RLC SDU，通过log只能知道UE有在收发data，并不能像LTE似的通过SN去判断UE DL data是否有序接收以及实际接收状况，因而可以查看PDCP 的DL 接收；但是传输voice或video的RLC UM DRB是不会有PDCP status report发送的，这种情况下UL也只能看是否有正常发PDCP SDU，至于对端收没收到对应的PDCP SDU ，由于没有PDCP status report，发送端UE其实也不知道；DL就只能通过查看DL PDCP reordering window的相关参数(RX_DELIV/RX_NEXT/RX_REORD)确定PDCP 层的DL数据接收状况，比如上面的RX_DELIV=RX_NEXT=xxxx， 就是接收十分良好的情况，其他情况主要还是要理解RX_DELIV/RX_NEXT/RX_REORD的含义，具体问题具体分析。

对于voice或video DRB，如果UL PDCP 有序发送，对端DL PDCP COUNT有序接收，即从L2角度看UE Tx Rx 正常，但是上层仍然显示有video或voice丢包的情况，这种一般就是网络侧丢包的问题，如果是UE侧工程师，拿测试机和对比机在相同地点公平性对比测试在对比分析下，一般就能确认问题。

 

pdcp data recovery

RRC层可能在PDCP安全和头压缩等功能不需要复位，但由于底层传输通道发生了重建，例如RLC重 re-establishment可能引起PDCP部分数据被放弃传输，因而触发PDCP自身的数据恢复过程，进行数据的重传恢复。

如上RRC参数recoverPDCP=true会引起PDCP data recovery，按规定recoverPDCP不能给DAPS bearer配置。

对AM DRB来说，当高层要求进行PDCP data recovery(recoverPDCP=true)时，发送PDCP entity将对所有在重建或者释放AM RLC entity之前递交给底层但是没有接收到底层成功传输确认的PDCP data PDU按照COUNT值升序进行重传。

在进行data recovery时会触发PDCP status report，如果配置了PDCP status report机制，则根据PDCP status report，已经被PDCP对端确认收到的数据，可以不重传。

在 DAPS HO中，UE 可以执行PDCP entity重建(reestablishPDCP=true)或者 PDCP data recovery(recoverPDCP=true)，在这种情况下，UE在DAPS HO期间要暂停source MCG 中所有非non DAPS bearer的数据传输和接收。

 

Data volume calculation

MAC BSR是用于向serving gNB 提供 MAC entity中的 UL data volume信息的过程，之后gNB根据BSR 中的UL data volume及自身loading，向UE下发对应的UL grant，用于UE UL 传输，这时候需要考虑PDCP的data volume，发送 PDCP entity会将以下内容视为PDCP data vloume：

(1)尚未为其构建 PDCP data PDU 的 PDCP SDU；

(2)尚未提交给下层的PDCP data PDU；

(3)PDCP control PDU；

(4)对于 AM DRB，需要PDCP entity重建需要重传的PDCP SDU；

(5)对于 AM DRB， 由于data recovery需要重传的PDCP data PDU。

 

如果传输 PDCP entity与至少两个 RLC entity相关联，当向MAC entity指示PDCP data volume以进行 BSR 触发和buffer大小计算时，传输 PDCP entity应：

1 如果RB的PDCP duplication处于激活状态：

向与primary RLC entity关联的 MAC entity指示 PDCP data volume；对于其他激活的RLC entity，指示除PDCP control PDU之外的 PDCP volume到与 RLC entity关联的MAC entity；如果某个RLC entity的PDCP duplication功能被deactive，就将PDCP data volume指示为0到与该RLC entity相关联的MAC entity。

2.1RB 的 PDCP duplication被deactive或 RB 是 DAPS bearer，此时如果配置了split secondary RLC entity并且如果在primary RLC entity和split secondary RLC entity中等待初始传输的 PDCP data volume 和 RLC data volume的总量大于等于ul-DataSplitThreshold：

 向与primary RLC entity关联的 MAC entity和与split seconday RLC entity关联的 MAC entity指示PDCP data volume；其他RLC entity 关联的 MAC entity的 PDCP data volume 是0。

2.2 如果小于ul-DataSplitThreshold，此时如果传输 PDCP entity与 DAPS bearer关联，如果上层没有请求UL data switching，向与source小区关联的 MAC entity指示 PDCP data volume；请求UL data switching的话，将与source cell关联的interspersed ROHC feedback的PDCP data volume(不包含PDCP control PDU) 向target cell的MAC entity指示PDCP data volume；将与source cell关联的interspersed ROHC feedback的PDCP control PDU的PDCP data volume向source cell的MAC entity指示PDCP data volume。

3 其他情况，向与primary RLC entity关联的MAC entity指示 PDCP data volume；将 其他RLC entity的PDCP data volume指示为0到关联的MAC entity。