LTE: What does mean by ROHC segmentation ?

Question

In PDCP layer, there is functionality of timer based discard. Can anyone please elaborate on this functionality of PDCP layer.

Answer 1

Ref 4995/5.2.5

ROHC defines a simple segmentation protocol. The compressor may perform segmentation, e.g., to accommodate packets that are larger than a specific size configured for the channel.

The ROHC segmentation protocol has been designed with an assumption of in-order delivery of packets between the compressor and the decompressor, using only a CRC for error detection, and no sequence numbers. If in-order delivery cannot be guaranteed, ROHC segmentation MUST NOT be used.

The segmentation protocol also assumes that all segments of a ROHC packet corresponding to one context are received without interference from other ROHC packets over the channel, including any ROHC packet corresponding to a different context. Based on this assumption, segments do not carry CID information, and therefore cannot be associated with a specific context until all segments have been received and the whole unit has been reconstructed.

ROHC segmentation is applied to the combination of the Header and the Payload fields of the ROHC packet,

Segment format:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   1   1 | F |  segment type
   +---+---+---+---+---+---+---+---+
   /           Segment             /  variable length
   +---+---+---+---+---+---+---+---+

F: Final bit. If set, it indicates that this is the last segment of a reconstructed unit.

Padding and/or Feedback may precede the segment type octet. There is no per-segment CID, but CID information is of course part of the reconstructed unit. The reconstructed unit MUST NOT contain padding, segments, or feedback.

When a final segment is received, the decompressor reassembles the segment carried in this packet and any non-final segments that immediately preceded it into a single reconstructed unit, in the order they were received. All segments for one reconstructed unit have to be received consecutively and in the correct order by the decompressor. If a non-segment ROHC packet directly follows a non-final segment, the reassembly of the current reconstructed unit is aborted and the decompressor MUST discard the non-final segments so far received on this channel.

Reconstructed unit:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   /            Header             /  
   +---+---+---+---+---+---+---+---+
   :            Payload            :  
   +---+---+---+---+---+---+---+---+
   /              CRC              /  4 octets
   +---+---+---+---+---+---+---+---+

CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4.

If the reconstructed unit is 4 octets or less, or if the CRC fails, or if it is larger than the channel parameter MRRU

Answer 2

RObust Header Compression (ROHC) protocol defined by the IETF (Internet Engineering Task Force). In
LTE, header compression is very important because there is no support for the transport of voice services via the Circuit-Switched (CS) domain.2 Thus, in order to provide voice services on the Packet-Switched (PS) domain in a way that comes close to the efficiency normally associated with CS services it is necessary to compress the IP/UDP/RTP3 header which is typically used for Voice over IP (VoIP) services.

The IETF specifies in ‘RFC 4995’4 a framework which supports a number of different header compression ‘profiles’ (i.e. sets of rules and parameters for performing the compression).

The support of ROHC is not mandatory for the UE, except for those UEs which support VoIP. UEs which support VoIP have to support at least one profile for compression of RTP, UDP and IP.6 The eNodeB controls by RRC signalling which of the ROHC profiles supported by the UE are allowed to be used. The ROHC compressors in the UE and the eNodeB then dynamically detect IP flows that use a certain IP header configuration and choose a suitable compression profile from the allowed and supported profiles.
ROHC header compression operates by allowing both the sender and the receiver to store the static parts of the header (e.g. the IP addresses of the sender/receiver), and to update these only when they change. Furthermore, dynamic parts (for example, the timestamp in the RTP header) are compressed by transmitting only the difference from a reference clock maintained in both the transmitter and the receiver.
As the non-changing parts of the headers are thus transmitted only once, successful decompression depends on their correct reception. Feedback is therefore used in order to confirm the correct reception of initialization information for the header decompression. Furthermore, the correct decompression of the received PDCP PDUs is confirmed periodically, depending on the experienced packet losses.

Comments

I think Harshita is asking for Segmentation at ROHC, let me try to answer from 4995.