Enhancing multimedia streaming over existing wireless LAN ...

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT Int. J. Network Mgmt 2007; 17: 331–346 Published online 7 August 2007 in Wiley InterScience (www.interscience.wiley.com) DOI: 10.1002/nem.667

Enhancing multimedia streaming over existing wireless LAN technology using the Unified Link Layer API Tim Farnham*,†, Mahesh Sooriyabandara and Costas Efthymiou Telecommunications Research Laboratory, Toshiba Research Europe Ltd., Bristol, UK

SUMMARY This paper examines how multimedia streaming scenarios can be enhanced by cross-layer interaction, and in particular link performance information and configuration options provided by the recently developed Unified Link Layer API (ULLA). It provides results of an experimental implementation developed for this purpose in a wireless LAN (WLAN) environment. Multimedia streaming is an application that is gaining in popularity for mobile devices and in particular mobile Internet-based content broadcasting is rapidly emerging as a key feature on mobile devices. In these scenarios, the wireless link (last hop) is normally the performance bottleneck due to the dynamic and limited capacity of the wireless medium. The use of ULLA in this context can provide the ability to tailor the video transmission to the wireless link performance and also to configure the links in response to performance problems or environmental changes. For this purpose the focus of multimedia streaming has been on WLAN link technology and dynamic adaptation (i.e., dynamic channel selection and video transcoding) using a dynamic resource reservation overlay protocol. Copyright © 2007 John Wiley & Sons, Ltd.

1. INTRODUCTION Multimedia streaming is a class of application that is gaining in popularity for mobile devices and, in particular, mobile Internet-based content broadcasting is rapidly emerging as a key feature in mobile devices. It is envisaged that many of these mobile devices will exploit the widely used wireless LAN technology to receive audio/video streaming services, making the last hop of the communications path a wireless link. The dynamic and unreliable nature of these wireless links often brings a set of challenges to multimedia applications that need to be overcome for acceptable performance levels. In the context of the investigation performed to evaluate multimedia streaming, we regard streaming to imply a near real-time requirement for transporting and displaying the multimedia content. We also consider there to be multicast and broadcast requirements that are quite unique to this type of service, but this does not necessarily imply the need to use broadcast wireless technology. However, it is desirable to exploit the ability of wireless technology to support these requirements efficiently. For instance, WLAN technology can support broadcast of near real-time traffic, but generally in an unreliable manner, or alternatively unicast traffic with less predictable latency. This unreliability and unpredictable latency result in packet losses, which can occur for two reasons. They can be caused by irrecoverable transmission errors on the link (resulting from channel impairments or packet collisions), or by link layer buffer overflow due to congestion. An optimization algorithm that aims to improve performance of multimedia streaming over WLAN technology needs to have a certain set of information regarding the status of the channel or link that it is to optimize in order to achieve the desired performance enhancement. We

*Correspondence to: Tim Farnham Telecommunications Research Laboratory, Toshiba Research Europe Ltd, 32 Queen Square, Bristol BS1 4ND, UK. † E-mail: [email protected]

Copyright © 2007 John Wiley & Sons, Ltd.

Received October 2006 Revised February 2007 Accepted March 2007

332

T. FARNHAM, M. SOORIYABANDARA AND C. EFTHYMIOU

use the Universal Link Layer API (ULLA) [1,2] in this paper to assess the status of the wireless environment and then decide how to go about enhancing the performance of multimedia transmission. It is not easy to determine the exact cause of packet errors in WLAN broadcast streaming scenarios as there is typically a limited amount of feedback at the link layer to determine why transmission errors have occurred, and also inconsistency in the method of reporting this information depending on device vendors and operating systems. This inconsistency is one of the problems selected for solution by ULLA. ULLA provides generic mechanisms to allow notification of link performance events and statistics to be passed to applications in a technology- and platform- (operating system) independent manner. It also allows applications to select and configure links when necessary. The main aim of the ULLA concept is to abstract link information and API interactions in a sufficiently general manner to permit a high degree of radio technology and platform independence. This permits exploitation on different embedded mobile devices without the application developer needing to be concerned with the specific details of radios and operating systems in different mobile devices. In this way, ULLA can provide link performance statistics and allow applications to configure links when performance impairments become unacceptable or when performance improvements can be made via other options that become available. Two types of adaptation are considered in this paper. Firstly, we consider the adaptation of radio link configuration in response to radio link transmission performance impairments. Secondly, we consider video transcoding adaptation in response to link congestion. In both cases we consider the radio link as the last hop in the communication path from video server to mobile clients. The following sections describe the scenarios and performance evaluation conducted for the two types of adaptation, but first the ULLA concepts and implementation details are introduced. 2. UNIFIED LINK LAYER API 2.1 Existing approaches

There are several APIs available on different platforms that abstract link characteristics and permit control of the underlying links. For instance, the Linux wireless extensions [3] permit control of wireless LAN devices on the Linux OS, while the Network Device Interface Specification (NDIS) achieves the same on WindowsTM platforms. However, these previous approaches are limited in that they do not provide a technology- and platform-independent approach. Therefore, different techniques must be used to obtain information from different link technologies, such as wireless LAN and cellular interfaces, and for different OS platforms. Also, the previous approaches do not provide a rich generic querying mechanism that supports both synchronous query and asynchronous notifications, or the extensible data model that permits support for both generic attributes and technology-specific enhancements. 2.2 ULLA concept

