1. IEEE NJ Coast Section IP Multi-media core network Subsystem (IMS): Enabler of Next Generation Services Amit Mukhopadhyay amitm@lucent.com & Carlos Urrutia-Valdés urrutia@lucent.com

2. November 3, 2004 2 IEEE NJ Coast Seminar Contents  Introduction to IMS  IMS Components  Service Example  Standards Developments  Convergence  Conclusion

3. November 3, 2004 3 IEEE NJ Coast Seminar What is IMS? Original (late ’90s/early ’00s) definition per 3GPP TS 23.228: The IP Multimedia CN subsystem comprises all CN elements for provision of multimedia services. This includes the collection of signaling and bearer related network elements… Ability to mix multiple media during a session is a key characteristics of IMS: Simultaneous voice, data and video applications Different media with different QoS requirements Common resources shared across multiple applications for service providers Common “touch-and-feel” for subscribers

4. November 3, 2004 4 IEEE NJ Coast Seminar IP Multimedia Subsystem (IMS) More Current View:  Architecture designed for IP Multimedia Services  Originally developed by 3GPP (for UMTS) and later adopted by 3GPP2 (for cdma2000); now being investigated by ITU,..  Support of other access technologies (e.g., DSL, Cable, Wi-Fi) a vision  Capable of Interworking with PSTN  Defined with Open Standard Interfaces  Based on IETF Protocols (SIP, RTP, …)  A Solution for Service Transparency  Interaction with Legacy IN Based Services under consideration In this presentation, the focus is on service delivery…

5. November 3, 2004 5 IEEE NJ Coast Seminar CSCF, BGCF MGCF & MRFC  Applications Layer  End-user telephony service logic  AIN call trigger points  Non-telephony based services  APIs for enterprise & legacy applications  Session Control Layer  End Point Registration  Session setup  QoS establishment  Transport & Endpoint Layer  Bearer Services, Media Conversion (PCM > IP)  Special functions: announcements, touch tones collection, voice recognition, speech synthesi IMS Building Blocks Media Gateway Media Server HSS OSA-GW Telephony AS Non-telephony AS

6. November 3, 2004 6 IEEE NJ Coast Seminar Wireline and Wireless SIP Endpoints GSM, UMTS, 802.11, Bluetooth, DSL, FTTP, … SIP TDM PBX Legacy IP Endpoints & PBXs H.323 and MGCP MGCF Web Portal INAccess Parlay App Server SIP App Server OSA SCS I-CSCF SG P-CSCF PDF Analog Endpoint PSTN SS7 IP Signalling Converter MediaGateway Media and End Point Layer Session Control Layer Application Layer MediaServer MRFC S-CSCF CentralizedDatabases HSS Support Systems Billing Mediation, Fault Correlation, Operations, Maintenance, … BGCF 3GPP/3GPP2 IMS Inspired Architecture SIP COPS Diameter H.248

7. November 3, 2004 7 IEEE NJ Coast Seminar IMS Entity Definitions  Signaling Entities –HSS - Home Subscriber Server or “HSS Collective” Consists of AAA and Databases –CSCF - Call Session Control Function – 3 flavors S-CSCF – Serving: Session control entity for endpoint devices I-CSCF – Interrogating: Entry point to IMS from other networks P-CSCF – Proxy: Entry point to IMS for devices –BGCF - Breakout Gateway Control Function Selects network to use for PSTN/PLMN interworking –MGCF - Media Gateway Control Function Controls MGW –MRFC - Multimedia Resource Function Controller Controls MRFP –PDF - Policy Decision Function Authorizes QoS requests –AS - Application Servers – provides services and applications Session Initiation Protocol (SIP) AS Open Service Access (OSA) Service Capability Server (SCS) & OSA AS AIN Interworking Server  Bearer Entities –MGW - Media Gateway Inter-works RTP/IP and PCM bearers –MRFP - Multimedia Resource Function Processor Provides conferencing, transcoding and announcements

