3rd party service provisioning in SIP-based
UMTS network
Jatta Rantala
Supervisor: Prof. Jorma Jormakka
Instructor: Kai Väänänen, M.Sc.
2004-06-01
1
Contents
• Background and Research Problem
• Research Methods
• What is IMS?
• Session Initiation Protocol
• IMS Service Architecture
• Service Provisioning in IMS Service Provisioning Architecture
• IMS Service Capabilities and OMA Service Enablers
• Challenges in 3rd Party Service Provisioning
• 3rd Party Service Provisioning Technologies
• Vendor Views
• Results
• Conclusions and topics for future studies
2004-06-01
2
Background and Research Problem
• IMS that defines architecture for the usage of Session Initiation Protocol enables
real-time and non-real-time IP Multimedia services for the wireless environment
and is evidently being deployed in mobile operators’ networks in the near future.
• Until recently predominantly network operators alone have developed the services
to mobile subscribers – lacking often innovative, new ideas - utilizing network
capabilities traditionally only available to them. -> service development too slow
and costly process that also requires specialized knowledge of the underlying
network protocols.
• The investment in IMS will be justified more probably, if the interfaces to IMS
Capabilities and Service Enablers are opened to third parties with open,
standardized and secure environments and APIs
-> Which third party service provisioning technology with associated API is
most applicable for IMS environment considering:
– The capabilities of the functionalities offered by the third party service
provisioning technology in answering to the challenges set by the SIP-based
IMS environment in addition to the network agnostic challenges
2004-06-01
3
Research Methods
• Literature study:
– Specifications of 3GPP and OMA
– Researches and studies of different academic sources
– Discussions with experts of the study topic
• Semi-structured Vendor Interviews:
– Conducted for two big Telecommunication equipment vendors
2004-06-01
4
What is IMS?
• IP Multimedia Subsystem is a SIP-based IP Multimedia infrastructure that provides a complete
architecture and framework for providing real-time and non-real-time IP multimedia services
on top of Packet Switched (PS) core while still preserving the legacy Circuit Switched (CS)
telephony services.
• IMS provides the necessary IMS Capabilities: service control, security functions (e.g.
authentication, authorization), charging, routing, registration, SIP compression and QoS
support.
• First time introduced in 3GPP Release 5 as “IMS Phase 1”, while in 3GPP Release 6 - “IMS
Phase 2” – IMS is further enhanced with e.g. Presence, Messaging and Group Management.
• IMS is also expected to bring the strengths of wireless and fixed-line worlds together. In 3GPP’s
words: “The IMS should enable the convergence of, and access to, voice, video,
messaging, data and web-based technologies for the wireless user, and combine the
growth of the Internet with the growth in mobile communications.”
2004-06-01
5
Session Initiation Protocol (SIP)
• 3GPP has chosen SIP for signalling between UE and the IMS as well as between the
components of IMS in order to facilitate maximum interoperability with existing (fixed and
mobile) Internet systems, devices, and protocols
• SIP is application-layer control protocol based on request-response paradigm for creating,
modifying and terminating multimedia sessions with one or more participants.
• Defined in IETF RFC 3261 with numerous extension RFCs for e.g. Presence, and Instant
Messaging
• Works over UDP and TCP
• Basically there are four types of logical entities in a SIP network, namely User Agents (UAs),
proxy servers, redirect servers and registrars. As IMS is an application of SIP Architecture
CSCFs and HSS implement these functions.
Method name
First line
Headers
Empty
line
Message
payload
2004-06-01
Request URI
INVITE sip:bob@brown.com SIP/2.0
Via: SIP/2.0/UDP 130.23.16.19:32746
;branch=z9hG4bKCabU9qqUgvZD
From: <sip:alice@wonder.net>;tag=uce5728c0
To: <sip:bob@brown.com>
Call-ID: f24793c0-c9a3-11d5-c48d-14064620c566
CSeq: 4 INVITE
Contact: <sip:alice@130.23.16.19:32746>
Content-Type: application/sdp
Content-Length: 143
v=0
o=alice 1756606023 1 IN IP4 130.23.16.19
s=c=IN IP4 130.23.16.19
m=audio 5004 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
6
IMS Service Architecture
• IMS Service Architecture combines three service platforms: SIP, OSA and CAMEL
• S-CSCF is in a central role acting as a contact point to the Application Servers, controlling the
sessions and detecting if and how to involve a service logic to provide value-added services
• SIP AS hosts and executes native SIP services that are programmable through a variety of
technologies including SIP servlets, Call Processing Language (CPL) script, SIP Common
Gateway Interface (CGI) and Java APIs for Integrated Networks (JAIN).
• OSA SCS provides a standardized, extensible, scalable and secure interface to enable third
parties to access SCFs implemented by means of SIP for developing value added services.
• IM-SSF is a interworking module between SIP and CAMEL supporting legacy IN-type services.
• HSS is a centralized data-base containing subscription-related information such as user
identification, numbering, addressing, security, location management and user profile
information to support network entities handling sessions.
2004-06-01
7
Service Provisioning in IMS Service Provisioning
Architecture
• Service provisioning in IMS is based on service control residing on
home network (I.e. all the messages are routed through home
operator S-CSCF)
• S-CSCF directs SIP messages to the right AS according the
triggers downloaded from the HSS
Application Server
Service Logic
Service Platform Trigger Points
HSS
SIP Interface
iFC
sFC
SIP
S-CSCF
SIP
2004-06-01
S
P
T
Filter Criteria
SIP
8
IMS Service Capabilities and OMA Service
Enablers
• IMS offers IMS Service Capabilities that can be used as building blocks for Service Enablers
and services
–
Session management, user data access, event subscription and notification, messaging, data
manipulation, conferencing
• OMA and 3GPP define SIP-based Service Enablers that are nor necessarily end-to-end
services, but but capabilities that value added services are built on.
–
IMS Messaging, Presence, Push-to-Talk over Cellular (PoC), IMS Group Management, IMS
Conferencing, IMS Charging
OMA Service Enabler
Charging
Conferencing
Data Manipulation
Messaging
User Data Access
Ut,
ISC,Gm ISC, Gm Ut ISC,Gm Ro, Rf
Event Subscription
and Notification
Sh
Session Management
IMS
reference points
ISC, Gm
Common
Capabilities
e.g. security
IP Multime dia Subsystem
Service
Legend:
Capabilities
ISC, Gm = S IP
Sh, Ro, Rf = Diameter
Ut = to be defined in 3GPP, not yet included in 3 GPP2
2004-06-01
Supporting
capabilities
9
Challenges in Third Party Service Provisioning
Network agnostic challenges
IMS-specific challenges
Security
Ability to expose the full functionality of SIP-enabled
networks on the API.
Hiding the network topology and exposing the service
enablers so that they can be discovered in automat
able and repeatable manner.
Existence of applicable interfaces to SIP-specific
functionalities and services (i.e. IMS Service
Capabilities and Service Enablers).
Firewall Traversal
Adding both manually and dynamically service triggers
to the IMS system under operator supervision for third
party service provider
Performance
Level of abstraction offered by the API that should be
open and standardized.
Third party not having to establish new relationships
with many operators for the usage of Service Enablers
that it might want to utilize.
Maturity of the technology.
2004-06-01
10
3rd Party Service Provisioning Technologies
• Parlay/OSA:
–
A set of APIs that enable operators and third parties to make use of network functionality securely
through open, and standardized interfaces defined by Joint API Group
–
Aim to progress from today’s single-service networks to multi-service networks, where the same service
can be offered independent of the underlying connectivity and access networks.
–
Offers set of Service Enablers that in Parlay/OSA are called Service Capability Features for Applications’
use
 Call Control, User Interaction, Mobility, Terminal Capabilities, Data Session Control, Generic
