QoS Mapping for Multimedia Applications in a Wireless ATM Environment Richard M. Wood, George Fankhauser ETH Zürich, Computer Engineering and Networks Laboratory
[email protected],
[email protected] Riku Kreula, Eki Monni Tampere University of Technology, Telecommunications Laboratory
[email protected],
[email protected]
Abstract: Quality of Service (QoS) guarantees provide the basis for modern high-bandwidth and real-time multimedia applications like video conferencing, teleteaching or remote-manipulation. Asynchronous Transfer Mode (ATM) technology plays a key role in providing deterministic or statistical guarantees with connection oriented reservations to provide optimal network conditions for differently coded media streams. Migrating such demanding applications to an ATM network that includes wireless links introduces dependency on the radio conditions of the physical layer. Even with high redundancy introduced at several layers (i.e. physical, medium access control, transport and applications) the quality of service may not be guaranteed like in a network built on copper or fiber network technology. Therefore, traditional multimedia applications will suffer from varying network conditions. In this paper the coding and control methods for a video conferencing system are presented that solve these problems by following a hybrid approach of making reservations on a wireless ATM network and using adaptive and error tolerant coding schemes at the same time. In detail, the mapping of userlevel quality of service to network and coding parameters is discussed and the control scheme to handle and negotiate these parameters in a multipoint conference is explained. The mapping of parameters is studied using the WaveVideo [1] codec which was developed for lossy transmission in general.
hospitals and office environments will include applications for viewing X-ray images and other medical data, teleconferencing and remote consultation. This project will show the benefits of wireless ATM by providing a location independent terminal with realistic data rates for demanding real world applications. Typical test configurations as shown in Figure 1 comprise of a fixed ATM network with stationary workstations and servers. Mobility enhanced switches connected to the ATM network forward the data for mobile users to access points (base stations) which form a cell based wireless access network. Roaming between cells is supported through the switch and a control station.
Fixed Terminal Base Station
Mobile Terminal Base Station
ATM Network Control Station
Mobile Terminal
Fixed Terminal
Figure 1: A typical wireless ATM network configuration Keywords: Wireless ATM, Quality of Service (QoS), Audio, Video, WaveVideo, Filter.
1. Introduction This paper is based on the work done in the ACTS project Magic WAND. The Magic WAND (Wireless ATM Network Demonstrator) is a joint European project to develop a demonstration of mobile terminals for multimedia information access using a fast and wireless ATM network. Communication between the mobiles is based on portable computers and the access points serviced by an ATM switch and a radio physical layer which will take place in the 5 GHz range. User trials in
At the radio physical layer redundancy for detecting symbols reduces the bit error rate for the first time. Then, integrated into the MAC-layer, a wireless data-link control system further enhances transmission quality by applying more redundancy and an ARQ scheme. These various error control efforts reduce the bit error rate in general but cannot correct lengthy error bursts or generally unfavorable radio conditions. The MAC-layer itself is based on a system that supports a contention and reservation phase to support the CBR (constant bitrate) and VBR (variable bitrate) service classes [2]. The aim of this paper is to present an approach to create a dynamic application level QoS controller that works on
Microphone Speaker Camera Videophone User Interface Video Display QoS Controller
Audio Play
Picture Phone
Video Display
Mixer
Audio Recording
Audio Play
SSM Client
Video Capture
Local AudioChannel
Local VideoChannel
Scheduler & Resources Controller
Remote Video Channel #2
AVWedge
Remote Audio Channel #2
The application consists of three main components: the multimedia application (in this case the Picture Phone application), the audio and video stream mixer and distributor (AVWedge), and the actual Quality of Service controller. The interface to the network (Winsock 2 API) is located in the AVWedge. Establishment and acceptance of new connections are handled by the Sharing and Session Management (SSM) module. All these modules interface each other as displayed in Figure 2, transferring AV streams and control information. An interface to the system is also established monitoring the overall system load (e.g. CPU and memory usage), thus preventing system overload and delays caused by differently performing hardware. Dependent on the involved operations the mentioned AV streams can be categorized into four types: incoming/ outgoing streams and audio/video streams. Each type of stream has to undergo a specific series of processing steps to achieve the desired output. These steps are encapsulated in a channel structure which handles its stream independently. The channels are implemented as system threads which enables the AVWedge module to have multiple processing paths and allows simpler scheduling. Outgoing streams are handled by local AV channels and incoming streams by remote AV channels. These channels are managed by the scheduler which is responsible for their creation and destruction aswell as pausing and resuming individual channels. An even more important task is their correct timing when recording or playing AV data units and the ability to change the priority level of each individual channel. This enables the scheduler to give more cpu time to the more important local channels, because the receivers QoS depends on the output of these channels. Playback synchronization between incoming audio and video streams is guaranteed
Remote Audio Channel #1
2. Overview
by the appliance of timestamps to outgoing streams during the recording. Local channels capture and record video and audio data from the local user by camera and microphone. The video data is captured in units of frames with an average in the range of 1 and 25 frames per second. To decrease the amount of data to transmit, the frames are encoded by a video compression codec. After that the encoded frame has to be segmented into a number of smaller packets. With the last processing step a RTP header is added to each packet and the packet is transmitted to the corresponding communication partner using a socket from the WinSock 2 interface. Each partner uses four sockets, one for each channel. Audio data is recorded in samples in the range of 8’000 and 40’000 samples per second which results in small data sizes and makes buffering instead of segmentation of samples necessary. Otherwise all audio processing steps correspond to their equivalent video counterparts. Remote channels receive the packets and extract the encoded AV data from them. After that the data can be decoded using the same codec with which it was encoded. Video frames have to be reassembled from the received packets first before decoding them. Finally the voice and picture of the communication partner is played to the speakers and displayed on the screen.
Remote Video Channel #1
top of the Winsock 2 API, with an underlying wireless ATM network. As both the wireless nature of the network and the ATM technology create differences from the traditional socket based approaches using TCP or UDP, these new features affect the QoS also on the application level. The paper is structured as follows: First, an overview of the system is given and the QoS requirements on the application level with focus on video transmission are discussed. In Section 3 the control and data paths of the system are described and the relationships between media codecs, filters and QoS-mapping functions are explained. Additionally, the QoS-controller for local and distributed QoS-management is introduced. In Section 4 the logic that maps user-level QoS requests to codec-, filter-, and network-parameters is described and sample functions for an existing video codec are given. Finally, the last section draws conclusions from the ongoing work and summarizes the paper.
Socket
Socket
Socket
Socket
Socket Socket
Socket Socket
WinSock 2
Figure 2: Modules and interfaces in the system The resources controller is responsible for the continuity in the AVWedge module which means iterative recording and playback even when a lot of the data is lost due to insufficient system or network resources. It periodically measures the performance of these resources. The QoS controller monitors with the assistance of the resources controller the data transfer and if required, adjusts the network and application level QoS parameters to match each other.
3. QoS Control for Wireless ATM Wireless ATM systems have characteristics that need to be considered when controlling the QoS of multimedia applications. The difficulty is that it is not possible to change QoS parameters of an active connection dynamically. For each new QoS set a new connection needs to be created. Moreover, when radio conditions invalidate the continued guarantee of the specified QoS the connection is closed. In such cases the application is notified via an extension of the socket interface. This means that in order to guarantee continuous service to an application a new connection with lower QoS needs to be created as soon as possible. It also means that the application has to lower its output levels to utilize a new connection. Hiding these changes of the connection status from the application is essential for a smooth operation. In the system the application has an identifier to a specific connection. While the actual network interface is hidden in the AVWedge module (cf. Figure 2), old connections can be closed and new ones created without the application being aware of this. This approach also makes it possible to implement virtual dynamic QoS changes.
However this approach requires extensive knowledge of network behaviour and how parameters alter it. As our system uses wireless ATM as a transmission media, it is necessary to adopt the second alternative to provide maximum performance from the network. Initially, the WAND wireless ATM system does not provide multicast to mobile terminals. However, QoS control is conceptually designed to deal with a multicast situation. The functions described in Section 3.2 still apply, but the filters depicted in Figure 3 are moved to the receiver side while all the terminals receive the maximum quality and scale it down to their needs after receiving.
3.1 QoS Control Loop In order to control the QoS for video and audio transmissions a regulation mechanism is employed that passes a QoS vector to the AVWedge module and receives feedback by reading an input vector with the measured QoS values indicating what the network and end-system capabilities and conditions currently are. See also [4]. When using the QoS controller several conditions are monitored and regulated: • Network QoS (varying service quality for VBR connections) • Lost connections (mainly in the case of CBR)
Receiver 1 Media Sink
QoSC Sender Media Source
r
Filte
QoSC Filte
r
Receiver 2 QoSC Media Sink
Data Path
Control Path
Figure 3: Control and data flow for a video sender with multiple receivers. As depicted in Figure 3, each sender and receiver is associated with a QoS controller. All communicate between each other via a reliable control channel that is implemented using TCP/IP over ATM. The data channels in contrast are pure ATM AAL5 connections which accept an additional QoS specification by passing a QoS structure to the socket interface on connection setup [3]. WinSock 2 provides two ways to specify the network level parameters while using ATM. The first way is to use predefined templates that correspond to a certain video and audio coding technique (e.g. H.261, G.711). In these templates network parameters are set to provide adequate channel for each technique. Another alternative is to control the network level QoS parameters independently.
• System load • User requirements In the case of channel loss the QoS controller has to set the bitrate to a lower value, which it derives from previous network performance, and reestablish the connection. For connections with high deviation of used bandwidth like video transmission the appliance of the VBR (variable bitrate) service is most appropriate. It provides on one hand a statistical guarantee of a minimal bandwidth and on the other hand is flexible enough to allow data transmission with smaller bitrates. The VBR service is based on the leaky bucket model with the three parameters peak bandwidth, token bucketsize and tokenrate. Specifying a large token bucketsize and a tokenrate which is smaller than the peak bandwidth results in the desired behaviour of the ATM connection. Delay and jitter contraints can also be defined for the VBR service. The values for the VBR parameters are calculated from previous network performance as well as from the transmitted frame sizes and framerate. In addition, the video and audio streams are allowed to form multipoint communication structures which require that the QoS controller monitors the end-system QoS too. Since most operating systems do not provide reservation mechanisms the system load is controlled reactively and adaptively (i.e. if the system cannot meet the requirements the QoS controller will adapt to the new situation). This resource scheduling approach (see also Section 2) guarantees the proper function on low-end systems or in
application scenarios with many participants (e.g. teleteaching).
The QoS vector consists of following parameter categories:
The user requirements are mapped from abstract values to technical parameters that control A/V coders, filters, network QoS parameters and the end-system. For the video case the mapping functions are discussed in Section 4.
• end-system QoS for both outgoing streams (send_qos)
3.2 Control Functions The concept of the QoS controller’s feedback loop applies only to the local system and locally experienced network conditions. To coordinate all the controller’s behaviour in a distributed system (e.g. a multi-point video conference) simple coordination functions are applied that minimize the network load and maximize the throughput on each receiving machine.
• filter QoS for each connection (two outgoing streams) (these values are passed to the filter, not AVWedge)
The coordination process originates at the receivers and works towards the sender. A receiver QoS controller first adapts to the end-system and network condition by testing what is possible (i.e. minimizing): recv_qos = min(oslr, map(user_requirements)) where oslr = offered_system_load(r,input vector) The input vector consists of all current network and system performance rates from all active connections. These rates are measured by the AVWedge module. The offered system load (processing capacity of the endsystem) for one specific connection r is influenced by the scheduler in the AVWedge which assigns processor shares if multiple senders and receivers run on a single system. The function map is used to translate abstract user requirements to specific network, system, and coding parameters (cf. Section 4). Once the receiver has decided what QoS will be needed the QoS vector is passed to AVWedge to adjust endsystem QoS and at the same time the vector is transmitted over the control channel to the sender. Senders collect the information and maximize all parameters in order to satisfy all receivers. For all receiving systems that do not request the maximum quality the sender will setup a filter to actively control in what respect the QoS is applied (if we would send data at bitrates that would exceed what the receiver measured, frames would be lost on the bottleneck link in an uncontrolled random manner). It’s therefore better to restrict the amount of data being sent. The sender QoS vector is calculated as follows: send_qos = min(osls, max(recv_qos1, .., recv_qosn)) where osls = offered_system_load(input vector). The offered system load is meant to be for the channels which handle the outgoing streams. The offered system resources should be higher than for the other channels.
• end-system QoS for each connection (two incoming streams) (recv_qos) • network QoS for each connection (two outgoing streams)
The end-system QoS parameters consist primarily of video/audio coding parameters and channel priority levels. Changes of QoS parameters always result in a reallocation of resources in the AVWedge module. Sometimes in a manner which diverges strongly from the intentions of the user. Here it is necessary for the AVWedge module to interact continuously with the QoS controller to provide feedback and to seek guidance. The danger with this procedure is that it may well never end. There should be a mechanism which guarantees convergence of actual QoS rates to the specified values of the QoS parameters after a minimal number of interactions. Currently we have not solved this problem. Another topic is the dynamic changes of system and network QoS rates which may occur with a high frequency. To reduce additional system load the QoS controller should be consulted as seldomly as possible. This can be achieved by applying a low pass filter to the QoS change rates which results in calling the controller only by large changes of system or network load.
3.3 Codec-Filter Pairs At the sender side two goals should be achieved: Minimize network traffic by sending only what receivers need, and minimize the sending end-system’s load by coding the media streams only once. For example, in a cellular wireless system with terminals under varying radio conditions network, throughput has to be adapted for each receiver. Since terminals with high bandwidth links still want to receive their requested QoS the sending side has to transfer multiple qualities. Such layered coding schemes have been proposed and implemented in various fashions. One approach for video is to use hierarchical compression methods that result in a multi-resolution representation. WaveVideo is such a coding method based on the Wavelet Transform. Originally, the goal of coding and transmitting the multi-resolution components of a video stream was to achieve error tolerance and robustness [1]. However, we can use this method also for deliberately reducing the video stream’s quality with very little effort by introducing filters at the sender’s side (cf. Figure 3). Filters are important components that come in pairs with the codecs. The filter for the WaveVideo codec allows to reduce spatial, color and temporal resolution without recoding. The effort needed to lookup filter settings and
dropping or forwarding network frames is very low compared to systems that rely on a multiple coding approach. The employed filtering architecture works for any coding method but the degrees of freedom for codecs like M-JPEG may be limited (e.g. only temporal scaling).
4. Mapping Application Level QoS Mapping of user requirements to networking and coding parameters is performed separately for audio and video. The quality of both media is specified via a single value that has no technical meaning or unit. Video streams are modeled with an additional preference list of properties. Although these properties could be specified with specific values (e.g. 7.8 frames/s), only the order is used to calculate a useful combination of all parameters. For the audio channel this possibility does not exist. Networking over wireless ATM is performed using a VBR (variable bitrate) connection for video, because the adaptive and error tolerant coding scales over a very wide bandwidth range. For audio, a CBR connection (constant bitrate) is employed which reflects the constant bandwidth usage of the ADPCM coder very well. In principle, any combination of coding scheme and network QoS can be studied by writing the appropriate mapping functions. The next two sections describe in detail how video- and audio-streams are mapped to the wireless ATM system using adaptive coding techniques and resource reservation respectively.
4.1 Video The presentation of QoS parameters to the user must follow the rule of omitting technical details. Such are the bitrate (e.g. Modem, ISDN or T1 link), the coding scheme (H.263, MPEG, etc.), or particular details like the MPEG quantization-factor. Users usually do not understand their meaning and will not be able to express their desires. Instead we use one global quality parameter that runs on a linear scale. In order to give the QoS controller a chance to do an efficient mapping from a single quality parameter to possibly many codec and network parameters, the user may also provide a preference list to specify what parameters are important to her. The list encompasses: • Pixel resolution • Color resolution • Motion resolution (framerate) • Delay The spatial resolution may be specified for luminance and color information separately and can be translated either to a certain resolution in measured pixels or to a certain peak-signal-to-noise ratio at a fixed pixel size. However, these combinations depend on the support of the decoder and the video display. Motion resolution in turn can be
changed for all coding methods. Finally, delay is a parameter that has to be considered for video coding methods which exploit advanced motion compression techniques. When specifying the video quality requirements, the user is given necessary feedback to adjust the preference list by displaying a continuous sample video. As shown in Figure 4, the user manipulates only one input value which avoids contradicting specifications. For detailed feedback and demonstration purposes the additional coding and network throughput values may be displayed on request.
Figure 4: The Quality of Service configuration user interface requests the input for QoS mapping: The overall quality and the QoS preference list. An optional view (lower part) shows the result of the mapping functions. Mapping the user requests to actual network and coding parameters requires different functions for each networking system and codec. The following examples discuss the parameter mapping for the WaveVideo coding method using a wireless ATM connection with a variable bitrate. The network has to fulfill certain statistical guarantees and the QoS controllers will adapt to the available network throughput by evaluating the system feedback (cf. Section 3). The token bitrate parameter will be adjusted according to this feedback. The token bucketsize is set to the size of the largest possible intracoded frame. This is sufficient as long as the bitrate for transmitting the next delta frame is smaller than the token bitrate. To simplify the example, only the throughput of the video channel, the quantization factors for luminance and chrominance channels, the framerate and the resulting video quality for the luminance channel (as an average PSNR over all frames) are shown. The extreme case is studied for a user that selects best quality and gives a preference list with spatial resolution first, color second and framerate last. The delay property is a constant for the WaveVideo compression algorithm and can be ignored. The video used is the test video “Claire” in true-colour, quarter NTSC resolution and a nominal framerate of 10 frames/s. For a system with unlimited network resources
the user quality-values would translate into a bitrate up to 2.3 Mbit/s for almost lossless video. The coding parameters are scaled upwards when the user requests a higher quality and are multiplied with a weight inverse proportional to the precedence in the list to emphasize the preferred properties of the video. 500.0 [kbit/s]
400.0 300.0 200.0 100.0
[dB] (limunance)
45.0 40.0
to calculate the corresponding bitrate and a reservation request for that bandwidth is made. While the mapping for audio is rather trivial, the QoS controller must deal with loss of connections. Reestablishing connections makes only sense when the required bandwidth is lowered. This reduction is done exponentially to find a new working point as soon as possible and therefore to minimize the interruptions on the audio channel. Such actions violate the users requirements and the system tries to reserve more bandwidth later in linearly incrementing steps until the original quality is reached. The same method is used for the initial case when the Admission Control of the network does not accept a connection for the first time.
35.0 30.0
[q] (chrominance) [q] (luminance)
50.0 40.0 30.0 20.0 10.0 0.0
[fps]
’Q=0’ 100.0 80.0 60.0 40.0 20.0 0.0
12.0 10.0 8.0 6.0
’Q=33’
’Q=66’
’Q=100’
5. Conclusions and Outlook
’Q=0’
’Q=33’
’Q=66’
’Q=100’
Figure 5: Example QoS mapping functions. Q specifies the current value of the overall quality setting in figure 4. Zero denotes minimal quality of service. Introducing an artificial limitation of the bandwidth at 450 kbit/s for testing, the mapping functions employ a penalty factor for colour resolution and framerate. As shown in Figure 5, the coding parameters change after reaching the bandwidth limit according to their position in the preference list. Although the bandwidth is limited, the quality for the users most valued property still advances. The PSNR for the luminance channel still increases almost linearly. The user still gets what she specified for the top-listed feature and can now react and change the order of the remaining values. Of course this gain is achieved by putting an additional burden on the other features like colour accuracy and framerate.
4.2 Audio For audio QoS selection a similar method is used. However, only the overall quality and optionally, the relative position of the delay property is considered. As for video coding, only complex compression methods introduce much delay. The overall quality is mapped on a predefined scale directly to the frequency response and the sampling accuracy. While the presented video coding is error tolerant the employed ADPCM code is not. For this reason, the requested quality by users is mapped to coding parameters
This paper discussed the integrated mechanisms and policies to control the QoS for video and audio. Starting at the receivers end using simple, non-technical quality specifications, mapping functions yield the technical parameters which are used in a second step to achieve an optimal transmission for all receivers. Simple example functions for the WaveVideo codec and a bandwidth limited connection were given. The described control process works in a distributed manner in order to balance the QoS requirements for all participating systems. The QoS mapping for video uses the wide-range scalability of certain codecs and the results can be tested without a real wireless ATM system which is being built in the Magic WAND project. For audio, the method proposed depends directly on the ability of the underlying network system to guarantee the network QoS. Also the setup times for reconnecting with lower QoS will have a major impact on the perceived audio quality and can only be tested with the real system. In order to improve the regulation process, statistical parameters passed up from the physical and link layer (e.g. radio signal condition) could be used in the future to find functions with faster convergence.
6. References [1] M. Dasen, G. Fankhauser, B. Plattner, “An Error Tolerant, Scalable Video Stream Encoding and Compression for Mobile Computing”, ACTS Mobile Summit 96, Granada, Spain, November 1996. [2] F. Bauchot, G. Marmigere, N. Passas, L. Merakos, S. Decrauzat, "MASCARA, a MAC Protocol for Wireless ATM", ACTS Mobile Communications Summit, Granada, Spain, November 1996. [3] “Windows Sockets 2 Application Programming Interface”, Revision 2.1.0, January 1996.
[4] A. Kassler, A. Lupper, “Multimedia Applications in a Medical Environment over Wireless ATM”, ACTS Mobile Communications Summit, Granada, Spain, November 1996.
