Content for TS 38.323 Word version: 18.3.0

1… 4… 5… 5.4… 5.8… 5.13… 6… 6.2.3… 7… A… B…

5.8 Ciphering and deciphering 5.9 Integrity protection and verification 5.10 Handling of unknown, unforeseen, and erroneous protocol data 5.11 PDCP duplication 5.11.1 Activation/Deactivation of PDCP duplication 5.11.2 Duplicate PDU discard 5.12 Ethernet header compression and decompression 5.12.1 Supported header compression protocols 5.12.2 Configuration of EHC 5.12.3 Protocol parameters 5.12.4 Header compression using EHC 5.12.5 Header decompression using EHC 5.12.6 PDCP Control PDU for EHC feedback 5.12.6.1 Transmit Operation 5.12.6.2 Receive Operation 5.12.7 Simultaneous configuration of ROHC and EHC
...

5.8 Ciphering and deciphering p. 28

The ciphering function includes both ciphering and deciphering and is performed in PDCP, if configured. The data unit that is ciphered is the MAC-I (see clause 6.3.4) and the data part of the PDCP Data PDU (see clause 6.3.3) except the SDAP header and the SDAP Control PDU if included in the PDCP SDU. The ciphering is not applicable to PDCP Control PDUs.

For downlink and uplink, the ciphering algorithm and key to be used by the PDCP entity are configured by upper layers TS 38.331 and the ciphering method shall be applied as specified in TS 33.501.

The ciphering function is activated/suspended/resumed by upper layers TS 38.331. When security is activated and not suspended, the ciphering function shall be applied to all PDCP Data PDUs indicated by upper layers TS 38.331 for the downlink and the uplink, respectively.

For DAPS bearers, the PDCP entity shall perform the ciphering or deciphering for the PDCP SDU using the ciphering algorithm and key either configured for the source cell or configured for the target cell, based on to/from which cell the PDCP SDU is transmitted/received.

For downlink and uplink ciphering and deciphering, the parameters that are required by PDCP for ciphering are defined in TS 33.501 and are input to the ciphering algorithm. The required inputs to the ciphering function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in TS 33.501). The parameters required by PDCP which are provided by upper layers TS 38.331 are listed below:

BEARER (defined as the radio bearer identifier in TS 33.501. It will use the value RB identity -1 as in TS 38.331);
KEY (the ciphering keys for the control plane and for the user plane are KRRCenc and KUPenc, respectively).

For NR sidelink communication, the ciphering algorithm and key to be used by the PDCP entity are configured by upper layers as specified in TS 24.587 and the ciphering method shall be applied as specified in TS 33.536.

For NR sidelink communication, the ciphering function is activated for sidelink SRBs (except for SL-SRB0) and/or sidelink DRBs for a PC5 unicast link by upper layers, as specified in TS 38.331. When security is activated for sidelink SRBs, the ciphering function shall be applied to all PDCP Data PDUs (except for carrying Direct Security Mode Command message as specified in TS 33.536) for the sidelink SRBs which belong to the PC5 unicast link. When security is activated for sidelink DRBs, the ciphering function shall be applied to all PDCP Data PDUs for the sidelink DRBs which belong to the PC5 unicast link.

For NR sidelink communication, the ciphering and deciphering function as specified in TS 33.536 is applied with KEY (NRPEK), COUNT, BEARER (LSB 5 bits of LCID with values 1 to 19 associated with the PDCP entity, as specified in TS 38.321) and DIRECTION (which value shall be set is specified in TS 33.536) as input. For L2 U2U relay communication between source remote UE and target remote UE, the BEARER is 0/1/2/3 for sidelink SRB0/1/2/3 and the LSB 5 bits of slrb-PC5-ConfigIndex associated with the PDCP entity for sidelink DRB, as specified in TS 38.331.

The ciphering and deciphering are not applied to MRBs and sidelink SRB4.

5.9 Integrity protection and verification p. 28

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP, if configured. The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering. The integrity protection is always applied to PDCP Data PDUs of SRBs. The integrity protection is applied to sidelink SRB1, SRB2 and SRB3. The integrity protection is applied to PDCP Data PDUs of DRBs (including sidelink DRBs for unicast) for which integrity protection is configured. The integrity protection is not applicable to PDCP Control PDUs.

