IEEE NJ Coast Section IP Multi-media core network

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

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

What is IMS? Original (late ’ 90 s/early ’ 00 s) definition per 3 GPP 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 Qo. S requirements • Common resources shared across multiple applications for service providers • Common “touch-and-feel” for subscribers IEEE NJ Coast Seminar November 3, 2004 3

IP Multimedia Subsystem (IMS) More Current View: q q q q Architecture designed for IP Multimedia Services Originally developed by 3 GPP (for UMTS) and later adopted by 3 GPP 2 (for cdma 2000); 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… IEEE NJ Coast Seminar November 3, 2004 4

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

3 GPP/3 GPP 2 IMS Inspired Architecture Web Portal Parlay App Server Application Layer Centralized Databases HSS SIP App Server eter m Dia OSA SCS Support Systems Billing Mediation, Fault Correlation, Operations, Maintenance, … SIP S-CSCF Session Control Layer SIP SIP MGCF I-CSCF P-CSCF COPS PDF SIP IP Signalling Converter SIP Media Server IN Access SG H. 248 MRFC Media and End Point Layer BGCF Media Gateway PSTN Wireline and Wireless SIP Endpoints GSM, UMTS, 802. 11, Bluetooth, DSL, FTTP, … Legacy IP Endpoints & PBXs H. 323 and MGCP IEEE NJ Coast Seminar TDM PBX SS 7 Analog Endpoint November 3, 2004 6

IMS Entity Definitions q 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 Qo. S 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 q Bearer Entities – MGW - Media Gateway • Inter-works RTP/IP and PCM bearers – MRFP - Multimedia Resource Function Processor • Provides conferencing, transcoding and announcements IEEE NJ Coast Seminar November 3, 2004 7

IMS Standards q 3 GPP and 3 GPP 2 - 3 rd Generation Partnership Project 2 – Have both defined the IP Multimedia Subsystem (IMS) – The harmonization effort has kept the definitions as similar as possible. q 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 q OMA - Open Mobile Alliance – Defining services for IMS architecture, e. g. Instant Messaging, Push-to-Talk q 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) q ETSI - European Telecommunications Standards Institute TISPAN - TISPAN is merger of TIPHON (Vo. IP) and SPAN (fixed networks) – Agreement on reuse of 3 GPP/3 GPP 2 IMS in comprehensive NGN plans – q ANSI - American National Standards Institute – Provides protocol definitions used by IMS – T 1. 679 covers interworking between ANSI ISUP and SIP q ATIS - Alliance for Telecommunications Industry Solutions – Addressing end-to-end solutions over wireline and wireless – Nearing agreement to use 3 GPP/3 GPP 2 IMS IEEE NJ Coast Seminar November 3, 2004 8

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

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

Mobile to Mobile detailed call flow (2) Ø Both users are already attached to the network and registered. 1. 2. UE-1 sends a SIP INVITE message to its Proxy CSCF(P-CSCF). 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 UE 2’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 PCSCF for UE-2 based on UE-2’s registration). 11. The P-CSCF forwards the SIP INVITE to UE-2. IEEE NJ Coast Seminar November 3, 2004 11

Mobile to Mobile detailed call flow (3) Step 12 -17 A 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 -23 A incomplete SDP “offer” was made in the initial INVITE from UE-1, then the PRACK can be used to make another SDP “offer”. esponds Step 24 -29 UE-2 may include an SDP “answer” from the SDP “offer” from the previous SIP PRACK message. Step 30 -35 UE-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 -41 UE-1 replies with a SIP PRACK to the previous SIP 180 RINGING. Step 42 -47 UE-2 sends a SIP 200 OK in response to the SIP PRACK. Step 48 -53 UE-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 -59 The 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 60 A Bearer Session is established between UE-1 and UE-2. The RTP session established here carries the negotiated media. . Step 61 -66 A 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 -72 UE-2 responds with a SIP 200 OK to UE-1 and the session is terminated. IEEE NJ Coast Seminar November 3, 2004 12

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

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

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

Market Dynamics Leading to Convergence q q Carriers are pursuing opportunities to improve near-term financial performance and create differentiated service offerings Users are expecting services that are: – – q 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 q Evolution to Vo. IP offers the opportunity to provide new services, such as Presence-enabled services, multimedia services, collaboration services, etc IEEE NJ Coast Seminar November 3, 2004 16

Conclusion: Converged Architecture & IMS q q q q 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 IEEE NJ Coast Seminar November 3, 2004 17