Learning Center
Plans & pricing Sign in
Sign Out

IT-based Open Service Delivery Platforms for Mobile Networks


									IT-based Open Service Delivery Platforms for Mobile Networks:
           From CAMEL to the IP Multimedia System


                      Dr. Thomas Magedanz
                         Muhammad Sher

           Faculty of Electrical and Computer Engineering
              Technical University of Berlin, Germany
                      NGNI Competence Centre
           FOKUS Fraunhofer Telecommunication Institute
                           Berlin, Germany
      IT-based Open Service Delivery Platforms for Mobile Networks
               From CAMEL to the IP Multimedia System
                           Dr. Thomas Magedanz, Muhammad Sher
                   Technical University Berlin/Fokus, Fraunhofer Institute Berlin, Germany

In this chapter we want to illustrate the evolution of Service Delivery Platforms (SDPs) over the last
decades for mobile communications i.e. from Customized Applications for Mobile Enhanced Logic
(CAMEL) to IP Multimedia Subsystem (IMS) defined for emerging all IP Networks. We will also view
the constant evolution of IT on one hand and the changing face of telecommunications, namely, the
convergence of fixed and mobile telecommunications and the Internet, and the related changes of
business models for service provision as well as the increasing functional complexity of services on the
other hand. Thus the SDP evolution has driven by the evolution of IT, Internet, telecommunications and
mobile communications in order to enable seamless multimedia services.
Keywords:- Service Delivery Platform, Fixed- mobile convergence, Middleware Technologies, APIs,
Open Service Architecture, IP Multimedia Subsystem, QoS, Next Generation Networks.

                                           Table of Contents

    1. Introduction -
                   Towards Fixed Mobile Convergence and Seamless Multimedia Services

    2. Mobile Service Delivery Platforms and the impacts of IT evolution
             2.1     IT evolution
             2.2     SDP evolution at a glance

    3. The Intelligent Network in the Mobile Domain – Customized Applications for Mobile
       Enhanced Logic (CAMEL)
             3.1     Some words on the Intelligent Network concept
             3.2     CAMEL Principles and Architecture
             3.3     CAMEL Standards and Applications
             3.4     Some words on the American Wireless Intelligent Network

    4. Open Network Application Programming Interfaces (APIs) - Parlay, OSA, JAIN
             4.1     API Motivation
             4.2     API Principles and Architecture
             4.3     API Standards and Applications
                     4.3.1 Parlay
                     4.3.2 GPP Open Service Access (OSA)
                     4.3.3 Java APIs for Integrated Networks (JAIN)

    5. The IP Multimedia System (IMS) for emerging All-IP networks
             5.1     IMS Motivation
             5.2     IMS Principles and Architecture
                     5.2.1 IMS Components
             5.3     IMS Standards and Applications
                     5.3.1 Value Added Services in IMS

    6. Summary & Outlook: Policy-based Service Control

The Service Delivery Platforms (SDPs) have always been standing in the center of telecommunications, as
they are the foundation for the creation, deployment, provision, control, charging and management of
telecommunication services provided to the end users and thus enabling the generation of revenues. The
SDPs represent the “programming interface” enabling programming of the underlying network capabilities
and therefore are primarily based in the usage of information technologies (ITs). They are changed over the
last decades constantly, as innovation has been taken place at rapid pace in this domain.


                                                                              Presence GLMS
                                                                             Presence     GLMS
                                                                             Service Delivery
                                                                                HSS                     IMS

                                                 RAN                          SGSN

                    Figure 1: Stove Pipe Architecture versus converged network SDP

Whereas historically different network types, i.e. fixed networks, mobile networks, data networks, and the
Internet have been operated by different operators with different business models providing quite different
services, these SDPs have been specifically designed for a given network environment. In such an
environment, also called the stove pipe architectural model (figure 1), services have been designed,
deployed, provisioned, controlled and managed on top of heterogeneous SDPs with no need for service
integration. There was a clear separation of fixed voice telephony, cellular voice telephony and fixed or
even mobile Internet access for web browsing and emailing.
With the emergence of mobile multimedia services, such as unified messaging, click to dial, cross network
multiparty conferencing and seamless multimedia streaming services, the convergence of networks (i.e.
fixed–mobile convergence and voice–data integration) is started, leading to an overall Internet–
Telecommunications convergence. This idea is highlighted in figure 2. In face of such convergence, the
need for universal SDPs supporting integrated services emerged. This means that SDP should in principle
enable the rapid and uniform programming and provision of seamless multimedia services on top of any
network environment. There is no doubt, however, that today two main trends are of pivotal importance for
SDPs design, namely the support of mobile users and the support of (mobile) multi media data services.

                                           Today                                                                             Future
                             Single-service networks                                                                Multi-service network

                                                                                                                          Service Network
                                                                                                                      S                     S
                                                       Data/IP Networks

                                                                                  Cellular Mobile

                                                           Cellular Mobile



                                                                                                              MGW     Backbone Network          MGW

                                                                                                                     MGW                MGW
                                                                                                                          Access Networks

                     Access, Transport & Switching Networks

                    Figure 2: Stove Pipe Architecture versus converged network SDP

In this chapter we want to illustrate the evolution of SDPs concepts and technologies over the last decades.
In the following section we look briefly at the evolution of IT and middleware technologies, which is
followed by an overview of SDP evolution from the Intelligent Network (IN) towards the IP Multimedia
Subsystem (IMS) defined for emerging all IP networks. Section 3 will look at the application of the remote
procedure call based intelligent network concept in the mobile domain which is called CAMEL
(Customized Logic for Mobile Enhanced Logic). In Section 4 we introduce the notion of
telecommunications application programming interfaces based on CORBA and J2EE middleware and
discuss the OSA/Parlay and JAIN. Section 4 is also looking at the impacts of web service technologies
resulting in the definition of Parlay X and the OMA Open Service Environment (OSE). Section 5 is
introducing the IP Multimedia Subsystem (IMS), which is today in face of fixed-mobile convergence and
emerging all IP networks and is regarded as the ultimate SDP spanning fixed and mobile IP networks.
Section 6 concludes this chapter giving some outlook on emerging policy based networks.

2. Mobile Service Delivery Platforms and the Impacts of IT evolution
The SDPs have constant impact on the evolution of IT on one hand and changing the face of
telecommunications and the Internet, namely, the convergence of fixed and mobile telecommunications and
the related changes of business models for service provision as well as the increasing functional complexity
of services on the other hand. Figure 3 displays the SDP evolution that has been driven by the evolution of
IT, Internet, telecommunications and mobile communications in order to enable seamless multimedia

                                            Seamless Multimedia Applications


                                                      Service Delivery           Internet
                       Telecommunications                 Platform

                                              Information Technologies
                                            RPC – CORBA – J2EE – Web Services

                        Figure 3: Impacting Factors of Service Delivery Platforms

2.1     IT Evolution in a Nutshell

The Information technology is defined as computer communications, networks, and information systems
that enable exchanges of digital objects. We can say also IT encompasses all forms of technology used to
create, store, exchange, and use information in its various forms like business data, voice conversations,
still images, motion pictures, multimedia presentations etc. A convenient term for including both telephony
and computer technology in the same word, IT is the technology that is driving what has often been called
"the information revolution." IT includes matters concerned with furthering computer science and
technology, design, development, installation, and implementation of information systems and applications.
Historically, the telecommunications world was quite different from the information technology and data
communications world. In the telecommunications world, where history started with the early days of
telegraphy in the end of the 19th century, the prime focus was on providing a highly reliable telephone
system for real time voice transport. This system has evolved subsequently from manually switched phone

calls (recall the switch board form the beginning of the 20th century) to automated switching systems,
handling the so called basic call process themselves. Value added services have been implemented inside
the switches by means of dedicated, switch-specific programmes (stored programme controlled switches),
which interacted via a switch-specific interface with the basic call process. Heterogeneity of switches inside
one network have made this a time and cost intensive procedure.
In the data communications world the focus was on the interconnection of remote computers without severe
real-time constraints, as mainframe computers have started to being replaced by distributed computing
systems in the sixties/seventies. There is no doubt that the future will converge to mobile networks
environment, uniting the traditionally separated telecommunications and internet world, will be an all IP
(Internet Protocol) based one. The reason for this is that IP-based technologies are much cheaper in
deployment and maintenance, and that most of the future information and communication services are data
driven where the contents origi nates from the internet. This also means that the corresponding signalling
and control protocols from the internet world are having a strong impact on the telecommunications
network evolution.
Based on the invention of the remote procedure call (RPC) in the sixties, it became possible to create
programmes that can talk to other remote programmes without any knowledge of their (possible)
distribution. In face of emerging object oriented programming languages such as C++ and Java and the
related middleware platforms, such as CORBA and J2EE, the notion of open network APIs has emerged at
the end of the last century as a natural evolution of the intelligent network concept. The principle idea,
namely to program services in the programming language of choice against abstract service interfaces on
application servers connected via the object oriented middleware to a network gateway, which has to map
the API operations onto a specific network protocol, has received global attention and acceptance.
With the emergence of web service technologies defined by the W3C, these APIs also have been adapted to
benefit from this major IT trend in the beginning of this century. Parlay X represents a web services based
simpler but functionally limited interface compared to the classic OSA/Parlay APIs. Also the OMA with its
Open Service Environment (OSE) and the Microsoft Connected Service Framework (MCSF) represent
similar but different initiatives in this context.