For downlink and uplink, the integrity protection algorithm and key to be used by the PDCP entity are configured by upper layers TS 38.331 and the integrity protection method shall be applied as specified in TS 33.501 for NR and in TS 33.401 for E-UTRA/EPC.

The integrity protection function is activated/suspended/resumed by upper layers TS 38.331. When security is activated and not suspended, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers TS 38.331 for the downlink and the uplink, respectively.

For DAPS bearers, the PDCP entity shall perform the integrity protection or verification for the PDCP SDU using the integrity protection algorithm and key either configured for the source cell or configured for the target cell, based on to/from which cell the PDCP SDU is transmitted/received.

For downlink and uplink integrity protection and verification, the parameters that are required by PDCP for integrity protection are defined in TS 33.501 or TS 33.401 and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in TS 33.501) or TS 33.401. The parameters required by PDCP which are provided by upper layers TS 38.331 are listed below:

BEARER (defined as the radio bearer identifier in TS 33.501 or TS 33.401. It will use the value RB identity -1 as in TS 38.331);
KEY (the integrity protection keys for the control plane and for the user plane are KRRCint and KUPint, respectively).

For NR sidelink communication, the integrity protection algorithm and key to be used by the PDCP entity are configured by upper layers TS 24.587 and the integrity protection method shall be applied as specified in TS 33.536.

For NR sidelink communication, the integrity protection function is activated for sidelink SRBs and/or sidelink DRBs for a PC5 unicast link by upper layers, as specified in TS 38.331. When security is activated for sidelink SRBs, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU for the sidelink SRBs which belong to the PC5 unicast link. When security is activated for sidelink DRBs, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU for the sidelink DRBs which belong to the PC5 unicast link.

For the SLRB that needs integrity protection and verification, the parameters that are required by PDCP for integrity protection are defined in TS 33.536 and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the KEY (NRPIK), COUNT, BEARER (LSB 5 bits of LCID with values 1 to 19 associated with the PDCP entity, as specified in TS 38.321) and DIRECTION (which value shall be set is specified in TS 33.536). For L2 U2U relay communication between source remote UE and target remote UE, the BEARER is 0/1/2/3 for sidelink SRB0/1/2/3 and the LSB 5 bits of slrb-PC5-ConfigIndex associated with the PDCP entity for sidelink DRB, as specified in TS 38.331.

At transmission, the UE computes the value of the MAC-I field and at reception it verifies the integrity of the PDCP Data PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.

The integrity protection and verification are not applied to MRBs and sidelink SRB4.

5.10 Handling of unknown, unforeseen, and erroneous protocol data p. 29

When a PDCP PDU that contains reserved or invalid values is received, the receiving PDCP entity shall:

discard the received PDU.

5.11 PDCP duplication p. 30

5.11.1 Activation/Deactivation of PDCP duplication p. 30

For the PDCP entity configured with pdcp-Duplication, the transmitting PDCP entity shall:

for SRBs:
- activate the PDCP duplication;
for DRBs:
- if the activation of PDCP duplication is indicated for the DRB:
  - activate the PDCP duplication for the DRB;
- if the activation of PDCP duplication is indicated for at least one associated RLC entities:
  - activate the PDCP duplication for the indicated associated RLC entities;
  - activate the PDCP duplication for the DRB;
- if the deactivation of PDCP duplication is indicated for the DRB:
  - deactivate the PDCP duplication for the DRB;
- if the deactivation of PDCP duplication is indicated for at least one associated RLC entities:
  - deactivate the PDCP duplication for the indicated associated RLC entities;
- if all associated RLC entities other than the primary RLC entity are deactivated for PDCP duplication:
  - deactivate the PDCP duplication for the DRB.

5.11.2 Duplicate PDU discard p. 30

For the PDCP entity configured with pdcp-Duplication or for the PDCP entity associated with two RLC entities for an SLRB, the transmitting PDCP entity shall:

if the successful delivery of a PDCP Data PDU is confirmed by one of the associated AM RLC entities and the AM RLC entity is not associated with an SRAP entity:
- indicate to the other AM RLC entities to discard the duplicated PDCP Data PDU;
if the deactivation of PDCP duplication is indicated for the DRB:
- if the transmitting PDCP entity is associated with one or more RLC entities and, either one SRAP entity or the N3C; and
- if the MP primary path is on the indirect path:
  - indicate to the RLC entities on the MP secondary path to discard all duplicated PDCP Data PDUs;
- else:
  - indicate to the RLC entities other than the primary RLC entity to discard all duplicated PDCP Data PDUs;
if the deactivation of PDCP duplication is indicated for at least one associated RLC entities:
- indicate to the RLC entities deactivated for PDCP duplication to discard all duplicated PDCP Data PDUs.

5.12 Ethernet header compression and decompression |R16| p. 31

5.12.1 Supported header compression protocols p. 31

The EHC protocol is based on the Ethernet Header Compression (EHC) framework defined in Annex A.

5.12.2 Configuration of EHC p. 31

PDCP entities associated with DRBs and MRBs can be configured by upper layers TS 38.331 to use EHC. Each PDCP entity carrying user plane data may be configured to use EHC. Every PDCP entity uses at most one EHC compressor instance and at most one EHC decompressor instance.

5.12.3 Protocol parameters p. 31

The usage and definition of the parameters shall be as specified below.

MAX_CID_EHC_UL: This is the maximum CID value that can be used for uplink. One CID value shall always be reserved for uncompressed flows. The parameter MAX_CID_EHC_UL is configured by upper layers (maxCID-EHC-UL in TS 38.331);

5.12.4 Header compression using EHC p. 31

If EHC is configured, the EHC protocol generates two types of output packets:

EHC compressed packets (i.e. EHC full header packets and EHC compressed header packets), each associated with one PDCP SDU;
standalone packets not associated with a PDCP SDU, i.e. EHC feedback.

An EHC compressed packet is associated with the same PDCP SN and COUNT value as the related PDCP SDU. The header compression is not applicable to the SDAP header and the SDAP Control PDU if included in the PDCP SDU.

EHC feedback are not associated with a PDCP SDU. They are not associated with a PDCP SN and are not ciphered/integrity protected.

5.12.5 Header decompression using EHC p. 31

If EHC is configured by upper layers for PDCP entities associated with user plane data, the PDCP Data PDUs are decompressed by the EHC protocol after performing deciphering and integrity verification as explained in clause 5.8 and 5.9, respectively. The header decompression is not applicable to the SDAP header and the SDAP Control PDU if included in the PDCP Data PDU.

5.12.6 PDCP Control PDU for EHC feedback p. 31

5.12.6.1 Transmit Operation p. 31

When an EHC feedback is generated by the EHC protocol, the transmitting PDCP entity shall:

submit to lower layers the corresponding PDCP Control PDU as specified in clause 6.2.3.3 i.e. without associating a PDCP SN, nor performing ciphering/integrity protection.

5.12.6.2 Receive Operation p. 31

At reception of a PDCP Control PDU for EHC feedback from lower layers, the receiving PDCP entity shall:

deliver the corresponding EHC feedback to the EHC protocol without performing deciphering/integrity verification.

5.12.7 Simultaneous configuration of ROHC and EHC p. 32

If both ROHC and EHC are configured for a DRB/MRB, the ROHC header shall be located after the EHC header. Figure 5.12.7-1 shows the location of the ROHC header and the EHC header in a PDCP Data PDU.

Reproduction of 3GPP TS 38.323, Fig. 5.12.7-1: Location of ROHC header and EHC header in a PDCP Data PDU

Figure 5.12.7-1: Location of ROHC header and EHC header in a PDCP Data PDU

If a PDCP SDU including non-IP Ethernet packet is received from upper layers, the EHC compressor shall bypass the ROHC compressor and submit the EHC compressed non-IP Ethernet packet to lower layers according to clause 5.2.1.

If a PDCP Data PDU including non-IP Ethernet packet is received from lower layers, the EHC decompressor shall bypass the ROHC decompressor and deliver the EHC decompressed non-IP Ethernet packet to upper layers according to clause 5.2.2.