IMS - enabling services, wherever the customer and whatever the access

1. IMS - enabling services, wherever the customer and whatever the access Duncan Mills - Vodafone Stuart Walker – Leapstone Sponsored by

2. Agenda • From NGN to Fixed Mobile Convergence • 3GPP and TISPAN overview • The IMS Architecture • Service Layer • MSF and IMS • Q&A

3. Where has NGN come from? • In fixed line there has been a long term move towards a VoPacket replacement for PSTN • Driver has always been to reduce Opex in fixed line networks by optimising bandwidth usage, whilst replacing outdated TDM switching fabric. • Compressed speech into less than 64kbps channels • Further optimisation using VAD, Silence Suppression, AAL2 or IP multiplexing yields significant reduction in core network bandwidth requirements. • Drivers in 3GPP are more service related • IMS is borne out of a need for ‘feature rich’ service • Bandwidth requirements and their impact on capacity on the Radio interface are actually worse than now. • Now, IMS possibly provides the final piece in the business case for NGN that makes the decision to move justifiable… FIXED MOBILE CONVERGENCE

4. Different drivers = same end goal? • If fixed wants OpEx saving and fabric replacement, but mobile wants new services, how come the answer is the same architecture for both? • Both sides see the advantage to common, seamless services over any access. • IMS is defined in 3GPP so it has all the requirements for mobile operators built in. • SIP controlled voice is already available in fixed networks (particularly for enterprise customers) so it extends existing technology. • However, an IMS deployment supporting only voice does not make sense • Mobile has to go from no installed base to the full suite of available service to be justifiable. • IMS delivering single services (voice, PoC etc) is too expensive and too limiting in the service set it facilitates

5. Who gains from Fixed and Mobile convergence? • Manufacturers • Single development stream reduces R&D costs • Next gen. networks = next gen. device = new revenue streams – to deploy it, operators have to buy it! • Has to be priced to make initial CapEx recovery for the operator a short term deliverable. • Operators • Optimised ‘all IP’ network reduces OpEx • Opens the fixed market’s customers to mobile operators and vice versa. • Next Gen Services = new revenue streams – to use it, the customers have to buy it • Has to be the right service set, priced to make the services attractive to the customer

6. Who gains from Fixed and Mobile convergence? • End Users • Common service set available regardless of device they use, the location they are in or the access medium they are using. • New services available – location based, blended interfaces combining multiple inputs into a single presentation. • Single sign on – one identity that goes everywhere with you. BUT The food chain runs from the End User upwards. What services do they want? When will they buy them? At what price point?

7. 3GPP IMS - Architecture Si 3GPP Profile SIP HSS Cx Sh Other Control Plane AS Bearer SLF OSA-GW Dh Dx Legacy protocol IM-SSF ISC I-CSCF S-CSCF Mw Mm Mj BGCF Mk Mr Mw Mg MRFC Mi MGCF ISUP or BICC P-CSCF PDF Gq Mp Mn IM-MGW Gm Go Legacy Bearer Mb GGSN MRFP Mb Gm Multimedia Content UE

8. TISPAN – Top Level ArchitectureTaken from TISPAN WI02007 (Overall Functional Architecture)

9. TISPAN – IMS Core Taken from TISPAN WI02029 (Functional Architecture IMS)

10. TISPAN NGN mapped on to 3GPP IMS +TISPAN add ons CLF, UAAF, PDBF, UPSF Applications Si None of these functions are included in the 3GPP architecture HSS Cx Sh AS SPDF Other IP Networks SLF OSA-GW Dh Dx IM-SSF IWF ISC I-CSCF S-CSCF Mw I-BCF A-RACF, SPDF Mj BGCF Mr Mw Mg IMS Core MRFC RACS Mi PSTN/ISDN MGCF SGF P-CSCF PDF Gq RACS Mp Mn IM-MGW (T-MGF) Gm Go Mb GGSN MRFP Transport L2TF, RCEF, AMF I-BGF NASS UE

11. 3GPP IMS applicability to NGN • In R6, 3GPP IMS has been made ‘Access Independent’ • the technology used to transport SIP messages to the edge of the IMS network does not affect the functionality within the IMS network itself. • This allows IMS to be applied to any form of Access technology that is capable of transporting SIP control messages to the P-CSCF • WLAN, DSL, Cable Modem, FTTx, Satellite, Broadband Wireless all become irrelevant – all that matters is SIP presentation to the P-CSCF. • Only aspect of Access that is relevant is User Equipment capability and QoS. SIP Application Servers SIP Application Servers HSS IMS I-CSCF MRF P-CSCF MGCF S-CSCF MGW

12. SIP Application Servers SIP Application Servers DSL/Cable Modem HSS IMS I-CSCF MRF DSLAM/CMTS P-CSCF MGCF Corporate S-CSCF MGW Access Independence of IMS CDMA 2000 WLAN MSC(Server) RNC SGSN GGSN BSC CN UMTS/GPRS MGW

