Multimedia services interoperability in next-generation networks for the residential environment.

Full text

Page 1

IEEE Network • November/December 2009
36
0890-8044/09/$25.00 © 2009 IEEE
owadays, multimedia services are presented in
multiple analyses as the key point for future
communications. This trend, together with the
confluence of different types of services, termi-
nals, and networks into a unique next-generation network
(NGN), will allow the incorporation of wideband applications.
NGN is a packet-based network able to provide telecom-
munication services to users and make use of multiple broad-
band quality of service (QoS)-enabled transport technologies,
and in which service-related functions are independent of the
underlying transport-related technologies [1].
Currently, the most relevant NGN standardization initia-
tives (European Telecommunications Standards Institute
[ETSI] and Third Generation Partnership Project [3GPP])
are focused on the regularization of these emerging infras-
tructures [2]. 3GPP has defined a first approach to the
NGN architecture in the mobile world through the IP multi-
media subsystem (IMS), which is now considered the stan-
dard for real-time multimedia communication services.
However, ETSI Telecommunications and Internet Con-
verged Services and Protocols for Advanced Networking
(TISPAN) is working on the adaptation of IMS to offer
these kinds of services through fixed access networks. This
solution will contribute to overcome all the restrictions of
service delivery in current platforms, avoiding the use of
proprietary solutions and the lack of competence in the
field of open service platforms.
NGN is based on an open architecture of standardized lay-
ers with guaranteed QoS, security, mobility, and flexible ser-
vice platforms; therefore, it appears as a suitable option for
achieving pan-European communication, since it is presented
as an integrated solution that can bring users the benefits of a
seamless and solid user experience regardless of their loca-
tion.
Mass market uptake of new services offered by such a plat-
form requires interoperability between operators. Only a
small number of network equipment providers are actually in
a position to really offer an end-to-end integrated telecommu-
nications solution applying the NGN specifications. Each of
these providers has its own proprietary solution, and they are
not prepared enough to be interconnected to equipment from
different providers since they apply different implementations
of the standard. Also, the specifications themselves are diffi-
cult to keep track of, as several major specification bodies are
involved, producing hundreds of documents.
Due to these facts, even simple a priori tasks such as a
basic call or a client registration are far from being out-of-the-
box features, requiring hardware and software adaptations
that may or may not be technically feasible. Once basic net-
working interoperability is achieved, additional challenges
such as integration with existing systems, multivendor service
layer interoperability, and mobility of users and terminals
must be addressed too.
Different research programs have appeared in order to
N N
Javier M. Aguiar, Carlos García, and Henar Vega, Universidad de Valladolid
Álvaro Martínez and Tamara de Vega, Telefónica I+D
Philippe Bouillé, France Telecom R&D
Antoine de Poorter, Ericsson Spain
Abstract
This article presents an open and functional architecture based on a next-genera-
tion network solution in order to seize its converged nature to guarantee interoper-
ability among different platforms and terminals. The defined architecture is an
integrated solution for end-to-end communication of various IP multimedia subsys-
tem platforms marketed by different vendors, belonging to several operators locat-
ed in different countries across Europe and supporting multiple terminals and
technologies in order to experiment with a new broadband telephony service for
the residential environment. This work addresses, in particular, the interoperability
problems of name resolution and implementation of the Session Initiation Protocol
Interface at the terminal as a key use in such a scenario. Also, several advanced
services are developed and tested within the proposed architecture as a proof of
concept of the IMS capability for quick service creation and deployment. The archi-
tecture proposed contributes to the reduction of obstacles and barriers among the
European countries in order to adopt NGN architectures, allowing a new type of
communication that is more complete and flexible.
Multimedia Services Interoperability in
Next-Generation Networks for the
Residential Environment

Page 2

