only; - one instance for each data radio bearer (DRB) relating to data traffic. Header compression is based on the ROHC mechanism for which multiple algorithms have been defined by the request for comments (RFC) specifications of the Internet engineering task force (IETF) standards body (Table 4.1). Profile identifier Compressed headers References 0x0000 uncompressed RFC 4995 0x0001 RTP/UDP/IP RFC 3095, RFC 4815 0x0002 UDP/IP RFC 3095, RFC 4815 0x0003 ESP/IP RFC 3095, RFC 4815 0x0004 RFC 3843, RFC 4815 0x0006 TCP/IP RFC 4996 0x0101 RTP/UDP/IP RFC 5225 0x0102 UDP/IP RFC 5225 0x0103 ESP/IP RFC 5225 0x0104 RFC 5225 Table 4.1. ROHC specifications Header compression is based on the observation that in a session, a number of fields are invariant, such as IP addresses or port numbers. Header compression is particularly effective when the size of the IP packet payload is relatively low, which is the case for voice (Figure 4.2). The decompressor uses the PDCP feedback control message to inform the compressor that decompression is successful or that synchronization between compression and decompression has been lost. VoLTE and ViLTE 12,2 kbps 12,2 kbps 244 bits every 20 ms 244 bits every 20 ms 12 bytes 8 bytes 4 bytes 20 bytes 28,2 kbps 13,8 kbps 564 bits every 20 ms 276 bits every 20 ms Figure 4.2. Header compression 4.1.1.2. RLC protocol The RLC protocol provides control of the radio link between the mobile and the eNB entity. The mobile can simultaneously activate multiple RLC instances, with each instance corresponding to a PDCP instance. The RLC protocol operates in three modes: - acknowledged mode (AM): session information protocol (SIP) uses this mode; - unacknowledged mode (UM): real-time transport protocol (RTP) uses this mode. - transparent mode (TM) for which no header is added. The RLC protocol performs the following operations: - retransmission in the case of error via the automatic repeat request (ARQ) mechanism, for the acknowledged mode only; - concatenation, segmentation and reassembly of PDCP frames both 