Soa In Telecommunications

T. Magedanz (TU Berlin / Fraunhofer FOKUS) - 2007

Tutorial about SOA Concepts in Telecommunications

Evolution of Telco Service Platforms in Face
of Network Convergence and SOA Principles
- A Déjà Vu?

Prof. Dr. T. Magedanz

Technical University Berlin / Fraunhofer FOKUS

thomas.magedanz@fokus.fraunhofer.de

www.fokus.fraunhofer.de/ngni
1


German Abstract
• Im Rahmen dieses Vortrages soll die Evolution von
Telekommunikationsdienstplattformen in den letzten 30 Jahren beleuchtet werden.
Dabei soll insbesondere die Dienstorientierung in der Telekommunikationswelt genauer
betrachtet werden.
• Ausgehend von dem Konzept der Intelligenten Netze aus den achtziger Jahren, werden
objekt-orientierte Application Programming Interface (API) Plattformen, wie
beispielsweise die JAIN, Parlay und Open Service Architecture APIs betrachtet, die in
den neunziger Jahren an Bedeutung gewonnen haben. Die Ende der Neunziger Jahre
einsetzende Etablierung von Web Service Technologien im Telekommunikationsumfeld,
insbesondere die Parlay X APIs werden ebenfalls reflektiert.
• Im Zentrum des Vortrags steht jedoch eine Einführung des IP Multimediasystems (IMS),
das derzeit von vielen Standardisierungsgremien als Dienstplattform für beliebige
Multimedia Kommunikations und Informationsdienste über konvergierende Netze
angesehen wird. Dieses maßgeblich auf IP Protokollen basierende System erlaubt dabei
die synergetische Einbindung der vorgenannten Dienstplattformen. Im Vortrag wird
nach der Vorstellung der IMS Architektur und Prinzipien insbesondere die Realisierung
von IMS Diensten auf der Basis von SOA Prinzipien und sogenannten IMS Enablern
betrachtet.
• Ein abschließender Ausblick auf das mögliche Zusammenspiel von IMS und Web 2.0
Diensten soll zukünftige Forschungsaspekte aufzeigen.
• Hinweis: Die Vortragsfolien sind in Englisch, der Vortrag wird jedoch in Deutsch
abgehalten.
• Mehr Informationen finden Interessierte unter: www.fokus.fraunhofer.de/ngni

2

Page 1


Agenda

• Network Convergence leading to common Service Delivery Platforms
• Intelligent Networks – The first SDP in Telecommunications
• Open Application Programming Interfaces – Parlay, OSA, JAIN
• Web Services in Telecommunications - Parlay X
• Internet meets Telecommunications – IP Multimedia System (IMS)
• State of the Art in Telco SOAs: IMS + SDPs + Web Service Tools
• Using IMS in the context of Web 2.0 and Community Services
• Summary

3


Evolution towards Converged Networks
Fixed PSTN
Networks
ISDN IT
DSL

Mobile
SMS WiFi WiMax
Networks WAP
Analogue GSM
GPRS
UMA Converged
UMTS HSDPA FMC
Web2.0 Triple
NGN
WWW Portals
FTP email IPTV Play (all-IP)
P2P IM VoIP
Internet

iTV

VoD Content
Sharing

Broadcast
Cable Home
Networks Networks

4

Page 2


Overall NGN Architecture (ITU-T)

Converged
NGN
(all-IP)

5


From Separate Networks To Converged Networks
Today Future
Single-service networks Multi-service network

Services
S

Service Network
Content Content
S S
S
Data/IP Networks

Cellular Mobile
PSTN/ISDN

API
Cellular Mobile

CATV
PLMN

Connectivity/
MGW Backbone Network MGW

MGW MGW
Access Networks

Access, Transport & Switching Networks 6

Page 3


Communications Landscape Is Changing

The IT Community
Rich in Applications
and Creativity
Technical
Convergence
The Telecom Community
Rich in Networks
and Connectivity

OSA, Parlay and JAIN are examples of emerging Technology
Standards that facilitate the convergence
of the IT and Telecom communities
7


Operator as Retailer of Services

What Operators have:
– Networks rich in Functionality
– A large customer base
– Efficient billing and customer management
– The ability to mass-market services
What Operators need:
– To expand their value chain into new markets
– New services that expand their business offerings
What Third Party Developers have:
– Ideas and creativity
– Huge numbers
– Vast knowledge of specialised IT and IP products and markets
What Third Party Developers need:
– Help in marketing their services
– A business infrastructure to create a cash flow

8

Page 4

Service Delivery Platforms = Horizontal Layering
SDP
Service Creation
App1
App1 App2
App1 App3
App1 Exposure Portals
Gaming Google
VASP
CRM

