IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 5, JUNE 2004
889
End-to-End Quality-of-Service Coordination for
Mobile Multimedia Applications
Teodora Guenkova-Luy, Andreas J. Kassler, Member, IEEE, and Davide Mandato
Abstract—Transmitting real-time multimedia streams over
heterogeneous mobile networks is a challenging task. Variation in
network and system conditions can dramatically affect application performance. When providing end-to-end quality-of-service
(QoS) multiple system facets should be coordinated: orchestration
of local and peer resources, reservation of network resources,
adaptation of multimedia streams, etc. This paper presents an
end-to-end negotiation protocol (E2ENP) for negotiating and
coordinating QoS on an end-to-end basis both at application and
network layer. Based on a flexible extensible markup language
(XML) model and extending SDPng concepts, the protocol enables
the negotiation of system capabilities and allows provider-services
to effectively influence the negotiation process. The aim of the
E2ENP design is to optimize the efficiency of multimedia call setup
and reduce the time for QoS renegotiations, whenever vertical
handovers or spontaneous network reconfigurations occur. The
basic protocol is presented, together with implementation and
measurement results, stemming from several studies on current
and future third-generation/fourth-generation scenarios.
Index Terms—End-to-end negotiation protocol (E2ENP), extensible markup language (XML), mobile networks, quality-of-service (QoS), real-time multimedia networking, session description
protocol new generation (SDPng), session initiation protocol (SIP),
third-generation/fourth-generation (3G/4G).
I. INTRODUCTION
H
IGH-DEMANDING audio/video applications that
operate in mobile environment experience frequent
quality-of-service (QoS) violations due to packet loss and
delay variations. The reasons are mainly signal fluctuations on
the radio link, handovers between different wired or wireless
network technologies, and network congestion. Ubiquitous utilization of distributed, multimedia services in next-generation
[third-generation/fourth-generation (3G/4G)] mobile systems
involves application of heterogeneous end-devices (e.g., mobile
phones, portable PCs, etc.), which vary significantly in their
capabilities to support multimedia streaming (i.e., different
codecs, memory size, processing units, operating systems, etc.).
This paper focuses primarily on the 3G/4G mobile systems and
ad hoc networks connected to infrastructure wireless networks.
Mobility within provider-owned networks can also affect
Manuscript received June 1, 2003; revised December 20, 2003. This work was
supported in part in the framework of the IST Project IST-2000-28584 MIND,
which is supported in part by the European Union, and in part by the DFG within
the AKOM framework.
T. Guenkova-Luy is with the Department of Distributed Systems, University
of Ulm, Ulm 89069, Germany (e-mail: [email protected]).
A. J. Kassler is with SCE, Nanyang Technological University, Singapore
639798 (e-mail: [email protected]).
D. Mandato is with WSL-SCLE, Sony International (Europe) GmbH,
Stuttgart 70327, Germany (e-mail: [email protected]).
Digital Object Identifier 10.1109/JSAC.2004.826926
end-to-end system management, as the subscriber management
can restrict network-resource utilization in accordance with
preagreed user-provider contracts. Hence, enforcement of
end-to-end QoS throughout all layers of a distributed multimedia system is a complex process incorporating multiple
tasks.
Current protocols and mechanisms for supporting QoS cover
mostly only single facets of the global QoS management. The
real-time protocol suite (RTP/RTCP) [1] is used for multimedia
data transfer and QoS feedback, resource reservation protocol
(RSVP) [2] allows to reserve network resources, common
open policy service (COPS) [3] manages policy exchange, etc.
However, QoS is a system aspect that crosses all components
and layers of a distributed multimedia system. QoS management should, therefore, incorporate mapping between different
classes and types of QoS parameters, orchestrating, respectively, various system facets. An adequate QoS coordination
mechanism should in addition consider how the user experiences system performance. QoS management of multimedia
sessions should be handled effectively also in situations, where
vertical handover or resource-availability changes result in
QoS violations. In such situations, applications typically have
to adapt and reconfigure themselves. Signaling must be very
efficient to minimize service disruption in such scenarios.
This paper presents an end-to-end negotiation protocol
(E2ENP) for capabilities and QoS. E2ENP uses session initiation protocol (SIP) [4] to transfer control data. An extensible
description model based on extensible markup language (XML)
[5] is used to specify system characteristics and QoS parameters based on enhancements for session description protocol
new generation (SDPng) [6]. We discuss problems of QoS
management and present patterns for applying end-to-end QoS
and system-resource coordination. Application- and implementation-specific features of E2ENP are presented. A thorough
evaluation of the protocol based on real implementation is used
to analyze the protocol performance. We conclude the paper
with discussion of measurements and our future research.
II. REFERENCE MODEL FOR END-TO-END
QoS COORDINATION
In an end-to-end QoS management architecture [7], different roles (e.g., end systems, network providers, etc.) can be
identified. Consequently, a set of conceptual models can be
derived [8]. A system model identifies relevant QoS-parameter
categories. A description model provides a formal definition of
system parameters according to the categories associated with
the system model. A negotiation model is used for configuration of distributed multimedia systems on an end-to-end basis
0733-8716/04$20.00 © 2004 IEEE
890
Fig. 1.
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 5, JUNE 2004
E2ENP reference model.
and considers QoS management roles as identified in [7]. This
section presents the system model. The description model and
the negotiation model are handled separately in Section III.
The system model distinguishes between applied abstractions of distributed mobile multimedia services. These
abstractions incorporate the complete process for achieving
QoS on an end-to-end basis. The model helps to identify parameter classes, which are later applied to specify an accurate
description and management model for QoS. Our system model
(Fig. 1) includes an end-device,1 which runs an application that
communicates with its peer. The application uses the operating
system (OS) or an intermediate middleware, which includes
scheduling mechanisms for accessing terminal resources (like
CPU or network buffer) and mechanisms for accessing the
network. The system software running on the network nodes
applies buffering and scheduling mechanisms to manage timely
access to network resources.
This model naturally leads to the identification of several
abstraction levels of QoS and their corresponding parameters,
which play a key role in the global QoS management process
(see [9]):
End-to-end perceivable QoS parameters: This set of
parameters corresponds to the user’s perception of the performance of the distributed application. The translation of
the perceivable QoS characteristics in more technical terms is
typically implemented inside the application.
Application QoS parameters are used to describe
end-to-end application performance in accordance with software and hardware resources of end systems/services. In
E2ENP, these parameters are negotiated between the peers
for coordinating QoS end-to-end in form of QoS contracts at
application level. Typical parameters for video are frame size,
frame rate, and visual quality.
Transport/network QoS parameters are used to describe
end-to-end requirements with respect to network resources.
The system must derive these values based on actual capa1End-device, end system device, end system, or terminal are synonyms used
interchangeably throughout this work.
bilities/codecs and their specific QoS configurations, media
characteristics, and available network-access technology. In
E2ENP, these parameters are associated with QoS contracts at
transport level.
End system specific resource parameters are memory,
CPU, battery power, etc. Such parameters are not negotiated,
but may be applied to generate specific end system policies
for the end system resource-reservation management. Such
policies can be used within the application to generate correct
E2ENP payloads, when a multimedia session is opened or
when an adaptation condition for the session occurs [10]. The
application communicates to its peer only the results of an
adaptation condition using E2ENP.
In addition to the QoS relevant parameters, end systems must
agree on a common set of input/output configurations (like addresses and ports) and other capabilities (like codecs, RTP packetization rules, etc.) in order to establish a valid end-to-end multimedia session.
Rules and conditions for mapping between end-to-end
perceivable QoS and application QoS parameters can be
based on psychovisual experiments [11]. Mapping between
application QoS parameters and transport/network QoS parameters depends on codecs, codec-configurations, and the
media characteristics [11]–[14]. For audio, this mapping is
straightforward (a codec together with its parameterization
results in network traffic requirements). However, for variable
bit-rate video streams, this mapping also depends on the target
visual quality and the amount of motion.
III. END-TO-END NEGOTIATION PROTOCOL FOR QoS
A key concept of E2ENP is the possibility to actively negotiate system configurations (i.e., application- and transport-level
QoS and system capabilities) for multimedia-session establishment and to dynamically and flexibly leverage this information for QoS-adaptation purposes. Furthermore, these configurations can be repeatedly applied to sessions having similar context (e.g., session parameters can be saved in the form of an advanced address book and then reused). This section presents an
GUENKOVA-LUY et al.: END-TO-END QOS COORDINATION FOR MOBILE MULTIMEDIA APPLICATIONS
overview on E2ENP negotiations, a complete specification of
this protocol can be found in [8]. The peer starting a negotiation
process is called “offerer” and the responder peer—“answerer,”
analogously to the “offer/answer model” [15].
A. Description Model
There are several standardization efforts concerning developments of description models.
• MPEG-21 within the moving picture experts group
(MPEG) deals with XML schemata for describing user
environments and terminal characteristics [16].
• International Telecommunication Union (ITU) provides
descriptions for terminal characteristics in form of codecs
[17] and network parameter specification as network
classes definition [18], [19]. Additionally, ITU specifies a
namespace for defining picture size for video information
[20].
• Multiparty Multimedia Session Control Working Group
(MMUSIC WG) [21] develops session description protocol (SDP [22], SDPng [6]) with its enhancements for
transport QoS [23]. These protocols define description
schemes for specifying terminal characteristics in the form
of codecs. In addition, [24] defines profiles to parameterize audio and video codecs. Currently, there is a desired transition from SDP to SDPng [25] to introduce possibilities for negotiation, QoS, security, and other system
features.
E2ENP defines its own description model using a hierarchical
QoS specification that enables the management of a multimedia
system at different abstraction levels (e.g., media stream, groups
of streams, media session, media applications).
1) Hierarchical QoS Specification and QoS Adaptation: Mobile multimedia applications manage one or (simultaneously) multiple media types (e.g., audio, video, data). In the
latter case, the corresponding media streams can be logically
grouped based on various criteria. Applications that serve
multiple users or allow handling distinct conversations (e.g.,
private or business conversations) may aggregate the corresponding streams in session/-s. This bundling of streams allows
assigning priorities that the services may then conveniently
use to select the most appropriate QoS adaptation strategy
(e.g., private conversations shall be downgraded to sustain
business conversations, in case of limitations in the resource
availability). Furthermore, within a session, all of the streams
originating from/ending in a terminal might be aggregated in
stream associations (e.g., in a game application the background
music streams shall be dropped to sustain the quality of the
life chat streams of the players). This stream grouping allows
assigning priorities among different associations and defining
appropriate adaptation strategies within the context of a single
session. Hence, the overall QoS specification can be conveniently modeled in a hierarchical manner so as to capture time
synchronization, QoS correlation, and resource constraints
aspects among streams. A hierarchical model allows designing
alternative QoS specifications, which the application needs
for efficiently and automatically adapting its resource usage
with respect to the current resource availability and user’s
expectations.
891
The model consists of a tree of QoS specifications. These QoS
specifications are defined at different levels of abstractions. The
root of the tree is associated with a QoS specification that imposes general constraints on the amount of resources used by
all of the sessions along with their corresponding streams. A
QoS specification associated with a branch node of the tree is
named “QoS context”: it represents a high-level application QoS
contract. A QoS context contains predefined adaptation rules
that steer the adaptive application to choose the most appropriate QoS specification upon given resource usage conditions
for a group of media types. A QoS context also allows defining
time-synchronization constraints on subordinate QoS specifications (for instance, time synchronization constraints are required in a movie play out among the audio streams and the
mouth movements of the actors depicted in the video stream).
Furthermore, a QoS context allows defining QoS correlation
constraints among media streams that are bundled for application specific reasons. For instance, electronic game applications
and/or media-rich interactive applications might feature bundles
of audio and video streams, which are associated with objects
to be presented to the user. As an example, a rotating cube displayed on a monitor with its faces textured with images from
different video streams, might be conveniently associated with
a specification imposing constraints (e.g., lower limits) on the
amount of the resources shared by the play out of the various
streams and distributed to the streams associated with the currently visible faces of the cube. Finally, each leaf of the tree
is associated with a QoS specification named “QoS contract”:
it represents the application QoS contract for the given stream
(which defines a unique QoS configuration of the stream). Each
application QoS contract has a one-to-one correspondence with
a specific transport QoS contract.
The various QoS specification abstraction levels are organized within the tree as follows (in descending order of levels
from the root—see Fig. 2): Session QoS context (defining
priorities and quotas), stream association QoS context, stream
QoS contract. At each level, siblings represent alternative
QoS specification the application can choose from when
provisioning/adapting QoS.
Any given subtree originating from a specific branch node
is associated with an adaptation-rule predicate. The resolving
of this predicate selects a child node and, hence, instructs the
system to enforce the QoS contract and/or QoS context associated with that child. For instance (see Fig. 2), “if video parameters V11 are no longer enforceable, switch to video parameters V12” or “if stream association 1” (video and audio)
is not supportable (e.g., due to handover and, thus, lower data
rate availability) switch to “stream association 2” (only audio).
In the latter case, the adaptation process translates in a change
of QoS context or, more simply, in a QoS context switch (which
recalls the context switch concept as defined in the operating
system ambit, hence the name QoS context).
It is completely up to the adaptive application and its business
logic to determine when to adapt (e.g., if packet loss ratio is between 0.1% and 0.5% for 2 s), how to adapt (e.g., switch codec
or remove video stream) and to what extent to adapt (reduce
frame rate from 25 to 10 f/s). E2ENP provides signaling mechanisms so that peers can agree on such adaptation conditions and
procedures and prepare resources and capabilities beforehand,
892
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 5, JUNE 2004
Fig. 2.
Example of hierarchical QoS specification.
Fig. 3.
E2ENP description model and referencing.
based on this tree model. An example that combines adaptive
applications and E2ENP to reconfigure the streaming process
based on QoS feedback is presented in [10].
The current E2ENP description model supports QoS contexts
up to session level. Nevertheless, the design of E2ENP allows
definitions of more complex QoS contexts (e.g., prioritization of
multimedia sessions within an application or even prioritization
of applications on an end system). Further details on the E2ENP
hierarchical QoS specification can be found in Section IV-C.
2) Referencing Mechanism for Control Data: In current systems, a complete set of session-configuration information is exchanged every time a session is negotiated or adapted (e.g.,
offer/answer model with SDP [15]). This scenario is not effi-
cient as the minimization of signaling traffic is crucial. Thus,
E2ENP defines an optional referencing mechanism to minimize
data exchange. For this purpose, E2ENP distinguishes between
service configuration, session configuration, and adaptation indication (Fig. 3) and associates configuration-information with
an identifier.
Each of the contracts/contexts associated with the nodes of
the QoS hierarchy is labeled with a specific identifier (e.g.,
qID, aID, sID—Fig. 3), which is used by peers to address
corresponding contracts during QoS-negotiation/renegotiation
process. By exchanging only identifiers, the QoS-renegotiation
traffic is minimized. Using the hierarchical QoS specification,
the adaptation process can be addressed at various levels of
GUENKOVA-LUY et al.: END-TO-END QOS COORDINATION FOR MOBILE MULTIMEDIA APPLICATIONS
Fig. 4.
893
E2ENP validation procedure.
Fig. 5. End-to-end negotiation protocol phases.
granularity. Therefore, the E2ENP reference model defines
specific description and management for session-control data.
E2ENP descriptions provided via this model are applied as
configuration and control commands for managing multimedia
sessions. Peers can exchange this information using any session-management protocol (e.g., SIP [4], see Section III-B2).
Examples on the E2ENP referencing mechanism are also
provided in Sections III-B and IV.
3) General QoS Contract Generation Procedure: In order
to produce meaningful information that can be negotiated via
E2ENP, a validation procedure is required. The application interacts with its resource management system to derive conditions for session establishment and adaptation. The application
uses the E2ENP description model to formally specify proper
system configurations and performance constraints. The E2ENP
uses a validation procedure (Fig. 4) in order to produce enforceable or valid QoS contracts.
Basic QoS contracts are generated at the end-devices and
express user’s QoS preferences. Transforming the user’s preferences the application derives application QoS parameters.
These parameters are mapped to the end system capabilities
to produce several QoS contract sketches, which indicate
theoretically possible QoS support at the local end system.
Provider policies can either be applied at the local system or
inside the network (during negotiation time), depending on
the subscriber-management model [8]. QoS contract sketches
that contradict the provider policies (e.g., user-provider contract) are marked as “spare” and cannot be applied within the
correspondent network segment. Thus, the valid QoS contracts contain the same QoS information as the QoS contract
sketches and the provider restrictions are explicitly visible in
the contracts (see also Section III-B2). The basic idea behind
this validation process is to convey all technically possible configurations between the negotiating end systems, irrespective
of provider constraints, since each end system might change
its access network within the duration of a given session (e.g.,
performing handover from wireless local are network (WLAN)
to universal mobile telecommunications system (UMTS), some
of the “spare” contracts might become applicable, whereas
some currently enforced ones might no longer be applicable,
and are marked as “spare”). The “collapsing algorithm” [6]
and “feature matching algorithm” [26] are similar to the
E2ENP validation algorithm approaches. However, they do
not consider the modular application of constraints at local
system (“technology validation”) and at the network (“policy
validation”).
B. Negotiation Model
A candidate protocol for developing negotiation model
for QoS coordination is the session initiation protocol (SIP)
[4]. Within the SIP framework several roles are identified
like end system, proxy, registrar, location service, which
can be enhanced to define provider management [8]. As SIP
defines an “envelope” for transporting data, an additional
protocol (e.g., SDP, SDPng, etc.) is necessary to define configuration descriptions for session establishment or session
adaptation. The “offer/answer model with SDP” [15] (and its
enhancements [27]–[29]) specifies a negotiation procedure for
session establishment. However, SDP and SDPng do neither
regard end-to-end QoS as global system feature, nor consider
minimization of signaling traffic. Hence, E2ENP applies the
“offer/answer model” only as a principle idea for its negotiation
model. In addition, E2ENP optionally considers interactions of
the protocol with the resource management subsystem within a
QoS-aware multimedia system. Local resource availability is a
major limitation when defining supportable QoS configurations
for a multimedia service.
1) E2ENP Modes and Phases: E2ENP uses different negotiation modes—push mode, pull mode, and push–pull mode, depending on who is the initiator, the responder, and who provides
particular initial information. In the push mode, the initiator proposes an initial set of QoS contract to the responder, whereas in
the pull mode, the responder provides the first set of QoS contracts to the initiator. In the push–pull mode, both peers provide
QoS and capabilities and try to reach an agreement.
E2ENP consists of three major phases (Fig. 5). The solid lines
denote E2ENP signaling, dotted and dashed lines express peer
interactions, which are being coordinated via E2ENP but are
894
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 5, JUNE 2004
not part of E2ENP, e.g., “reservation” with RSVP and “media
streaming” with RTP. Depending on services and scenarios, different phases can apply different negotiation modes.
Prenegotiation: This phase deals with negotiation of configuration information valid for more than one multimedia session,
e.g., service configuration. This information can be leased
between end systems. During this phase, terminals exchange
information on supported codecs, desirable QoS contracts,
etc. Having the prenegotiation information in advance, the
end systems can speed up the negotiation process for session
establishment.
Negotiation: The information exchanged during this phase
deals with configuration and establishment of a specific multimedia session. If the terminals cannot (due to limited memory)
or are not allowed to (due to system policies) perform prenegotiations, necessary system configurations can be additionally exchanged within the negotiation phase. Thus, two types of negotiation are defined—a short negotiation, which uses references to
data exchanged in previous prenegotiation phase and a full negotiation, which contains both service information and specific
session configurations. Parameters exchanged during negotiation phase define QoS contexts, which media streams should
be created for the given session; how these streams are associated with codecs and basic QoS configurations thereof; and what
kind of QoS and time-synchronization constraints are applied.
QoS contracts and contexts are applied for multimedia session
establishment and for any eventual QoS adaptation process that
might take place during a multimedia session. Negotiated information might also be leased between end systems.
Renegotiation: This phase deals with enforcement of specific QoS Contracts and contexts and the indication of adaptation conditions. If a different QoS contract/context should be enforced due to resource availability change, renegotiation phase
would be invoked by the application providing the index of the
new QoS contract to be enforced. The renegotiation phase can
also be used to specify new configurations (e.g., if a dynamic
codec download extends the capabilities). A short renegotiation (using only references to previously exchanged data) and a
full renegotiation (enhancing the system/session configurations,
whenever system upgrades/downgrades occur) are defined. The
short renegotiation is, thus, an efficient process, since it uses
only references to previously negotiated data, and singnaling
impact is correspondingly minimized.
2) Resource-Management Aspects: In order to support the
E2ENP referencing model, E2ENP imposes requirements on
the behavior of the network entities interacting with E2ENP.
The QoS signaling via E2ENP is out of band and path decoupled (after [30]). Application-level proxies that can interpret
such kind of signaling are in position to manipulate the QoS
configurations exchanged by terminals [23]. However, the
original, unchanged configurations might be useful for end systems, when planning and performing handovers. Additionally,
provider rules applied within one subnetwork, might not be
available and/or legal in another subnetwork when performing
a handover. Consequently, network components, which are in
position to enforce provider rules, should add them to the QoS
contracts in a way that this information is explicitly visible
and recognizable as a provider restriction from the negotiating
peers. Terminals can, thus, distinguish between end system con-
Fig. 6. Example of E2ENP resource coordination at session establishment
based on SIP as E2ENP carrier.
straints and provider rules. The resulting required separation of
QoS contracts and provider rules should guarantee successful
end-to-end application-signaling even when components for
enforcing provider policies are involved.
E2ENP QoS contracts are used for resource-reservation
during session establishment and adaptation. E2ENP adopts
the “economy principle” [14] to describe the order of reservation processing, i.e., end system local resources should
be reserved ahead of network resources, which are the most
expensive ones. Resource management within the network
may be heterogeneous (e.g., IntServ [2], DiffServ [31], etc.);
end systems may not be allowed to perform network resource
reservation signaling; or the signaling may be terminated in the
network at a gateway. However, it is the task of the end systems
to synchronize session setup with optional network resource
reservation.
Fig. 6 shows an example of the E2ENP resource coordination at session establishment based on examples with SIP. The
negotiation phase is performed before or at the actual start of a
session. Based on results of previously applied phases, the end
systems agree which capabilities and QoS contracts to enforce
for the given streams within the session (the XML code of these
configurations is shown in Sections IV-B and C). At completion
of this phase, peers have agreed upon the QoS contracts they
are going to enforce for the given streams and the right set of
capabilities to apply. Fig. 6 explains the push mode, whereby
the offerer sends an initial proposal (i.e., E2ENP configuration
offer) that contains its desired capabilities and QoS levels
together with the potential stream adaptation paths in a SIP
INVITE to the answerer. As the offerer knows its desired QoS
levels, it optionally reserves local resources beforehand [i.e.,
local resource management (LRM)]. The answerer proves the
offerer’s proposal and also reserves appropriate resources,
locally. The answerer replies (183 Session Progress) with a
subset of capabilities and QoS parameters (i.e., E2ENP configuration answer). This information matches both the answerer
and the offerer views about the session establishment and
future QoS adaptations. The answerer may also reply with its
counterproposal which may describe additional capabilities and
GUENKOVA-LUY et al.: END-TO-END QOS COORDINATION FOR MOBILE MULTIMEDIA APPLICATIONS
QoS that the answerer would like to apply for the session. This
enables the offerer side to upgrade its capabilities dynamically,
e.g., by downloading appropriate codecs. By receiving the
answerer’s counterproposal, the offerer proves locally if the
resources need to be relocated to match the answerer’s reply.
The offerer sends PRACK to the answerer to inform it about the
start of the network reservation and the answerer acknowledges
this action (i.e., E2ENP command-start-reservation). Network
resource reservation proceeds at the transport/network layer
using, e.g., RSVP. The next sequence depends on the model
used for network resource reservation (sender initiated/receiver
initiated). If RSVP is not available end-to-end or terminated
at the network edge, RSVP PATH will not be received by the
answerer. Therefore, by using UPDATE the offerer and the
answerer inform each other about the state of the network reservation and about the final capability/QoS level to be enforced
for the session to be established. Once network resources are
reserved end-to-end or only partially, the answerer sends a 180
ringing to the offerer. The call setup is completed by sending a
200 OK for the initial INVITE from the answerer to the offerer.
The offerer acknowledges this by sending an ACK. There may
be situations, where the local resource reservation may fail,
e.g., at the answerer after receiving the initial proposal. As the
initial proposal may contain alternative QoS levels and alternative capabilities that the offerer would also tolerate (within
the adaptation path), the answerer may chose an alternative
capability/QoS level. This information must be propagated
in the 183 Session Progress that the offerer is able to relax
resource requirements and reconfigure its media stream engine.
Also, network resource reservation may fail due to insufficient
resources. In this case, the offerer would try an alternative QoS
level with less network resource requirements until resources
are reserved successfully. The final agreed upon QoS level must
be notified to the answerer within the UPDATE message so as
to release additional resources. E2ENP itself does not provide
messages for resource reservation. E2ENP only coordinates the
network resource reservation, which should be accomplished
using protocols like RSVP triggered by the hooks provided
through the E2ENP agent (i.e., the reception and sending of
command-start-reservation).
Renegotiation message sequence is similar to negotiation, but
has less signaling overhead due to the E2ENP referencing mechanism. Renegotiation can be started by any of the peers detecting
a QoS violation and, thus, the initial offerer may become by
renegotiation an answerer and vice versa.
There may be situations, where a service domain entity (e.g.,
enhanced SIP proxy) is involved in the negotiation process
by intercepting the signaling between the offerer and the answerer [8]. A provider entity may analyze the application QoS
parameter and add provider-constraints in form of transport
QoS parameter to the QoS offers and answers. Additionally,
a provider entity may define restrictions to single transport
QoS parameters exchanged between the offerer and the answerer or may add provider-authorization tokens for resource
reservation to the respective offers and answers. The peers
can extract and use these tokens to authenticate themselves
before network-reservation entities. The peers recognize the
provider-specific information as it is added in a separate part of
the E2ENP payloads (see beginning of Section III-B2). Thus,
895
the peers distinguish between the information send end-to-end
by the offerer/answerer and the additional constraints/tokens
added by the service entities. When intercepting a PRACK
message with E2ENP command-start-reservation the provider
entities may start a network resource reservation providing
assistance to those end systems which cannot reserve network
resources on their own. The provider processing of the E2ENP
payloads (i.e., adding constraints to application or transport
parameters or including reservation tokens) depends on the
trust models between the end-peers and the provider [8].
In addition to the management of end system and provider
configuration information, the E2ENP-specific resource coordination includes requirements for data consistency, when managing resources, in order to avoid deadlock-like reservation scenarios on the terminals (see [7] and [8]).
IV. E2ENP DESIGN AND EXAMPLES
E2ENP is designed to be network and system independent. It
allows to describe system capabilities, QoS contracts and QoS
contexts in a declarative manner. E2ENP does not define its own
network transport medium but uses an already available carrier
protocol, e.g., SIP [4]. Nevertheless, E2ENP defines its own addressing scheme to uniquely identify E2ENP sessions and communicating peers at application level. The addressing syntax can
be mapped to any IP-based session management protocol [8].
E2ENP summarizes several specifications, concerning multimedia system configurations. E2ENP directly adopts these definitions without unifying the metric units (i.e., time units are in
seconds or milliseconds, information units in bits or bytes, etc.)
and the naming schemes applied there (see also Section III-A).
A concise namespace for defining identifiers to single contracts,
stream associations and higher level associations has to be standardized to produce unique identifiers, since the applications
using E2ENP need to precisely understand these identifiers. The
E2ENP specification differs to some extent from SDPng, due
to the fact that E2ENP adapts system capability descriptions to
the needs of QoS application and delivery. Despite these differences, E2ENP is still applicable as an extension of SDPng, due
to the extensibility of the XML-Schema definitions [32].
The following examples show XML code snippets of the
major elements used during E2ENP phases. The correctness
of the examples has been proven using a validating XML
parser [33], [34]. We have used a scenario, where a session
contains an audio and a video stream. The application can
select between two audio codecs (GSM, G.722) and one video
codec (MJPEG). The application can adapt frame size, frame
rate, video quality (by tuning the quantization parameter of
the codec) resulting in different bandwidth requirements (see
Table I). In our example, there are six possible combinations
from which the application can select. E2ENP provides the
mechanisms to signal the codecs, the application QoS contracts,
network QoS contracts, and the QoS contexts. It is up to the
application to decide when to switch from step m to step n (see
[13], for an example).
Some of the major E2ENP parent elements do not carry
“e2enp” header, since they stem from different E2ENP XML
namespace definitions [6] and [23]. Different E2ENP elements
896
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 5, JUNE 2004
TABLE I
ADAPTATION “QUALITY STEPS” OF THE APPLICATION
Fig. 8.
Capabilities.
Fig. 7. PDU header.
are shown in uncompressed form for better readability. Future
versions of E2ENP will consider partial or complete E2ENP
compression, e.g., using hashes.
A. PDU Header
The “e2enp:purpose” section (Fig. 7) is the header of
the E2ENP protocol data unit (PDU). It appears at the
beginning of every PDU exchanged at prenegotiation, negotiation, or renegotiation. The “e2enp:session” section
defines the owner/originator of the E2ENP PDU (after [6]
and [22] owner/originator specification). If available the
“e2enp:expires” states the relative lease time of this PDU
in seconds. The absolute time point defining the start of the
leasing is provided using the time/date tokens of the carrier
protocol applied, e.g., SIP [4]. The example in Fig. 7 shows
a “e2enp:purpose” section for a prenegotiation, which refers
to another PDU identified through “e2enp:use” section, i.e.,
refers to a
the session with
. The
previous session with
structure of the E2ENP PDU identification and the identification of the referred PDU is the same, i.e., the “e2enp:session.”
The “e2enp:description” identifies the PDU type, the negotiation phase and the negotiation mode. Additionally, the
“e2enp:description” is used to provide reservation-coordination
commands for start and end of the network reservation [8].
B. Capabilities and QoS Contracts
Fig. 8 shows a definition of system capabilities in form of
codecs according to the RTP-profile definition [24]. The two
major sections “e2enp:audio-codec” and “e2enp:video-codec”
specify the supportable codecs with their names and applicability scope. The “rtp:pt” specifies RTP-transport for the codecs,
referencing the already defined with “e2enp:audio-codec” and
“e2enp:video-codec” descriptions. Dynamic RTP-payload
types are characterized through definition of parameterization
subelement of “rtp:pt.”
The aim of the separate mapping of the codec definitions to
the payload-types is to optimize the PDU processing. The application can first prove if a given codec is supported and if
the codec is not supported the respective serialization format
(in this case RTP payload-types) can simply be ignored. Additionally, for some codecs it is possible to associate dynamic
payload types, which in fact is a complementary information to
the codec, therefore, it is presented separately from the codec itself. The XML parameter definition for dynamic payload types
is a feature supported in E2ENP, but not in SDPng.
Fig. 9 shows the structure of the QoS contracts at application
level (i.e., audio and video QoS contracts) and at transport
level. Within the audio and the video QoS contracts the
“e2enp:contract” describes the user’s QoS preferences as
application QoS parameters. Inside the audio contracts the
parameters “sampling-rate-set” (sampling rate in Hertz) and
, stereo
, etc.) are according
“channel-set” (e.g., mono
to [24]. Within the video contracts the meaning of the parameters is the same as for the codec parameterization (Fig. 8),
i.e., “e2enp:video-codec,” where “frame-rate-range” defines
number of frames [frame/s], “frame-size-set”—the displayable
, see [20]) and
frame sizes (
the “color-quality-range” and “overall-quality-range” are percentage values, where 1% “color-quality” or “overall-quality”
is equal to 100 units of the corresponding descriptions. The
mapping between the QoS definitions and the codecs to form a
QoS contract is done using “rtp:map.” The QoS contract is identified through the attribute “name” within the “e2enp:contract”
element. The definition of the transport QoS is adopted from
GUENKOVA-LUY et al.: END-TO-END QOS COORDINATION FOR MOBILE MULTIMEDIA APPLICATIONS
Fig. 10.
Fig. 9. QoS contracts.
[23]. The mapping between the QoS contracts and transport
definitions is achieved at session establishment time, since only
then it is known how many streams would be opened for the
respective media session and which network resources are necessary for these streams. The provider restrictions on the QoS
contracts are expressed with an additional element associated
with the “e2enp:contract” [8]. The capabilities (Fig. 8) and
the QoS contracts (Fig. 9) are usually exchanged between end
systems during a prenegotiation (see Section III-B1).
C. Media Session Configuration—QoS Contexts
Fig. 10 shows the RTP-specific stream configuration. This
description is partially adopted from SDPng [6]. The “component” element is used to define a single media stream, e.g.,
Fig. 10 shows the definition of one audio and one video stream.
The “alt” element specifies an alternative configuration of the
respective media stream. Fig. 11 shows the logical configuration of the stream association QoS contexts, expressing different
897
RTP specific stream configuration.
adaptation possibilities. A QoS context (the “e2enp:context” element) is defined (as described in Section III-A1) as the association of adaptation paths (the e2enp:adapath element), which
describe the nominal and alternative QoS specifications to enforce during adaptation, and the applicable time-synchronization and/or QoS correlation constraints (the e2enp:constraints).
As defined in Section III-A2, the audio and the video configurations are identified and referenced in this example by their
names. For example, the audio information described in the
RTP specific stream configuration (Fig. 10) is referenced via its
name “audio-stream-1,” a video QoS contract information defined in “e2enp:qos-contracts for=“video”” (Fig. 9) is identified
by its name “video-contract-1.” For the purpose of referencing
”
already defined components, the attributes named “ref_
(e.g., “ref_component,” “ref_contract,” etc.) are used.
The “e2enp:adapath” (Fig. 11) defines QoS adaptation rules
for single streams, stream groups, and multimedia sessions
as a whole. The “e2enp:alt” element specifies possible alternative QoS contracts used within the adaptation process.
The first “e2enp:alt” element in a group identifies a nominal
contract the end systems should first apply to reserve resources
898
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 5, JUNE 2004
Fig. 12.
Enforcing and blocking of QoS contracts.
representation of “audio1” changes between the currently
active “audio-contract-1” and the alternative configuration
“audio-contract-2.” The “e2enp:enforce” and “e2enp:block”
can also be applied for enforcing/blocking QoS contexts, e.g., if
an association of an audio and video stream is no longer applicable, this association can be blocked and an association with
a single audio stream can be enforced [8]. The “e2enp:target”
element defines the abstraction level of the QoS information
(see also Section III-A1).
In this case, the referencing mechanism (Section III-A2) is
applied via the “path” attribute and identifies complete branch
of a hierarchical QoS definition (Section III-A1) produced
during the prenegotiation (see Figs. 8 and 9) and the negotiation
phases (see Figs. 10 and 11). The example in Fig. 12 corresponds to information exchanged between end systems during
a short renegotiation phase (Section III-B1). The renegotiation
structure of a short E2ENP renegotiation is always fixed
irrespective of how many alternative audio/video streams and
associations of streams are defined. At a short renegotiation the
peers use only block/enforce elements to point at the respective
change. As a complete renegotiation PDU is formed from contents similar to those shown in Figs. 7 and 12 compared with a
prenegotiation PDU (combination of the contents—Figs. 7–9)
or a negotiation PDU (combination of the contents—Figs. 7,
10, and 11), the short renegotiation is very compact and leads to
efficient signaling. In Section V-D, we analyze the performance
gain when using the short renegotiation phase.
Fig. 11.
QoS contexts and QoS adaptation.
V. E2ENP CONCEPT VALIDATION
at multimedia-session establishment. Streams grouping and
synchronization rules (see Section III-A1) for an association of
media streams are defined over the “e2enp:context” element.
For example, Fig. 11 shows two possible QoS contexts, which
can be applied for a multimedia session—“association1-1”
with audio and video stream and “association1-2” with only
audio stream.
The examples in Figs. 10 and 11 correspond to the information exchanged between the end systems during a short negotiation (Section III-B1).
D. QoS Adaptation
E2ENP refers to already negotiated data in order to perform
QoS adaptation at renegotiation time (Fig. 12). The “e2enp:enforce” element is used to point at the new QoS contract to
be applied and the “e2enp:block” defines, which currently
used QoS contract should be blocked. In this case, the stream
This section presents the E2ENP UA architecture and the applied test environment, developed for validating the E2ENP concept, as well as the results of this validation.
A. E2ENP User Agent Architecture
Fig. 13 shows the architecture of the E2ENP user agent
(E2ENP UA). The complete implementation of the E2ENP UA
is based on Java 1.4.1 [35] and consist of the following entities.
• E2ENP finite-state machine (FSM)—Each instance of
such FSM corresponds to an E2ENP control session,
which can be created by the application. The E2ENP UA
uses the FSMs to regulate the access of multiple E2ENP
control sessions to the carrier protocol (e.g., SIP) stack.
The E2ENP UA controls the consistency of the E2ENP
information, i.e., the E2ENP UA keeps track of mutually-dependant E2ENP sessions saving and verifying the
information of the E2ENP PDU headers.
GUENKOVA-LUY et al.: END-TO-END QOS COORDINATION FOR MOBILE MULTIMEDIA APPLICATIONS
899
TABLE II
PARAMETERS OF THE USED PCS
TABLE III
EMULATED NETWORK TYPES WITH NISTNET
Fig. 13.
E2ENP user agent architecture.
• Description language translator—uses SAX XML parser
[33], [34] for processing the XML code of the E2ENP
PDUs, where:
i) parser—translates E2ENP payloads into system-internal representation;
ii) generator—translates system-internal objects into
E2ENP XML descriptions.
• Carrier protocol stack—for sending/receiving of control
messages. The implementations presented in this paper
are a SIP surrogate using RMI [36] (implementation of
University of Ulm) and a SIP stack [Sony International
(Europe) GmbH solution] based on Java, developed according to [4].
B. Test Goals
The major goals are: to validate the E2ENP logic; to optimize
the processing through tuning the E2ENP PDUs’ structure; to
measure the E2ENP round-trip times within different networks
for the TCP-based RMI and the UDP-based SIP; to investigate
the reaction time of the E2ENP UA, in order to prove if the session establishment/management times are acceptable from the
user point of view and to perform comparative measurements
with a similar control protocol (e.g., SDPng). As an evaluation
criterion it was considered that all media-session establishment
should last no longer than 2–5 s (prenegotiation, negotiation)
and the adaptation within the duration of a multimedia session
should last no longer than 1 s (renegotiation) to fulfill the user’s
expectation for almost immediate reaction. This evaluation criterion considers the fact that a user would rather accept longer
session establishment times, but for him/her it is not acceptable
that an adaptation during running multimedia session lasts very
long. Additionally, long lasting adaptation processing and signaling might cause disturbances in the perceived media, which
is also not acceptable for the user [37].
C. Test Environment
The equipment used for E2ENP tests is shown in Table II.
Table III displays network types considered for the measurements. The network measurements were performed using the
NISTNET [38] network emulator and the parameters and
values given in Table III correspond to the parameter inputs
in NISTNET. In Table III “delay” corresponds to the one
way access-network delay between a terminal and the first
access-router.
D. Test Results
For the performance measurements of the E2ENP UA
components, the end-to-end application round-trip times
(Section V-D1), and for the comparison of E2ENP with SDPng
(Section V-D2) the following scenario is applied:
The multimedia session to be established and later on
adapted consists of one unidirectional audio and video stream.
No more than three alternative codecs and no more than
three QoS contracts per stream are used. Streams need to be
synchronized, forming two different QoS contexts.
More complex scenarios would result in larger payloads.
The influence of the payload size on E2ENP processing and
end-to-end signaling is discussed in Section V-D1.
1) E2ENP Components and Processing: Measurements for
evaluating the parser and the generator were performed on a
single PC (Table II—first entry) and the performance of these
components depends on the size of the negotiated information.
The basic unit used when processing the XML payloads is an
“XML line” as the SAX parser [33], [34] processes the XML
code sequentially, generating a single event per XML element.
The initial PDU size for an E2ENP payload is 100 lines
(i.e., 4.26 kB XML code). For investigating the parser/generator performance, we varied the number of input lines. As shown
in Table IV, the XML processing time of the parser/generator increases linearly with the PDU size. It should be noted that the
900
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 5, JUNE 2004
TABLE IV
MEASURED PARSER AND GENERATOR SCALING BEHAVIOR
PROCESSING A SINGLE E2ENP PDU
FOR
Fig. 14. Measured E2ENP roundtrip times depending on the network
characteristics.
E2ENP prenegotiation/negotiation payload sizes varies with the
number of streams, QoS contracts, and contexts. However, the
size of a short renegotiation is always fixed (Fig. 12) due to the
hierarchical QoS specification. Therefore, if a QoS renegotiation is at stream level—one stream level QoS contract is blocked
and another is enforced, if a QoS change is at stream-association
level—a QoS context is blocked and another is enforced, etc.
Irrespective of the level at which a QoS change occurs a short
renegotiation expresses this within only two XML elements and
within two reference lines (see “path” definition in Fig. 12).
As the size of a PDU influences the end-to-end signaling
delay (Fig. 14), we fixed in the performance tests the XML file
sizes (see the scenario at the beginning of Section V-D). The
applied uncompressed XML files are, respectively, 4.26 kB
for the prenegotiation, 3.23 kB for the short negotiation,
and 1.28 k for a short renegotiation, which references two
stream-level QoS contracts respectively for blocking/enforcing.
A single PDU (prenegotiation, negotiation, or renegotiation)
is exchanged in offerer-to-answerer direction and once in
answerer-to-offerer direction. As we were interested in the
E2ENP and user agents performance, the application did not
change the contents of the PDU when receiving it from the
user agent to include QoS counteroffers. Thus, the following
examples show the pure E2ENP application-to-application
signaling overhead.
We used a test bed including two end-devices as offerer
and answerer roles and one PC as a router (Table II), which
emulates the network performance with NISTNET according
to Table III. We varied available data rates and introduce delay
TABLE V
MEASURED E2ENP UA FSM PROCESSING TIMES PER E2ENP PHASE
to measure the E2ENP end-to-end signaling delay based on SIP
and RMI carrying the E2ENP XML files. Our measurements
(Fig. 14) show that due to the UDP-based transport using
explicit synchronization within the SIP code, the SIP-based
E2ENP performs better in low-bandwidth networks. If more
data rate is available, the complexity of the explicit SIP
synchronization increases the impact of the peer performance,
thus the end-to-end application signaling is slower compared
with the RMI-based implementation. Within high-bandwidth
networks the RMI-based SIP surrogate shows better results,
since the transport synchronization is done by TCP. Different
E2ENP phases result in different number of messages. When
using SIP with E2ENP in the push mode, a prenegotiation
consists of two messages; the negotiation/renegotiation consist
of 11 messages for both QoS-information exchange and
network resource-reservation coordination [8]. The time
necessary for a prenegotiation, negotiation or renegotiation
depends on the applied SIP transaction. E2ENP uses OPTIONS
method to perform prenegotiation (i.e., non-INVITE server
transaction [4]) compared with the INVITE transaction used
for negotiation/renegotiation. The OPTIONS method requires
longer synchronization in order to reliably exchange the control
data within only two messages, compared with the INVITE
three-way-handshake [4]. Additionally, the prenegotiation
shows the largest PDU size. An analysis of the scenario (beginning of Section V-D) shows that the renegotiation has up to
50% less signaling data compared with the negotiation procedures for establishing a multimedia session (prenegotiation,
negotiation).
The size of a PDU does not influence the FSM performance,
since following the design rules (Section III-B1) the E2ENP
UA can cope with either short or full negotiation/renegotiation.
The FSM performance depends only on the corresponding call
synchronization (Section V-A).
The following measurements were taken on a single PC
(Table II—first entry) for both SIP and the RMI-based SIP
surrogate. Table V shows the response times of the E2ENP
FSMs for the offerer and the answerer. The E2ENP UA uses
two different adaptation layer to connect the E2ENP FSMs,
one to SIP and another to RMI. In our implementation, the
E2ENP FSM waits initially for binding to the parser/generator
every time an initial call to the description language translator
is executed. This results in longer prenegotiation time for both
SIP and RMI due to the time needed to initialize the XML SAX
parser (Table V—offerer side). In contrast, a binding procedure
to the carrier protocol stack is made every time a remote invocation takes place when using the RMI base implementation.
This results in longer response times for the RMI-based SIP
GUENKOVA-LUY et al.: END-TO-END QOS COORDINATION FOR MOBILE MULTIMEDIA APPLICATIONS
surrogate (Table V—offerer side). At the answerer side, both
RMI and SIP implementations are comparable, which verifies
the stability of the E2ENP UA FSM, since the major amount of
negotiation processing takes place at the answerer side. Future
versions of E2ENP UA will decouple XML parser and carrier
protocol stack binding from the negotiation process itself. This
would result in faster prenegotiation phase.
2) E2ENP and SDPng Comparative Measurements: We
were interested to compare our solution (especially using the
short renegotiation) with state of the art [6], [15]. Since E2ENP
and SDPng differ in their description models, there is one
specific scenario, where the two technologies can be compared.
SDPng does not differentiate in its description model between
negotiation and renegotiation, has no prenegotiation phase, and
does not support short phases. Additionally, SDPng does not
have hierarchical QoS specification mechanisms for defining
hierarchical session descriptions. It is also not possible to define
PDU headers. Furthermore, the basic SDPng description model
[6] does not contain elements for QoS codec parameterization
and for transport QoS. The proposal for SDPng transport
QoS extensions [23] is up to now not adopted within the
SDPng description scheme. Due to these differences, a standard SDPng negotiation and a SDPng renegotiation has been
implemented and tested in accordance with the “offer/answer
model” [15]. The performance of this implementation has been
then compared (using the same SIP stack) with a full E2ENP
negotiation (prenegotiation data included in the negotiation
phase but no prenegotiation phase carried out), and with a short
E2ENP renegotiation. Our SIP/SDPng prototype can use the
RMI-based SIP surrogate and the SIP stack both described
in Section V-A. Thus, a consistent framework for comparing
the two technologies is provided. The session information is
always exchanged (E2ENP and SIP/SDPng) as uncompressed
XML file. We observed the following size of exchanged session
configurations in one direction (i.e., an offer or an answer):
for the SDPng negotiation and renegotiation 4.96 kB, for the
full E2ENP negotiation 6.65 kB, and for the short E2ENP
renegotiation 1.28 kB. The information within the SDPng
descriptions corresponds to the following:
• audio and video alternative codec descriptions for mediastreams according to [24];
• association of the defined streams with RTP transport parameter, common to those defined in [1].
The E2ENP full negotiation contains information about the
following:
• PDU header (see Fig. 7);
• audio and video alternative codec descriptions for media
streams according to [24] (see Fig. 8);
• parameterization of video codec descriptions (see Figs. 8
and 9) in the form of QoS parameters at application level;
• definition of transport QoS parameter (see Fig. 9);
• association of streams with RTP transport parameter,
common to those defined in [1] (see Fig. 10);
• definition of hierarchical QoS specification (see Fig. 11).
The short renegotiation PDU contains information similar to
Figs. 7 and 12.
901
TABLE VI
E2ENP AND SDPNG COMPARATIVE MEASUREMENTS
The results of the SDPng and E2ENP application-to-application roundtrip times are shown in Table VI and denote the
total time needed to establish and (re)negotiate QoS for a multimedia conference. These measurements were taken on a single
PC (Table II—first entry) and, thus, approximately correspond
to LAN behavior. Session setup time for E2ENP and SDPng
show similar behavior, where E2ENP is slightly slower (6%)
due to the larger amount of information exchanged. This is due
to the overhead of the hierarchical QoS model. In contrast, the
average response of E2ENP for the renegotiation phase is 240
ms (or 57%) faster than SDPng for our simple test scenario.
In more complex scenarios, the E2ENP short renegotiation is
even more efficient, as the size of the E2ENP renegotiation payload is highly limited due to the hierarchical QoS specification,
whereas the size of SDPng renegotiations varies with the complexity of the described application/session scenario. It should
also be noted that E2ENP directly points at the changed configuration data (i.e., enforce contract X, block contract Y) whenever performing adaptations. In contrast, SDPng renegotiations
must be compared with initial exchanged data to recognize the
change.
VI. RESULTS AND DISCUSSION
The results of the E2ENP performance measurements are in
accordance with the defined goals (Section V). The comparison
and the analysis of the SIP and RMI-based SIP-surrogate show
that further improvements of the initialization procedures and
the performance of the carrier protocol stack are necessary to
optimize the overall E2ENP performance. Additionally, a work
around for the SAX parser initialization procedure is required
to avoid delays at initial negotiation processing of the E2ENP
UA. Furthermore, E2ENP UA initialization delays at the very
first run of the JVM on a PC were observed. Performing repeated measurements, it was detected that this is a problem of
the JVM itself, which should be further investigated. From the
measurements, we conclude that E2ENP can be used to control multimedia services in low bandwidth networks. The overhead of the hierarchical QoS descriptions is low compared with
the flexibility gain and the improved renegotiation performance.
This is important, as the user tolerates a slightly longer conferencing setup as long as the disruption during adaptation is minimal and there is a need to adapt and reconfigure the streaming
process. This will definitely be required in fourth-generation
(4G) networks, where terminals will have multiple air interfaces
and handover from 802.11–based WLANs to cellular networks
might occur. If the bandwidth availability of such heterogeneous
networks differs significantly, applications must adapt or suffer
severe packet loss.
E2ENP’s effectiveness, in comparison with other similar
protocols, should further be investigated. The authors will
902
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 22, NO. 5, JUNE 2004
integrate the E2ENP UA (Section V-A) in a QoS broker
architecture similar to BRENTA [8] and test it in a complete
adaptive multimedia-conferencing scenario together with
real-time streaming, provider policy management, and network
reservations. The E2ENP solution shows scalability especially
in the case of QoS adaptation (renegotiation). The performance
can be further improved by applying compression techniques
to E2ENP payloads.
VII. CONCLUSION AND FUTURE WORK
This paper introduced an end-to-end protocol for negotiating
QoS-parameters at application, transport layer and session
configurations. It uses a hierarchical QoS model and applies
referencing mechanisms to reduce signaling load whenever
QoS adaptations are required. The special features of E2ENP
are the negotiation of QoS configurations used for QoS adaptation, including alternative QoS contracts, QoS contexts, and
QoS-adaptation rules for enabling mobile multimedia-capable
devices to utilize heterogeneous access networks. The measurement results demonstrate the scalability of our approach
and show that our mechanisms significantly reduce time for
QoS adaptation processes. Our comparative measurements
of E2ENP and SDPng processing confirm the advantages of
E2ENP.
Considering the goals of the SDP/SDPng transition, the
authors believe that E2ENP can influence SDPng direction
concerning capabilities and QoS negotiation. Major points to
discuss are optimization, consistency, and unification of XML
schema(s) and XML namespaces for describing capabilities and
QoS. Furthermore, strict namespaces for named and referenced
values (i.e., capabilities, QoS contracts, QoS contexts) have to
be defined to provide proper naming and unique referencing of
media streams, sessions, and applications.
Our future work concentrates on integration of E2ENP
into a complete QoS framework. To this extent, we plan to
provide proxies capable of interpreting E2ENP payloads,
which then work together with authentication, authorization,
and accounting mechanisms (A4C platform). This enables
service-based charging mechanisms and enhanced media-based
admission control. In addition, the proxies will work together
with QoS brokers in the network during resource reservation
phases to deploy flexible interactions between service domain
and transport domain. Finally, we will test our E2ENP in ad
hoc network scenarios, where QoS adaptations will occur
more frequently due to topology change and wireless resource
fluctuations.
REFERENCES
[1] H. Schulzrinne et al., “RTP: A transport protocol for real-time applications,” IETF, RFC 1889, Jan. 1996.
[2] A. Mankin et al., “Resource reservation protocol (RSVP),” IETF, RFC
2208, Sept. 1997.
[3] D. Durham et al., “The COPS (common open policy service) protocol,”
IETF, RFC 2748, Jan. 2000.
[4] J. Rosenberg et al., “SIP: Session initiation protocol,” IETF, RFC 3261,
June 2002.
[5] W3C. Extensible Markup Language (XML) 1.0 (2nd ed.) [Online].
Available: http://www.w3.org/TR/1998/REC-xml-19980210
[6] D. Kutscher et al., Session description and capability negotiation, IETF Internet-Drafts (draft-ietf-mmusic-sdpng-06 and
draft-ietf-mmusic-sdpng-07), Mar./Oct. 2003.
[7] T. Guenkova-Luy, A. Kassler, J. Eisl, and D. Mandato, Efficient
end-to-end QoS signaling—Concepts and features, IETF Internet-Draft
(draft-guenkova-mmusic-e2enp-sdpng-00), Mar. 2002.
[8] MIND Project, Top-level architecture for providing seamless QoS, security, accounting and mobility to applications and services, Deliverable
D1.2, Nov. 2002.
[9] X. Gu et al., “An XML-based quality of service enabling language for
the Web,” National Science Foundation, Project Rep., 2001.
[10] P. Ruiz, J. Sanchez, E. Garcia, A. Gomez-Skarmeta, J. Botia, A. Kassler,
and T. Guenkova-Luy, Adaptive multimedia multi-party communication
in ad hoc environments, Software Technology Track, HICSS-37, Jan.
2004.
[11] M. Alfano and N. Radouniklis, A cooperative multimedia environment
with QoS control: Architectural and implementation issues, TR-96-040,
Int. Comput. Sci. Inst., Berkeley, CA, Sept. 1996.
[12] A. J. Kassler, “Video adaptation within a quality of service architecture,”
Ph.D. dissertation, Dept. Distributed Syst., Univ. Ulm, Ulm, Germany,
2001.
[13] MIND Project, “MIND trials final report,” Deliverable D6.4, Nov. 2002.
[14] K. Nahrstedt and J. M. Smith, “The QoS broker,” IEEE Multimedia
Mag., vol. 1, no. 2, pp. 53–67, Spring 1995.
[15] J. Rosenberg and H. Schulzrinne, An offer/answer model with SDP,
IETF, RFC 3264, June 2002.
[16] A. Vetro et al., “Study of ISO/IEC 21 000-7 CD—Part 7: Digital item
adaptation,”, ISO/IEC JTC 1/SC 29/WG 11/N5612, Mar. 2003.
[17] International Telecommunication Union, Control protocol for multimedia communication, ITU Recommendation H.245.
, Internet protocol data communication service—IP packet transfer
[18]
and availability performance parameters, ITU Recommendation Y.1540.
, Network performance objectives for IP-based services, ITU Rec[19]
ommendation Y.1541.
, Video codec for audiovisual services at p 64 kbit/s, ITU H.261.
[20]
[21] J. Ott. Multiparty multimedia session control WG. [Online]. Available:
http://www.dmn.tzi.org/ietf/mmusic/
[22] M. Handley and V. Jacobson, “SDP: Session description protocol,”
IETF, RFC 2327, Apr. 1998.
[23] L. Bos et al., SDPng extensions for quality of service negotiation, IETF
Internet-Draft (draft-bos-mmusic-sdpng-qos-00), Mar. 2002.
[24] H. Schulzrinne and S. Casner, “RTP profile for audio and video conferences with minimal control,” IETF, RFC 3551, July 2003.
[25] J. Ott and C. Perkins, SDPng transition, IETF Internet-Draft (draft-ietfmmusic-sdpng-trans-04), May 2003.
[26] G. Klyne, “A syntax for describing media feature sets,” IETF, RFC 2533,
Mar. 1999.
[27] G. Camarillo et al., Integration of resource management and session initiation protocol (SIP), IETF, RFC 3312, Oct. 2002.
[28] J. Rosenberg and H. Schulzrinne, Reliability of provisional responses in
the session initiation protocol, IETF, RFC 3262, June 2002.
[29] J. Rosenberg, The session initiation protocol (SIP) UPDATE method,
IETF, RFC 3311, Oct. 2002.
[30] H. Lu and I. Faynberg, “An architectural framework for support of
quality of service in packet networks,” IEEE Commun. Mag., vol. 41,
pp. 98–105, June 2003.
[31] S. Blake et al., An architecture for differentiated services, IETF, RFC
2475, Dec. 1998.
[32] Ch. Valentine, XML Schemas, SYBEX, 2002.
[33] D. Megginson. SAX—Simple API for XML. [Online]. Available:
http://www.saxproject.org/
[34] Oracle Technology Network. Oracle XML developers kit. [Online].
Available: http://otn.oracle.com/tech/xml/xdk/content.html
[35] Sun Microsystems, Inc. Java TM 2 platform, standard edition (J2SE).
[Online]. Available: http://java.sun.com/j2se/
, Java TM 2 remote method invocation (RMI). [Online]. Available:
[36]
http://java.sun.com/j2se/1.4/docs/guide/rmi/index.html
[37] A. Watson and M. A. Sasse, “Measuring perceived quality of speech and
video in multimedia conferencing applications,” in Proc. ACM Multimedia, 1998, pp. 55–60.
[38] National Institute of Standards and Technology, NIST NET Home Page.
[Online]. Available: http://snad.ncsl.nist.gov/itg/nistnet/
2
GUENKOVA-LUY et al.: END-TO-END QOS COORDINATION FOR MOBILE MULTIMEDIA APPLICATIONS
Teodora Guenkova-Luy received the M.Sc. Engineer degree in computer technologies from Technical
University Sofia, Sofia, Bulgaria, in 1996 and the
M.Sc. degree in informatics and computer science
from the University of Ulm, Ulm, Germany, in 2001.
Currently, she is working toward the Ph.D. degree in
the Department of Distributed Systems, University
of Ulm, where she is an Assistant Researcher
working on her thesis concerning application level
quality-of-service coordination and management.
In the past, she worked in the area of microwave
and millimeter-wave hardware simulation and development for wireless communication at the Technical University Sofia and the University of Stuttgart,
Stuttgart, Germany. She has participated in several international research
projects (BRAIN, MIND, DAIDALOS). She has published a standard draft
in IETF and actively takes part in the work of the IETF MMUSIC WG. Her
research interests are in system modeling, middleware architectures, end-to-end
performance of distributed systems, and quality-of-service as a special issue
of the end-to-end system performance.
Andreas J. Kassler (M’97) received the M.Sc.
degree in mathematics and computer science from
Augsburg University, Augsburg, Germany, in 1995
and the Ph.D. degree in computer science from
University of Ulm, Ulm, Germany, in 2002.
Currently, is an Assistant Professor at Nanyang
Technological University, Singapore. He teaches
graduate-level courses on data networks and multimedia and has been invited to deliver research
talks and tutorials at many universities and industrial organizations. He is a Project Manager for
international research projects and is actively participating in several IETF
working groups. His research interests are in multimedia communication
and quality-of-service aspects, spanning network layer protocols, wireless
transmission, and multimedia middleware architectures.
Dr. Kassler is a Member of ComSoc and the Technical Committee of
Telecommunications of the IASTED.
903
Davide Mandato received the Dr.Eng. degree in
electronic engineering from the University of Padua,
Padua, Italy, in 1990.
From 1990 to 1995, he worked as a Firmware
and Software Engineer at Necsy, Italy, in projects
dealing with artificial telephonic traffic generation, telephonic traffic monitoring, and IN Voice
Activated Dialing services. From 1996 to 1998,
he worked as a Software Engineer at Trillium
Digital Systems, Inc., Los Angeles, CA, working
on SS7 ISUP and B-ISUP protocol layers, and on
ISUP/B-ISUP interworking functionality. In 1997, he moved to the research
field focusing on distributed systems and JAIN SS7 TCAP API. From 1998
to 1999, he worked as System Manager at the Eurofighter Simulation System,
Germany, focusing on distributed data bases. In 1999, he joined the Wireless
System Laboratories, Sony International (Europe) GmbH, Stuttgart, Germany,
working as Principal Engineer in IST projects (BRAIN, MIND), and in the
fields of context-awareness, mobile ad hoc networks, and mobile multimedia
middleware.