Session 4

2. Session 4 Transitioning to IMS Via Your SIP-Based Network

3. Agenda • Overview of a typical pre-IMS Architecture • Review of the IP MultiMedia Subsystem framework • The IMS Architecture • Transitioning to an IMS Architecture • Key Factors in a Transition Project

4. Introduction • The IMS architecture is receiving increased interest in the industry • The challenge is that the full IMS architecture, while providing exceptional flexibility, is very complex • By understanding at a high level the IMS components and their functions, the service provider is able to plan a migration path to an IMS architecture • Realistic transition plan that meets the corporate goals • Plan that maintains the flexibility but minimizes the complexity

5. Application Processing Database Network Interface Typical Pre-IMS Architecture Enhanced Services System Characteristics • Single vendor supplier system • Mix of vendor-developed and third-party components • Tightly coupled components • No interoperability standards • Proprietary interfaces between components • System can deliver only one service • Stove-piped architecture • Enhancements expensive (if even possible) • Enhancements may require new hardware • Lengthy testing and qualification for geographic markets • Safety • Network compliance

6. Impact on the Service Provider • Positive • Availability of industry-hardened solutions • Conferencing, voicemail, RBT, video conferencing • Negative • Expensive infrastructure • Barrier to new service offerings • Vendor lock-in • Expensive to change • “Slow” vendor introduction of enhancements • Simultaneous availability = no competitive advantage • “Slow” roll-out of new services • Detailed design and concept testing • Difficult to re-use the solution capabilities for new services

7. IMS Framework • IP Multimedia Subsystem Goals • Common architecture to support enhanced services • Disaggregated architecture supporting multi-vendor ecosystems • Subscriber network agnostic • Based on standards • IP and SIP • Standard interfaces • IP Multimedia Subsystem (IMS) Architecture • Developed by the Third Generation Partnership Project (3GPP) with subsequent involvement by: • IETF, ETSI, 3GPP2, CableLabs • Started in the mobile world, moved to fixed line • Standards are still evolving

8. IMS Architecture

9. SCIM S-CSCF HSS/HLR I-CSCF BGCF P-CSCF MGCF MRFP MGW IMS – A Simplified View Application Servers Key Elements: • AS – Application Server • SCIM - Service Capability Interaction Manager • MRFC - Multimedia Resource Function Controller • MRFP - Multimedia Resource Function Processor • MRF – Media Resource Function • CSCF- Call Session Control Function • BGCF - Breakout Gateway Control Function • MGCF - Media Gateway Control Function • MGW - Media Gateway • HSS - Home Subscription Server • HLR - Home Location Register SIP SIP MRFC CSCF RTP MRF PSTN

10. Unified Messaging Announcements Video Mail VideoConferencing IPCall Center Pre-Paid Voice Mail Conferencing Video Ringback Gaming Win Media mp3 Text IMS – Further Simplified SIP PLMN SIP Routing Cloud S-CSCF Web Content PSTN SIPSIP w/ VoiceXML SIP w/ MSCML MPEG-4 HTTP, FTP, NFS RTP Cable Network Storage MRF

11. IMS - Impact on the Service Provider • Negative • Complex architecture • Requires consideration of interface standards • Requires careful interop testing • Challenge of managing multiple vendors • Positive • Faster development and deployment of enhanced services • Ability to more easily develop services to result in a competitive advantage • Flexibility of vendor choice • IMS provides a migration path (not all or nothing)

12. Transition to an IMS Architecture • It is possible for a service provider to “get their feet wet” • Initial step is to consider the project goals • Multiple apps on the same infrastructure • Faster service development • Support of network types • Determine elements required • Typical minimum elements • Application/application server • HSS/HLR or database • Media Resource Function or media server • Media Gateway • CSCF or proxy

13. Database MRF MGW Media Data Transition – Minimum Elements Application Key Considerations: • Lowest cost fully functional option • Good for basic interop testing • Requires app developer to know VXML or MSCML • Standard apps like Voicemail or Conferencing • Database used to store scripts, prompts, and user data SIP VXML MSCML SIP RTP PSTN

14. Proxy Database MRF MGW Media Data Transition – Another Step Diverse Applications on Application Servers Key Considerations: • Higher cost option • Good for interop testing and data traffic load testing • App developer can use the app server service creation environment • More complex apps with multiple script fetches PSTN

15. Proxy Database MRF MRF MRF MGW Media Data Transition – An Additional Step Diverse Applications on Application Servers Key Considerations: • Higher cost option • Good for interop testing, data traffic load testing, media traffic load testing • App developer can use the app server service creation environment and load balancing capabilities • More complex apps with multiple script fetches and larger customer groups PSTN

16. Key Factors in a Transition Project • Match the transition project goals to the company’s business goals • Plan realistic steps • Don’t overextend • Maintain flexibility • If one approach doesn’t work, what other approaches are possible • When in doubt, leverage the experiences of others • Vendors and Partners

17. Wrap-up Q & A / Quiz