OSA
Enablers
MRF Service Execution
Service Execution Environment Exposure
Parlay /X www Internet
LBS OMA
(incl. Content
Content
Delivery) Environment Layer blogs
Billing

Delivery Skype 3rd Party ASP
Abstraction Layer DB
OTA MRF icq
Abstraction Layer HLR
HSS
Presence MMSC SMSC
USSD Gw
MediaGW
IVR
Scope of this Talk
Control Layer
Provisioning

Control Layer
(MSC-Server, CSCF, AAA,..)
Operation & Maintenance

Connectivity Layer
IP-Backbone
IP-

Public network Private network
Mobile Access Fix Access Mobile Access Fix Access

GSM CDMA
GSM CDMA
Access Network Layer PSTN
PSTN
Cable
Cable WiFi
WiFi LAN
LAN
Supervision

UMTS
UMTS
IMS Satellite
IMS Satellite
GPRS
GPRS WiFi xDSL DECT PBX
EDGE WiFi xDSL DECT PBX
EDGE

9


Service Evolution towards SOA

Service Scope Telecommunication Services Internet Services
Enabling IT
Telco 2.0
Policies Service Brokering
Community Services
Service Ochestration Web 2.0
BPEL
Content Services User generated Content
IMS
Multimedia Services P2P / Content Sharing
XML / SOAP Parlay X
Telecom Webservices IM / Skype / Presence
Java RMI
3rd Party Services OSA / Parlay / JAIN Conferencing
CORBA Application Programming Interfaces VoIP / SIP / AAA
IP Streaming
Intelligent Network HTTP / Browsing
Value added Services
RPC Service Independent Building Blocks

Messaging / SMS
Basic Communications Telephony / Fax Email / FTP
Network Specific Services
10

Page 5


Evolution of Service Delivery Platforms
SOA
Web 2.0 Web/Application
3rd Party
Server Application
Multimedia Application Services
Services Server (Enterprises / Content)
SIP App.
Server
Parlay X
OSA / Parlay
NGN / IMS
SIP
OSA/Parlay/JAIN Gateway Interface

IN / CAMEL
AAA
Services
Server SIP
IN Platform
Server INAP/CAP
Diameter Interface
Stored
Program
Control
Services
= Services VoIP GSM PSTN
GPRS/UMTS

11


Agenda

• Summary

12

Page 6


IN Definition
• The term Intelligent Network (IN) was coined by Bellcore (now
Telcordia) in 1986
• The Intelligent Network
– represents a telecommunications network service control architecture
– provides an open platform supporting the uniform:
• creation,
• introduction,
• control,
• management of services
– beyond basic telephone services in the telecommunications environment
• IN is not only a platform IN is a framework!

13


IN as a Universal API / Service Platform
IN platform provides service and network independence
– Service decomposition
– Separation of switching and service control network elements
• IN can be considered as an additional (network) layer on top of any
bearer network, e.g. PSTN, ISDN, B-ISDN
Service A Service B

Service
Independence
SIB SIB SIB
IN Platform
IN Architecture
Network (SSP, SCP)
Independence

Networks
Mobile PSTN Internet
(Resources)
14

Page 7


Towards the First Intelligent Network
Unified IN service logic and data for all switching nodes provided by:
– Intelligent Node contains service logic and data accessible for switching
nodes (Note: Intelligent node is a non-switching node!)
– Hooks are required within the switching nodes to access the remote
Intelligent Node
– SS7 network enables real-time signaling interconnection of nodes

Service Central Service
Program
Data Control Point (SCP)
Logic

Signalling Network

Basic API API API Enhanced Switches
Call
(SSPs)
Model

15


The First IN Architecture
• Service Management System /
Operations System (SMS)

SCE SMS SCP
SS7
• Service Switching Points (SSPs)
network
• Service Control Point (SCP) STP
STP
• Intelligent Peripheral (IP)
IP
SSP SSP
• Signaling System No. 7 network
– Signaling Transfer Points (STPs) PSTN

• Note: IN represents a “logical” separate
network on top of "bearer networks"!

16

Page 8


INCM as a Roadmap for IN Architecture Definition

• Definition of IN service capabilities:
– Start with the definition of the services and identify the services' basic
capabilities (Service Features) in a network independent way
– Decompose these service capabilities into smaller functional blocks
(SIBs) in order to achieve some degree of service independence
• Definition of the IN architecture able to support distributed realization of the
identified benchmark service capabilities:
– Define network entities in terms of functional elements and their
interactions
– Allocate these elements to specific physical entities with corresponding
interfaces/protocols