The ULLA framework tries to address the complexity and interoperability problems related to the large number of technology- and operating system-specific APIs available today [1]. It does so firstly by defining an operating system-independent interface, and secondly by offering a unified, technologyindependent view of the wireless links and technologies available on a platform. It provides a set of handles to access and control communication facilities, enabling new ways of developing link- and application-aware optimization algorithms. The generic interface supports mechanisms not only for accessing information from the underlying link technologies, but also for the issuing of commands to control the configuration of available links and wireless interfaces. Figure 1 illustrates functional components that constitute the ULLA architecture. There are three core services: command, query and event capabilities that are implemented by ULLA and are offered to Link Users through the ULLA Link User API. Link Users can include any higher-layer protocols, middleware or application software that wishes to use services provided by ULLA. Queries could be either synchronous information requests or asynchronous notification subscriptions which are Copyright © 2007 John Wiley & Sons, Ltd.

Int. J. Network Mgmt 2007; 17: 331–346 DOI: 10.1002/nem

ENHANCING MULTIMEDIA STREAMING USING ULLA

333

Figure 1. ULLA architecture diagram specified using a query language called UQL (ULLA Query Language), essentially a subset of the widely used Structured Query Language (SQL). ULLA processes the information requests and returns appropriate link information back to the Link Users immediately. Events refer to the flexible asynchronous notifications that signal changes in the conditions of the link and channels, based on configurable criteria specified by the Link User. ULLA event-processing functionality forwards appropriate link configurations, measurements, statistics and other link events to applications in an asynchronous manner. Commands allow Link Users to configure links and Link Providers in a standard way. ULLA conceals the technology-specific details of link technologies from Link Users by abstracting link technologies through a generic ullaLink class which represents communication services provided by Link Providers. In this context, Link Providers are devices or software entities that provide a communication facility which interfaces with ULLA using the ULLA Link Provider API, as shown in Figure 1. An entity called a Link Layer Adaptor (LLA) is used to provide a proxy interface to integrate legacy drivers to the ULLA. Technology-specific details are captured by extending this generic class using class inheritance techniques. Optionally, a data storage that keeps link-specific information centrally, allowing efficient information access by Link Users, is also defined by the ULLA framework. In general, ULLA provides the flexibility required to support features of a diverse range of legacy and future access technologies as well as the requirements of various Link Users by means of an object-oriented design. This accommodates the specific needs of multimedia optimization and adaptation scenarios by offering flexibility in terms of measurement configuration and statistics gathering of link- and channel-related parameters. 2.3 ULLA implementation

The component diagram in Figure 2 illustrates the main components within the implementation and their dependencies. The Link Manager (LM) within the ULLA permits the arbitration of potential conflicts between operations invoked by different Link Users. The LU (Link User) component is an executable application in native or Java (or JavaScript) code. When it registers with the ULLA three threads are created, these being a periodic action thread, an IPC (Inter-Process Communication) thread (for interaction with the LPs (Link Providers) and LM ) and a listener thread for database trigger events. Likewise, when the LP registers with the ULLA, two threads are created as the periodic action thread is not required at the LP level. The periodic action thread is responsible for handling periodic commands and notifications requested by the LU or LM. The IPC thread is responsible for command and authorization interactions between the LU, LM and LP. When an LM is registered with the ULLA core, all LU operations have to be authorized by the LM and therefore, when an operation is invoked by the LU, it is forwarded Copyright © 2007 John Wiley & Sons, Ltd.


334


«executable» linkUser «thread» luPeriodicThread

«executable» LinkManager «thread» luListenerThread

«thread» luIPCThread

«thread» lmIPCThread

«thread» lmListenerThread

lmAuthorizationHandlers

LuIf

static or dynamic linking

UllaCore

postgres ullaLuIf

«delegate» «executable» lla

«library» libulla

«library» :libpq

«delegate» ullaCommandIf

ullaQueryIf

:ullaCommandProcessing

:ullaQueryProcessing

libtvos

«thread» lpIPCThread «library» :tvos

:ullaEventProcessing

«thread» lpListenerThread

libsmc

ullaLpIf

lpIf

«delegate» ullaEventIf «library» :libsmc

dynamic or static linking

Figure 2. Component diagram of ULLA implementation to the LM and the LM can either accept, reject or perform the action on behalf of the LU. The LM and LP have a higher privilege level than normal LUs and on Linux run with superuser privileges. The LU normally runs with user-level privileges and so this necessitates a secure IPC mechanism to traverse the two domains. This is achieved with two access levels for shared resources: a normal LU level, which LUs can access, and a privileged (LM and LP) level, which LUs do not have write access to. The shared memory access functionality is contained in the library libsmc and the IPC mechanism API within the library libtvos. 2.4 ULLA storage

