Radio Link Efficiency

A radio interface is bandwidth constrained because it is bound to use limited spectrum. Although 3G networks claim to provide bit rates up to 2 Mbps, it is still a far cry from the 52.8 Mbps a very high data rate digital subscriber line (VDSL) can offer on a single twisted-pair copper loop. Similarly, bit rate of 11 Mbps in WLAN is no comparison to 1 Gbps of the gigabit Ethernet (IEEE 802.3). Therefore, it is highly desired to use the available bandwidth as efficiently as possible, so as to give the user a decent performance for IP compared to the wired world. Moreover, cellular operators pay a significant amount of their deployment costs in acquiring a spectrum. Therefore, radio link efficiency is also highly desired for cost savings.
One approach to improving efficiency for some IP protocols is to use header compression. A problem with IP is its large header overhead. This problem is more visible for those real-time applications where a packet is generated at a very fast rate and the payload size is comparable or even smaller to the header size. For example, an RTP (real-time protocol) packet carrying interactive voice conversation could have an IPv6 header of 40 bytes, a UDP header of 8 bytes, and an RTP header of 12 bytes, making the total header bytes equal to 60 bytes.

The size of the payload, depending on the speech coding, could be as low as 15 to 20 bytes. In this example the header size is twice the payload size. The Robust Header Compression ROHC working group has developed [RFC 3095] header compression schemes for RTP/UDP/IP. The schemes can reduce the header size down to one or zero byte. The wireless links also need to have robust header compression for the other protocols, such as TCP and SCTP.Bandwidth efficiency can also be improved by performing compression on IP payloads. The IP Payload Compression Protocol (IPComp) [RFC 2393] defines a framework for payload compression. The 3GPP2 network uses the PPP from the PDSN to the MS and has suggested using the PPP Compression Control Protocol [RFC 1962] for PPP payload compression. Bluetooth LAN access profile also suggests using PPP and PPP payload compression.
However, if the encryption is applied to IP datagrams, the compression at a lower layer (e.g., PPP) becomes ineffective. IPComp is especially useful when encryption is applied to IP datagrams. RFC 2757 provides a good analysis of the feasibility of IP payload compression. It suggests that IP payload compression is something of a niche optimization and may not be always useful. It also says that many of the IP payloads are already compressed (images, audio, video, "zipped" files) by the applications or are already encrypted above the IP layer. These payloads will not compress further, limiting the benefit of this optimization. Also, the application-level compression can often outperform IPComp because the applications can use compression dictionaries based on knowledge of the specific data being compressed. Therefore, for payload compression the best bandwidth efficiency can be achieved if application-level compression techniques are used extensively. The challenge is to ensure that all the applications have a compression mechanism and are using them over wireless links.