2.2      SDP Evolution at a Glance

The SDPs typically provide so-called value added services, i.e. services which extend the basic capabilities
of the underlying networks, e.g. flexible call treatment (e.g. call forwarding) or special charging services
(e.g. free phone) added to the plain old telephony service (POTS). Such service capabilities include
advanced (multiparty and multimedia) call control, different kinds of messaging, data session control,
flexible charging, user location, presence status, etc. Following the good old manual and electric
switchboards, telecommunication services, such as call forwarding, call screening, etc. had been provided
in the sixties directly in the switching nodes. This approach has been called stored program control.
However, heterogeneity of switching nodes, signalling protocol diversity and the lack of common
standardized interfaces for value added service provision made this an expensive approach with very slow
service offers to market.
The invention of the common channel signalling systems, particularly the signalling system n (SS7),
enabled the design of real time remote service control architectures. Based on the RPC paradigm AT&T
and later Bellcore (Telcordia) invented the Intelligent Network (IN) in the seventies. Based on a
standardised call model for switches and the corresponding SS7-based Intelligent Network Application
Protocol (INAP), centralised highly reliable computer systems, so called Service Control Points (SCPs),
                                   rom remote via the SS7 network. Different global intelligent network
have been able to control switches f
standards defined by ITU-T, ANSI T1S1, ETSI and Telcordia with increasing service capabilities have
been developed and implemented in the eighties and nineties (figure 4).
The intelligent networks have mainly changed the way of telecommunications service design and
implementation by defining reusable service components for implementing rapidly new services, such as
free phone, premium rate, prepaid, and virtual private networks in a network independent way. Service
provision times increased significantly. In addition to exploiting IN in the mobile world, some efforts have
been undertaken to make use of IN for controlling Voice over IP environments. Besides the global success

of the IN and CAMEL, it became obvious over time, that the IN programming model is limited due to the
used IT and the inherent complexity of the INAP protocol.

                            SIP App.
                                                                                      IP Multimedia
              Internet       Server                                                      Services
                          AAA      SIP               Server
                                                                   Application         3rd Party
                         Server   Server
                                                                     Server           Application
   2000                                                                                 Services
             Web Services                                                        (Enterprises / Internet)
                                                OSE / Parlay X
                            Diameter                                                   OSA / Parlay
                             Interface                                                Interface
             CORBA/Java                                   OSA/Parlay Gateway
      90’s                               Interface
                                                                                             IN / CAMEL
                RPC                                           IN Platform
      80’s                                                                                        Stored
               = Services                                               GSM        ISDN          Services
                                       VoIP           GPRS/UMTS

                                              Figure 4: SDP Evolution at a Glance

3. The Intelligent Network in the Mobile Domain – Customized Applications for
   Mobile Enhanced Logic (CAMEL)
Based on the success of the intelligent networks in the fixed network world, the International
Standardisation Bodies adapted the intelligent network concept for the mobile world, known as Customized
Application for Mobile Enhanced Logic (CAMEL) in Europe and Wireless Intelligent Network (WIN) in
the United States. The CAMEL Application Protocol (CAP) has been defined for the implementation of IN
and CAMEL environment. Four versions of CAMEL have been defined during the nineties for extending
the scope of CAMEL, so that all major intelligent network services can be provided within mobile

3.1          Some Words on the IN Concept

The challenges for providing value added services more rapidly according to the ever changing user
demands in the sixties, the existence of the RPC enabling a remote communication and thus more economic
programming of switching systems has created a new design of the telecommunications systems. AT&T
and Telcordia have invented the intelligent network concept. A centralised computer based system (called
Service Control Point (SCP)) controls in real time remotely the switching nodes (called service switching
points (SSPs)) for the provision of value added services by means of a dedicated signalling protocol IN
Application Protocol (INAP) on top of the common channel signalling network (the signalling system no. 7
(SS7)). Besides INAP, the call mo del (CM) was key component which model a unified behaviour of a
switch during call processing. The centralisation of service logic and data while providing distributed
service access enabled a much more efficient creation, provision and management of services. Moreover,
the idea of the intelligent network has been to offer a set of generic Service Building Blocks (SIBs) as
shown in figure 5 to create a multitude of value added services, similar to a distributed operations system

that enables plenty of applications to be executed. This means that the combination of IT middleware and
telecommunications system enlarged drastically the programmability of the telecommunications network.
The Telco Lego brick system for value added services has also been standardized by the International
Telecommunications Union (ITU-T) in the famous Q.1200 recommendation series for Intelligent Networks
capability sets and by Telcordia and ANSI (American National Standards Institute) within the Advanced
Intelligent Network (AIN) releases. It has to be recognised, that the IN concept decoupled the service
provision from the underlying network, which allows in principle to provide IN-based services on top of
different bearer networks. Thus the IN has been applied originally to the PSTN, subsequently to ISDN, and
in the end of the 90th to mobile networks (i.e. GSM) under the name of WIN or CAMEL.

                                          Service A             Service B

                                             SIB         SIB      SIB
                                                                            IN Platform
                                                   IN Architecture
                                                     (SSP, SCP)

                                       Mobile            PSTN           Internet

                                Figure 5: The Intelligent Network Concept

Today the IN is used all over the world for value added services provision, like universal access numbers,
virtual private networks, freephone, premium rate calls and messages, and most particular prepaid cards.
Most of the IN sales in the end of the 20 th century have been in form of CAMEL platforms deployed on top
of GSM/GPRS networks that replacing the traditional but limited “VAS service node” based service
architectures. Furthermore, studies and prototypes have also proved the applicability of IN concepts onto
all IP networks. Therefore, the IN represents the first “open” universal value added service platform for
several bearer networks.

3.2     CAMEL Principles and Architecture
One major reason for the success of the GSM system is the strict standardization of all service aspects.
However, this also has limited the innovation and competition of operators. Therefore specific service
nodes have been introduced within the operator networks, providing IN-like service capabilities, such as
prepaid services. As service node based service provision was limited to the operators network only due to
their proprietary interfaces, roaming users had no access to these value added services. Thus, ETSI and
later 3GPP have looked for a standardized solution for value added service provisioning for roaming users.
Recognizing the success of IN in the fixed network world, the IN has been adopted for its usage to the
mobile domain. One important design challenge for CAMEL was to cope with a multi vendor mobile
environment; therefore a stepwise standardization has been performed, defining so-called CAMEL Phases.

The general CAMEL architecture is provided in figure 6. A specialized set call procedure known as
CAMEL Service Environment (CSE) in the home network and provides the operator specific value added
services for mobile originating and mobile terminating services, such as prepaid and VPN. This CSE can be
accessed via a simplified IN protocol, called CAMEL Application Protocol (CAP), from SSP-enhanced
MSCs, called GSM Service Switching Functions (SSFs), from the home network and most importantly
from partnering visited networks. In addition to CAP, CAMEL is dependent on the Mobile Application
Protocol (MAP) for the dynamic provision of CAMEL subscription information within GSM subscriber
profiles and location-based CAMEL services.

                                     SCP            HLR
          Home                                                                         VLR
                                                               2                     SSP
                                                                      3                            IP
                               IP                                                    MSC                     Visited
                                                SSP                                                          Networks
                                     SSP       GMSC                              4
                             VLR                                                             1
                               A                                                                   roaming
              Call                                                         Mobile Originating Service Example
               User @ home                                             1     -   Subscriber dials number
                 network                                               2     -   Send Initial Detection Point (IDP)
                                   CAP Dialogues                       3
                                                                             -   Receive Connect
                                   MAP Dialogues                       4
                                                                             -   Connect to B -party directly

                                    Figure 6: CAMEL - IN within Mobile Networks

3.3       CAMEL Standards and Applications