Messaging, Connectivity Manager, Account Management, Charging, Policy Management ,
Presence and Availability Management
–
The Parlay/OSA API relies on middleware technologies for the remote invocation of Parlay/OSA API
method. There exist three technology realizations for this middleware transport technology in Parlay/OSA
specifications. These are IDL for CORBA middleware, WSDL for SOAP over HTTP transport and JAIN
Service Provider Access (SPA) for e.g. JAVA Remote Method Invocation (RMI).
Application
server
Application
OSA API
discovery
Open
Service
Access
Interface
class
framework User Location Call control
HSS
OSA internal API
2004-06-01
CSE
Service capability server(s )
S-CSCF
Servers
E.g. Location server
MExE server
SAT server
11
3rd Party Service Provisioning Technologies
• Web Services
- Provides a standard means of interoperating between different software
applications, running on a variety of platforms and/or frameworks even over
the Internet. It also focuses in the external business-to-business integration
- Initiatives in Parlay Web Services WG, Parlay X Work Group and OMA
- Relies on Web Services technologies used in already in IT industry (XML,
SOAP, WSDL and UDDI)
XML
Script
Parlay X Applications
“Connect(A, B)”
Parlay/OSA Applications
XML
Java
VB
Script
Increasing
abstraction
createCall()
routeRes(A)
routeReq(A)
routeRes(B)
routeReq(B)
…
…
XML Transport:
Complex XML sequences
over SOAP, CORBA,
HTTP, …
Java
VB
“OK”
XML Transport:
Simple XML sequences
over SOAP, CORBA,
HTTP, …
Parlay X APIs
Parlay X
Web Services
Parlay/OSA APIs
XML
Parlay/OSA Gateway
CORBA,
Java, XML
Network Protocols
(e.g. SIP, INAP etc.)
Network Elements
2004-06-01
12
3rd Party Service Provisioning Technologies
• SIP
–
In addition to Parlay/OSA, IMS environment offers SIP Application Server for provisioning of IP
Multimedia services. IETF has proposed a view SIP Service APIs and scripts allowing the creation of
SIP-based services
–
In the 3GPP specifications it is assumed that the SIP Application Server resides inside the operator
domain (ISC-interface is intra-operator interface), which means that in the case of third party service
provisioning the service would have to be developed by trusted third parties and hosted by the operator
–
In case desiring the business model of Parlay/OSA for third party hosting its application external to the
operator domain, an additional entity implementing the necessary Authentication, Authorization, and
Accounting (AAA) mechanisms and service level agreements would have to be presented.
–
One solution could be adding a SIP AS Gateway in the middle acting the role of Presence Server. The
Service Enablers would register themselves to the SIP AS and 3 rd parties could find those by subscribing
the presence of all the presentities registered in the SIP AS gateway.
Scope of OMA
(OSE)
Application Layer
(e.g. PoC, Chat, BuddyList)
SIP-AS
OSA-AS
proprietary
OSA
Enabling Services Layer
SIP-AS
OSA-GW
ISC
IMS Session Control layer
(X-CSCF, HSS, ...)
2004-06-01
Scope of 3GPP/3GPP2
(IMS service Provisioning)
S-CSCF
13
Relation to be clarified
Vendor views: Vendor A
Main Street
WSI
in Enterprises
Tornado
WSI in Mobile
Liberty
SIP
JAIN
Chasm
Early Market
2004-06-01
OMA
OSA/Parlay?
Bowling Alley
14
Vendor views: Vendor A
•in general Parlay/OSA with CORBA and SIP would be applicable for internal service providers
offering call related services, while Parlay X could be offered for trusted third parties offering the
same kind of services with limited functionality. Web Services Gateway then would be most
applicable to value adding data applications and Internet-based data applications provided by
both trusted and “untrusted” third parties.
2004-06-01
15
Vendor views: Vendor B
• Vendor B sees that SIP offers limited functionalities to enable
business model to open Telecom network to “untrusted” entities.
Therefore vendor B assumes that SIP AS is within operator
controlled environment. Otherwise, the IMS environment would
need to be completed by additional firewalls or trust management
enforcement systems in addition to Business-to-Business
framework, which are not specified in standards.
• The technology that shall be provided depends on the type of
application, time of deployment, expected characteristics, used
operator business model and finally used capabilities and
services.
2004-06-01
16
Some Results
• Parlay/OSA
– The mapping of OSA to SIP has not been properly described -> Mapping only for Call Control exists at
the moment.
– If the mappings will drive changes to the APIs, the target of Parlay/OSA of being network agnostic will
break down. Then the same API could not be used for different networks, i.e. fixed, mobile or IMS.
Therefore the Parlay/OSA being network agnostic is its strength and weakness.
–
Additional SCFs should be introduced to cover the service opportunities offered by IMS (e.g. Group
Management, PoC)
– CORBA-middleware creates problems when crossing enterprise and service provider firewalls ->
OSA/Parlay used in most cases within the operator domain rather than as network opening mechanism
• Web Services
– Is directed to wider Web development community
– Performance, security pitfalls
–
–
• SIP
–
Standardization of Web Services has been slow in the Telecommunications industry
Parlay-X doesn’t provide AAA, SLA and other specific capabilities -> if Parlay-X is to be provided to 3rd
parties outside operator domain, these functions should be provided by other means
–
With SIP Service APIs and scripts one can generate all the parts of the SIP message -> complete
mapping exists
Application Developer has to be expert on SIP protocol
–
–
The solution suggested is not standardized
It is claimed that service creation for new data services with SIP is faster than with OSA/Parlay
2004-06-01
17
Conclusions and topics for future studies
• Parlay/OSA, Web Services and 3GPP IMS/SIP are not directly comparable, since they are
focusing on different levels in the value chain of service providers. Therefore these technologies
cannot be seen to replace each other, but rather complement each other.
• There is a challenge to find the right balance between the “bottom-up” (capabilities first) and
“top-down” approaches (use cases first) and choosing the best API-type and programming
paradigms (i.e. CORBA, Java, SIP, WEB-tools) for each type of enabler.
• Future study should concentrate on finding the mapping of Presence to SIP and to find out
whether PoC can be made available through Parlay/OSA Call Control
• Also the SIP-based third party service provisioning solution should be studied from the
perspective of security
2004-06-01
18
The Nordic and Baltic
telecommunications leader
Questions?
Thank you for your attention!
2004-06-01
19