Reference 0 X 0000 No compression RFC 4995 0 X 0001 RTP/UDP/IP RFC 3095, RFC 4815 0 X 0002 UDP/IP RFC 3095, RFC 4815 0 X 0003 ESP/IP RFC 3095, RFC 4815 0 X 0004 RFC 3843, RFC 4815 0 X 0006 TCP/IP RFC 4996 0 X 0101 RTP/UDP/IP RFC 5225 0 X 0102 UDP/IP RFC 5225 0 X 0103 ESP/IP RFC 5225 0 X 0104 RFC 5225 i Encapsulating Security Payload (ESP) is a key component of the IPsec protocol suite. The ESP protocol provides confi- identiality and integrity by encrypting data to be protected and placing the encrypted data in the data portion of the IP ESP. Depending on the user's security requirements, this mechanism may be used to encrypt either a transport-layer segment (e.g., TCP, UDP) or the entire IP datagram. Encapsulating the protected data is necessary to provide confidentiality for the entire original datagram. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is not recommended because of insecurity. Unlike Authentication Header (AH), ESP does not protect the IP packet header. However, in the Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is applied to the entire inner IP packet (including the inner header) while the outer header remains unprotected. ESP operates directly on top of IP using IP protocol number 50 [24]. CHAPTER 5 The IEEE 802. 16m Convergence Sub-Layer PDCP entities associated with DRBs can be configured by upper layers to use header compression. RFC 4995 has configuration parameters that are mandatory and that must be configured by upper layers between compressor and decompressor peers. Those parameters define the ROHC channel. As described earlier, the ROHC channel is a uni-directional channel, i.e., there is one channel for the downlink and one for the uplink. Therefore, there is one set of parameters for each channel and the same values are used for both channels belonging to the same PDCP. The ciphering function includes both ciphering and deciphering and is performe