8. November 3, 2004 8 IEEE NJ Coast Seminar IMS Standards  3GPP and 3GPP2  3GPP and 3GPP2 -3rd Generation Partnership Project 3rd Generation Partnership Project 2 –Have both defined the IP Multimedia Subsystem (IMS) –The harmonization effort has kept the definitions as similar as possible.  IETF  IETF - Internet Engineering Task Force –Provide the definitions for SIP, SDP and other protocols underlying IMS –IMS is driving some of the work in IETF  OMA  OMA - Open Mobile Alliance –Defining services for IMS architecture, e.g. Instant Messaging, Push-to-Talk  ITU  ITU - International Telecommunication Union –Provides protocol definitions used by IMS –H.248 for media control –Q.1912.SIP for SIP – ISUP interworking (in conjunction with IETF)  ETSI  ETSI - European Telecommunications Standards Institute –TISPAN –TISPAN - TISPAN is merger of TIPHON (VoIP) and SPAN (fixed networks) –Agreement on reuse of 3GPP/3GPP2 IMS in comprehensive NGN plans  ANSI  ANSI - American National Standards Institute –Provides protocol definitions used by IMS –T1.679 covers interworking between ANSI ISUP and SIP  ATIS  ATIS - Alliance for Telecommunications Industry Solutions –Addressing end-to-end solutions over wireline and wireless –Nearing agreement to use 3GPP/3GPP2 IMS

9. November 3, 2004 9 IEEE NJ Coast Seminar Control Bearer Called Party Visited Network Called Party Home Network Calling Party Home Network Calling Party Visited Network UE P-CSCF HSS S-CSCF SIP Diameter UE P-CSCF AS HSS S-CSCF SIP AS SIP Diameter I-CSCF Diameter DNS Backbone Packet Network RAN Backbone Packet Network RAN Initiate SIP Invitation 1 1 Retrieve Subscriber Profile (if needed) 2 2 3 3 Apply Service Logic Retrieve Address of CLD Party Home Network and Forward INVITE. 4 4 Identify Registrar of CLD Party and Forward INVITE. 5 5 Retrieve Subscriber Profile (if needed) 6 6 7 7 Apply Service Logic Forward INVITE to CLD Party 8 8 Ringing / Alerting 10 IMS Subscriber to IMS Subscriber high level call flow SDP Negotiation / Resource Reservation Control 9 9 RTP Stream Answer / Connect 11

10. November 3, 2004 10 IEEE NJ Coast Seminar Mobile-to-Mobile detailed call flow(1) Not ncessary if home network is the same for both UEs. Evaluates initial filter criteria Authorizes QoS

11. November 3, 2004 11 IEEE NJ Coast Seminar Mobile to Mobile detailed call flow (2)  Both users are already attached to the network and registered. 1.UE-1 sends a SIP INVITE message to its Proxy CSCF(P-CSCF). 2.A SIP 100 Trying message is generated back to the UE. (This SIP 100 Trying message will not be shown throughout these call flows, but it is assumed that a SIP 100 Trying will be generated in reply to all SIP INVITE messages to avoid retransmission of the SIP INVITE.) 3.The P-CSCF determines the S-CSCF for UE-1. 4.The S-CSCF evaluates the Filter Criteria for UE-1 and then queries the DNS server to request the location information about the called party UE-2. (A DNS query is not necessary if UE2’s home network is the same as UE-1’s home network. In this case the S-CSCF after evaluating the filter criteria forwards the INVITE to a local I-CSCF and the procedure skips to step 6.) 5.The address of the I-CSCF for the UE-2 is returned from the DNS Server. 6.The SIP INVITE is passed to the I-CSCF for UE-2. 7.A request is made to the HSS to determine the location/profile/status of UE-2. 8.A reply is given from the HSS to the I-CSCF to identify the S-CSCF for UE-2. 9.The SIP INVITE is forwarded on to the S-CSCF for UE-2 which evaluates the service profile of the user and the initial filter criteria. 10.The S-CSCF forwards the SIP INVITE to the P-CSCF for UE-2. (The S-CSCF knows the P- CSCF for UE-2 based on UE-2’s registration). 11.The P-CSCF forwards the SIP INVITE to UE-2.