The ULLA data storage implementation is based on a publicly available database solution called PostgresTM [4]. The Postgres back-end server provides the ULLA storage facility in an extensible and fully featured SQL standard compliant approach; it also provides additional (non-standard) functionality such as support for triggers and different access control security mechanisms. This enables the dynamic loading of trigger functions and can allow for more complex statistical or other data manipulation functions to be inserted into the database back-end. A separate library (i.e., ullafn library) includes all the functions required by the back-end server (e.g., trigger functions, arithmetic and statistical functions). This additional functionality comes with added overhead in terms of memory occupation and higher processing cost. Therefore the use of the Postgres database is only recommended for high-end devices with adequate resources (e.g., laptops and high-end PDAs) as opposed to resource-limited devices. The PolyhedraTM [5] SQL-compliant database provides a similar set of features to the Postgres approach, with the addition of real-time operation (memory resident) and active query mechanisms. This makes it attractive for supporting ULLA notifications, while still providing the same SQL standard features of the Postgres-based solution. A low-footprint version of Polyhedra (called Polyhedra FlashliteTM) Copyright © 2007 John Wiley & Sons, Ltd.



Attribute name ‘signalStrength’ ‘noiseLevel’ ‘activity’

Units

Type

ULLA_DBM ULLA_DBM ULLA_BYTES

ULLA_LINK ULLA_LINK ULLA_CHANNEL

Window

335

Interval

Min.

Max.

Min.

Max.

1 1 1

1000 1000 1000

1 1 −100

1 1 −10 000

Table 1. Measurement capability of LLA is also available that makes it attractive for lower-end devices and in particular embedded devices with flash memory-based file systems. 2.5 Link Layer Adapter

We have developed (jointly with other project partners [1]) an IEEE 802.11 LLA that supports the LP concept for existing WLAN devices. The LLA was written for the Linux operating system and uses standard Linux wireless extensions [3] to interface with the device driver. The current version of the LLA supports a number of commands, including scanAvailableLinks, connect and disconnect. The setAttribute() function call is used for configuring wireless parameters such as frequency channel and mode. The LLA also extracts a number of performance-related parameters, including signal and noise levels, from the driver using the wireless extensions’ iwspy and iwevent mechanisms. Finer control over how these parameters are measured is achieved through measurement configuration performed through the ULLA API. The channel class is supported by the LLA and the monitoring of frequency channel-related activity (as shown in Table 1) is provided by putting the radio into monitoring mode and measuring the transmissions on each channel in turn. As this process is disruptive to active data communications, it is currently necessary to have two radio devices active in order to perform continuous monitoring. However, in the future it may be possible to have single radio devices which support simultaneous monitoring and transmission. Other measurement information supported by the LLA includes packet drop events (e.g., caused by excessive retry or buffer overflow) and transmit/receive frame and byte counters. The LLA includes measurement statistics support for computing the mean, maximum, minimum, variance and standard deviation of measurement values (such as those shown in Table 1). For the noise level (which is a measurement taken immediately prior to reception of a valid packet) and signal strength (which is a measurement taken at the start of packet reception) attributes, the statistics are computed over a specified (non-overlapping) window and interval, which are given in terms of the number of frames successfully received (as denoted by positive interval values; negative numbers are used for timebased intervals). In this case, the signal strength is recorded for each packet received and the minimum, maximum, mean, standard deviation and variance calculated over the current window setting. These statistics are recorded separately for each link. The activity is the number of bytes in transmissions observed on the channel in the given interval over the specified time window (given in number of intervals with a minimum of 1 and maximum of 1000). However, as monitoring on each frequency channel is not a continuous process (as the radio can only monitor one channel at a time), the interval in this case also determines the dwell time on each channel. The activity measurements and statistics are calculated for each channel separately. 2.6 ULLA interfaces

The implementation consists of a core ULLA library component which can be dynamically or statically linked to the LU, LM or LP components and a database access library component. Upon registration of an LU, LM or LP—by calling the ullaRegisterLp, ullaRegisterLm or ullaRegisterLu functions, respectively— a number of threads are created. These handle the asynchronous events sent from the ULLA database to the LU or LP and also perform periodic actions such as notifications. The event threads listen on sockets to messages sent from the database back-end which are triggered by updates on the database. Copyright © 2007 John Wiley & Sons, Ltd.


336


The Java and Javascipt APIs are wrapper APIs that expose the ULLA functions to Java and JavaScript programmers, respectively. The Java and JavaScript ULLA functions are accessed via the Ulla class in a similar manner to the C API. The main difference is that the arguments are passed into the API functions directly rather than using C structures; this is because the JavaScript environment supports extensibility in the number of arguments passed and also because structures and memory pointers are not supported in Java environments. The JavaScript ULLA built-in functions are shown in the following example. function changeLink() { var ULTuples = 0 var ULId = new Array() var Network = new Array() var RxBitRate = new Array() var TxBitRate = new Array() var Tuple=0 var Result var BitRateMax = 0 var MaxUl = 0 ULTuples = Ulla.resultNumTuples() for (Tuple =0; Tuple BitRateMax) { BitRateMax = RxBitRate MaxUl = Tuple; } } Ulla.resultFree() if (State[MaxUl] == Ulla.MEDIASTATE_DISCONNECTED) Result = Ulla.doCmd(ULId[MaxUl], “connect”) } with (Ulla) { registerLu(“TESTLU”, “Javascript Link User”, “1.0”, Ulla.ROLE_TRUSTED_LU, exceptionHandler) requestNotification(“SELECT id, networkName, rxBitrate, txBitrate, state from ullalink WHERE txBitRate = {SELECT MAX(txBitRate) from ullalink}”, 0, 0, changelink) } The above example is the JavaScript code required to request a notification (via the changeLink function) when the maximum Tx bit rate of the available links changes. A check (within the changeLink function) is then performed to determine which of these links has the maximum Rx bit rate. If this link is not currently connected, a connection is attempted via the doCmd call, thus switching from the old link to the new link (if permitted to do so by ULLA). Copyright © 2007 John Wiley & Sons, Ltd.