Note: Services are regarded as requirements for the IN architecture definition!

17


INCM Planes
• INCM defines four planes, Service
Service Feature 1 Service Feature 1
addressing Plane
Service Feature n Service Feature n
– service design aspects,
– global and distributed Global Service SIB 1
service provisioning Logic BCP SIB 2
SIB 3
functionality, Global Functional Plane
– and physical aspects Information Functional Entities
of an Intelligent Network Flow SCF SDF
Distributed
BCSM
SSF
CCF SRF SSF Functional Plane

INAP SCP Physical Plane
SS7
Physical
Network SN
SSP IP Entities

Bearer Network

18

Page 9


3GPP CAMEL
• CAMEL = Customized Applications for Mobile Enhanced Logic
• CAMEL
– Is the use of IN in mobile circuit switched and packet switched networks:
GSM/GPRS
– IN-based architecture enabling to offer operator specific services (OSS) to
mobile subscribers even when roaming in another network (international
roaming)
• CAMEL enables inter-network GSM/GPRS service control, by reusing
the existing international signaling transport infrastructure
– CAMEL Application Protocol (CAP) is based on IN Capability Sets 1 and 2
– CAMEL additionally exploits Mobile Application Part (MAP)
• CAMEL Standardisation started in 1994 (as a GSM Phase 2+ Feature)
• CAMEL evolves in Phases, which are part of Releases!!!

19


CAMEL Phases
• Camel Phase 1
– Basic Call Control functionalities for GSM calls
• Camel Phase 2
– ApplyCharging in VPLMN : GSM calls are monitored directly in VPLMN
– Announcement : access to annoucements directly from the VPLMN
• Camel Phase 3
– Handling of GPRS Sessions and pdp-contexts for session control, monitoring
(location update, QoS,…) and charging (time and volume triggers)
– Support of SMS-MO through CS and PS networks
– Anytime interrogation and modification of customer data in HLR
– Mobility management enhancements
• Camel Phase 4
– Multi-leg GSM call handling
– Creation of a new GSM call
– PLUS: Interworking with IP Multimedia Subsystem
20

Page 10


Related IN References
• T. Magedanz: ”IN and TMN providing the basis for future information networking architectures”,
in: Computer and Communications, pp. 267-276, Butterworth-Heineman, Vol.16, No. 5, May
1993
• T. Magedanz, R. Popescu-Zeletin: "Intelligent Networks - Basic Technology, Standards and
Evolution" , International Thomson Computer Press, ISBN: 1-85032-293-7, London, June 1996
• T. Magedanz, R. Popescu-Zeletin: "Open Service Platforms for the Information Society", in:
Intelligent Environments, P. Droege (Ed.), pp. 335-344, ISBN: 04444-82332-8, Elsevier
Science Publishers, Amsterdam, Holland, February 1997
• "TINA - Architectural Basis for Future Telecommunications Services", in: Computer
Communications, Volume 20, pp. 233-245, 1997
• I. Venieris, F. Zizza, T. Magedanz (Eds.): „Object Oriented Software Technologies in
Telecommunications – From Theory to Practice“, ISBN: 0471-6233792, Wiley Publishers UK,
April 2000
• T. Magedanz, M. Sher: “IT-based Open Service Delivery Platforms for Mobile Networks – From
CAMEL to the IP Multimedia System”, in Mobile Middleware, section VI, P. Bellavista, A
Corradi (Eds), Chapman & Hall/CRC Press, pp. 999-1036, ISBN: 0849338336, January 2006

21


Agenda

• Summary

22

Page 11


OSA/Parlay/JAIN: One Set of Open APIs

Parlay/OSA (Open Service Access) define an API that enables operator
and 3rd party applications to make use of network functionality
through a set of open, standardised service interfaces

Applications (independent of underlying
App 1 App 2 App N
network technology)

Parlay/OSA API
3GPP
ETSI
Gateway Parlay
JAIN SPA

ISDN GSM/GPRS Internet /
UMTS
Mapping to network specific protocols
23


Parlay’s Impact on Standardisation
OSA (Open Service Access)
UMTS Release 99, Release 4 & 5
3GPP TS 29.198 plus TS 29.998
Plus acceptance in 3GPP2 architecture
for Ref. Point 8 in 2002

ETSI SPAN 12 OSA Project
APIs for 3rd-Party Service
Phase 2.0 (12/1999) Application Interface
Phase 2.1 (06/2000) ES 202 915
Phase 3 (10/2001) JAVA-based APIs for integrated networks (JAIN)
Phase 3.1 (06/2002) JAIN Parlay = JAIN Service Provider ACCESS (SPA)
Phase 4 (12/2002)
JAIN
Plus some influences on existing concepts:
• IN/TINA Interworking WG IN/TINA Adaptation Unit RFP
• OMG Telecoms Service Access and Subscription (TSAS) RFP
24