The driving force for CAMEL standardisation and subsequent deployment was the support of prepaid
roaming and virtual private networks for post paid roaming users. CAMEL standards mainly concentrate on
the definition of the CAP based on INAP specialization and extensions to the MAP for dynamic CAMEL
service provisioning. Figure 7 displays the major evolution steps.

      •   CAMEL Phase 1 was defined in 1996 as the first but limited standard which defining mainly call
          control, location services and some charging aspects to support a simplified prepaid service and
          VPN. It defined a simplified IN call model and just six CAP operations.
      •   CAMEL Phase 2 was completed 1998 adding full charging support and thus full prepaid support
          and user interaction capabilities. Complexity of call model and protocol has been enhanced.

                                                                      Home Network
                            Camel Phase 4                                                               Camel Phase 1 + 2
                                   HSS                                                                       HLR

                     3G IP based Voice
                     & Data Networks IM-SSF               CAP
                                                          (over IP)                                 MSC           IVR
                                                                                                    (SSF)          (IP)
                                   S-CSCF                                              CAP            2G Circuit Switch
                                                            Camel Phase 3                               Voice Network

                                                                           2.5G Packet Switch
                                                                           GPRS Data Network

                                         Figure 7: Evolution of CAMEL Standards

      •   CAMEL Phase 3 defined in two versions in 1999 and 2000 that extended the CAMEL capabilities
          to more sophisticated call control, data session control, extended location services, SMS services
          and some others. However, it required major upgrades of the infrastructure and thus substantial
      •                                                                       ,
          CAMEL Phase 4 defined in 2001 provided full IN capability set 2 call control and a modular
          CAP protocol structure. In addition, it defined the option to use CAMEL on top of the emergi ng
Today we find mainly CAMEL Phases 1 and 2 deployed in the networks as these solve the major operator
needs. CAMEL Phases 3 and 4 are considered for most operators to expensive. Experiences have shown
that CAMEL deployment is quite costly due to high interoperability testing. Moreover, it has become
obvious, that both a home network and all visiting networks have to run the same CAMEL version in order
to take advantage of CAMEL, otherwise the deployment of a higher CAMEL phase in a home network is
of very limited use.

3.4       Some words on Wireless Intelligent Networks (WINs)

Wireless Intelligent Network (WIN) is different form CAMEL as it is just focusing on adopting IN for
providing specific value added services on top of wireless networks. Service provision of roaming users in
other networks is not a target. WIN is defined by ANSI, TIA and T1standards bodies in the US; ANSI
represents US interests abroad in terms of technical and policy positions and TIA and T1 create standards
for wireline and wireless networks. TR45 is a wireless division of TIA; TR45.2 subcommittee focuses on
standards for mobile and personal communications; ANSI-41 and WIN T1 create network inter-connection
and interoperability standards for wireline and wireless, T1S1/T1P1 subgroups develops standards and
technical reports related to wireless networks and services. The WIN standards follow a development
process different from CAMEL. As WIN standards are conceived and are assigned a project number, e.g.
PN-4287 prepaid charging. Once adopted by TIA, the PN becomes an interim standard, such as IS-771
WIN Phase 1. After an interim standard has been published by TIA, there is a 3-year period of revision and
acceptance. When industry adopts the interim standard it becomes part of ANSI 41 e.g. IS-771 is targeted
to become part of ANSI 41-E.

4. Open Network Application Programming Interfaces (APIs) - Parlay, OSA, JAIN
The notion of distributed broadband IN systems has emerged in the nineties. However, a substantial change
of the IN system architecture has not been adopted, as the IN system had besides all above described
advantages some inherent limitations. Most particular, the IN platform has not provided the desired level of
flexibility in service provisioning, as the service platform was still coupled with the underlying network
protocols and switching equipment and thus limited. This means that there has not been a full decoupling of
the service level and the switching level, and thus the programming of IN services was quite complex and
only possible by a limited set of special telecom experts. Additionally, the business models of IN-based
telecommunication networks were quite closed, which was considered as a major limitation in face of the
changing value chain of multi media services.
In face of these limitations, the ongoing convergence of Telecommunications, IT and the Internet, the
notion of a new programming paradigm for telecommunications is emerged as open application
programming interfaces (APIs). Driven by the need for a common multi media service platform for
converging networks and the proven commercial usability of distributed object oriented platforms, new
standards for open service platforms are emerged. The main reason is the option to map the API to different
network types (i.e. call control API to fixed telephony network and to VoIP network) and thus to run the
services seamlessly across different networks. One way is to implement an OSA/Parlay gateway on top of
IN/CAMEL platform, i.e. to map the APIs onto INAP/CAP, however direct mappings to ISUP and SIP is
also feasible. Another reason is the option, to enable the secure connection of third party provider and
enterprise application servers to the network operator’s gateway and thus the operators flexibly implement
different business models for applications.

4.1      API Motivation

One main principle of the IN concept was to exploit the capabilities of the state of the art information
technologies in order to enlarge the developer community and make the implementation of services more
economically. As in the nineties the notion of object oriented programming, software languages like C++
and Java, and coincidently distributed object-oriented systems, such as OMG’s Common Object Request
Broker Architecture (CORBA) and Sun’s Java 2 Enterprise Edition (J2EE) appeared, the IN architecture
was subject of many R&D activities centring around the distribution of IN components and ease of service

                                                            Applications making use of genric API
                     App 1     App 2             App N      services ( independent of underlying
                                                            network technology )
                                Parlay /OSA API
                                                                       Service         - Call Control
                                                                       Gateway         - Messaging
                                                                                       - Charging
                                                                                       - User Location
             Mapping to network specific protocols (INAP, ISUP, SIP, ..)               - ...

                    ISDN            GSM/GPRS
                                    GSM/GPRS                     Internet/ /

                                Figure 8: Open Network APIs (OSA/Parlay)

In addition, there was in face of emerging content based services an increasing complexity of the business
value chain and thus the operator’s need for supporting more complex business models. The provision of
the network to third party service providers and enterprises was considered as an option to generate more
market oriented services and thus revenues. Using software distribution technologies, i.e. middleware and
the provision of an API offering a much easier programming of telecommunication services represent the
main design criteria of these merging API based SDPs.

4.2      API Principles and Architecture

Based on the pioneering work of the Telecommunications Information Networking Architecture (TINA)
Consortium in the early nineties, the Parlay Group (consists of operators, vendors, and IT companies) has
started in 1998 with definition of an open network Parlay API. This API is inherently based on object
oriented technology and the idea is to allow – if desired by the business model – third party application
providers to make use of the network or better speaking the value added service interfaces. However, today
the best view on Parlay is to consider it as some kind of telecom specific Enterprise Application Integration
(EAI) platform technology, allowing service providers to develop value added applications on top of a
different and/or changing network environment as shown in figure 8. This allows a smooth network
technology evolution below the developed applications.

Originally designed for the use on top of IN systems, i.e. to open up IN systems for third party developers
in fixed networks, the API evolved fast to a general API to be used on any underlying fixed, mobile, voice,
or packet network. 3GPP has aligned in 2001 their work on an Open Service Access (OSA) API with
Parlay as a response to support their service vision of the Virtual Home Environment (VHE), as also ETSI
did for their SPAN (Service Provider Access to Networks) APIs in the same year. Today all three standards
are completely aligned and thus represent probably the most accepted standard in this domain.
Additionally, SUN started in the late nineties (with the increasing commercial acceptance of the Java
language) the specification of the Java APIs for Integrated Networks (JAIN) as a set of specifications
for implementing Java-based next generation IN platforms on top of different bearer networks. Recognising

the similarities in their targets, JAIN joined the Parlay, 3GPP, ETSI group in 2002 and developed the JAIN
Service Provider Access (SPA) API. Figure 9 explains the evolution of open network APIs standards.

                                                              n OSA (Open Service Access)
                                                              n UMTS Rel. 99, Rel.4, Rel 5, Rel 6.

                                                                                n ETSI SPAN: PSTN/ISDN
                                                                                n APIs for 3rd-Party Service
                                                                                  Application Interface
          n   Phase 2 (12/1999)
          n   Phase 3 (10/2001)
          n   Phase 4 (12/2002)                      n JAVA-based APIs for integrated networks (JAIN)
          n   Phase 5 (12/2004)                      n JAIN Parlay = JAIN Service Provider ACCESS (SPA)

                             Figure 9: Evolution of Open network APIs Standards

Looking these APIs in some more detail, it is important to recognise the open/extensible nature of the APIs
architecture. The main idea is to provide in a dedicated network node known as OSA/Parlay Gateway
operated by the network operator an open set of service interfaces, which exhibit specific value added
service capabilities. This comprises call control, messaging, data session control, location, presence,
charging, etc. Applications could access these capabilities, thanks to object oriented technology (i.e.
CORBA, C++, Java), easy to use interfaces (optionally via a network) to implement value added services.
A dedicated interface known as the framework is in charge to register/discover new service interfaces,
perform application / network authentication, service level agreements, etc.

                                               Parlay/OSA Applications
                                       Application         wall          Hosted Application
                                         Server                               Server
                Enterprise    Intranet
                                  OSA / Parlay APIs                        Internet
                                                        Parlay                    Hosted            Boundary
                Service                                Gateway                    Application Svr
                Provider      Router   Network
                Domain                 Elements
                              Managed IP             Elements      SCP       Mobile           HLR
                               Network                                      Network

                                   Figure 10: The OSA / Parlay API Concept