337

The JavaScript can be embedded into HTML documents directly or via a referenced URL. The JavaScript is then loaded and executed within the browser code. The Mozilla SpiderMonkey (http://www.mozilla.org/js/spidermonkey/) based JavaScript engines within the Firefox, minimo and webc browsers have been used to test this approach. Firefox and minimo are open-source browsers that are part of the Mozilla project (www.mozilla.org) and the webc browser is a lightweight portable embedded browser from ebs (www.ebsnetinc.com) that runs on any 32-bit OS platform with processor speed greater than 30MHz and greater than 1 Mbyte of RAM. This makes deployment of ULLA-enabled agents very attractive for providing link configuration and remote information reporting in such limited embedded environments. These environments can also support the Secure Socket Layer (SSL) implementation to provide a secure method of controlling the link configuration, which is important to avoid rogue agent misbehaviour. For example, when the JavaScript script is downloaded from a server device using SSL it can be verified that this is the original script and that only the original script can subsequently perform a configuration request on the server (via an HTTP post operation) without any need to rely on the underlying link security mechanisms. The benefit of this approach is illustrated in Figure 3, in which the packet loss monitoring function can use ULLA to report events and update the statistics to enable an ULLA agent (a JavaScript script containing the performance reporting function) to then report back the information to the packet scheduling function (at the transcoding proxy). Also, the notification of performance degradation can be handled within the agent script to, if necessary, automatically activate a change in link configuration.

Data plane

Video Clients

Loaders

Server laptop Video Client 1

Netperf server 1

UDP IP

Host AP 1 Video server

Transcoding proxy

UDP

Router

IP

IP Ethernet

Ethernet

IP Ethernet

UDP

802.11

Netperf client 1

TCP

802.11

IP 802.11

UDP

IP Ethernet

Ethernet

TCP

IP

Video Client 2

Ethernet

Netperf server 2

UDP Host AP 2 Ethernet

802.11

TCP IP

802.11

Netperf client 2

TCP IP 802.11

Control plane

TCP IP

= Packet scheduling Fn = Packet loss monitoring Fn = Performance reporting agent

Overlay protocol server / agent TCP

Host AP 1 Ethernet

802.11

802.11

ICMP IP

TCP

Ethernet

IP Host AP 2 Ethernet

802.11

802.11

ICMP IP 802.11

Figure 3. Protocol reference circuits for experimental implementation Copyright © 2007 John Wiley & Sons, Ltd.


338


3. LINK ADAPTATION There are many link layer parameters that could be adapted when performance degrades, for instance transmission rate (bit rate), packet fragment size (and threshold), retry limit and the Request To Send/Clear To Send (RTS/CTS) mechanism enabled or disabled. However, for unicast transmission these parameters are often configured dynamically by the optimization algorithms within the link layer. Therefore, the benefits are generally limited, particularly for unicast links carrying TCP-based data with link layer retransmission and transport layer window-based flow/congestion control mechanisms. An important exception to this is the frequency of the channel that the link uses. Typically this is statically assigned and does not change even if better channels become available. Therefore, it is an important parameter that can be dynamically selected to enable interference avoidance, and thus can potentially achieve high performance improvement in congestion scenarios where there is too much contention for network resources. There is also a trend towards more flexible spectrum utilization based on cognitive radio concepts, and this scenario can be considered as a first step towards frequency agile cognitive radio systems. In contrast to the reliable TCP data support, streaming services are not well catered for in WLAN scenarios. The unreliable and dynamic nature of WLAN transmission is well documented [6] and it results in high packet loss that can clearly be improved by modifying the existing channel access and retransmission protocols. Packet losses can occur for two reasons in these scenarios. They can be caused by irrecoverable transmission errors on the link (for instance, as a result of collisions and fading) or by link layer buffer overflow, as WLAN devices have no congestion indication or avoidance mechanisms. Protocol enhancements can be made by reducing the contention for network resources, such as using prioritized access schemes within the IEEE 802.11e Enhanced Distributed Coordination Function (EDCF) specification or by contention-free polling mechanisms, as provided by the Point Coordination Function (PCF) in the IEEE 802.11 specification. Alternatively, adapting the existing channel access and retransmission protocols can be performed by adding proprietary overlay protocols [7] that exploit the ULLA concept without requiring new WLAN device replacement. The Windows OS contains overlay mechanisms to provide better support for streaming traffic. These are based on rate control, prioritisation and traffic-shaping mechanisms incorporated into the QoS scheduling protocol driver. However, this approach does not consider any status information from the wireless network devices, e.g. the wireless network load/contention or packet loss events. In contrast, our approach utilizes ULLA to provide notification of performance degradation events and reacts dynamically to this. 3.1 Dynamic channel selection

A channel class concept has been developed (and included as an option within the ULLA specification) to provide sufficient information to permit intelligent dynamic channel selection. The channels can be either frequency channels, time domain channels or indeed any other form of resource sharing (multiplexing) scheme (such as spatial multiplexed channels), and in this manner no unnecessary constraints are placed on the possible adaptation options that can be supported. Also, a channel does not necessarily have to be actively in use for information relating to the channel to be obtained. A simple example of this is in dynamic frequency selection schemes, in which the activity on different channels is observed before selecting the least loaded. The abstraction of frequency channels is straightforward as there are a fixed number (depending on the regional regulations) of frequency channels which it is permissible to use for a certain link technology. Therefore, the technology indication is included in the channel abstraction along with generic attributes such as bandwidth and activity, to allow for this distinction. The frequency channels can also be used in a frequency-hop spread-spectrum manner (for instance, in Bluetooth technology) and so the abstraction also permits the definition of whether the channel is included or excluded from a frequency hop set for use in adaptive hopping or dynamic channel selection schemes. The time channel abstraction permits fixed or dynamic time assignment schemes (such as prioritized access in 802.11e EDCF, the polling scheme used in the 802.11 PCF or the enhancement overlay protocol Copyright © 2007 John Wiley & Sons, Ltd.



339

with a frame structure shown in Figure 4), with separate time channel instances corresponding to each particular time-sharing scheme. A time channel can then be selected (for use on a particular link) based on the generic characteristics of the channel object and whether it is available or not due to regulatory or other policy-based reasons. The problem with time-based channels, as with more complex frequencyhopping schemes, is that the current activity (which can reflect the percentage occupancy or number of transmitted frames or bytes) on the channel is not sufficient to determine its suitability for use. More performance information about the channel is required and this must also be available for each traffic class if differentiated services are supported (such as prioritized access schemes). Therefore, the additional information used for time channels is as follows: • • • • • • • • •

sTxFrames—Tx frames count for each service class sRxFrames—Rx frames count for each service class sTxLatency—Tx latency for each service class sRxLatency—Rx latency for each service class sTxBitRate—Maximum Tx data rate for each service class sRxBitRate—Maximum Rx data rate for each service class sTxOverhead—% overhead of the Tx channel scheme sRxOverhead—% overhead of the Rx channel scheme sTxDropped—Count of the number of dropped frames for each service class

3.2 Dynamic resource reservation

The dynamic resource reservation overlay protocol utilizes Internet Control Message Protocol (ICMP)based signalling to interact between packet scheduling functions in different devices. As this is a generic link-independent overlay approach it has all the advantages of inherent flexibility of overlay protocols [8]. However, an overlay approach has the drawback of being constrained by existing underlying link technologies. As we make no assumptions about the device capabilities, the overlay has to cope with this. The overlay also has to use generic signalling methods that are available in WLAN environments, which means that the signalling itself may be less reliable (e.g., broadcast ICMP packets are used). The overlay approach utilizes ULLA to obtain channel activity, packet loss and other performance information from the link layer (such as frame and byte counts). This information is returned to the control point (the transcoding proxy in this case) and is used to trigger the contention-free reservation mechanism. Therefore, the ULLA notification mechanism is used within ULLA agents (which handle the performance monitoring function) to trigger activation and deactivation of the reservation mechanism, based on the level of congestion and interference detected. When active, the transcoding proxy sends a broadcast ICMP control packet to indicate the start and end of the contention-free period and the end of the super-frame period. Devices that do not have reserved slots assigned to them defer transmission attempts until the contention period. The frame structure (see Figure 4) allows virtual contention-free access to the channel for the video service class by reserving time slots within the super-frame structure for the video frames. Data-loading traffic, on the other hand, has to defer transmission based on the contention-free period value x sent by the proxy in the broadcast assignment ICMP control message (see Figure 5). Video traffic at this time is suspended for the contention period y and only resumes after the grant of another reserved contentionfree period at the start of the next super-frame. The suspension is achieved by interrupting packet processing in the data plane. This can be achieved in a number of ways, for instance by instructing the WLAN device to go into a sleep state, or by intercepting and buffering packets destined for the device. The method we have implemented uses the interception and buffering approach so that the radio device itself has no knowledge of the overlay protocol behaviour and also link level buffer overflow is avoided, which would otherwise degrade performance significantly. The super-frame and x, y durations are dynamically configurable on a super-frame period. However, for the purposes of our experimental implementation we fixed the super-frame size to 35.2 ms and allow Copyright © 2007 John Wiley & Sons, Ltd.


340


Overlay Super-Frame

Video Packet

Reservation

Control broadcast (Allocations)

ACK

Reservations

Data Packet

ACK

Allocated slot bursts for broadcast video

Virtual Contention Free Period

Virtual Contention Period

Figure 4. Dynamic resource reservation overlay protocol frame structure

sd Dynamic Resource Reservation Transcoding Proxy

loop Reservation period

Video Client

Loader

ICMP Reservation Request ICMP Performance Monitor Event

ICMP Assignment Broadcast

ICMP Assignmen tBroadcast

Delay(x) Contention Free Period

UDP Video Frame

UDP Video Frame

UDP Video Frame

UDP Video Frame

Delay(y) TCP Netperf Data

TCP Netperf Data Contention Period

TCP Netperf Data

TCP ACK TCP Netperf Data

Figure 5. Dynamic resource reservation overlay operation Copyright © 2007 John Wiley & Sons, Ltd.



341

a maximum contention-free period x value of 17.6 ms, in order to achieve acceptable video latency and avoid starving the TCP data traffic of network resources. These values would need to be adapted as the number of video streams is increased in order to maintain the same video packet success rate.

4. CONTENT ADAPTATION Video content adaptation to the underlying link or device performance and capabilities can normally be handled in two ways, either by video transcoding on-the-fly or by providing multi-format video content. There are advantages and disadvantages to both these approaches. Transcoding is a computationally intensive process that takes video input streams and converts them into output streams that are either in a different compression format to the input stream or simply compressed at a higher compression ratio than the input stream to save bandwidth. This provides a high degree of flexibility as any type of output stream can be supported (provided the transcoder contains the necessary encoding module). The opensource VideoLAN Client (VLC) software [9] contains capabilities to perform real-time transcoding, but the processing requirements can be very demanding as the transcoding process essentially involves a complete stream decode and re-encode, all in real time. This is only realistically feasible on high-end devices such as PCs or dedicated proxy servers. Providing multi-format video content, on the other hand, is simpler to implement, particularly for stored video content (as opposed to live video broadcast). The disadvantage of this approach is that the formats may be determined without specific knowledge of the device or link capabilities, and for broadcast scenarios bandwidth can be wasted by transmitting content formats that no devices currently require. However, links and devices can be relatively easily categorized and so this approach has become very popular for web-based video content distribution. The multiformat video approach can be further enhanced with simple measures such as adaptive frame rate control for different multicast branches (for instance, by dropping frames in the frame duplication process), but the ability to perform this without degradation of quality depends on the encoding format, and is only practically possible with layered video encoding formats that utilize enhancement layers or video encoding schemes that do not use inter-frame references (i.e., forward and backward prediction). Multi-format video distribution can be used in conjunction with transcoding where diverse device or link types are being supported simultaneously, for instance, high-quality large display devices (such as laptops) and low-quality small display devices (such as mobile phones). In this case the transcoding would only have to be performed for the two different formats simultaneously. For the purpose of our experimental implementation we utilize the VLC transcoding facility and perform adaptation of the video rate (compression level) and also packet duplication to enable switching between unicast and broadcast WLAN distribution schemes. The duplicate streams can in theory be adapted on a stream-by-stream basis, but in our implementation we currently only adapt all the streams together. This is sufficient to cater for the scenario of equal mobile device types with equal quality-ofservice requirements.

5. EXPERIMENTAL SETUP AND RESULTS 5.1 Setup

We have investigated the performance benefits of the link and content adaptation approaches, described in this paper, using our experimental implementation. In the first instance a reservation protocol was used as a performance enhancement overlay on top of a conventional 802.11b WLAN (as shown in Figures 3 and 4). The overlay protocol has the benefit that it can be applied to existing 802.11b WLAN devices (in this case D-Link DCF-660W 802.11b devices were used), without the need for changing infrastructure or support 802.11e extensions or other link layer protocol modifications. It permits higher priority channel access for video streaming traffic via the packet scheduling function and overlay protocol. The overlay Copyright © 2007 John Wiley & Sons, Ltd.


342


support is incorporated into the LLA implementation and registers a time-based channel with the ULLA core to allow a performance reporting function (within an ULLA agent application) to observe performance and report it back to the transcoding proxy. The client, server and transcoding proxy devices are all supported with conventional unmodified laptop PCs running Linux Fedora Core 4. The video clients and transcoding proxy utilize the open-source VideoLAN Client (VLC) software [9]. Our implementation utilizes access points based on laptops with D-Link DCF-660W cards and the Linux hostap driver, which supports an open AP solution using hostapd. This actually allows an extra level of flexibility that would not be possible with an off-the-shelf access point, mostly from a security [10] but also from a performance point of view. For our experimentation the benefit is that the device can be simply switched between access point (infrastructure) and ad hoc modes of operation. When in the ad hoc mode of operation, direct peer-to-peer data exchange is possible and this has the effect of doubling the network capacity for this type of direct interaction. The mode change can also be performed via the ULLA API if the AP is ULLA enabled, although the reservation overlay protocol does not rely on this ability. Another possibility that this implementation approach provides is the ability to integrate the two access points and transcoding proxy into a single laptop device, as shown in Figure 3. The benefit of integrating the access points is considered in previous work [7] and permits the consideration of both adjacent channel interference as well as contention between traffic on the same channel. In this paper we only consider the resource sharing on each channel and assume that the frequency is adequately separated so as not to cause adjacent channel interference. The experimental setup includes two video clients and two loading clients, which are either PDAs or laptop PCs. An integrated access point and transcoding proxy server laptop is also included. The video server can be remotely accessed over the Internet or from a local network camera. The video streams utilized between the transcoding proxy and clients are based on MPEG4 compression with either Real-Time Protocol (RTP) over User Datagram Protocol (UDP) or MPEG transport stream over UDP. This latter case supports the broadcast or packet copying of video streams to more than one client within the packet scheduling function. RTP video streams are requested by the client device using RTSP, whereas the UDP streams are initiated at the transcoding proxy. 5.2 Results

As we introduce congestion to the WLAN that represents background data traffic, such as intensive file transfer or web browsing (by additional data traffic loading using netperf-generated TCP streams between netperf clients and servers), the packet loss rate increases (due to buffer overflow and collisions) and, as the preset performance threshold is crossed, the time-based channel overlay is activated. In order to observe the resulting improvement in performance, two client devices are operated in two separate WLANs simultaneously (as shown in Figure 3) and the cumulative distribution of packet success rate performance (measured for every 100 packets transmitted by the proxy) over a 200-second test period (with the same video transmission) is plotted in Figure 6. The results indicate the dynamic nature of WLAN performance (due to the offered load variations of the video streams), but this situation is improved by the enhancement overlay, as can be seen by observing the performance difference between client 1 (which is operating in a WLAN environment which has no enhancement overlay) and client 2 (which operates in a WLAN with the ability to activate an overlay protocol enhancement). It is worth noting that there is a residual packet loss even when no additional loading traffic is placed on the WLANs. This is as a result of the fact that the two video streams are being transmitted simultaneously on the two WLAN networks, which results in a small level of interference even with a well separated channel spacing. The effect the enhancement overlay has on the loading traffic is seen in Table 2, which indicates that client 1 is more or less unaffected by the video traffic in ad hoc mode (although in infrastructure mode there is a significant difference). This means that in ad hoc mode the same throughput can be achieved regardless of whether the video is being transmitted or not. This is due to the performance limitation of the laptop and 802.11b devices to be able to achieve higher throughput; for instance, this is determined by residual packet loss rate, the round trip time for TCP flow control and the buffer Copyright © 2007 John Wiley & Sons, Ltd.



343

Probability PacketSuccess Rate < X

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 40

50

60

70

80

90

100

Packet Success Rate % (x)

Client 1 - no enhancement

Client 2 - no enhancement

Client 1 - no enhancement (client 2 enhanced)

Client 2 - enhanced

client 1 - no loading

client 2 - no loading

Figure 6. Cumulative distribution of video packet success rate during experimental tests

Netperf client/server # 1 2

Ad hoc mode Overlay enhancement

Normal (no enhancement overlay)

On

Off

Unicast video

Without video

4.3 1.7

4.3 3.8

4.0 4.0

4.3 4.6

1.3 1.3

2.3 2.3

Infrastructure mode 1 2

1.3 0.6

1.3 1.3

Table 2. Loading client throughput performance (Mb/s) size of the 802.11b device. However, the performance is degraded when the video is switched to unicast mode (which requires layer 2 acknowledgements and retransmission). For the case of client 2 activating the overlay, which improves the video performance, the netperf loading throughput is significantly reduced compared with client 1. This enables us to estimate a unicast/broadcast mode cut-off point, which is the number of video clients required to make broadcasting with the overlay enhancement more attractive than simply to unicast video to each client (and use packet duplication in the transcoding Copyright © 2007 John Wiley & Sons, Ltd.


344


proxy). The number of clients required was estimated, using one video client, by transmitting (in a unicast manner) multiple duplicate video streams to the same video client. The cut-off point was found to be two clients (streams), as three or more streams resulted in poor video quality (from the excessive packet delay and losses). The performance of video content adaptation has also been evaluated by observing packet loss performance in the presence of congestion, but this time, instead of selecting the overlay protocol enhancement, the video application rate is adapted to reduce the congestion. This approach to the problem is necessary when there are no alternative channel options available to enhance the performance or when unicast mode is selected and the network loading is still high. Observations have shown that the packet loss rate can be reduced by 3–4% using lower rate video streams (for instance 400 kb/s compared with 1.5 Mb/s). However, this approach is not as effective as the reservation overlay in the presence of unicast TCP-based traffic, as the TCP traffic still provides a similar level of network contention and the reduction in packet loss is purely due to reduction in buffer overflow. However, switching from broadcast to unicast video streams (and performing packet duplication), at the same time as reducing the video rate by the same amount, is effective in improving video performance without increasing the network loading. Therefore, the overall strategy that we have developed for multimedia streaming performance improvement is as follows: • Assess the number of video clients in the network requiring each content stream. • Optionally, assess what other loading exists on the network and whether this is best supported with infrastructure of the ad hoc mode. • Determine the minimum acceptable video rate among clients and use this to determine whether the number of clients requiring the stream is greater than the broadcast cut-off point. If so, then use enhancement channel with broadcast mode. Activate the enhancement overlay only when the packet success rate is unacceptable. • If the number of clients is less than the cut-off point use unicast mode and packet duplication. • If packet losses due to congestion is still observed, reduce the video rate until packet success rate is acceptable or select a different frequency channel if interference observed is from a neighbouring WLAN.

6. CONCLUSIONS This paper has explored a performance enhancement method which combines dynamic resource selection and dynamic content adaptation techniques, for resolving congestion and interference problems inherent in multimedia streaming in wireless LAN environments. The proposed approach exploits the use of the open Unified Link Layer API concept, which has been developed within a collaborative European project. It identifies a number of challenges for multimedia streaming applications arising from dynamic loading and channel conditions in WLAN environments, and highlights the requirement for collocating more than one optimization strategy within a system to overcome any performance degradations. Therefore, the proposed scheme not only describes a number of different techniques but also demonstrates the ability to coordinate a number of dissimilar optimization tasks operating at various levels of the protocol stack using the unified API concept. The results of the experimental investigation show that such a strategy for performance enhancement offers significant gains, especially in wireless multimedia environments, as compared to the traditional way of employing a single optimization strategy to counter performance problems. The use of the unified API for obtaining measurements from the wireless link layer and for configuring enhancement options enables the implementation of such complex optimization strategies that are capable of providing the best performance all of the time. Future work that has been identified in this area includes the incorporation of further enhancement types into our generic optimization framework and developing the necessary algorithms needed to provide the decision-making process regarding the selection of such optimizations. There are many ways Copyright © 2007 John Wiley & Sons, Ltd.



345

to improve performance in a wireless environment simply because there are so many causes of performance degradation in the first instance. Our goal is to be able to cater for a range of performance optimizations through use of the Unified Link Layer API as a common framework, thus enabling the quick addition of future work into legacy systems.

ACKNOWLEDGEMENT This work was supported in part by the European Union (GOLLUM-project, IST-511567); see www.istgollum.org.

REFERENCES 1. ULLA definition: deliverables D2.4 and D3.1. www.ist-gollum.org [22 May 2007]. 2. Farnham T, Sooriyabandara M, Efthymiou C, Wellens M, Rerkrai K, Bandholz M, Riihijärvi J, Mähönen P, Melpignano D, Siorpaes D, Gutiérrez V, Gefflaut A, van Rooijen A. Unified Link Layer API: design and initial implementation results. In IST Mobile and Wireless Communications Summit 2006, Mykonos, Greece. 3. Linux Wireless Extensions Home page. http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html [22 May 2007]. 4. Postgres database. http://www.postgresql.org [22 May 2007]. 5. Polyhedra database. http://www.polyhedra.com [22 May 2007]. 6. Xie J, Das A, Nandi S, Gupta A. Improving the reliability of IEEE 802.11 broadcast scheme for multicasting in mobile ad hoc networks. In IEEE Wireless Communications and Networking Conference, Vol. 1, 13–17 March 2005; 126–131. 7. Farnham T. Radio link enhancement using an open flexible protocol stack framework. Wireless Communications and Mobile Computing 2005; 5: 379–395. 8. Harting F, Niebert N, Schieder A, Rembarz R, Schmid S, Eggert L. Advances in network-supported media delivery in next generation mobile systems. IEEE Communications Magazine 2006; 44(8): 82–89. 9. VideoLAN. http://www.videolan.org [22 May 2007]. 10. InteropNet Labs Full Spectrum Security Initiative. Open and free IEEE 802.1X/WPA/WPA2/IEEE 802.11i. http://www.opus1.com/nac/whitepapers-old/08-Opensource-LV05.pdf [2 July 2007].

AUTHORS’ BIOGRAPHIES Tim Farnham is Chief Research Fellow for systems and architecture research activities within the Toshiba Telecommunications Research Laboratory in Bristol. He began his research career in 1992 with the Defence Research Agency (now known as QinetiQ), where he was task leader for research in the area of networking and network management for future tactical communication systems for the British Army. He was also advisor to the British delegation at NATO project meetings on land tactical communications post 2000 (TACOMS-2000), which was a major multinational project defining standards for future communication systems. In 1995 he joined the Hewlett-Packard research laboratories in Bristol to perform research into future broadband wireless communication systems for the office and home. He represented Hewlett-Packard at the ETSI project on Broadband Radio Access Networks (BRAN) and also contributed to the development of the Shared Wireless Access Protocol (SWAP) standard in the HomeRF group. In 1999 he joined Logica-Telecom, a provider of service platforms (service nodes and intelligent network peripherals) for the mobile telecom industry, where he was involved in the system design and implementation of performance enhancement and distributed management functionality for service platform products. In April 2000 he joined TRL. He is a member of the IET and IEEE and holds a PhD in Engineering and Computer Science (on the management and control of radio communication networks) from DeMontfort University, Leicester.



346


Mahesh Sooriyabandara obtained his PhD in engineering in 2004 from the University of Aberdeen, UK. In September 2004 he joined the Telecommunications Research Laboratory at Toshiba Research Europe Ltd in Bristol as a research engineer. He is a member of the Systems and Architecture Group, specializing in next-generation wireless communications systems and is currently working on the European Commission sponsored IST project Gollum. His current research interests include dynamic optimization techniques, and reconfigurable and cognitive frameworks for future wireless networks.

Costas Efthymiou received his MSc in communications systems in 2001 from the University of Bristol, UK, and is currently writing up his PhD research on wireless networks. He joined the Telecommunications Research Laboratory of Toshiba Research Europe Ltd in March 2005 as a research engineer within the Reconfigurable Systems Group and is working on the IST Gollum project. His current research interests include dynamic optimization, link characteristics estimation and cognitive communications. He is a member of the IET and the IEEE.