13. SIP Application Servers SIP Application Servers SIP Application Servers HSS I-CSCF MRF P-CSCF MGCF S-CSCF MGW MSC(Server) RNC SGSN GGSN BSC CN UMTS/GPRS MGW IMS as a common ‘middleware’ layer IMS Applications VoIP Interworking Elements IMS Core BGCF IP Bearer Network

14. P-CSCF I-CSCF S-CSCF SIP Application Servers OSA Application Server CSE(SCP) BGFC MRF OSA-SCS HSS IM-SSF MGCF sgw MGW IMS Nodes (1/2) • Database Elements • HSS(Home Subscriber Server) • SLF (Subscription Locator Function) • IMS Control Elements • CSCF (Call Session Control Function) • S-CSCF (Serving CSCF) • P-CSCF (Proxy CSCF) • I-CSCF (Interrogating CSCF) • Control Plane Interworking Elements • MGCF (Media Gateway Control Function) • BGCF (Breakout Gateway Control Function) • SGW (Signaling Gateway)

15. P-CSCF I-CSCF S-CSCF SIP Application Servers OSA Application Server CSE(SCP) BGFC MRF OSA-SCS HSS IM-SSF MGCF sgw MGW IMS Nodes (2/2) • IMS Service Elements • AS (Application Server) • External Service and Service • Interworking Elements • OSA Elements - SCS (OSA Service Capability Server, OSA Framework, OSA Application Server • CAMEL elements -IM-SSF (IP Multimedia Switching Service Function), CSE (CAMEL Service Environment) • Resource Elements • Media Resources Function (MRF) • Media Interworking Elements • MGW (Media Gateway)

16. Benefits of a SIP control plane • SIP is an end-to-end signalling protocol used to establish, modify and tear down IP sessions • The IMS nodes can remain in this SIP signalling path throughout a session, ensuring that the network is always aware of the service: • Allowing the network to control the QoS of the bearer • Allowing the network to invoke rich services on behalf of the user • Allowing for traditional and new charging models (e.g. duration-based, A-party pays, A-party pays for the voice, B-party pays for the video etc)

17. “So what ?”- says the subscriber Infrastructure with no clear application….. this wouldn’t be the first time

18. Service Co-ordination Service Brokerage Service Orchestration Service Control IN with the benefit of hindsight

19. SIP based service orchestration – Service Velocity and Service Agility Service Velocity – new applications and services to market quicker to address the short lived service market Niche Market Services Traditional Telco Services Service Agility – flexibly bundle applications into customer products to address niche subscriber markets Duration (active service lifetime) New market – economically realizable through faster and more flexible service layer Short Lived Services Penetration (number of subscribers using service)

20. IMS Service Orchestration Model S-CSCF - Subscriber service profile pulled from HSS at Registration time. Multiple profiles per subscriber (profile per alias) Profile is a list of priority ordered services point triggers SPT. SPT = boolean expression using SIP Method SIP Headers and Contents Session Case SDP contents Service Interactions handled through a SCIM function, depicted as part of the SIP AS although not really defined. Service profile updates pushed to S-CSCF from HSS.

21. MSF R2 Service Orchestration Model Call Agent Invokes Service Broker on originating and or terminating side of call. Call Agent can apply embedded service logic before and after invocation of Service Broker. Service Broker engaged set of priority ordered applications on seven ‘trigger’ conditions (oCallAttempt, oBusy, oNoAnswer, oHangup, tCallAttempt, tBusy, tNoAnswer) Conflict resolution / Interaction handling implied but not defined. Permit multiple applications per link in SIP chain for efficiency.

22. Shared Service Data HSS provides a shared network data repository allowing applications to share subscriber data. In multi-HSS deployments, Dh interface to SLF is used to locate correct HSS for subscriber. Sh interface (Diameter) - operations Sh-Pull (read data) Sh-Update (modify data) Sh-Subs-Notify (request notification of data change) Sh-Notify (notification of change) Defined Data Sets Repository Data – opaque data, network defined IMS Public Identity IMS User State S-CSCF Name Initial Filter Criteria Location Information User State Charging Information MSISDN

23. Parlay and ParlayX • Parlay X API’s • Common • Third Party Call • Call Notification • Short Message • Multimedia Messaging • Payment • Account Management • Terminal Status • Terminal Location • Call Handling • Audio Call • Multimedia Conference • Address List Management • Presence Parlay X Applications Parlay Applications • Parlay API’s • Framework • Call Control • Generic • Multi-party • Multi-Media • Conference • Content Based Charging • Terminal Capabilities • Presence and Availability • Policy Management • Data Session Control • Account Management • User Interaction • Mobility Management • Generic Messaging • Multimedia Messaging • Address List Management • Presence Parlay X APIs Parlay X Web Services Parlay API’s Parlay Gateway Network Protocols (e.g. SIP, INAP, etc) Network Elements

24. SIP AS Multiple mechanisms exist for creating SIP applications. SIP-CPL – Call Processing Language. An XML based scripting language for controlling call services. Designed to be implemented on either network servers or user agent servers via a lightweight CPL interpreter. Limited but safe, no variables, no loops, no ability to run external programs. SIP-CGI – Common Gateway Interface. Like HTTP CGI, the script resides in a network server and passes message parameters through environment variables and sends instructions back via the standard output. CGI scripts can be written in most programming languages. SIP Servlet – Servlets are similar to GCI but rather than a separate process messages are passed to class that runs in the JVM on the server. As they are Java based SIP servlets should be portable between server platforms. JAIN SIP – A low level API that maps directly to the SIP RFC. JAIN SIP Lite – A high level API; uses a greater degree of protocol abstraction and acts as a high level wrapper around the SIP protocol. Requires much less knowledge of the SIP protocol on the part of the developer than JAIN SIP.

25. Legacy Service Access via IMS-SSF IM-SSF function allows access to legacy IN services from the SIP service network. Acts as a proxy in the SIP domain and as an SSP in the IN domain. Effectively peers SIP to ISUP and applies the SSP functions. Only works in one direction, i.e. IN services on a SIP network. Realistically some legacy services may require SIP-I to be delivered to the IM-SSF in order to prevent information loss. IM-SSF products are commercially available.

26. Other Service Models No consensus to date on what architectural elements constitute an SDP Some vendors use the term SDP for their application servers or content delivery solutions, whereas other vendors and service providers tend to include a whole portfolio of products and components such as CRM systems or rating engines in their SDP offering. In general, an SDP should be seen as a commercial bundle of different products, possibly offered by different vendors. Some comment elements of SDPs are :- • Service Execution Platform (e.g. Application Server) - a core element of an SDP providing the deployment and execution environment for broad range of voice and data applications. • Network Abstraction Layer (e.g. Parlay GW ) - a core element of an SDP providing standardized interfaces to core network elements and services. • Service Exposure Layer (e.g. Parlay X GW) - an optional element exposing service capabilities (usually via Web Services) to 3rd party service providers and enterprises. • Content Delivery Platform - an optional element usually present in mobile SDPs for the provisioning of multimedia content to mobile devices. Web Services Service Delivery Platforms SDP Service Exposure Layer Service Execution Platform Content Delivery Platform Network Abstraction Layer Network Elements

27. OSE (OMA Service Environment) Main components Application – either in house or third party Policy Enforcer – applies policies (authorization, authentication, ..) to the interaction between the Application and the Enabler or between Enablers. Enabler – Intrinsic functions providing access to the underlying network resources. OMA only define interfaces not individual methods for the enabler. Execution Environment – provides Life Cycle, Load Balancing and other OA&M functions.

28. Service Orchestration – tricky stuff

29. Media Specific Applications - SDP Modification Insulate Applications from the full media awareness – present to them only the media parameters appropriate to their function. Treat as a single service chain, SDP ‘components’ updated as the chain progresses. Parallel invocation could reduce latency but needs potentially complex rules to re-combine multiple SIP INVITEs to the destination.

30. Partial Media Terminating Applications Applications may terminate the media session (directly or via a shared media server). In such cases there is no onward signalling from the application. However, the application may have only terminated a single media type; in such cases the Service Orchestration Function should ‘fork’ the INVITE and continue with session establishment and service invocation for the remaining media types.

31. MSF Release 2+ (IMSF) - Objectives Import IMS functions into the R2 architecture in order to :- • Support nomadicity (roaming) of terminals and users. • Support inter working between core IMS and MSF R2+ • Roaming of IMS subscriber to R2+ network • Roaming of R2+ subscriber to IMS network

32. MSF Release 2+ (IMSF) – Architectural Snapshot PA PXA AG = Access Gateway TG = Trunking Gateway SG = Signalling Gateway SCA = Static Call Agent DCA = Dynamic Call Agent RCA = Routing Call Agent MS = Media Server SBG = Session Border Gateway BM = Bandwidth Manager SB = Service Broker HSS = Home Subscriber Server AS = Application Server PGW = Parlay(x) Gateway SLG = Service Logic Gateway PA = Parlay Application PXA = Parlay X Application SDP OSE OSA SCS AS PGW SLG IM-SSF SCIM HSS MS SB BM RCA SBG-NC SCA DCA I-CSCF S-CSCF AG P-CSCF SG TG SBG-NE 1st Gen VoIP End Points IMS End Points

33. A typical example of a rich voice call • A has a subscription with fixed operator X • B has a subscription with mobile operator Y • B is roaming to mobile network Z • A calls B – voice call • A has originating services, B has terminating services • B adds in video • A has terminating services • A adds in white-boarding • A has originating services

34. A typical example of a rich voice call Network Y IMS Network X MSF R2+ AS AS DCA S-CSCF S-CSCF HSS HSS I-CSCF RCA I-CSCF P-CSCF SBG-NE P-CSCF GRX SGSN DSL/Cable Modem GGSN DSLAM/CMTS Network Z UMTS/GPRS RNC User A User B

35. Summary • IMS offers the ability to rapidly define and implement services that interact with each other seamlessly, regardless of the access technology and location of the end user. • Subscribers have their services available to them on multiple types of end user device and with common presentation and identification. • The access technology no longer governs the service presentation to the end user, and so a vast new range of services is conceivable.

36. Q & A Thanks to our sponsors