Important act is that the API is network independent, i.e. in principle each network (note that the type of the
network doesn’t matter) will provide its own OSA/Parlay gateway, and one application can make use of
several gateways. This means that an application can run with the same logic simultaneously on top of a
fixed telephone network and a voice over IP network. Today OSA/Parlay technology is going to be
deployed slowly all over the world. Typical applications include premium charged content delivery

services, location based services, and enterprise mobile office applications. In this case the network
operators provide capabilities for sending messages and charging for it, mobile user location information
and third party call control, respectively.

4.3 API Standards and Applications

Most important fact is that the API can be extended functionally over time by the inclusion of new service
capabilities and thus enables some kind of Telecoms Enterprise Application Integration (EAI). The Parlay
group, ETSI and the 3GPP Open Service Access (OSA) APIs are representing the current aligned state of
the art in this context. These APIs support both OMG CORBA and Sun´s J2EE. In addition, Sun has
created a similar Java-only telecoms architecture known as Java APIs for Integrated Networks (JAIN). The
functional capabilities of these network APIs include multimedia call control, messaging, user interaction,
charging, user status and location, presence, etc, enabling besides the classic intelligent network services
like the implementation of click to dial, mobile commerce and content delivery services.

4.3.1   Parlay

As we know that the Parlay Group started in 1998 with the definition of the Parlay API. Originally
designed as an extension of the IN within fixed networks, the API has been extended over the years as a
generic API for any underlying network, i.e. fixed, mobile, IP networks. The Parlay group has always
studied the impacts of new IT on the API design and thus has studied the use of CORBA, Java and also in
2002 web service technologies. Different phases of Parlay Group are as follows:

    •   Phase 1: (only for PSTN) finished end of 1998
             o   The Parlay Comsortium consisted of the following five companies: BT, Microsoft, Nortel
                 Networks, Siemens, Ulticom (DGM&S Telecom) . Developed APIs: Framework, Call
                 Control, Messaging, and User Interaction. Version 1.2 of these APIs was released in
    •   Phase 2: (extended scope to wireless and IP) finished end of 1999
             o   The following new six consortium members were added: AT&T, Cegetel, Cisco,
                 Ericsson, IBM and Lucent.
             o   Group completely opened in 2000.
    •   Phase 3: (extended towards M-Business) finished June 2001
             o   Alignment with 3GPP Open Service Architecture and Java APIs for Intergated Networks
    •   Phase 4: (Presence, Policy Management) finished in September 2002
             o   Incorporation of web services
             o   Simplified interface development: Parlay X
    •   Parlay 5: new Messaging API, enhanced Parlay WS & Parlay X2
Today the Parlay APIs represent the state of the art technology for implementing open service delivery
platforms on top of various bearer networks, including all IP networks. The Parlay API specification itself
is divided into two main roles, the Framework and the so called Service Capability Features (SCF) as
shown in figure 11. The SCFs are responsible to provide the real mapping to the underlying network
resources whereas the Framework logically ties all together and makes a Parlay installation manageable.
The SCFs that are bundled in one server, is called a Service Capability Server (SCS). A minimum Parlay
Gateway must have a Framework and should have at least one SCF. Because the interfaces between SCF
and Framework are also defined using the chosen middleware (CORBA) technology, it is not necessary
that they reside on the same host or even that they are impleme nted with the same technology or

programming language. That means a Parlay Gateway can be a compact box but can also be designed as a
heterogeneous distributed architecture. This fact is further enhanced as fault tolerance and load balancing
for systems which requiring high availability.



                                    Parlay/OSA API

                Framework             Interface         SCF X                                 SCF z

                                                                                      SCF y           SCF a


                   Network                 Service
                   Resources             Interface X

                                Figure 11: Framework vs Service Interfaces Parlay Framework
The Parlay Framework, as a core component in the interface architecture, serves as a single entry point for
all applications. It provides mainly, beside the initial access, authentication (framework to application and
vice versa), authorization, service discovery, and service agreement. For the SCFs the framework provides
additionally interfaces for registration and lifecycle management. In detail the Framework interfaces are:

    •   Framework Access Session API – It contains the trust and security management parts that manages
        the initial entry point, authentication of both framework and client application, and granting access
        (authorization) to specific SCFs.
    •   Framework to Application API – It handles general events concerning the relation, and provides
        integrity management (load management, fault management, heartbeat, OAM), service discovery,
        and service agreement functionality for the application.
    •   Framework to Enterprise Operator API – Provides general events but also service subscription
        capabilities that mean everything about client management, service contracts, service profiling,
        and even operator account management.
    •   Framework to Service API – Besides general events, this API enables services to register, to
        discover other SCFs, managing their lifecycle, and doing integrity management. Parlay SCFs
The Parlay Group defines in its actual version 5.0 the following Service Capability Features which provide
a more generic and abstract interface to network resources, or network features and hiding network specific
protocols and entities:

    •   Call Control – It consists generic call control (up to two parties), multiparty call control,
        mul timedia call control (e.g. video calls), and conferencing call control (moderated multiparty).

    •   User Interaction – Its one part is call related and allows IVR driven applications. The other part is
        not call related and its purpose is mainly for messaging like sending and receiving SMS.
    •   Mobility – This SCF allows requesting, triggering and being notified about user location and user
        status information.
    •   Terminal Capabilities – Querying terminal capabilities and features.
    •   Data Session Control – Third party control of packet switched connections between peers
    •   Generic Messaging – Offering a mailbox or message box like access to stored messages. It has a
        directory like structure and can store and handle emails, SMS, MMS, voicemails and video mails.
    •   Connectivity Management – Handles Quality of Service aspects of connections and services
    •   Account Management – Allows querying, creating and deleting balances and vouchers for
    •   Charging – Enables applications to charge for their services, either online or offline, prepaid or
        post paid.
    •   Policy Management – Covering policy driven parts of a network. Allows management of many
        aspects concerning policy driven computing, inclusively domains, repositories, groups, rules, and
    •   Presence and Availability Management – Provides management for presence and availability
        information of a user. E.g. user A is currently online and can be reached under the following
        addresses but not for user B. It allows an application to modify as well as watching this
        information. Parlay X
As one major target of OSA/Parlay is to make the networks programmable by means of the state of the art
in middleware technologies in order to make the network programmable by the application providers, the
API has been enhanced by the use of the new web services paradigm, which combines the eXtensible
Markup Language (XML), Web Service Description Language (WSDL), and Simple Object Access
Protocol (SOAP). The idea of web services follows the idea that in most times the contents providing the
starting point for information services originates in the Internet–the Web. Furthermore, services could be
constructed from packaging other remote services available in the web.

                                   C++               “Web Services” App               Parlay X App
                                                   XML                           XML
                               / Java App          Script  Java      VB          Script   Java     VB
                                                      Not really            “ MakeACall(A,B)”
                    createCall()                     Demanded    !
                                            routeReq(A)                                     XML Transport:
                    routeReq(A  )           routeReq(B)    routeRes(B)
                    routeReq(B  )                          …                             Simple XML sequences
                    …                                                                     over SOAP, CORBA,
                                    routeRes(A)                       Parlay X APIs             HTTP, …
                                    …               XML Transport:         Parlay X Gateway
                                            Complex XML sequences
                                                  over SOAP, CORBA,       createCall()
                                                        HTTP, …           routeReq(A)
                      Classic IIOP                                        routeReq(B)
                      Parlay                                              …
                      APIs CORBA                     XML              CORBA
                               IDL, Java                                            SIP SCP/CSE
                                            Parlay Gateway Java,
                                                          XML, …                   Server

                           Figure 12: Parlay Classic API vs. Parlay X APIs

Consequently web service technology, such as .NET from Microsoft comprises the basic means for
describing, registering, finding and using web services. In the telecommunications world, Parlay web
services, and the more simplified version of it called Parlay X shown in figure 12, represents today the
state of the art in web services. These are considered also as the main starting point for what the Open
Mobile Alliance (OMA) is looking for – mobile web service enablers. OMA is considered today as a super
standards forum, bringing together various others such as wireless village, WAP forum, etc. The main
target is to approve useful wireless standards for enabling rapid service delivery. Because many already
asserted Parlay gateways and applications are based on CORBA middleware the web service specification
for the classic Parlay interfaces is not really demanded for now, whereas the Parlay X web services
becomes more and more important. Because the Parlay X specification tries to simplify the Parlay APIs, it
is always at the cost of functionality that can be provided. It is decided that the Parlay X specification
should follow a division of 20% functionality and 80% simplicity.
The latest specification Parlay X 2.0 contains the following parts:
    •    Third Party Call
    •    Call Notification
    •    Short Messaging
    •    Multimedia Messaging
    •    Payment
    •    Account Management
    •    Terminal Status
    •    Terminal Location
    •    Call Handling
    •    Audio Call
    •    Multimedia Conference
    •    Address List Management
    •    Presence