Page 12


OSA / Parlay’s Technical Approach

The Parlay/OSA API
• Framework Interface Set - Common
Functions That Are Required to Enable
Services to Work Together in a Coherent Application
Fashion e.g. Server
– Authentication, Discovery, Manageability
• Transport interface
– CORBA, WSDL (Web Services) Framework Service
• Service Interface Set(s) - Common Functions interface interface
That Deliver Whole Complex Services or Sub-
components of Services e.g
– Call Control, User Interaction, Content- Parlay/OSA Gateway
based Charging, Location, Presence and Resource Resource
Availability, Messaging, Policy interface interface
Management, Quality of Service …
• Resource Interfaces - Interfaces used
between a Parlay Gateway and network
elements
– not specified in Parlay (but hints in OSA)
25


Parlay / OSA – EAI Approach
Application
Application
k2

Application
n

Applications
catio
ewor

face

Interface

Service2

2 Parlay/OSA API 3
Appli
Fram

Inter

Framework2Service SCF X SCF z
Location
Framework Interface e.g. Call Control
1 SCF y
Mapping

SCF a
Interface

0
Gateway Messaging

0 SCF Implementation
1 Service registration Proprietary
2 Service Discovery & SLA Service HLR

3 Service Usage Interface X Network
MSC SMSC Resources
26

Page 13


Focal Points of API Standardisation (Parlay 5)

User Generic
Framework Call Control Messaging

Not part of OSA
Interaction

Data session Terminal Connectivity
Mobility
control Capabilities Management

Presence &
Content Account Policy
Availability
based charging Management Management
Management

MM
Messaging
27


Parlay – OSA – ETSI – JAIN Relationhip
Parlay Version 3.1 spec. 3GPP OSA ETSI OSA API JAIN SPA API spec.
API Release 4 Version 1 spec.
spec.
Overview TS 29.1980-1 ES 201 915-1 JSR-136 v.1.0 (JTSP)
Common Types TS 29.1980-2 ES 201 915-2 JSR-145 v.1.0 (Common)
Framework TS 29.1980-3 ES 201 915-3 JSR-024 v.1.0 (TSM, SD, SAM)
JSR-119 v.1.0 (IM)

Call Control TS 29.1980-4 ES 201 915-4 JSR-021 v.1.1 (JCC)
User Interaction TS 29.1980-5 ES 201 915-5 JSR-103 v.1.0 (UI)
Mobility TS 29.1980-6 ES 201 915-6 JSR-098 v.1.0 (ULS)
Terminal Capabilities TS 29.1980-7 ES 201 915-7
Data Session Control TS 29.1980-8 ES 201 915-8
Messaging N/A ES 201 915-9
Connectivity Management N/A ES 201 915-10
Account Management TS 29.1980-11 ES 201 915-11
Charging TS 29.1980-12 ES 201 915-12
Policy Management TS 29.1980-13 ES 201 915-13
PAM TS 29.1980-14 ES 201 915-14 JSR-123 v.1.0 (PAM) 28

Page 14


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

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

TCAP ISUP INAP SIP MAP MGCP
Vendor
Independence
IP Wireless
Wireless PSTN Satellite
Satellite
IP Broadband
Broadband PSTN
29


Agenda

• Summary

30

Page 15


Parlay-X Technical Motivation
• The Parlay/OSA APIs are a dramatic improvement over classic IN and telecom service
development
– “Brings time to deploy new service to 3-4 months” OSA Forum 2003
• The Parlay/OSA were defined in UML, and mapped to Corba IDL and Java
– Didn’t address web developers

Expressive Power Number of Developers

JavaScript, Visual Basic Scriptable millions

Parlay, sockets APIs 0.5
• (C++, Java)
INAP, ISUP, SIP, MAP Protocols 3 – 10,000

31


Motivation for Parlay X Web Services
Note: Network Operator acting as Web Service Provider

Sort in Public
Directory
Network order UDDI
Resource
Send Registry
Latest
SMS
Scores
Network Whose Zip
Resource on-line ? New
New Codes
Application
Application
Airline flight
Make
check
payment
Network
Resource Initiate Call
Current
Conference
local Account
Network
Weather Statement Resource 32

Page 16


The Parlay/OSA APIs

Name Description Usage Release

