This article begins to deal with the content of NR PDCP. The above picture is a screenshot of the service and function overview of 38.300 PDCP. PDCP functions include transmission of user plane or control plane data; maintenance of PDCP SN; header compression and decompression using ROHC and EHC protocols; encryption (to prevent eavesdropping) and decryption; integrity protection and integrity verification (to ensure the correctness of data) ; Routing split bearers.
The data reordering function of the NR system is completely migrated from the RLC layer to the PDCP layer, and the PDCP layer is responsible for performing the reordering function to ensure sequential delivery to the upper layers; however, if certain scenarios require sequential transmission, it can be handed over to the PDCP implementation. In many cases in NR scenarios, fast delivery of data packets is more important than in-order transmission. The PDCP layer also supports out-of-order delivery configuration. Once this configuration is enabled, the PDCP layer does not reorder the data, and directly submits the PDCP SDU to the high level. The out-of-order delivery configuration is applied to services that are particularly sensitive to delay or some services with special requirements. PDCP supports retransmission, and its operation is similar to RLC ARQ, but does not support segmentation. PDCP will associate a count with each SDU, and count is a combination of PDCP sn and HFN. count is used to identify lost SDUs and request retransmission; if reordering is configured, the received SDUs must be reordered before being sent to the upper layer. When reordering processes the SDUs in the buffer, the SDUs of the lower count need to be transmitted to the upper layer in an orderly manner, and then the SDUs of the higher count can be delivered. PDCP can also configure a discard timer for each PDCP SDU; when the discard timer expires, the corresponding SDU will be discarded and not transmitted; of course, the repeated data also needs to be discarded. In addition, repeated transmission is an important technology introduced by NR to meet the needs of low-latency and high-reliability transmission. For details, see NR PDCP duplication.
Since PDCP does not allow COUNT to wrap around in DL and UL, specific implementation on the network side is required to prevent the above phenomena from happening, for example, by releasing and adding corresponding RBs or by full configuration (38.331 5.3.5.11).
The figure above is a possible structure of the PDCP sublayer.
PDCP needs to be configured according to RRC layer parameters. PDCP is used to map RBs to logical channels of DCCH, DTCH, SCCH and STCH types, and PDCP will not be used for other logical channels except the above four logical channels.
Each RB (except SRB0 of the Uu interface) will be associated with a PDCP entity. Based on RB characteristics (such as unidirectional/bidirectional or split/non-split) or RLC mode, each PDCP entity may be associated with 1/2/3/4/6/8 RLC entities, as follows:
(1) split bearers, each PDCP entity will be associated with two UM RLC entities (in the same direction), four UM RLC entities (each direction corresponds to two RLC entities) or two AM RLC entities;
(2) For RBs configured with PDCP duplication, each PDCP entity will be associated with N UM RLC entities (in the same direction), 2 × N UM RLC entities (each direction corresponds to N) or N AM RLC entities, where 2 <= N <= 4; see PDCP duplication description for details.
(3) For DAPS bearers, each PDCP entity will communicate with two UM RLC entities (one for the source cell and one for the target cell in the same direction), four UM RLC entities (for each direction of the source cell and the target cell) Corresponding to 2), or 2 AM RLC entities (one for the source cell and one for the target cell);
(4) In other cases, each PDCP entity is associated with one UM RLC entity, two UM RLC entities (one for each direction) or one AM RLC entity.
The quantitative relationship between the above UM RLC entity and AM RLC entity may seem confusing. Take (4) as an example. Under normal circumstances, a PDCP entity only needs to be associated with one AM RLC entity (regardless of the direction), but May be associated with 1 to 2 UM RLC entities (considering the direction)? Then look at the description in the following paragraph of RLC.
The UM RLC entity can be configured as a transmitting UM RLC entity or as a receiving UM RLC entity. The transmitting UM RLC entity receives RLC SDUs from PDCP and sends RLC PDUs to its peer receiving UM RLC entity via MAC. The receiving UM RLC entity transmits RLC SDUs to PDCP and receives RLC PDUs from its peer transmitting UM RLC entity via MAC.
AM RLC entity consists of transmitting side and receiving side. The transmitting side of the AM RLC entity receives the RLC SDU from PDCP and sends the RLC PDU to its peer AM RLC entity via MAC. The receiving side of the AM RLC entity transmits RLC SDUs to PDCP and receives RLC PDUs from its peer AM RLC entity via MAC.
It can be seen from the above paragraph that the UL and DL transmission of UM RLC entity requires transmitting UM RLC entity and receiving UM RLC entity respectively, which correspond to UL and DL respectively, that is, 2 UM RLC entities; while AM RLC entity is controlled by transmitting side and receiving side, that is, one AM RLC entity can complete UL and DL transmission.
In other words, for UM mode, 2 UM RLC entities are required for UL and DL transmission, respectively for UL and DL transmission, while for AM mode, only one AM RLC entity is needed to complete UL and DL transmission.
As written in the above screenshot 38.322, I just said that, the configuration of several SRBs and DRBs in the actual network is placed here.
In addition, the version after R16 adds the content of sidelink. In addition to the Uu port, UEs can also communicate through the PC5 interface. The simple diagram of sidelink is as follows.
The PC5 interface is the interface between the car module and the car, roadside equipment, and human interaction. D2D on the user plane between UEs using V2X services
(Device to Device) direct communication interface. PC5 can be used as a way of direct vehicle-to-vehicle communication when there is no wireless network coverage, so uu and PC5 can coexist.
When the UE is within the coverage of NG-RAN, no matter which RRC state the UE is in or when the UE is outside the coverage of NG-RAN, it supports sidelink transmission and reception through the PC5 interface.
NR sidelink PC5 inter-UE communication-related architecture diagram is as above, and the same as the conventional architecture, PDCP is between RRC and RLC.
In order to support the 5G ProSe UE-to-Network Relay (U2N Relay) function, R17 introduces Sidelink relay to provide network connection for U2N remote UE; the protocol stack diagram of the user plane and control plane of the L2 U2N Relay architecture is shown above, where PDCP and There is an additional SRAP sublayer between RLCs, which is mainly used for the mapping between Uu relay RLC and PC5 relay RLC.
Specifically, the PDCP entity is located at the PDCP sublayer. Multiple PDCP entities can be defined for the UE. Each PDCP entity is responsible for transmitting data of one RB. PDCP entity can be associated with control plane or user plane, depending on whether PDCP is associated with SRB or DRB.
The following figure is the functional diagram of PDCP entity; for split bearer and DAPS bearer when sending data, PDCP entity needs to be sent for data routing.
The PDCP entity associated with DRB can use headerCompression according to RRC configuration, and the receiving end can configure headerCompression with corresponding decompression function to reduce the number of transmitted bits. This mechanism is especially suitable for small loads, such as IP voice and TCP confirmation scenarios. PDCP versions after R16 support the header compression protocols of ROHC and EHC. Header compression was developed to compress IP packets, therefore, it is only applied to the data part, not to SDAP headers and SDAP Control PDUs. It is worth noting that each header compression protocol will be independently configured for DRB.
Below is the explanation of headerCompression IE,
headerCompression: If rohc is configured, the UE shall apply the configured ROHC profile in UL and DL. If uplinkOnlyROHC is configured, the UE shall apply the configured ROHC configuration file in UL, and headerCompression is not required in DL. ROHC can be configured for any RB. However, ROHC and EHC can be configured for one DRB at the same time. The network will only reconfigure headerCompression when it involves reconfiguration of PDCP reestablishment, and will not configure any drb-ContinueROHC. When configuring outOfOrderDelivery, the network configures headerCompression as notUsed.
drb-ContinueROHC: Indicates whether the PDCP entity should continue or reset the ROHC header compression protocol during PDCP re-establishment. This field is only configured in the case of resuming the RRC connection or reconfiguration with sync, while the PDCP termination point is not changed and fullConfig is not indicated. If the bearer is configured as a DAPS bearer, the network does not include this field during configuration.
In addition, the DAPS HO mentioned above belongs to the content of NR mobility enhancement. In order to reduce the interruption time during HO, the solution is proposed. In DAPS HO, the UE will continue to receive DL data from the source gNB until the release source cell. In the uplink It will also continue to send UL data until the RA of the target gNB is successfully completed. For DAPS HO, when receiving HO command, UE should create a MAC entity of target cell; for target, establish RLC entity and related DTCH logical channel; for DRB, for source and target, independent PDCP entity and ROHC RLC entity should be configured ; Keep the remaining source configuration until the source is released. When HO fails, if the source link is still valid, the UE can use the source link for recovery instead of re-establishment.
The above figure corresponds to the functional diagram of the PDCP entity associated with the DAPS bearer; referring to the above description, for the DAPS Bearer, the PDCP entity needs to be configured with two sets of security functions and keys, and two sets of header compression protocols are used for the transmission of source and target cells .
The PDCP layer provides services to the RRC or SDAP layer, including the transmission of user and control plane data; header compression, encryption and integrity protection.
The maximum size supported by PDCP SDU is 9000 bytes, and the maximum size supported by PDCP control PDU is also 9000 bytes.
The service provided by the PDCP entity that requires the RLC entity includes AM mode data transmission, and needs to feedback a success indication after successfully transmitting the PDCP PDU; UM mode data transmission service.
The last part looks at the content of encryption, decryption and integrity protection.
Ciphering and deciphering
Encryption is an important means of protecting data. The function of encryption is to ensure that the content cannot be obtained after the information is intercepted, thereby protecting the privacy of the data. The encryption function includes two parts: encryption and decryption. After the encryption function is activated, the sender encrypts its corresponding PDCP data PDU according to the COUNT value corresponding to each PDCP data SDU and the encryption algorithm and key specified by the upper layer. After receiving the PDCP data PDU, the receiving end first determines the COUNT value corresponding to the PDU, and then decrypts it using the algorithm and key specified by the upper layer. The content that needs to be encrypted is MAC-I and PDCP data PDU (except SDAP header and SDAP control PDU). Encryption functions shall not be applied to PDCP control PDUs.
The encryption algorithm and key used by the PDCP entity are configured by the upper layer RRC, and the encryption function is activated by the RRC message. After the security is activated, the encryption function can be used for all DL/UL PDCP data PDUs indicated by the upper layer.
The parameters required for PDCP encryption include COUNT value and data transmission direction. The encryption algorithm encrypts/decrypts the data according to these parameters.
The parameters that need to be provided by the upper layer include Bearer (the value is obtained by subtracting 1 from the RB id) and the encryption key (the integrity protection keys used for the control plane and the user plane are KRRCenc and KUPenc respectively).
For DAPS bearers, it is determined based on the whereabouts of the PDCP SDU. For example, for transmission with the source cell, the encryption algorithm and key of the source cell are used to execute the PDCP SDU; for transmission with the target cell, the encryption algorithm configured for the target cell is used. and keys are implemented on PDCP SDUs.
NR sidelink, the encryption algorithm and key used by the PDCP entity are configured by the NAS, and the encryption function of the sidelink SRBs or DRBs of the PC5 unicast link is activated through the RRC message. Inputs required as encryption and decryption algorithms include KEY (NRPIK), COUNT, BEARER, and DIRECTION. Encryption and programming are not used for MRBs and sidelin SRB4.
Integrity protection and verification
The integrity protection functions performed by the PDCP layer include integrity protection and integrity verification. Integrity protection protects the unencrypted data part and PDCP PDU header in the PDCP PDU. Integrity protection is always enabled for PDCP data PDU of SRB, and can also be used for PDCP data PDU of DRB, but not for PDCP control PDU; it is also applicable to sidelink SRB1 SRB2 and SRB3. But integrity protection and verification are not used for MRBs and sidelin SRB4.
After the integrity protection function is activated, the sender calculates the message authentication code (MAC-I) of each PDCP PDU corresponding to the SRB/DRB according to the integrity protection algorithm, and fills the MAC-I in the MAC-I corresponding to the PDCP PDU. domain, as shown above. When the receiving end receives the PDCP PDU, it calculates an X-MAC based on the corresponding input parameters, and verifies the integrity of the received PDCP PDU by comparing whether the X-MAC is consistent with the MAC-I. If the calculated X-MAC is consistent with the received MAC-I, it proves that the received data is complete and has not been tampered with, otherwise it indicates to the upper layer that the integrity verification fails.
The integrity protection algorithms and keys used by PDCP entities are configured by RRC and activated through RRC messages. After security activation, the integrity protection function will be applied to all UL/DL PDUs, including the PDUs used to activate integrity protection. The RRC message for activating integrity protection uses the integrity protection configuration carried in the message for integrity protection. Therefore, before the integrity verification of the message, it should be sent to the RRC entity, and the RRC will decode the message, and then the PDCP entity completes the integrity verification of the message according to the integrity protection configuration information provided by the RRC.
The same is true for PC5-S message.
The input parameters required for PDCP integrity protection include COUNT value and data transmission direction, and the integrity protection algorithm performs integrity protection for data according to these parameters. The parameters that need to be provided by RRC include Bearer (the value is obtained by subtracting 1 from the RB id) and the integrity protection key-Key (the integrity protection keys used for the control plane and the user plane are KRRCint and KUPint respectively).
For DAPS bearers, it should be determined based on the whereabouts of PDCP SDUs. For example, for transmission with source cells, the integrity protection algorithm and key of source cells should be used to perform integrity protection or verification of PDCP SDUs; for transmission with target cells, use The integrity protection algorithm and key configured for the target cell perform integrity protection or verification on the PDCP SDU.
NR sidelink, the integrity protection algorithm and key used by the PDCP entity are configured by the NAS, and the integrity protection function of the sidelink SRBs or DRBs of the PC5 unicast link is activated through the RRC message.
For SLRBs that require integrity protection and verification, the required inputs for the integrity protection algorithm include KEY (NRPIK), COUNT, BEARER, and DIRECTION.
At the end of this article, the next step will still make a summary of PDCP-related parameters, variables, and structures for subsequent viewing, and then I will give priority to the description of the data transfer process in 38.323. As for other parts, I will talk about it slowly when I have time.