It is obvious that most of this interfaces can directly mapped to one or more Parlay interfaces, but more and
more implementations today are mapped directly to related components and their corresponding interfaces
or protocols, e.g. to SIP and Diameter in case of an IMS. Parlay X Web services have also been adopted by
3GPP CN TSG (September 2004) for inclusion in the OSA Release 6 in TS 29.199-xx-600. Open Mobile Alliance

The OMA was originally created in 2002 by consolidating the WAP Forum and the Open Mobile
Architecture initiative. Now there are also consolidated the following organizations:
     • Location Interoperability Forum (LIF)
     • SyncML initiative
     • MMS Interoperability Group (MMS-IOP)
     • Wireless Village
     • Mobile Gaming Interoperability Forum (MGIF)
     • Mobile Wireless Internet Forum (MWIF)
Some of the most prominent members in the OMA are Cisco, Hewlett Packard, Sun Microsystems, and
Sony-Ericsson. The OMA says in their principles: “Open Mobile Alliance aims to enable mobile
subscribers to use interoperable mobile services across markets, operators and mobile terminals by defining
an open standards based framework to permit application and service to be build, deployed, managed
efficiently and reliably in a multi-vendor environment.” To achieve these principles the OMA liaising with
various other organizations from the mobile area, like 3GPP and 3GPP2, ETSI, ITU-T, Parlay and more to
leverage existing and approved standards into their architecture. The overall OMA system architecture is
described and defined by the architecture working group in the OMA Service Environment specification
(OSE). It ensures that the OMA service enablers utilize IMS capabilities whenever applicable. Therefore it
also describes the consistent usage of capabilities from the IP Multimedia Subsystem. The OSE
specification will describe how the architectures from different OMA working groups and also external
organizations can be re-used and combined to minimize the "silos" in the OMA enablers, and how all the
pieces of the OMA architecture will fit together.

                                                    15 Microsoft Connected Services Framework

This recently new approach was officially launched by Microsoft on February 2005 for general availability
and is build totally on Microsoft Technologies. While the access for services is mainly build on
standardized technologies and protocols, like Web Services, XML and SOAP, the Framework itself is a
suite of products and services from Microsoft. What kind of role the Connected Services Framework will
play in the future of the Service Delivery Platform market is not foreseeable now. But to ignore a big
company with such a big market share would be a mistake.

                            Figure 13: Microsoft Connected Framework

4.3.2   3GPP Open Service Access (OSA)

The Open Service Access (OSA) was designed by the 3rd Generation Partnership Project (3GPP) to provide
intelligent services in the Global System for Mobile (GSM) communications systems, a 2G cellular systems
originating in Europe, and Universal Mobile Telecommunication Standard (UMTS), the European 3G
cellular standard that followed on the success of GSM.

                       Internet /    SIP
                       UMTS         Server                       OSA API
                                              Parlay                using
                                             Gateway               network
                                                       CORBA /                    Data
                        SCP                                        services
                                      MAP                            Application system
                                    Telecom Network                  Enterprise
                                        Domain                       Domain

                            Figure 14: OSA API

Figure 14 depict the OSA that API how network capabilities become programmable through OSA/Parlay
gateway. Additionally, it shows how these APIs can benefit from advances in in-house as well as externally
hosted internet service creation and hosting technology. Like JAIN, the OSA/Parlay APIs combine two
service creation models: the internet service creation model and the telecommunication service creation
model. Parlay and OSA are two closely related APIs and since late 2001 these APIs have been formally
merged, so they are often called OSA/Parlay.

4.3.3 Java APIs for Integrated Networks (JAIN)
Java APIs for Integrated Networks (JAIN) is an initiative led by Sun Microsystems Java Community
Process (JCP) to create abstractions and associated Java interfaces for service creation across PSTN, packet
switching and wireless networks. The goal of JCP is to allow the broader Java community to participate in
the proposal, selection and specification process for Java API. The JAIN standardization effort is organized
into two broad areas:
    •   Proposal specifications that standardize interfaces to PSTN and IP signalling protocols.
    •   Application specifications that deal broadly with the APIs required for service creation within a
        Java framework.
The JAIN defines a Service Creation Environment (SCE), a Service Logic Execution Environment (SLEE),
a software component library, and a set of development tools as shown in the figure 15. The JSCE allows
the development of new service building blocks and the assembly of services from these building blocks.
Services are than deployed into the SLEE. The SLEE is a set of software interfaces that support and
simplify the construction of portable communications services. The primary goal of the SLEE is to ensure
service portability. To achieve this SLEE provides a specification for APIs that are needed by services and
that must be supported by JAIN-complaint SLEE vendor. The second goal of the SLEE is to simplify the
services. It does this by specifying a common set of functions or components that must be made available
to application developers.

                                                      JAIN Service
                                  Untrusted                            Trusted
                                  third-party                         third-party
                                 applications                        applications
                                 JAIN Service Provider        Security Interface
                    Open API                                                                Independence
                                    Access (JSPA)
                                                   Secure Telco Space                          Network
                                       JAIN Service Logic Execution Environment             Independence

                                                JAIN Call Control (JCC)
                                     and JAIN Coordination and Transactions (JCAT)          Independence

                                 TCAP       ISUP       INAP    SIP    MAP          MGCP
                               IP                       Wireless
                                                        Wireless     PSTN      Satellite
                                IP       Broadband
                                          Broadband                   PSTN

                                Fig. 15: JAIN and SLEE Environment

5. IP Multimedia System (IMS) for emerging All-IP networks
In face of an emerging all IP network and the emergence of quite generic internet protocols defined by the
Internet Engineering Task Force (IETF) for multi media session control, i.e. Session Initiation Protocol
(SIP), and Authentication, Authorisation, and Accounting (AAA), i.e. Diameter, a new overlay service
architecture has been defined for fixed/mobile IP networks – IP Multimedia Subsystem (IMS), standardised
by 3GPP and 3GPP2 in the 2000 and this architecture is considered for global deployment in 2005/2006.
The main idea of the IMS is to allow the flexible connection of so called SIP Application Server (AS) to

the IMS core infrastructure, which connected via SIP and Diameter that can implement any kind of
multimedia control or content services. Besides VoIP and multimedia multiparty services particularly Push
to Talk (PTT) is considered as IMS killer application.

5.1      IMS Motivation

In face of the all IP network vision, namely to use of fixed and mobile IP networks for both data and
voice/multimedia information looking for the target service control architecture. The IMS is an approach to
provide overlay SDP architecture for IP networks, entirely build on Internet protocols defined by the IETF,
which have been extended on request of 3GPP to support telecommunications requirements, such as
security, accountability, quality of service, etc. Mobile operator face today the problem, that mobile users
can gain access to the internet and make use of internet services, such as instant messaging, presences, chat,
content download, etc. On the other hand the operators defines a minimum SDP architecture for providing
QoS, security and charging for IP based services, while providing maximum flexibility for the realisation of
value added and content services.
The IMS provides easy and efficient ways to integrate different services, even from third parties and
enables the seamless integration of legacy services and is designed for consistent interactions with circuit
switched domains. The IMS manages event oriented quality of service policies e.g. use of VoIP and HTTP
in a single session: VoIP has QoS, HTTP is best effort. These systems (IMSs) also have event oriented
charging mechanism policies; means change specific events on the appropriate level. If two events need the
same IP resources we may charge them differentially for the same user in the same session. These
characteristics make the IMS as the future technology in a comprehensive service and application oriented

5.2      IMS Principles and Architecture

The IMS is based on Internet protocols, basically those for session control (SIP), AAA (Diameter) and
media transport (RTP) and a clear separation of data transport, session control and application logic. Figure
15 displays a generic IP based SDP architecture (note that QoS control and chargi ng is not addressed in the
figure!). In the IMS architecture, Session Initiation Protocol (SIP) is used as the standard signaling protocol
that establishes controls, modifies and terminates voice, video and messaging sessions between two or
more participants. The related signaling servers in the architecture are referred to as Call State Control
Functions (CSCFs) and distinguished by their specific functionalities.

                       Connection / call control functions               Subscription                   AAA: User and
                                                                           Server                       Appl Profiles
                       Application control functions                      Function

                                                             Diameter                        Diameter

                        SIP    Session       SIP       Session                 SIP               Application        •Service Execution
                                Control                 Control                                    Server
                               Function                Function                                   Function          •Service Management
                                                                        SIP            SIP                          •Service Creation
                              RTP                                                     Media
                                                                                      Server                   •IVR
                                                                         SIP         Function                  •Conferencing
                 •Basic call control                          SIP
                                                                          Signaling                            •Speech Recognition
                 •Signaling                                               Gateway                              •Text-to-Speech
                 •Resource Management                    Media
                                                        Gateway           Function
                 •CDR Generation                        Function                                SS7/IP Signaling
                                                       Bearer data

                              Fig. 16: The IMS Functionality Diagram

