Article Preview
TopIntroduction
IEEE 802.16 (known as WiMAX) (IEEE, 2005) allows rapid deployment of media services in areas in the world unlikely to benefit from extensions to both 3G such as High Speed Downlink Packet Access (HSDPA) and Universal Mobile Telecommunications System (UMTS) such as Long-Term Evolution (Ekstrom et al., 2006). WiMAX’s uplink capacity should exceed that of HSPDA’s 384 kbps, though not LTE’s. In Brazil, mobile WiMAX is the basis of a digital TV service but there is also interest in exploitation of uplink interactive services (Meloni, 2008), which could involve media streaming. WiBRO in Korea is also now harmonized with WiMAX and likewise (Kim, Lee, & Lee, 2008) interactive media services are proposed. Uplink media streaming is a value-added addition to a broadcast IPTV service. As such it is attractive to commercial operators as it could be used for mobile video conferencing and video telephony, as well as the exchange of personal video clips.
For these services, selection of appropriate video transport and uplink (UL) queue management will be important to reduce packet loss and latency. Therefore, the contribution of this paper is to make recommendations for video streaming sourced from a WiMAX Subscriber Station (SS). The paper particularly examines active queue management (AQM) schemes over IEEE 802.16 networks. We compare RED, REM, BLUE, and question whether they offer any advantage over drop tail queue management schemes. We also compare simple UDP and congestion-controlled TCP-Friendly Rate Control (TFRC) (Handley et al., 2003) video stream transport. A number of schemes (e.g., Fu et al., 2006) have been developed for TFRC-based streaming over a wireless network, particularly if a further network path exists over a core wired network (Görkemli, 2008). While a basic UDP stream represents an AQM non-compliant source (see the next paragraph), TFRC represents an AQM compliant source. As TFRC responds to packet loss, as well as round-trip time and packet size, it will change its rate if packets are actively dropped from an SS queue. TFRC is intended to provide a less aggressive congestion control than TCP’s ‘sawtooth’ response to network congestion, resulting in a smoother sending rate more suitable for video streams.
Within the wired Internet, AQM techniques (Koo, Ahn, & Chung, 2004) are intended to achieve high link utilisation without introducing delays. The most well-known AQM technique is Random Early Detection (RED) (Floyd & Jacobsen, 1993) in which packets in the queue are intentionally dropped or explicitly marked as a signal to the source to reduce its rate. For a compliant source a dropped packet prompts the congestion control mechanism to reduce its sending rate. For a non-compliant source, one that does not reduce its rate, RED also keeps the queue size low but does not discriminate against ‘bursty’ traffic sources. Dropping occurs in a probabilistic fashion according to the time-wise, exponentially-averaged queue size and, to avoid unreasonable overhead, no record is kept of the state of each connection. By random dropping, rate synchronization amongst compliant sources is avoided.
Our simulation results show that, though a particular queuing discipline may be more suspect than others, in the scenario investigated all the examined AQM schemes can lead to oscillatory queue occupancy during periods of congestion, which makes them unsuitable for video streaming over IEEE 802.16 networks. In fact, one cannot rely on prior studies advocating one AQM technique or another if these studies do not investigate temporal behavior.
A possible solution in a dedicated WiMAX DTV service is priority treatment of video reference frames. For general media streaming, our work suggests that strict access control will be needed for WiMAX uplink services to reduce the risk of congestion adversely affecting video transfer. When congestion occurs, a packet dropping policy should again reflect the relative importance of video frame types and their contribution to the data load. However, this is not straightforward because the frame types in use can vary according to the codec profile.