IEEE Network • November/December 2009
37
encourage studies and projects related to interoperability and
large-scale NGN deployments. One of these initiatives is
Cooperation for European Sustained Leadership in Telecom-
munications (CELTIC), the cluster focused on communica-
tions integrated in the international cooperation program
EUREKA. The objective of this initiative is the development
of pre-competitive comprehensive integrated communication
system solutions that will be the core of the CELTIC Pan-
European Laboratory, enabling trial and evaluation of service
concepts, technologies, and so on.
Within this environment appears the Multimedia Commu-
nication Service (MaCS) project [3–5], on the results of which
this article is based. The aim of MaCS is to attain pan-Euro-
pean communication between NGN terminals and platforms
coming from different providers and using different technolo-
gies, achieving a suitable level of interoperability.
This document introduces an architecture that provides
multimedia conversational communication between two or
more users placed in different locations across Europe and
connected through NGN, providing a bidirectional real-time
transmission containing both video and audio. Innovation
aspects are focused on providing multimedia communication
among users of diverse networks independent of the terminal
(PCs, videophones, etc.), making communications more flexi-
ble and adapted to end-user needs.
This article is organized as follows. The next section intro-
duces the underlying architectures and technologies of the
architecture proposed, while the following section is focused
on the interoperability issues. We then present several innova-
tive multimedia services that make use of the interoperable
features provided by the platform. In the following section
some test results are discussed. We then deal with the
strengths of an IMS-based system. The final section presents
major conclusions related to this work.
Architecture Model
Pan-European Laboratory
Vendors have implemented their own versions of the standard
IMS architecture, with often conflicting interpretations of the
specifications. These conflicts arise as a natural result of their
aim for differentiation. This aim often leads them to refute
standards if the vendor approach suits their objectives signifi-
cantly better. Few cooperation efforts have been launched so
far in order to effectively achieve interoperability; among
them, the IMS Plugfest Events organized by the IMS Forum
as well as some private consortia such as the Open Services
Partner Alliance (OSPA) or the Rich Communication Suite
Initiative (RCS) can be mentioned.
The added value of the CELTIC initiative lies in the pre-
competitive development of an integrated communication sys-
tem solution, at the core of which lies the CELTIC
Pan-European Laboratory. Thus, the main priorities of
CELTIC are the trial and evaluation of services, technologies,
and terminals, together with the analysis of business models in
order to have a direct transfer of these results into marketable
products and applications. Hence, this emergence of interop-
erable and pre-competitive networks and products will
increase the maturity of the market.
Within this environment, the MaCS Project has contributed
to the creation of this laboratory, offering a platform involving
various operators and manufacturers from different countries
across Europe. Through this platform, the project offers an
open and functional communication system based on next-
generation architectures (and particularly IMS), ensuring
interoperability between the different agents and appropriate
performance of advanced multimedia communication services.
Figure 1 shows the communications environment that has
been built within the MaCS Project. Different laboratories
Figure 1. Pan-European laboratory.
SIP
SIP
SIP
SIP
France
Telecom
European backbone
Phillips lab
Sagem lab
Service
Nokia NGN
platform
Control
Access
Deutsche
Telekom
Service
IPTel NGN
platform
Control
Access
Multimedia
terminals
SIP
SIP
Telefónica
University of
Valladolid lab
Service
Ericsson NGN
platform
Control
Access
Multimedia
terminals
Multimedia
terminals

Page 3