It is important to note that an IMS compliant end user system has to provide the necessary IMS protocol
support, namely SIP, and the service related media codecs for the multimedia applications in addition to the
basic connectivity support, e.g. GPRS, WLAN, etc. In general, SIP is a signalling protocol, similar to the
Digital Subscriber Signalling #1 (DSS1) and ISDN User Part (ISUP) used in circuit switched networks and
the Intelligent Network Application Protocol (INAP) in the telecommunications world. However, telecom
experts may argue that DSS1, ISUP and INAP are quite different. Indeed, DSS1 and ISUP are just
signalling protocols for ISDN telephony in between the end system and the switch and between switches,
respectively. By contrast, INAP is a service control protocol and used to remotely control switches for
value added service provision. SIP is used commonly for both domains, but just in the VoIP world. Most of
all SIP is a signalling protocol in between VoIP elements, but can also be used to talk from a SIP server to
an SIP application server (SIP AS), which is defacto a dedicated SIP element. This also means that SIP
has some inbuilt service capabilities, allowing SIP elements to implement some IN like services, e.g. call
forwarding, call screening, etc.




               Visited                                           HSS


               Network                         Dx               (AAA)                Application


                                Mw                   Mw                    ISC         Media
                P-CSCF                    I-CSCF               S-CSCF

                                                                               SIP     Server

                                                               Breakout                   Media
                                                               Gateway                   Gateway
                                           Network                              Mj
                 Access Networks
                (WLAN, UMTS, DSL)                                                         Interworking with
                                                                                         Legacy Networks
                                                                                        (GSM, ISDN, DVB)

                     Figure 17: SIP and Diameter - Key protocols in the IMS architecture

The functionality related to Authentication, Authorization and Accounting (AAA) within the IMS is based
on the IETF Diameter protocol and is implemented in the Home Subscriber System (HSS), the CSCFs and
various other IMS components in order to allow charging functionality within the IMS. Instead of
developing the protocol from scratch, Diameter is based on the Remote Authentication Dial in User Service
(RADIUS), which has previously been used to provide AAA services for dial-up and terminal server across
environments. The Diameter Protocol has two parts: the Diameter base protocol and the Diameter
applications. The base protocol is needed for delivering Diameter data units, negotiating capabilities and
handling errors. The Diameter application defines application-specific functions and data units.
The other protocol which is important for multimedia contents is Real-time Transport Protocol (RTP). It
provides end-to-end delivery for real-time data. It also contains end-to-end delivery services like payload-
type (codec) identification, sequence numbering, time stamping and delivering monitoring for real-time
data. RTP provides QoS monitoring using the RTP Control Protocol. RTCP also conveys information about
media session participants.

5.2.1    IMS Components
Figure 18 shows the important entities of IMS and their little description is given as: The first contact point
within the IP multimedia core network subsystem is the Proxy Call State Control Function (P-CSCF). The
P-CSCF behaves like a proxy accepting requests and services from internally and forwards them. The next
component is the Interrogating Call State Control Function (I-CSCF) which is the contact point within an
operator's network for all connections destined to a subscriber of that network operator, or a roaming
subscriber currently located within that network operator's service area. The functionalities performed by I-

CSCF are assigning an S-CSCF to a user performing SIP registration/charging and resource utilisation etc.
Than we have the Serving Call State Control Function (S-CSCF) which performs the session control
services for the endpoint. It maintains session state as needed by the network operator for support of the
services. Its functionality includes user registration/interaction with services platforms for the support of

                    IMS Service              HSS               Application
                                             (AAA)               Server

                    P -CSCF                 I- CSCF               S- -CSCF
                                                                   S CSCF        Server

                                            IMS Core                            Media

                                                                              Interworking with
                     Access Networks
                                                                             Legacy Networks
                    (WLAN, UMTS, DSL)
                                              Underlying IP Core Network     (GSM, ISDN, DVB)

                                        Figure 18: The main IMS Architecture

After the core components we have the Home Subscriber Server (HSS) which is the equivalent of the HLR
(Home Location Register) in 2G systems; however, extended with two Diameter based reference points. It
is the master database of an IMS that stores IMS user profiles including individual filtering information,
user status information and application server profiles. The other component in the IMS service layer is the
SIP Application Server (AS) which is the service relevant part in the IMS. Only well defined signaling and
administration interfaces (ISC and Sh) and thus SIP and Diameter protocols need to be supported. This
enable developers to use almost any programming paradigm within a SIP AS, such as legacy Intelligent
Network servers (i.e. CAMEL Support Environments), OSA/Parlay servers/gateways, or any proven VoIP
SIP programming paradigm, like SIP Servlets, call programming language (CPL) and Common Gateway
Interface (CGI) scripts, etc. The SIP AS is triggered by the S-CSCF which redirects certain sessions to the
SIP AS based on the downloaded filter criteria or by requesting filter information from the HSS in a user
based paradigm. The SIP AS itself comprises filter rules to decide which of the applications deployed on
the server should be selected for handling the session. During execution of service logic it is also possible
for the SIP AS to communicate with the HSS to get additional information about a subscriber or to be
notified about changes in the profile of the subscriber.
The Media Resource Function (MRF) in IMS can be split up into the Media Resource Function Controller
(MRFC) and the Media resource Function Processor (MRFP). It provides media stream processing
resources for like media mixing, media announcements, media analysis and media transcoding as well
speech. The triple of Border Gateway Control Function (BGCF), Media Gateway Control Function
(MGCF) and Media Gateway (MG) perform the bearer interworking between RTP/IP and the bearers used
in the legacy networks.

5.3      IMS Standards and Applications

The IMS has been standardised since the beginning of this century within Release 5 and extended in
Release 6 within 3GPP and 3GPP2 as extension to the GPRS/packet domain network. The Release 5
standards have been driven by the vision to define the IMS for providing multimedia services including
VoIP and thus being able to make the circuit switched GSM part of 3G networks obsolete in the long term,
whereas realistically Release 6 has optimized the IMS to provide the envisaged IMS killer application Push
to Talk (over Cellular). In addition, ETSI TISPAN is since 2004 looking at service infrastructures for fixed
mobile convergence and next generation networks extends the IMS to make it applicable on top of various
access networks, i.e. WLANs and particular fixed Internet i.e. DSL.

The policy-based QoS (Quality of Service) control architecture in the IMS is the key part to provide IP-
based multimedia applications and services with end-to-end QoS guarantee. The reference model of a
policy-based network consists of two main elements, the policy decision point (PDP) and the policy
enforcement point (PEP). The PDP weighs the policy request sent by the PEP, as a result of a policy event
against a corresponding set of policy rules. As a response to a policy request, the PDP either evaluates the
policy rules for the request or retrieves the set of policy rules relevant for the request. The policy decision
or the set of policy rules is then transported to a PEP using the policy transaction protocol which is called
Common Open Policy Service (COPS) as shown in figure 19. The PDP is the final authority that PEP needs
to refer to for actions to be taken. This allows operators to control QoS in a user plane and exchange
charging correlation information between IMS and GPRS network using COPS protocol. The COPS is a
simple query and response protocol that allows policy serves (PDPs) to communicate policy decisions to
network devices (PEPs) and uses TCP to provide reliable exchange of messages. It provides the means to
establish and maintain a dialogue between the client and the server and to identify the requests.

                                                                    Policy Manager
                                  Policy Management Tool

                                                                LDAP Policy Repository
                                   Policy Decision Point

                                                                Policy Enforcement Point
                                                                 Policy Enforcement Point
                                       COPS/SNMP                  Policy Enforcement Point
                                                                         Enforcement Point

                                                                      Policy Enforcer

                           Figure 19: The policy-based administration framework

The IMS architecture supports both online and offline charging capabilities. Online charging is a charging
process where IMS entities, such as an application server (AS), interact with the online charging system.
The online charging system in turn interacts in real time with the user’s account and controls or monitors
the charges related to service usage e.g. the AS queries the online charging system prior to allowing session
establishment or it receives information about how long a user can participate in the conference. Offline
charging is a charging process where charging information is mainly collected after the session and the
charging system does not affect in real time the service being used. In this model a user typically receives a
bill on monthly basis, which shows the chargeable items during a particular period. Due to different nature
of charging models different architecture solutions are possible.

5.3.1    Value Added Services in IMS