Parlay/OSA Rich set of telecom Suitable for use by Parlay/OSA V 4.1
APIs, for use in professional and 3GGP R5
CORBA (C, C++) software Parlay/OSA V4.1
and Java developers.
environments. (Forthcoming)
Suitable for
Several hundred developing a pre-
methods. paid application.
Parlay-X Web Set of high-level, Suitable for use by Parlay-X Version 1
Services simple to use web developers. (May 2003)
telecom APIs, for Designed for use Parlay-X Version 2
use in a Web with IDE.
Services (Dezember 2004)
Suitable for
environment. 8 developing a ‘call-
interfaces. me’ button on a
web page.

33


Parlay in Web Services
Gateway / Element
1. Publish UDDI Servier
Published Web Services
Parlay Registry
Web Services

3. Bind

WSDL Bindings 2. Find

Client Web Application
- embedded web service calls

The Web Services deployment environment supports the server and client
participating in a common discovery system, and using a common binding to
communicate.
34

Page 17


3GPP Parlay X Web Services
TS 29.199 specifications
• Parlay X Web services have
been adopted by 3GPP CN TSG Part 1: Common
(September 2004) for inclusion Part 2: Third party call
in OSA Release 6 Part 3: Network-initiated third party call
– The documents are numbered TS Part 4: Short Message Service (SMS)
29.199-xx-600
Part 5: Multimedia Message Service (MMS)
– 3GPP TS 29.199 is structured in 14
Parts Part 6: Payment
Part 7: Account management
Part 8: User status
Part 9: Terminal location
Part 10: Call handling
Part 11: Audio call
Part 12: Multimedia Conference
Part 13: Address List Management
Part 14: Presence
35


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

Page 18


Related OSA/Parlay References
• “Getting started with OSA/Parlay – What, Why, How”, invited Tutorial for Parlay Education
Track at Parlay Meeting, San Diego, USA, May 19, 2003
• “The OSA/Parlay Playground @ FOKUS”, invited keynote speech at Parlay Meeting, San
Diego, USA, May 19, 2003, www.parlay.org/news/events/pastevents.asp#may2003
• T. Magedanz: "Validating Open API-based M-Commerce Applications - The Open FOKUS
OSA/Parlay Playground", marcus evans OSA/Parlay and Convergent Service Delivery
Platform Deployments conference, London, December 1-3, 2003, www.metelecoms.com
• T. Magedanz, A. Hafezi, R. Wechselberger: “Practical Experiences in Deploying OSA/Parlay
on Top of UMTS and 3G beyond Networks – The IST Project OPIUM and the FhG FOKUS
3Gb center”, pp. 65-70, Proceedings of the 8th International Conference on Intelligence in next
generation Networks (ICIN 2003), Bordeaux – France, 31 March - 3 April 2003
• T. Magedanz et.al.: “A unified IN-Internet Service Environment based on Parlay“ pp. 264-268,
Proceedings of the 8th International Conference on Intelligence in next generation Networks
(ICIN 2003), Bordeaux – France, April 2003, www.adera.fr/icin2003
• Invited half day tutorial “Parlay Education Track – Getting Started with Parlay”, 12th Parlay
Member Meeting, Miami, Florida, USA, May 10th, 2004
• “Web Services for Programming Converged Networks – Experiences from the Usage of the
FOKUS Parlay-X Gateway Within the National German 3G Beyond Testbed”, Marcus Evans
Conference on Web Services Opportunities in the Telecom Industry, London, UK, 21 - 23 June
2004
• “Understanding the 3GPP OSA / Parlay APIs - Classic API, Parlay Web Services & Parlay X”,
half day Tutorial, International Conference on Intelligence in Networks (ICIN) - Enabling service
delivery networks for the multimedia age, Palais des Congrès Bordeaux, France, October 18-
21, 2004
37


Agenda

• Summary

38

Page 19


Voice and VAS Evolution - The SIP Influence
In face of emerging all-IP networks the IETF Session Initiation Protocol (SIP)
is considered today a key enabler for real-time converged communications
and the development of interactive services.

SIP session and SIP-enabled services basic SIP functionality SIP-enabled services

SIP-Services SIP-Services User Presence/Availability
Establishment of user presence Unified Messaging
Conferencing

and availability (buddy-list
Messaging

functionality of IM) Chat
Gaming

Voice
Video

Multimedia
…

User Location&Mobility Conferencing
Establishment of current IP
address. Support of personal and Push-to-talk
terminal mobility
Online Games
Multimedia Support Distributed Virtual
Supports voice, e-mail, IM, video Realtiy Systems
and any other form of application
SIP Session with session characteristics Push Services
Invite Invite
SIP SIP Interactive
Device OK IP network OK Device Call Setup & Processing Entertainment
Establishment and management of
ACK ACK communication parameters (e.g. IP-PBX, IVR
codec, timeframe, …)
39