IEEE Network • November/December 2009
38
located in various countries have been interconnected in order
to allow testing of the services developed.
Reference Architecture
As introduced previously, the MaCS architecture developed
for the implementation of the multimedia services is based on
the architecture proposed by ETSI TISPAN, which in turn is
mainly based on IMS. The MaCS architecture includes several
modifications depending on the network features and the spe-
cific requirements of multimedia services [6]. This architecture
has been deployed by several operators using different ven-
dors’ equipment in a pan-European communications network,
addressing the interoperability issues arising — particularly
IMS client interface and name resolution — within the MaCS
Project lifetime. Figure 2 presents a global overview of the
MaCS architecture proposal, identifying the correspondences
of the entities proposed with those depicted by ETSI TISPAN
in its network architecture specification.
The main elements composing the MaCS architecture are
briefly described as follows:
• The network attachment subsystem (NASS) is mainly in
charge of the following functionalities:
–Dynamic provision of IP addresses and terminal configura-
tion parameters.
–IP level authentication.
–Authorization and access configuration based on user pro-
files.
• The admission and resource control platform (ARCP) is
basically in charge of admission control (interacting with
the NASS) and port management functionalities. ARCP is
reached from the access network through the multimedia
access gateway (MAG).
•The call session control function (CSCF) includes the func-
tionalities of three IMS core elements:
–The proxy-CSCF (P-CSCF) is the user access
point in the IMS subsystem.
–The serving-CSCF (S-CSCF) is in charge of ses-
sion management.
–The interrogating-CSCF (I-CSCF) is the intercon-
nection point between networks from different
operators.
The CSCF is the logical signaling entity connect-
ed to the end user’s terminal in the signaling path.
It provides the user with access to the service
provider network, and some of its functions include-
acting as a registrar server, controlling sessions of
registered users for the support of services, and
proxying Session Initiation Protocol (SIP) mes-
sages. Moreover, the CSCF interacts with service
platforms, communicating with different servers
such as the conference server (CS), the application
server (AS), the media server (MS), and the pres-
ence server (PS).
•The AS provides value-added multimedia services,
hosting and executing services such as messaging
and session forwarding. The AS exports an appli-
cation programming interface (API), which pro-
vides a higher abstraction layer for the
multimedia service designers. The network hides
the IMS layout from the services, and at the
same time provides building blocks for service
designers.
•The service database is in charge of the function-
alities encompassed by the home subscriber serv-
er (HSS) defined by ETSI TISPAN. It is the
element containing the information regarding the
subscription of a user, in charge of the storage of
user identification (addressing and numbering), security
information, registration, and profile information.
• The interconnection border gateway (IBG) constitutes the
connection interface between different IP transport net-
works. It is in charge of functions such as packet filtering
(port opening/closing), packet flagging, resource allocation
and reservation, IP address and port translation, and net-
work address port translation (NAPT).
• The MAG is the network entity that terminates the access
connections of the access network. This entity limits the
connection of the access network, providing the aggregation
capabilities between the access network and the IP core
network, and implementing functions such as IP packet for-
warding, packet marking, and flow policing.
• The interconnection border control function (IBCF) con-
trols the boundary between the domains of two different
operators at the signaling level, interacting with the trans-
port resources and protecting the signaling information on
both sides: source and destination.
Interoperable Infrastructure
From the point of view of terminals and infrastructures inter-
connection, an important obstacle appears when managing
interoperability between IMS platforms [7] from different
manufacturers. This is the need for a common implementa-
tion of the IMS client interface at the terminal. To fulfill this
need, it is necessary to define a specific SIP profile in order to
guarantee both interoperability and multimedia conversational
services requirements, since SIP [8] has been adopted as the
signaling protocol by the IMS system.
The problem emerges due to the existence of two flavors of
the specification: some vendors may implement the 3GPP
Figure 2. Global architecture proposal and ETSI TISPAN equivalent entities
(in ovals).
MaCS service
layer
Access
transport
network
Core
transport
network
CS AS
CSCF
IBCF
ARCP
NASS
MAG
IBG
I-BGF
C-BGF
NASS
IBCF
CSCF
RACS
UPSF
(HSS)
User
equipment
MS PS
SIP
SIP
SIP
Service
data base

Page 4

IEEE Network • November/December 2009
39
standard, while others may implement the one offered by the
Internet Engineering Task Force (IETF). This causes the
necessity to make certain changes in both the platforms (to
ensure interoperability) and the clients, in order to be able to
register from any of the terminals in any of the platforms.
Therefore, MaCS has defined its own SIP profile in order to
ensure that platforms and terminals involved in the overall
architecture implement the standard at an equivalent level.
Moreover, the terminals developed within the MaCS Project
are SIP-based in order to make the most of the communica-
tions advantages it offers. Figure 3 shows the global laborato-
ry and the main SIP signaling connections.
Another key point to solve is the name resolution when
establishing calls between users located in different platforms.
A first approach is use of the Domain Name System (DNS)
specifying different domains for each platform. However, the
existence of diverse mechanisms for resolution via DNS (SRV
requests, type A registers, NAPTR) forces the administrators
of each domain to study the problem in a global way and
establish a unique method for name resolution. Thus, the
communication system deployed within MaCS adopts a hier-
archical architecture for naming resolution, with different
approaches at the IMS domain level but a common name res-
olution system on top. Figure 4 shows the final scheme imple-
mented in MaCS.
Interoperable Multimedia Services
In order to demonstrate the achieved interoperability between
heterogeneous vendor and operator platforms, different ser-
vices have been developed and tested over the MaCS pan-
European communications network. The services are mainly
focused on the residential environment, such as Multimedia
Messaging, Originating Information Presentation and Restric-
tion (OIP/OIR), Presence and Reachability Service (PRS),
and Local Address Book and Network Address Book
(LAB/NAB). Implementation of these services at a European
level has been achieved thanks to the separation between the
service, transport, and network layers presented by the NGN
architecture. This separation allows the development of ser-
vices directly on the service layer, without considering details
of the transport layer. During execution of the project, differ-
ent tests have been carried out in order to demonstrate the
pan-European connection.
The following services represent an innovation regarding
interoperability since their implementation takes place in an
international scenario and between heterogeneous NGN plat-
forms. The services developed demonstrate that the use of
NGN in an interoperable scenario effectively facilitates the
task of creating new services. These services have been speci-
fied following Unified Modeling Language (UML) and 3GPP
phase division methodologies.
OIP/OIR
The aim of this service is to use the network as the source for
multimedia information used to identify the caller, such as its
picture and avatar, instead of the terminal. In this way the
receiving terminal gets a uniform resource locator (URL)
added by the network to the session establishment message.
The terminal extracts from the URL the multimedia informa-
tion about the sender, which will be shown to the end user.
User identification can be performed via the terminal’s
URL, caller’s uniform resource identifier (URI), a phone
number in E.164 format, and a photo or an avatar associated
with the caller, as long as these data are available and quali-
fied by the network. If these data are not received (e.g., net-
work problems), a caller’s identification is displayed as
unavailable.
Figure 3. Global overview of the interconnection architecture (for two operators).
MaCS service
layer B
Core
transport
network A
Core
transport
network B
Access
transport
network B
MaCS service
layer A
Operator B
domain
Operator A
domain
SIP
SIP
SIPSIP
SIP
User
equipment B
User
equipment A
CSCF
CSCF
IBCFIBCF
Service
database
Service
database
CS ASMSPS CSASMS PS
Access
transport
network A
MAGMAG
IBG
IBG
ARCPARCPNASS
NASS