The value added services can be provided in all IP environments in principle on all involved SIP systems
which are interacting via SIP. This means that it could be end systems, i.e. user agents (UAs), and/or SIP
servers, i.e. proxies or back to back UAs (B2BUAs), or the SIP AS. Unfortunately today there doesn’t exist
any common programming paradigm for SIP value added services. Most often there is the notion of service
scripts, namely, SIP servlets, call programming language (CPL) and Common Gateway Interface (CGI)
scripts. All of these have compared to IN/CAMEL and OSA/Parlay platforms with severe limitations in
functionality and developers support. However, as SIP has been selected as the universal signalling
protocol in the 3GPP IP Multimedia Subsystem (IMS) domain, the notion of SIP application servers, which
offer often combinations of CGI and servlets approaches, is emerging. However, also OSA/Parlay can be
used on top of SIP as well as IN/CAMEL as displayed in Figure 20.
    •    CAMEL Services via Camel Support Environment (CSE) - intended for the support of existing
         IN Services (provides service continuation).

                                            OSA Service
                                            OSA Service
                         SIP AS                                                  Camel CSE
                                             (Parlay AS)
                                              (Parlay AS)

                                              OSA SCS
                                               OSA SCS
                                            (Parlay GTW)                          IM SSF
                                             (Parlay GTW)
                                ISC / SIP                                              ISC /SIP
                                                         ISC / SIP
                                                   Local AS


              Figure 20: 3GPP IMS Service Architecture Options: CAMEL – OSA – SIP AS

    •   OSA Services via Open Service Access Service Capability Server - intended for the support of
        3rd Party Application Providers. OSA SCS provides access and resource control.
    •   IMS services on SIP-Application Server - intended for new services. A multitude of widely
        known APIs (CGI, CPL, SIP Servlets) is available.
    •   IMS services directly on the CSCF (similar to SIP AS) - SIP-AS is co-located on the CSCF
        which seems to be useful for simple services. It may be beneficial for the service availability and
        the service performance.

                                                                                                      Application Server
                          Diameter                Application              OSA
                          SIP                                                         CAMEL
                                                  Servers               AS

                                                     SIP AS                           IM-SSF
                              HSS                                          GTW
                                                                                                     IMS Core Server

                                                                     Local AS

                                                   (SIP Proxy)                        Media Server

                                            PDF               SIP Server

                                 Figure 21: IMS Application Server options

It has to be noted that the IMS itself is designed as a platform providing service enablers. This means IMS-
based services are not standardised. Therefore it is difficult to identify today concrete IMS services. The
reason is that the standards bodies want to provide as much as possible freedom for service ideas and
service implementations. Only the absolute necessary minimum functionality for QoS, security, charging
capabilities have been standardised to enable better value added IP-based services, compared to the classic
internet services. However, IMS services are important for the introduction of IMS as an SDP. The IMS
services are assumed to be addressed by the OMA. An excellent example is PTT or PoC as shown in figure
22. The key PTT functions include presence, Group list management, PTT media processing and the PTT
application logic (including floor control handling). These are glued tightly together in the first vendor-
specific PoC deployments, but from 2005/2006 onwards IMS-based PTT implementation will be deployed.
The idea is to enable the reuse of the PTT core ingredients for other service offers, such as presence based


                                                                                                    Application Server
                                                     PoC SIP AS

                                                        PoC             PoC          PoC
                                   HSS                Presence         GLMS         Logic

                                                                                                    IMS Core Server
                 PoC User Group

                                                      P/I/S-CSCF                   PoC Server
                                                      (SIP Proxy)
                                                                                 IMS Media Server
                                               PDF            SIP Server

                                       Figure 22: IMS- based PoC realisation

As seen in the PTT example new services are beneficial combination of service capability features. Most
likely upcoming services will also relay on features like presence, group-list management, additional logic
and other features on operator network e.g. location, SMS, MMS. It is obvious that service capability
features must be reused for scalability and capital expenses reasons. The remaining problem is “how to
manage and orchestrate services?”, “how to create stringent services that bundle service capability
features?” and mainly “how to open up the network for services in a secure way?”. As postulated in the
3GPP specifications the adoption of OSA/Parlay concepts and technologies can contribute a lot.
OSA/Parlay already provides an industry standard that enables unified access with gateway character to
service capability features of operators’ network. Even secure access by third parties can be handled by the
OSA/Parlay framework. This framework may control resources, permit mal functions or defective service
habit. Assuming there is secure access for third parties the network is not only opened up for a variety of
service developers but a milestone in service personalisation is set up. By the usage of “Rapid Application
Development” tools optimized for OSA/Parlay every subscriber can design and specify his own set of

6. Summary & Outlook
We have looked in this article on the evolution of SDPs in the last decades. It should have become clear by
now, that in face of converging networks and emerging interconnected multi-domain all IP networks the
provision of an SDP is a challenging task, requiring a lot of integration work. The IMS is today regarded as
the ultimate SDp approach, taking advantage of the inherent use of IP-centric protocols. However, the
deployment of IMS is driven by applications and the need to interwork with legacy access networks as well
as legacy SDPs, such as IN/CAMEL and OSA/Parlay. In this regard figure 22 illustrates that the adoption
of OSA/Parlay as unifying service framework on top of both CAMEL and/or IMS can unify the service
provision across different and converging networks.
The underlying figures 23 & 24 extend the above in regard to the ability of OSA/Parlay to support flexibly
both, the FMC network operators for EAI purposes, as well as the optional and flexible support of services
originating from third parties and enterprises. The later is an important aspect, as it is clear that there won’t
be any future killer application for FMC and NGNs, rather a myriad of customized applications provided to
specific user communities. In general, policies represent a technique to describe by means of scripts the
requirements and desired behaviour of a network or network elements in a protocol independent way. This
means them abstract (similar to an API approach) from the specific details of the underlying network
components, which may also include service platforms.

                                  Seamless NGN Services (opt. by 3rd Parties )

                                  OSA/Parlay Services            ( Apps Servers)
                                                                                            Parlay (X) API

                   New                                                                         Reuse
                                              OSA Gateway
                                               OSA Gateway             OSA Gateway
                                                                       OSA Gateway
                   MM Services                                                                 CAMEL
                                              SIP AS    (AAA)          Camel CSE               Services

                                        SIP                      CAP
                              3GPP IMS           S -CSCF                   CAP       CAP GSM /

                                               PDF    PDF                                   GPRS
                           WLAN /
                                         WAG                     SGSN            MSC

                     Figure 23: Summary of SDP evolution linked to network evolution

Looking at the Internet it is based on an open best effort business model and the overall internet comprises
an open set of sub networks, i.e. different internet service providers (ISPs) have to cooperate with each
other. In this multi-domain environment end to end service provision, particularly augmented with Quality
of Service (QoS) across different domains, is a challenging task. As inside the different networks different
technologies and protocols may be used, the provision of a service, for example a virtual private network,
requires the definition/provision in a network protocol independent way. This is what policy-based
management and control has been designed for.

                                 3rd Party
                                  3rd Party
                                   3rd Party
                           Community Applications
                            Community Applications
                             Community Applications                           Communities

                       Operator Community
                        Other Apps
                      Applications (e.g. PTT)
                                          OSA / Parlay API vs. Web Services (Parlay X)

                   Framework                          ...         Call
                                      Presence                                 Messaging
                      UDDI                                       Control

                                  Make IPCall
                    P/I/S-CSCF      Send IM
                    (SIP Proxy)     Push2Talk     Make Call       Make Call            Make Call
                                   IMS Core      Send email                            Make IPCall
                                                                   Send SMS
                                                                     Send MMS
                                          UMTS                                    ISDN Send IM
                      WLAN                                       GSM                     Send email
                                                                                 (+ DSL)

       Figure 24: OSA/Parlay on top of IMS and CAMEL enabling flexible Service Implementations

Today in the Internet, policy based service provision is considered the major enabling technology for QoS
enabled multimedia service provision in all IP networks as shown in figure 25. Policies are a programming
means for programmable networks which provide the necessary abstraction form the underlying network
technologies. Note that this is similar to the early intelligent network or the recent open API approach in the
telecommunications world. As the future network will be an all IP networks so policies represent strong
starting point for the development of future value added services in all IP networks. i.e., it can be assumed
that policies can also be used to program value added services on top of SIP servers and other network
elements. However, still a lot of research has to be performed, as this young technology is still in infancy
but very promising.

         Value-added Service Environment          App.       Common Policy-based Service Creation Environment

                                                                                                           Standard APIs

                Service             Service                 Service                     Policy                   AAA
                Directory    Registration/Discovery         Mapping                   Repository

                                                      Policy Decision Point        Resource Discovery
             Open Communication Env.

                  PEP        PEP            PEP           PEP             PEP           PEP
           ..... Resource                                             Resource
                            CSCF        SIP-Proxy         QoS                       Content server .....
           Underlying Network Tech.     Underlying Network Tech. (e.g., Core IP)
           (e.g., UMTS)

               Figure 25: Policy-based network management for all IP network environments

It is important to recognise that the IMS and OSA/Parlay as well as associated initiatives, such as OMA
OSE and Microsoft’s CSF will be far from complete and a lot of R&D works needs to be performed in the
coming years. Corresponding open SDP infrastructures are required to support the prototyping and
validation of new SDP concepts and multi media applications. The FOKUS NGN Testbed featuring the
Open OSA/Parlay playground and the Open IMS playground are representing such test bed infrastructures.