Seamless Services – The Network doesn’t Matter
• Network diversity and network innovation pace has lead to network
abstraction based on IP as common denominator
• Connectivity Services versus Multimedia Services
• Users are interested in services – thus End Systems and Service
Platforms matter
Seamless
Applications
GSM
GSM and Services
UMTS
UMTS EDGE
EDGE
CDMA
CDMA
WLAN
WLAN
WiMax
WiMax IP – Network
POTS/
POTS/ Extended with QoS,
ISDN
ISDN Security and Charging
Wireline
Wireline
xDSL
xDSL
other
other
40

Page 20


IMS Architecture Principles
• IMS does NOT standardise specific services, but enablers
• BUT supports inherently multimedia over IP, VoIP, IM, presence (SIP)
• IMS enables the flexibility in providing IP-based applications !!

Architecture • Horizontal Architecture defining a
“docking station” for applications
MMApps
Applications
• Defines service enabler capabilities
Presence
Presence GLMS
GLMS • Builds on existing IETF and telco
IMS SDP standards
and
IMS
Service Enablers
HSS
• Provides better security, Service
based QoS, flexible charging and
single sign on compared to the
RANIP (!)SGSN GGSN
Networks Gateway “standard” open internet
Legacy non-IMS
Networks 41


IMS Core Infrastructure Functionality
• Implementing generic functionality in the infrastructure is most
economical !!
Multiparty / Multimedia Session
Architecture handling based on SIP Control
Multimedia Content Pull & Push
Applications
PoC Messaging Support
Conferencing and Group Com. Support
Presence GLMS
GLMS
Presence Fixed Mobile Convergence / 3P
IMS Single-Sign-On User-Authentication
and
IMS
Enabling Services
HSS High Secure Service Access and
Provision
SGSN GGSN Service based Bearer QoS
RAN IP Network
Network
Flexible Charging
Gateway
Legacy Network Interworking Support
Legacy non-IMS
Networks Docking Station for Service Enablers
Docking Station for Applications
42

Page 21


IMS Motivation – Flexible Service Provision
Provision of service enablers and dynamic service portfolio extension
- Presence and Group server are considered key for the future
- Application Servers can be control and/or content servers
Messaging Server Presence Server
Any new Application
Content Server Call / Session Server
Servers

IP Multimedia
Signalling (SIP)
System (IMS)

Transport (RTP)
Packet Network (Core)

Access Networks Access Networks
(WLAN, UMTS, DSL) (WLAN, UMTS, DSL)

43


IMS - enabled Services
• IMS is an overlay network based on IP connectivity (allways on
paradigm)
• Usage of SIP allows to support many two party, multi party,
multimedia services in between users and application servers
– VoIP, video calls, conferencing, instant and deferred multimedia
messaging, pull & push streaming services, presence services, push to
talk, click to dial, etc.
• Convergence services:
– Fixed Mobile Convergence (same services for fixed and mobile networks)
– Triple Play (= VoIP, Internet, TV)
– Quadruple Play (= Triple Play plus Mobility)
• IPTV, Video on Demand, interactive TV
• Combinational Services
– Combinations of IP services, e.g. VoIP & Messaging,
– Integration of packet data with circuit switched services
44

Page 22


IMS integrates different Communication Services

Pre-IMS Communication IMS Communication
(“Service Islands”) (“Combinational Services”)

Voice

Groups
Voice / Video
SMS
TV SMS

Presence
Instant Instant
Messaging Messaging
MMS
MMS PoC

From the usage of specific
individual communication services ... ... to the integrated usage of different
communication services centered
around presence information and
within groups ( communities)
45


NGN Global Standards Cooperation
es &
line
vic Wire erged
Alliance for Telecommunications Industry Solutions
Alliance for Telecommunications Industry Solutions

er Open Mobile Alliance
Agreement on reuse of 3GPP/3GPP2 IMS in comprehensive NGN plans

onv
TISPAN –ETSI body on Next Generation Network

S Defining IMS services, e.g. Instant Messaging, Push-to-Talk C
Not strictly mobile oriented, driving wireline services also NGN res
ctu
The Parlay Group / Java Community Process Arc hite
Integral to IMS architecture, define standard API frameworks

cy
ga
Le
Nearing agreement to use 3GPP/3GPP2 IMS

American National Standards Institute
ITU-T NGN Focus Group
ITU-

CJK China Japan Korea
Starting Focus Group on NGN

T1.679 covers interworking between ANSI ISUP and SIP
Leveraging IMS in wireline

International Telecommunication Union
re Q.1912.SIP covers interworking between ITU-T ISUP and SIP

