Content for  TS 38.323  Word version:  18.0.0

For AM DRBs configured by upper layers to send a PDCP status report in the uplink (statusReportRequired in TS 38.331), the receiving PDCP entity shall trigger a PDCP status report when:

• upper layer requests a PDCP entity re-establishment;
• upper layer requests a PDCP data recovery;
• upper layer requests a uplink data switching;
• upper layer reconfigures the PDCP entity to release DAPS and daps-SourceRelease is configured in TS 38.331.

For UM DRBs configured by upper layers to send a PDCP status report in the uplink (statusReportRequired in TS 38.331), the receiving PDCP entity shall trigger a PDCP status report when:

• upper layer requests a uplink data switching.

For AM DRBs in the sidelink, the receiving PDCP entity shall trigger a PDCP status report when:

• upper layer requests a PDCP entity re-establishment.

For AM MRBs configured by upper layers to send a PDCP status report in the uplink (statusReportRequired in TS 38.331), the receiving PDCP entity shall trigger a PDCP status report when:

• upper layer requests a PDCP entity re-establishment;
• upper layer requests a PDCP data recovery.

If a PDCP status report is triggered, the receiving PDCP entity shall:

• compile a PDCP status report as indicated below by:
  • setting the FMC field to RX_DELIV;
  • if RX_DELIV < RX_NEXT:
    • allocating a Bitmap field of length in bits equal to the number of COUNTs from and not including the first missing PDCP SDU up to and including the last out-of-sequence PDCP SDUs, rounded up to the next multiple of 8, or up to and including a PDCP SDU for which the resulting PDCP Control PDU size is equal to 9000 bytes, whichever comes first;
    • setting in the bitmap field as '0' for all PDCP SDUs that have not been received, and optionally PDCP SDUs for which decompression have failed;
    • setting in the bitmap field as '1' for all PDCP SDUs that have been received;
• submit the PDCP status report to lower layers as the first PDCP PDU for transmission via the transmitting PDCP entity as specified in clause 5.2.1 for Uu interface and in clause 5.2.3 for PC5 interface.

For AM DRBs, when a PDCP status report is received in the downlink or in the sidelink, the transmitting PDCP entity shall:

• consider for each PDCP SDU, if any, with the bit in the bitmap set to '1', or with the associated COUNT value less than the value of FMC field as successfully delivered, and discard the PDCP SDU as specified in clause 5.3.

The ROHC protocol is based on the Robust Header Compression (ROHC) framework defined in RFC 5795. There are multiple ROHC algorithms, called profiles, defined for the ROHC framework. Each profile is specific to the particular network layer, transport layer or upper layer protocol combination e.g. TCP/IP and RTP/UDP/IP. The detailed definition of the ROHC channel is specified as part of the ROHC framework defined in RFC 5795. This includes how to multiplex different flows (header compressed or not) over the ROHC channel, as well as how to associate a specific IP flow with a specific context state during initialization of the compression algorithm for that flow. The implementation of the functionality of the ROHC framework and of the functionality of the supported header compression profiles is not covered in this specification. In this version of the specification the support of the following profiles is described:

PDCP entities associated with DRBs and MRBs can be configured by upper layers TS 38.331 to use ROHC. Each PDCP entity carrying user plane data may be configured to use ROHC. PDCP entities associated with sidelink DRBs can be configured to use ROHC for IP SDUs. For DRBs and MRBs other than DAPS bearers, the PDCP entity uses at most one ROHC compressor instance and at most one ROHC decompressor instance. For DAPS bearers, the PDCP entity uses at most one ROHC compressor instance (i.e. use the ROHC compressor instance for source cell before uplink data switching, and use the ROHC compressor instance for target cell after uplink data switching) and at most two ROHC decompressor instances.

RFC 5795 has configuration parameters that are mandatory and that must be configured by upper layers between compressor and decompressor peers ; these parameters define the ROHC channel. The ROHC channel is a unidirectional channel, i.e. if rohc is configured there is one channel for the downlink and one for the uplink, and if uplinkOnlyROHC is configured there is only one channel for the uplink. There is thus one set of parameters for each channel, and if rohc is configured the same values shall be used for both channels belonging to the same PDCP entity. These parameters are categorized in two different groups, as defined below:

• M: Mandatory and configured by upper layers;
• N/A: Not used in this specification.

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

• MAX_CID (M): This is the maximum CID value that can be used. One CID value shall always be reserved for uncompressed flows. The parameter MAX_CID is configured by upper layers (maxCID in TS 38.331);
• LARGE_CIDS: This value is not configured by upper layers, but rather it is inferred from the configured value of MAX_CID according to the following rule:
  • If MAX_CID > 15 then LARGE_CIDS = TRUE else LARGE_CIDS = FALSE;
• PROFILES (M): Profiles are used to define which profiles are allowed to be used by the UE. The list of supported profiles is described in clause 5.7.1. The parameter PROFILES is configured by upper layers (profiles for uplink and downlink, sl-RoHC-Profiles in SidelinkPreconfigNR for sidelink in TS 38.331);
• FEEDBACK_FOR (N/A): This is a reference to the channel in the opposite direction between two compression endpoints and indicates to what channel any feedback sent refers to. Feedback received on one ROHC channel for this PDCP entity shall always refer to the ROHC channel in the opposite direction for this same PDCP entity;
• MRRU (N/A): ROHC segmentation is not used.

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

• ROHC compressed packets, each associated with one PDCP SDU;
• standalone packets not associated with a PDCP SDU, i.e. interspersed ROHC feedback.

A ROHC 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. For DAPS bearers, the PDCP entity shall perform the header compression for the PDCP SDU using the ROHC protocol either configured for the source cell or configured for the target cell, based on to which cell the PDCP SDU is transmitted. Interspersed ROHC feedback are not associated with a PDCP SDU. They are not associated with a PDCP SN and are not ciphered.

If ROHC is configured by upper layers for PDCP entities associated with user plane data, the PDCP Data PDUs are decompressed by the ROHC protocol after performing deciphering as explained in clause 5.8. The header decompression is not applicable to the SDAP header and the SDAP Control PDU if included in the PDCP Data PDU. For DAPS bearers, the PDCP entity shall perform the header decompression for the PDCP SDU using the ROHC protocol either configured for the source cell or configured for the target cell, based on from which cell the PDCP SDU is received.