We are very thankful to all members of NGNI Competence Centre of 3Gb Testbed at Fokus Fraunhofer
Berlin to their valuable suggestions to improve the draft of this text. We are especially thankful to Simon,
Karsten and Fabricio for providing information about Parlay, open issues and QoS in IMS.

AAA                         Authentication, Authorisation, and Accounting
AIN                         Advanced Intelligent Network
ANSI                        American National Standards Institute
APIs                        Application Programming Interfaces
AS                          Application Server
B2BUAs                      Back To Back User Agents
BGCF                        Border Gateway Control Function
CAMEL                       Customized Applications for Mobile Enhanced Logic
CAP                         CAMEL Application Protocol
CGI                         Common Gateway Interface
COPS                        Common Open Policy Service
CORBA                       Common Object Request Broker Architecture
CPL                         Call Programming Language
CSCFs                       Call State Control Functions
CSE                         CAMEL Support Environment
DSS1                        Digital Subscriber Signalling #1
EAI                         Enterprise Application Integration
FMC                         Fixed Mobile Convergence
GGSN                        GPRS Serving Node
GPRS                        General Packet Radio System
GSM                         Global System for Mobile
HLR                         Home Location Register

HSS      Home Subscriber Server
ICSCF    Interrogating Call State Control Function
IETF     Internet Engineering Task Force
IMS      IP Multimedia Subsystem
IN       Intelligent Network
INAP     IN Application Protocol
ISPs     Internet Service Providers
ISUP     ISDN User Part
IT       Information Technology
ITU-T    International Telecommunications Union
J2EE     Java 2 Enterprise Edition
JAIN     Java APIs for Integrated Networks
JCP      Java Community Process
MAP      Mobile Application Protocol
MCSF     Microsoft Connected Service Framework
MG       Media Gate
MRF      Media Resource Function
MRFC     Media Resource Function Controller
MRFP     Media Resource Function Processor
NGN      Next Generation Network
OMA      Open Mobile Alliance
OSA      Open Service Access
OSE      Open Service Environment
PCSCF    Proxy Call State Control Function
PDP      Packet Data Protocol
PDP      Policy Decision Point
PEP      Policy Enforcement Point
PoC      PPT over Cellular
POTS     Plain Old Telephony Service
PTT      Push To Talk
RADIUS   Remote Authentication Dial In User Service
RPC      Remote Procedure Call
RTP      Real-time Transport Protocol
SBLP     Service Based Local Policy
SCPs     Service Control Points
SCSCF    Serving Call State Control Function
SDP      Service Delivery Platform
SIBs     Service Building Blocks
SIP      Session Initiation Protocol
SLEE     Service Logic Execution Environment
SOAP     Simple Object Access Protocol
SPA      Service Provider Access
SPAN     Service Provider Access Networks
SS7      Signalling System Number 7
SSPs     Service Switching Points
TINA     Telecommunications Information Networking Architecture
UAs      User Agents
UMTS     Universal Mobile Telecommunication Standard
VHE      Virtual Home Environment
WAP      Wireless Application Protocol
WIN      Wireless Intelligent Networks
WLAN     Wireless Local Area Network
WSDL     Web Service Description Language
XML      eXtensible Markup Language
QoS      Quality of Service

[1] Magedanz, T., Popescu-Zeletin, R., "Intelligent Networks - Basic Technology, Standards and Evolution",
    International Thomson Computer Press, ISBN: 1-85032-293-7, London, UK, June 1996.
[2] I. Venieris, F. Zizza, T. Magedanz, „Object Oriented Software Technologies in Telecommunications – From
    Theory to Practice“, ISBN: 0471-6233792, Wiley Publishers UK, April 2000.
[3] T. Magedanz, R. Glitho: “Intelligent Networks in the New Millenium“, Feature Toopic, IEEE Communications
    Magazine, USA, Vol.38, No. 6, June 2000.
[4] T. Magedanz, M. Smirnov (Eds.), Special issue “Voice/ Data Integration – A Snapshot of Intelligent Networks
    and Internet Convergence“, Computer Communications Journal, Elsevier Publishers, Holland, Volume 35, Issue 5,
    April 2001.
[5] Ravi Jain: “Programming Converged Networks: Call Control in Java, XML, and Parlay/OSA”, John Wiley &
    Sons, Great Britain, 2004, ISBN: 0-471-26801-1.
[6] Miikka Poikselka “The IMS: IP Multimedia Concepts and Services in the Mobile Domain”, John Wiley &
    Sons, Great Britain, 2004, ISBN: 0-470-87113-X.
[7] K. Knüttel, T. Magedanz: “IP Multimedia Subsystem, a System Description for a comprehensive service and
    application oriented network architecture”, The 2nd IASTED International Conference on Communication and
    Computer Networks (CCN 2004), ISBN: 0-88986-429-2, page 67-72, ACTA Press, MIT, Cambridge, MA, USA,
    November 8-10, 2004.
[8] K. Knüttel, T.Magedanz, D. Witszek: “THE IMS PLAYGROUND @ FOKUS – AN OPEN TESTBED FOR
    Research Infrastructures for the DEvelopment of NeTworks and COMmunities (Tridentcom), Trento, Italien,
    Februar 23 - 25, 2005, Proceedings pp. 2 – 11, IBSN 0-7695-2219-x, IEEE Computer Society Press, Los
    Alamitos, California.
[9] N. Blum, T. Magedanz: “'Push-To-Video as a platform for NGN Services”, 11th European Wireless 2005 - "Next
    Generation Wireless and Mobile Communications and Services", Nicosia, Cyprus, April 10-13, 2005.
[10] J.M. Klaus, T. Magedanz: „Parlay PAM in 3GPP's IP-Multimedia Subsystem“, 14. GI/ITG Fachtagung
     Kommunikation in Verteilten Systemen (KIVS) 2005 , pp. 73-80, in GI Edition, Lecture Notes in Informatics,
     Kommunikation in Verteilten Systemen, P. Müller, R. Gotzheim, J.b. Schmitt (Hrsg.), ISSN 1617-5468, ISBN 3-
     88579-390-3, Köllen Druck+Verlag GmbH, Bonn 2005.
[11] T. Magedanz, “Self-Adaptive Service Provisioning Framework for 3G+/4G Mobile Applications”, in: IEEE
     Wireless Communications Magazine, Special Issue on Applications and Services for the B3G/4G era, Vol.11,
     No.5, October 2004, Pp. 48-57, ISSN 1536-1284.
[12] G. Cortese,, “CADENUS: Creation and Deployment of End-User Services in Premium IP Networks”, IEEE
     Communications Magazine, January 2003.
[13] S. Salsano et al., QoS Control by Means of COPS to Support SIP -based Applications, IEEE Network March/April
[14] Gonzalo Camarillo, G., Miguel A. Garcia-Martin, “The 3G IP Multimedia Subsystem, Merging The Internet and
     the Cellular Worlds”, John Willey & Sons Ltd. West Sussex, England, 2004.
[15] Ravi Jain, John-Luc Bakker, Farooq Anjum, “Programming Converged Networks”, John Willey & Sons, Canada,

Related Web Links

[1] FOKUS Open IMS play ground home page:
[2] 3rd Generation Partnership Project.
[3] FOKUS Open IMS play ground home page:
[4] 3rd Generation Partnership Project.


About the Authors
                            Thomas Magedanz (Ph.D.) is head of the “3Gbeyond” division at Fraunhofer
                            Institute FOKUS, Germany, which also provides the national Open 3Gb Test bed.
                            In addition, he is full professor at the Technical University of Berlin in the field of
                            next generation telecommunication infrastructures. He is an internationally
                            recognised expert in the areas of Intelligent Networks (IN) and Open Service
                            Platforms. He is a member of the IEEE, editorial board member of several
                            journals, and the author of more than 120 technical papers/articles. He is the author
                            of two books on IN standards and IN Evolution and is an regularly invited tutorial
                            speaker at major international telecom events and conferences as he is famous for
                            his comprehensive investigations and “easy to digest” style of presentations. More
                            information: .

                            Muhammad Sher is Ph.D. research fellow at Technical University Berlin and
                            Fokus Fraunhofer Institute Berlin, Germany with Prof. Dr. Thomas Magedanz. In
                            addition, he is assistant professor at Faculty of Applied Sciences, International
                            Islamic University, Islamabad, Pakistan in the field of computer networks and
                            network security. He is an author of more than 15 research papers and one book on
                            “Foundation for Computer Networks”. He received National NCR IT Excellence
                            Award in the field of research and development in 2000 and received Dr. Razi-ud-
                            Din Saddiqui Award from IIU on his book in 2004. He also supervised more than
                            40 projects at graduate levels.


To top