Quality of Service Management in an Integrated Mobile Voice/Data-Enabled Service Architecture Hendrik Decker (1), Michael Krautgärtner (2), Casey Ong (3), Michael Wallbaum(4) Siemens AG, ZT SE 2, D-81730 München,
[email protected] Siemens AG, ZT SE 2, D-81730 München,
[email protected] Kent Ridge Digital Labs, 21 Heng Mui Keng Terrace, Singapore 119613,
[email protected] Computer Science 4, RWTH Aachen, D-52056 Aachen,
[email protected]
Abstract The System Adaptability Manager (SAM) is part of a Voice-Enabled Mobile Application Support Environment (VE-MASE). The latter is the core of the MOVE project, which supports the integration of real- and non-real-time data in mobile multimedia applications. The SAM collects events and measurements from other VE-MASE components, performs real-time analysis of quality of service (QoS) parameters for real- and non-real-time data, and delivers results to a Call Manager module. The SAM co-ordinates a per-stream QoS trading for the complete transmission medium, e.g., voice and data. The main contribution of this paper is a new classification of integrated QoS levels for voice/data collaboration which guides the operation of the SAM.
Summary Section 1 recalls OnTheMove [1] [2] and the main objectives of its follow-up project MOVE [3] [4]. Section 2 characterises the purpose and functionality of the System Adaptability Manager (SAM) and its main advances over a namesake OnTheMove component. Section 3 first recapitulates a partition of five QoS classes for Voice over IP (VoIP) in networks that support interworking between PSTN and Internet Telephony. This leads to the identification of three super-classes of feasibility levels, distinguishing three basic kinds of voice quality. Then, these three classes are combined with a binary distinction concerning the feasibility of transmitting non-real-time data (typically, HTTP content). That finally yields six voice/data-integrated QoS classes by which the operation of the SAM can be controlled. We believe that distinguishing such quality classes is crucial for a user-friendly management of integrated voice-data collaboration, particularly for mobile users. To our knowledge, no such classification has ever been discussed in the literature so far.
1 Beyond OnTheMove In contemporary mobile networks, real-time multimedia features are still in their infancy; only some simple voice or data services are provided. However, there is growing demand for using integrated voice/data services on a larger scale, with degrees of availability and quality that are comparable to common standards of fixed network services. A significant step toward enabling realtime multimedia data features has been taken by the ACTS project OnTheMove. It has solved problems of the seamless integration of different bearers, carriers and terminal types. It provides a homogeneous Mobile Application Support Environment (MASE) middleware and an API for UMTS-compliant applications running on mobile devices. The main focus was on the transmission of images and video data, while the integration of audio has not been considered.
The follow-up project MOVE addresses this issue by developing a middleware architecture called Voice-Enabled Mobile Application Support Environment (VE-MASE), including a Voice/Data Application Programming Interface (V/D-API). MOVE supports the network-, bearer- and terminalindependent design of integrated voice/data applications (e.g., announcement services for weather, travel, help desks, call centres, and so-called ‘What’s-On’ information retrieval) over a single Internet connection. Figure 1 illustrates the MOVE approach: Mobile devices connect to the Mobility Gateway, which acts as a mediator between mobile and fixed network. The Gateway performs network- and requirement-specific adaptation and media conversion. Notably, adaption and conversion can be done across boundaries of different networks, thus concealing the heterogeneity of underlying bearer services and mobility-related functions. The VE-MASE and its API are distributed and partially replicated over mobile devices, Gateway and Service Provider.
Mobility Gateway Mobile Client
V/D API
Information Server with HTTP Server
Voice over IP
V/D API
V/D Scheduler MASE Client Call Manager
Audio Gateway
SAM MASE Gateway Collaboration Manager Call Manager
V/D Application Client
V/D Application Server V/D API Call Manager
V/D Application Client Voice Over IP
Figure 1: Overview of the MOVE network architecture
Figure 2 shows a decomposition of MOVE into its main components, some of which are inherited from OnTheMove. One of the four VE-MASE components is the System Adaptability Manager (SAM), the purpose and function of which is summarised in this extended abstract. In [7], relationships and interactions between the SAM and other components of the VE-MASE, the MASE, the Voice/Data API and the Scheduler are discussed in more detail.
$SSOLFDWLRQ
0RELOH ,QWHUQHW
&DOO&HQWUH 6HUYLFHV
/RFDWLRQDZDUH 6HUYLFHV
:RUOG:LGH :HE
Mobile Application Programming Interface 9 R L F H' D W D$ 3 ,
VE-MASE Components &ROODERUDWLRQ 0DQDJHU $XGLR *DWHZD\
MASE Components (OnTheMove)
6HVVLRQ $GDSWDELOLW\ 0DQDJHU
3URILOH 0DQDJHU
&DOO 0DQDJHU
8VHU 0DQDJH PHQW
0XOWLPHGLD &RQYHUVLRQ
+7733UR[\
8076$GDSWLRQ/D\HU ZLUHOHVVQHWZRUNV
/RFDWLRQ 0DQDJHU 'LUHFWRU\ 6HUYLFHV
(YHQW 0DQDJHU
Scheduler *60
:LUHOHVV/$1
8076
Figure 2: MOVE Components
2 The MOVE System Adaptability Manager The MOVE System Adaptability Manager (SAM) is responsible for the provision of optimized and personalized mobile services. The Profile Manager handles user-, network- and terminalspecific QoS parameters. According to these parameters, the SAM computes the best possible adaptation of VE-MASE communication services. The SAM has several capabilities of adaptation: • It can choose between different networks that comply with given requirements for Quality of Service (e.g., available bandwidth) and cost. • It can compress, convert, transcode, or reduce multimedia objects prior to transmission. For example, an image is to be transmitted to a monochrome screen terminal. For that purpose, color data can be eliminated by the Mobility Gateway. Decisions about adaptations related to the available bandwidth and the cost involved are made by the QoS Trader within the SAM. Also, the SAM exerts a voice/data trading policy in case of decreasing bandwidth on a wireless link. For instance, it may change the encoding of the audio stream, ask for multimedia conversion of the HTTP-Proxy to reduce the size of HTTP data, shut down voice transmission or disable Web browsing, etc.
In general, the SAM monitors QoS parameters dynamically and delivers an overall voice/data QoS level to the Call Manager according to the QoS trading policy (which usually means, to always strive for an optimal QoS and to ensure the smoothness of quality degradation). More precisely, the SAM collects events and measurements from the Audio Gateway, the Scheduler, the Collaboration Manager, the HTTP Proxy and its multimedia conversion component. The QoS parameters are analysed in real-time for real-time audio and non-real-time data. The result (e.g., QoS class can’t be guaranteed) is delivered to the Call Manager. The latter then also is informed about an adapted QoS class that actually can be guaranteed. In turn, the Call Manager instructs the Audio Gateway and the Collaboration Manager accordingly (e.g., to use a lower or higher bandwidth codec, or to shut down or resume web browsing). To summarise: The SAM achieves an integrated QoS trading by co-ordinating a per-stream QoS analysis. As opposed to a namesake component in OnTheMove, the MOVE SAM takes into account how simultaneous voice and data streams interact and affect each other.
3 QoS classes for voice/data integration TIPHON [5] defines four QoS levels for the fixed network and for the interworking between the PSTN and Internet telephony (VoIP) via gateways. They are numbered 1), 3), 4) and 5) below, ordered by increasing quality. Mobility warrants the integration of another quality level, number 2), situated between Medium and Best Effort. 1) Best Effort: This level provides a usable communication but potentially with significantly impaired speech quality. End-to-end delays are likely to impact the overall conversation. No upper bound on delays is required. Depending on network congestion, the perceived voice quality may fall below GSM FR level. This level is expected to be provided over the public Internet, at least. 2) Low
This level takes into account that the quality of voice transmission via IP currently is often considerably below common standards of conventional telephony.
3) Medium
This level provides an IP Telephony experience similar to common wireless mobile telephony services (e.g., GSM networks using FR codecs). It is expected to be implemented over uncongested IP networks.
4) High
This level provides an IP Telephony experience similar to PSTN (or, e.g., wireless mobile telephony services in good radio conditions, for instance GSM networks using EFR codecs or devices using G.726 [6]), but with increased delay. It is expected to be implemented over QoS-engineered IP networks.
5) Best
This level provides an IP Telephony experience similar to PSTN or even better. It is expected to be implemented over QoS-engineered IP networks and also LAN environments.
By a straightforward interpolation of values in a table devised in [5], the following values can be assigned to the VoIP quality levels above.
Best
High
Medium
Low
Best Effort
MOS Quality
4.0 – 5.0
3.8 – 4.2
2.9 – 3.8
2.0 – 2.9
0.0 – 2.0
Mouthto-Ear Delay
0 – 150 ms
150 – 250 ms
250 – 350 ms
350 – 500 ms
≥ 500 ms
Call Set-up
0 – 1 sec
1 – 3 sec
3 – 5 sec
5 – 10 sec
≥ 10 sec
Figure 3: VoIP QoS Classes
"MOS" stands for "Mean Opinion Score", i.e., the average voice codec quality as experienced by a number of test persons. The scale ranges between 1 (unacceptable) and 5 (excellent). Conventional telephone codecs usually have a MOS above 4.0. "FR" stands for "Full Rate", EFR for "Enhanced Full Rate" (there are also "Half Rate" codecs, where HR is worse than FR and EFR is better than FR). GSM voice bandwidth is allotted to users by half, full or more enhanced rates, depending on the amount of traffic. Finally, G.726 is an ITU-T recommendation for, among others, the conversion of a single 64 kbit/s PCM channel encoded at 8000 samples/sec to and from a 32 kbit/s channel [6]. In general, the quality of voice transmission and data transmission may vary considerably. For instance, the data quality may be sustainable on a comparatively high level while the voice level drops below a required value, or vice versa. By assigning one of the quality levels 1) − 5) separately to both the voice and the data portions of transmitted data, one would arrive at 25 possible combinations. However, a classification according to figure 4, below, seems more plausible and closer to distinctions experienced by the typical user. In the ’voice’ column, we have chosen to differentiate between three cases: In the first, any of the VoIP QoS levels 1) − 4) is guaranteed to be sustainable during a session, where a predefined amount of delay can be expected to be never exceeded. (In a more refined table, four separate sub-cases could be made out of each layer for which one of levels 1) − 4) is guaranteed.) In the second, only a best effort result (level 5) can be predicted. The last of the three cases into which the various degrees of VoIP are lumped together is that, for some reason, no voice transmission is feasible, which is simply denoted by ’No’. In the ’data’ column, we have settled with two polar cases: either it works or it doesn’t. More precisely, the positive of the two cases is that data transmission (e.g., collaborative web browsing) can be provided with state-of-the-art multimedia conversion, depending of course on the currently available network. We abbreviate this case with CWB / MMC. The negative case is that no data transmission (thus, no collaborative web browsing) is feasible because the real-time audio stream uses all available bandwidth to ensure the corresponding QoS level. Again, we denote this case by ’No’. Combining the three ’voice’ cases and the two ’data’ cases, we arrive at the following six QoS classes for integrated voice/data services:
QoS 1 2 3 4 5 6
Voice 1) - 4) 1) - 4) 5) 5) No No
Data CWB / MMC No CWB / MMC No CWB / MMC No
Figure 4: Voice/Data QoS Classes
In principle, there are two possibilities for determining the mapping of QoS parameters via the Call Manager API: a) During call set-up, only the network type is defined (GSM, wireless LAN), and predefined QoS parameter settings are used by the SAM. b) The QoS levels are chosen independently of the network type during call set-up via the V/DAPI of the Call Manager. Once the QoS parameter values are set, the SAM controls corresponding thresholds. The Call Manager is able to change the conference QoS attributes (i.e. defined by SDP) in case the currently required QoS class cannot be guaranteed or sustained. The HTTP Proxy could receive new settings for the multimedia conversion from the SAM. Finally, we remark that the MOVE middleware architecture suggests a classification of events collected by the SAM into four layers. In [7], this layering is elaborated and discussed in detail. More information about MOVE and its applications can also be found in the companion paper [8]. Any potential for exploiting synergetic relationships with regard to the topic of interactive wireless multimedia services of the MOMENTS project [9] remains to be further investigated.
References [1] ACTS OnTheMove homepage http://www.sics.se/docs/~onthemove. [2] B. Kreller et al., UMTS: A Middleware Architecture and Mobile-API Approach, IEEE Personal Communications Magazine, April 1998. [3] ACTS MOVE homepage http://move.rwth-aachen.de. [4] J. Meggers et al., Voice-Enabled Mobile Middleware: The MOVE Project, http://move.rwth-aachen.de, link Public Documents, 1998. [5] ETSI Seminar, Project TIPHON, WG 5, http://www.etsi.fr/tiphon/, links Presentations, ETSI Seminar tiphon.ppt and IP-Tel-ETO by R.Stasny.ppt, 1998. [6] ITU-T Recommendation, Series G, http://info.itu.ch/itudoc/itu-t/rec/g.html, 1998. [7] Design of V/D-API and Architecture of the VE-MASE, AC343 MOVE Deliverable D2, 1998. [8] D. Carrega et al., Delivering Integrated Voice and Data Services for Mobile Customers with the MOVE Middleware Architecture, in this volume, 1999. [9] ACTS MOMENTS web pages http://www.uk.infowin.org/ACTS/RUS/PROJECTS/ac002.htm and http://veppi.mm.wdss.ntc.nokia.com.
