3rd party service provisioning in SIP-based UMTS network

1
3rd party service provisioning in SIP-based
UMTS network

• Jatta Rantala
• Supervisor Prof. Jorma Jormakka
• Instructor Kai Väänänen, M.Sc.

2
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

3
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. -gt 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
• -gt 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

4
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

5
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
  3GPPs 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.

6
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.

7
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.

8
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

9
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

10
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.
11
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 todays 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).

12
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)
  

13
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 3rd parties could find those by
  subscribing the presence of all the presentities
  registered in the SIP AS gateway.

14
Vendor views Vendor A
15
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.

16
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.

17
Some Results

• Parlay/OSA
• The mapping of OSA to SIP has not been properly
  described -gt 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 -gt
  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
• Standardization of Web Services has been slow in
  the Telecommunications industry
• Parlay-X doesnt provide AAA, SLA and other
  specific capabilities -gt if Parlay-X is to be
  provided to 3rd parties outside operator domain,
  these functions should be provided by other means
• SIP
• With SIP Service APIs and scripts one can
  generate all the parts of the SIP message -gt
  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

18
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

19
Questions? Thank you for your attention!