Linux Teleconferencing: Improving the Wireless Network
A stated goal of the Third Generation cellular standards bodies (3G) is for the wireless network to function as a seamless extension to the Internet and other IP-based packet network services. The brunt of the ground-breaking work we still await has been passed from companies to standards bodies to the Internet Engineering Task Force (IETF). IP transparency extends a plethora of services to the mobile devices already available to those with a wire line to the Internet, as well as simplicity and ease of adding new and more creative services explicitly designed to enhance wireless experience. An obvious result is an increase in the demand for wireless minutes by customers of the 3G carrier members.
The bandwidth available for broadband data transmission is both restricted and costly. Licenses for the frequency spectrum needed to support 3G services have been auctioned to network operators in the UK for $36 billion. More recently the Federal Communications Commission (FCC) raised a net $17 billion in a similar auction to US-based operators. This prompts carriers to improve the efficiency with which they employ the spectrum. The use of IP as a transport mechanism for voice (e.g., VoIP) requires the wireless network to carry real-time multimedia, even as it struggles to do non-real-time multimedia. For example, a full rate voice encoder like the G721.1 used by GSM-type networks generates 30ms (milliseconds) of payload, straddled with 40 bytes of a combined IP, UDP and real-time protocol (RTP) header as prescribed in the H.323 International Telecommunications Union (ITU) protocol for the delivery of multimedia. The 30ms of speech payload typically translates to 20 bytes, thereby giving us an efficiency of only 33%.
Header compression algorithms proposed to the IETF reduce the header down to one byte in steady state but have varying degrees of hobbling complexity. The header compression algorithm is required to present both bit-exact payload and an encapsulating IP protocol header to the mobile device. This is referred to as loss-less compression.
The benefits presented by header compression prove to be an imperative measure in increasing the spectral efficiency of multimedia communications, particularly since CRTP, proposed in the late 1990s by Cisco, is deemed insufficient, or not robust enough, by the involved steering committees of the IETF, as well as the Third Generation Partnership Project (3GPP).
The details of which header compression algorithm the IETF will choose have not been fully determined. Nonetheless, the requirements have been hammered out and are summarized in Table 1. In fact, the current proposals meet many of the requirements but are peppered with intellectual property rights—something that defeats the objective of the IETF. A second round of proposals are under consideration so that different methodologies may be solicited. The current algorithms exploit the nature of the IP/UDP/RTP streams. Tables 3, 4 and 5 classify the nature of the header field for each protocol IP, UDP and RTP respectively. Table 2 defines the classifications.
The essences of these algorithms are the strategies borne from these classifications. They are “never send”, “communicate at least once”, “communicate at least once or update”, “communicate update and/or refresh frequently”, “guarantee continuous robustness”, “communicate as is in all packets and establish” and “be prepared to update delta”.
Telecommunications companies that have pursued this approach to compress packet headers range from Nokia, Matsushita and Cisco to, most notably, Ericsson, for their heavyweight effort. The full details of their proposed algorithm have been submitted in IETF draft form and can be found at http://www.dmn.tzi.org.org/ietf/rohc/.
- Reality is disapointing
8 min 49 sec ago
- Máy sấy quần áo
2 hours 54 min ago
- Services on GlusterFS
3 hours 4 min ago
- máy lọc nước
3 hours 55 min ago
- Máy lọc nước
3 hours 58 min ago
- Reply to comment | Linux Journal
4 hours 44 min ago
- Definitely cool stuff here
5 hours 46 min ago
- thanks for the information
6 hours 57 min ago
- nice information thanks
7 hours 35 min ago
10 hours 31 min ago