ctu en
H.248 for media control
ites Driv
h es
c
ArWirel 3rd Generation Partnership Project
3rd Generation Partnership Project2
Define IMS network elements and infrastructure
for mobile environments

Cablelabs / PacketCable NGN
over s
IPTV itecture
Define IMS network elements and
infrastructure for IPTV and Triple Play
s Arch
ol
To Internet Engineering Task Force
Defines SIP, SDP and other protocols underlying IMS
IMS is driving some of the work in IETF

46

Page 23


Complexity of 3GPP / 3GPP2 IMS Architecture

IMS Service IMS enabler
HSS Application
Framework Presence
(AAA) Server IMS enabler
Group Mgt

Media
P-CSCF I-CSCF S-CSCF
S-CSCF
Server
MFRC + MFRP
PDF

Media
IMS Core
Gateway
System SGW, MGCF, MGF

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

Note: IMS Charging Architecture is not reflected on this slides = Diameter Interfaces to many entities 47


Major Service Platform Interfaces
Note: Cloning of IN principles!
Service Delivery Platform (Application Server)

Value Added Services
HSS
Service Platform Trigger Points
Service Platform Adaptor
Sh =
SIP B2BUA Interface
Diameter
Cx =
Diameter ISC = Ext. Session Initiation Protocol

S-CSCF
SIP Proxy Server
S
SIP Filter criteria 2 SPT Mapping SIP
P
T

48

Page 24


How does a IMS Provide Enhanced Services

• S-CSCF determines that a call requires enhanced service processing
– Filtering may be based on calling / called party or other mechanism
(defined by filtering criteria) eg. SIP message type, header fields, etc.
• Based on filtering criteria, the S-CSCF determines the address of the
Application server and relays the call to the AS function. The
Application Server receives the call and invokes the appropriate
service logic taking one of the following actions:
– Redirects the call to a new destination
– Send the call back through the S-CSCF in order to monitor subsequent call
events (ie act as a SIP Proxy)
• The Application Server (based on some other input) can also set-up
calls between other entities in the network (ie. act as a B2BUA)

49


IMS Initial Filter Criteria
• The IFC is the key point for service provisioning in IMS and specified in 3GPP TS 23.218 and 29.228
• The S-CSCF downloads the IFC‘s for a particular user from HSS and has the ability to forward SIP
messages to an appropriate Application Server (SIP AS, OSA SCS)
• AS application/service invocation is triggered as a result of a pattern matching on any SIP header
or body
E.g. Online
E.g. Call
AS Application AS Application
Charging - AS Application Forwarding
Record
1 Application 2
routing Application
!! 3 Application - No Record
routing

2 INVITE 3 INVITE 4 INVITE
5 INVITE
iFc 3 met
iFc 1 met
Filter Criteria 2 SPT Processing
1 INVITE Prio 1 = AS1, Prio 2 = AS2, Prio 3 = AS 3, etc.
6 INVITE

S-CSCF IM User Profile(s)
200 OK

Cx - User Profile download/update
HSS IM User Profiles
storage
50

Page 25


Scalability of the IMS
Add dynamically more CSCFs and AS if needed

Sh
HSS
SIP AS 1 SIP AS 2 … SIP AS n

ISC

User
User
Profile
User
Profile S-CSCF 1 S-CSCF 2 … S-CSCF n
Profile
Cx

User Profile contain registered Service (ASs) per User
Upon user registration S-CSCFs will be populated with this information
51


IMS Application Server Options
Application Server

Diameter Application OSA
SIP
Servers CAMEL
AS

SIP AS OSA SIP/INAP
HSS (Servlets) GTW GTW
(AAA)
SIP
IMS Core Server

Local AS

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

SIP Server
RTP

52

Page 26


Different AS Alternatives
• CAMEL Services via Camel Support Environment (CSE):
– intended for the support of existing IN Services (provides service continuation).
• 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 co-located on the CSCF
– seems to be useful for simple services. May be beneficial for the Service
Availability and the Service Performance.

53


CAMEL Reuse within IMS
IN IN App 1 CAMEL Support Env.
SIP 2 CAP mapping needed! SCP CAP (Application Server)

S CAP Interface
IM SSF

HSS h ServicePlatform Trigger Points
IM SSF (SIP2CAP)
Sh =
Diameter SIP Interface Diameter
Cx = Ro + Rf =
Diameter ISC Diameter
S-CSCF Online &Offline
SIP-Server
Charging (ECF, CCF)
S
SIP Filter criteria
P
T
54

Page 27


OSA / Parlay AS within IMS
Service Delivery Platform Parlay X AppApp
Parlay App 1 Parlay X
(Application Server) Parlay App 2
Parlay X GW
Parlay AS (API)