12. November 3, 2004 12 IEEE NJ Coast Seminar Mobile to Mobile detailed call flow (3) Step 12-17A SIP 183 Session Progress message is sent back from UE-2 to UE-1. This SIP message may contain the SDP “answer” from the SIP INVITE SDP “offer”. Step 18-23A SIP PRACK (PRovisional ACKnowledgement) is sent from UE-1 to UE-2. If an incomplete SDP “offer” was made in the initial INVITE from UE-1, then the PRACK can be used to make another SDP “offer”. Step 24-29UE-2 responds with a SIP 200 OK to the previous SIP PRACK message. The message may include an SDP “answer” from the SDP “offer” from the previous SIP PRACK message. Step 30-35UE-2 may respond to the original SIP INVITE with a SIP 180 RINGING indicating that the called UE is ringing. This message traverses the same path back as the SIP INVITE took for delivery. Step 36-41UE-1 replies with a SIP PRACK to the previous SIP 180 RINGING. Step 42-47UE-2 sends a SIP 200 OK in response to the SIP PRACK. Step 48-53UE-2 also responds with a SIP 200 OK to the original SIP INVITE. This message traverses the same path back as the SIP INVITE and should contain the SDP “answer”. Step 54-59The SIP ACK message is sent from UE-1 to UE-2. This Acknowledgement will contain the agreed upon resources for the session in the SDP. Step 60A Bearer Session is established between UE-1 and UE-2. The RTP session established here carries the negotiated media.. Step 61-66A SIP BYE message is sent by either party, UE-1 or UE-2. In this case UE-1 sends the SIP BYE to UE-2 to terminate the call. Step 67-72UE-2 responds with a SIP 200 OK to UE-1 and the session is terminated.

13. November 3, 2004 13 IEEE NJ Coast Seminar CORPORATE DIRECTORY INSTANT MESSAGING PERSONAL DIRECTORY VOICE MAIL EMAIL SOFT PHONE ? ? ? ? Each service has a different interface look & feel No integration across services Information can not be shared across services Consistent look and feel across services Services gracefully transition (IM to Voice to video call) Flexible addressing (E.164, URI, IP) Correspondences sorted by contact, not method (email vs call log) Data consolidation/distribution Today Future Convergence: End-user view One Simple Interface to Many Services and Access Vehicles Xyz Com

14. November 3, 2004 14 IEEE NJ Coast Seminar Convergence: Service Provider View Common core surrounded by a variety of access networks IP Network (e.g., over DSL) Circuit Switched Network IP Network (e.g., Enterprise) 802.11/802.16 Access Circuit Mobile Network Packet Mobile Network IP Network (e.g., over Cable) Softswitch Media Gateway Application Servers OSA-GW HSS IAD IMS

15. November 3, 2004 15 IEEE NJ Coast Seminar Convergence – Many Aspects DriversIncrease RevenueReduce Cost Dimensions End-UserNetwork Service Interaction (e.g. Voice+ IMM) Shared network resources (e.g. one core network) Service Bundling (e.g. Lifestyle Services) Network-agnostic platforms Seamless Roaming (e.g. WiFi-Mobile, Mobile-Wireline) Common Experience (same look & feel) Enablers Common session control (e.g. IMS) Common transport network (e.g. Core, MGW) Common service platforms (e.g., App. Servers, MRFP) Centralized Operations (e.g. common NOC, Std interfaces, Billing) Unified end-user terminals & APIsCommon database platforms (e.g. HSS, AAA)

16. November 3, 2004 16 IEEE NJ Coast Seminar Market Dynamics Leading to Convergence  Carriers are pursuing opportunities to improve near-term financial performance and create differentiated service offerings  Users are expecting services that are: –Independent of access –Have the same look and feel –With rich media content –Can be delivered to different types of devices  Integration of wireline & wireless experience can result in –Lower customer churn –Lower operational & capital costs –Higher revenue per subscriber  Evolution to VoIP offers the opportunity to provide new services, such as Presence-enabled services, multimedia services, collaboration services, etc

17. November 3, 2004 17 IEEE NJ Coast Seminar Conclusion: Converged Architecture & IMS  Separation of access & transport layers from service layer  Session management across multiple real-time communication services  Interworking with legacy TDM networks  Blending of real-time and non-real-time communication services  Consistency in sharing user profiles across services  Consistent authentication & billing mechanism  Consistent user interface  Open standards & APIs for new services