Page 5

IEEE Network • November/December 2009
40
The restriction of caller identification allows the caller to
avoid receiving parties getting his/her identification in any
of the ways previously mentioned, unless for some special
cases in which the receiver has a way to cancel this restric-
tion. The caller has the possibility to establish the restric-
tion of identification to be permanent (for all calls) or as a
temporary setting (the service is only invoked for that spe-
cific call).
Presence and Reachability Information Service
Presence information makes reference to a user’s capacity to
know the availability of its contacts in order to contact them
through a phone call. The real communication capability
depends on network availability, compatibility between termi-
nals, and so on. Presence information allows the user to
inform his/her contacts about his/her availability to receive
calls and at the same time to check about theirs. This way a
user can indicate that he/she is away and therefore will not be
able to answer any incoming calls.
The five presence states that are normally used are: con-
nected, disconnected, away, unavailable, and a personalized
message that allows the user to indicate several circumstances
such as “having lunch” or “attending a meeting.” Therefore,
the user is able to indicate in a more descriptive way the rea-
sons for his/her unavailability.
Users can attempt to subscribe to other users’ presence
information. These other users have to explicitly accept such a
subscription before the requesting user receives their presence
information. The possible contacts can always accept or reject
another user request to access their presence information.
They can also block a user whenever they want, so this user
stops receiving presence information, generally receiving
instead a disconnected status message. In the same way, this
user can be unblocked at any moment so he/she can again
receive the initial user’s presence information.
The reachability information automates actions such as
call rejection, redirection, or missed call messaging depend-
ing on the rules established for each contact state. This ser-
vice uses a series of routing rules that can be configured via
the Web, in combination with presence information. The
routing rules include group management, so the group the
user belongs to can affect the session processing (and there-
fore the presence state showed); for example, a user with a
presence state of unavailable would receive calls from users
belonging to the VIP group, but not from users out of that
group. These VIP users will also see a presence state differ-
ent from the state the rest of the users see, given that the
reachability service can modify the presence information
received.
LAB and NAB Services
These two services allow a user to store information related to
his/her contacts, such as name, address, phone number, email,
alias, picture, and avatar. LAB service keeps this information
locally in the terminal, whereas NAB service stores the infor-
mation in the network.
Users of these services can create new contacts, check,
modify, or delete their contacts data, and search for a specific
contact in the list. Users can also establish a session, in any of
its modalities, with one of their contacts. All the previous
operations are executed directly on the local list of contacts,
which then gets synchronized with the network list. Whenever
a user gets connected from a terminal, the network contact
list is loaded into the terminal.
Synchronization between LAB and NAB is done through
the SyncML protocol, which allows synchronization among
several databases. Its purpose is to synchronize all local
address books the user may have in different terminals, so the
user has his/her agenda information at his/her disposal what-
ever terminal is used to establish the connection.
Figure 4. MaCS name resolution scheme.
dt.macs.com ft.macs.com
IMS
Ericsson
IMS
Nokia
IMS IPTel
Hardware
terminal
Hardware
terminal
Software
terminal
Hardware
terminal
Software
terminal
Software
terminal
IMS
DNS
macs.com
A type
DNS resolution
NAPTR type DNS
resolution
SRV type DNS
resolution
tid.macs.com