Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 38.323  Word version:  18.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.4…   5.8…   5.13…   6…   6.2.3…   7…   A…   B… 
5.4 Status reporting  5.4.1 Transmit operation  5.4.2 Receive operation  5.5 Data recovery  5.6 Data volume calculation  5.7 Robust header compression and decompression  5.7.1 Supported header compression protocols and profiles  5.7.2 Configuration of ROHC  5.7.3 Protocol parameters  5.7.4 Header compression using ROHC  5.7.5 Header decompression using ROHC  5.7.6 PDCP Control PDU for interspersed ROHC feedback  5.7.6.1 Transmit Operation  5.7.6.2 Receive Operation 
...

 

5.4  Status reporting  p. 23

5.4.1  Transmit operation  p. 23

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.
Up

5.4.2  Receive operation  p. 24

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.

5.5  Data recovery  p. 24

For AM DRBs, when upper layers request a PDCP data recovery for a radio bearer, the transmitting PDCP entity shall:
  • perform retransmission of all the PDCP Data PDUs previously submitted to re-established or released AM RLC entities in ascending order of the associated COUNT values for which the successful delivery has not been confirmed by lower layers, following the data submission procedure in clause 5.2.1.
After performing the above procedures, the transmitting PDCP entity shall follow the procedures in clause 5.2.1.
Up

5.6  Data volume calculation  p. 24

For the purpose of MAC buffer status reporting, the transmitting PDCP entity shall consider the following as PDCP data volume:
  • the PDCP SDUs for which no PDCP Data PDUs have been constructed;
  • the PDCP Data PDUs that have not been submitted to lower layers;
  • the PDCP Control PDUs;
  • for AM DRBs, the PDCP SDUs to be retransmitted according to clause 5.1.2 and clause 5.13;
  • for AM DRBs, the PDCP Data PDUs to be retransmitted according to clause 5.5.
If the transmitting PDCP entity is associated with at least two RLC entities, or with one or more RLC entities and either an SRAP entity or the N3C, when indicating the PDCP data volume to a MAC entity for BSR triggering and Buffer Size calculation (as specified in TS 38.321 and TS 36.321), the transmitting PDCP entity shall:
  • if the PDCP duplication is activated for the RB:
    • indicate the PDCP data volume to the MAC entity associated with the primary RLC entity, or the MAC entity associated with the SRAP entity if the MP primary path is the indirect path;
    • indicate the PDCP data volume excluding the PDCP Control PDU to the MAC entity associated with the RLC entity other than the primary RLC entity, or the MAC entity associated with any Uu RLC entity, when the MP secondary path is the direct path, activated for PDCP duplication;
    • indicate the PDCP data volume as 0 to the MAC entity associated with RLC entity deactivated for PDCP duplication;
  • else (i.e. the PDCP duplication is deactivated for the RB or the RB is a DAPS bearer):
    • if the split secondary RLC entity is configured; and
    • if the total amount of PDCP data volume and RLC data volume pending for initial transmission (as specified in TS 38.322) in the primary RLC entity and the split secondary RLC entity is equal to or larger than ul-DataSplitThreshold:
      • indicate the PDCP data volume to both the MAC entity associated with the primary RLC entity and the MAC entity associated with the split secondary RLC entity;
      • indicate the PDCP data volume as 0 to the MAC entity associated with RLC entity other than the primary RLC entity and the split secondary RLC entity;
    • else, if the total amount of PDCP data volume, RLC data volume pending for initial transmission (as specified in TS 38.322) in either the primary RLC entity (when the MP primary path is the direct path) or the split secondary RLC entity on the direct path (when the MP primary path is the indirect path), and data volume pending for initial transmission in the N3C (if available), or mapped SL RLC entity associated with the SRAP entity, is equal to or larger than ul-DataSplitThreshold:
      • indicate the PDCP data volume to both the MAC entity associated with the Uu RLC entity (i.e., either primary RLC entity or split secondary RLC entity) and the MAC entity associated with the SRAP entity;
      • indicate the PDCP data volume as 0 to the MAC entity associated with Uu RLC entity other than the primary RLC entity or the split secondary RLC entity;
    • else, if the transmitting PDCP entity is associated with the DAPS bearer:
      • if the uplink data switching has not been requested:
        • indicate the PDCP data volume to the MAC entity associated with the source cell;
      • else:
        • indicate the PDCP data volume excluding the PDCP Control PDU for interspersed ROHC feedback associated with the source cell to the MAC entity associated with the target cell;
        • indicate the PDCP data volume of PDCP Control PDU for interspersed ROHC feedback associated with the source cell to the MAC entity associated with the source cell;
    • else:
      • 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 the indirect path:
        • indicate the PDCP data volume to the MAC entity associated with the SRAP entity;
        • indicate the PDCP data volume as 0 to the MAC entities associated with all Uu RLC entities on the direct path;
      • else:
        • indicate the PDCP data volume to the MAC entity associated with the primary RLC entity;
        • indicate the PDCP data volume as 0 to the MAC entity associated with the RLC entity other than the primary RLC entity.
Up

5.7  Robust header compression and decompression  p. 26

5.7.1  Supported header compression protocols and profiles  p. 26

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:
Profile Identifier Usage Reference
0x0000No compression RFC 5795
0x0001RTP/UDP/IP RFC 3095, RFC 4815
0x0002UDP/IP RFC 3095, RFC 4815
0x0003ESP/IP RFC 3095, RFC 4815
0x0004IP RFC 3843, RFC 4815
0x0006TCP/IP RFC 6846
0x0101RTP/UDP/IP RFC 5225
0x0102UDP/IP RFC 5225
0x0103ESP/IP RFC 5225
0x0104IP RFC 5225
Up

5.7.2  Configuration of ROHC  p. 26

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.
Up

5.7.3  Protocol parameters  p. 26

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.
Up

5.7.4  Header compression using ROHC  p. 27

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.
Up

5.7.5  Header decompression using ROHC  p. 27

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.
Up

5.7.6  PDCP Control PDU for interspersed ROHC feedback  p. 27

5.7.6.1  Transmit Operation  p. 27

When an interspersed ROHC feedback is generated by the ROHC protocol, the transmitting PDCP entity shall:
  • submit to lower layers the corresponding PDCP Control PDU as specified in clause 6.2.3.2 i.e. without associating a PDCP SN, nor performing ciphering, as specified in clause 5.2.1.

5.7.6.2  Receive Operation  p. 28

At reception of a PDCP Control PDU for interspersed ROHC feedback from lower layers, the receiving PDCP entity shall:
  • deliver the corresponding interspersed ROHC feedback to the associated ROHC protocol without performing deciphering.

Up   Top   ToC