HSS Sh FW MPCC MMM PRES CHARG

Parlay GTW
Sh =
Cx = Ro + Rf =
SIP-Server
Charging (ECF, CCF)
S
SIP Filter criteria
P
T
55


JAIN over IMS

JAIN SBB
S JAIN SBB
JAIN SLEE
Sh =
Cx = Ro + Rf =
SIP-Server
Charging (ECF, CCF)
S
SIP Filter criteria
P
T
56

Page 28


SIP Application Server (Servlets)

SIP Service Servlets
S SIP Service Servlets
SIP Servlet Engine
Sh =
Cx = Ro + Rf =
SIP-Server
Charging (ECF, CCF)
S
SIP Filter criteria
P
T
57


IMS Enablers = Reusable IMS Application Servers

• IMS did not address the standardisation of specific application by purpose
• Only major AS interfaces are defined = IMS is a „docking station“ for ASs!
• Open Mobile Alliance (OMA) is supposed to do service specific
standardistaion on top of IMS
• Examples include Presence, Group Management, Instant Messaging (IM),
Push to Talk over Cellular (PoC), etc.
• Over time it become clear that there is a set of common servers, i.e. enabling
servers IMS Enablers, which can be used in the implementation of more
complex IMS services
• Major enablers today to be used in IM, PoC and Group Video Calls, etc.:
– XML Document Management System (XDMS) enabler for group configuration
– Presence Server (PS) enabler for maintaining presence information
– Device Management (DM) enabler is used for client system configuration,as ASs
and enablers may need specific software on the client system!

58

Page 29

Open Mobile Alliance (OMA)

• In June 2002, the mobile industry set up a new, global organization called
the Open Mobile Alliance (OMA)
– www.openmobilealliance.org
• The Open Mobile Architecture initiative supporters and the WAP Forum
formed the foundation for the Open Mobile Alliance
• The following organizations have integrated into OMA:
– Location Interoperability Forum (LIF)
– SyncML Initiative
– MMS-IOP (Multimedia Messaging Interoperability Process)
– Wireless Village
– Mobile Gaming Interoperability (MGIF)
– Mobile Wireless Internet Forum (MWIF)
• Other industry forums focusing on interoperability and open standards are
welcome to join
59


OMA Service Enablers and IMS
• IMS provides to the common SIP based session control
infrastructure Standards
– Interface to the access network
– Signalling, routing and reachability
– Authentication and Security OMA
– Charging, accounting for
– Docking Station for application Servers and enablers Application
Enablers
• OMA SIP-based service enablers are specified on top of
IMS as common platform, e.g.
– Presence, XML Document Management, Push to Talk
over Cellular, Instant Messaging, etc.
– For details see 3GPP
www.openmobilealliance.org/release_program/index.html
– The IMS in OMA Enabler Release version 1.0 contains for
general requirements and guidelines and does not Network
specify detailed requirements that should be tested or
that by themselves can be implemented in products. Architecture

60

Page 30


OMA Service Enablers
• OMA Service Enabler release list
– http://www.openmobilealliance.org/release_program/index.html
• Approved Enablers (in second phase, Nov 2006)
– IMS in OMA version 1.0
– OMA Push-to-Talk over Cellular (PTT) version 1.0
– OMA Web Service (OWSER) version 1.1
• OMA Web Service Network Identity version 1.0
– OMA Multimedia Messaging Service version 1.2
– OMA Instant Message and Presence Service version 1.2.1
– OMA DNS version 1.0
– OMA Device Management version 1.2
– OMA Useragent Profile version 2.0
– OMA XML Document Management version 1.0
– …
61


OMA Service Environment (OSE)
• The Open Mobile Alliance has defined plenty of service enablers
• But how to provide and combine these enablers?
• Based on OSA/Parlay ideas OMA decided in 2005 to start its work on the OSE
http://www.openmobilealliance.org/release_program/ose_ad_archive.html
• OSE is based on policy based service interface provision and separates:
– Applications
• either resident on an in-house platform or a third party application
– Policy enforcer
• applies policies to the interaction between the application and the Enablers and
between Enablers wherever applicable and in some cases the Policy may be
null.
– Enabler
• contains intrinsic functions which can interact with other functions, within the
domain of the architecture and underlying network resources.
– Execution environment
• deals with aspects such as Life Cycle management, load balancing, OA&M etc.

62

Page 31

Soa In Telecommunications

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Destacado

Destacado (8)

Similar a Soa In Telecommunications

Similar a Soa In Telecommunications (20)

Último

Último (20)

Soa In Telecommunications