3 g m gw


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

3 g m gw

  1. 1. HELSINKI UNIVERSITY OF TECHNOLOGYDepartment of Computer Science and EngineeringTelecommunications Software and Multimedia LaboratoryEdgar J. RamosAnalyzing the Media Control interfaces andMobile Media Gateway for the Ip MultimediaSubsystem (IMS)Master’s Thesis submitted in partial fulfillment of the requirements for the degreeof Master of Science in Technology.Espoo, February 4, 2008Supervisor: Professor Antti Yl¨-J¨¨ski a aaInstructor: Gonzalo Camarillo, M.Sc.
  2. 2. HELSINKI UNIVERSITY ABSTRACT OF THEOF TECHNOLOGY MASTER’S THESISAuthor: Edgar J. RamosName of the thesis: Analyzing the Media Control interfaces andMobile Media Gateway for the Ip Multimedia Subsystem (IMS)Date: Feb 4, 2008 Number of pages: 100Department: Department of Computer Science and EngineeringProfessorship: T-110Supervisor: Professor Antti Yl¨-J¨¨ski a aaInstructor: Gonzalo Camarillo, M.Sc.The IMS as part of the 3G evolution networks involves costs and investments for thedevelopment of new systems and technologies. The Multimedia Resource Function Pro-cessor (MRFP) is an important component on the IMS to provide the operations overthe media in the packet-switched domain. Also it has been identified strong synergieswith the circuit-switched domain Media Gateway (MGW). This Thesis mainly analyzesthe Mp interface deployment, which is the one used to send the control messages tothe MRFP. Additionally several protocol alternatives are reviewed from the proposedMedia Control protocols defined in IETF together with the scenarios where a MRFP isneeded. At the moment of writing this work, the Mp interface has not been standard-ized fully. Therefore, the models and protocols reviewed and their impact are analyzedfor the Mobile Media Gateway’s User Plane Control Function (UPCF) application. Thefinal analysis lead to the selection of a media server control model including the proto-cols recommendation for each interface. At last, a prototype was developed to illustratethe possible adaptations from the Mobile Media Gateway. It was meant to handle theMp interface behaving as a MRFP and setup IMS IP calls. This final output provides acontribution to one possible transition path for the evolution from the circuit switcheddomain to the packet switched domain using the Mobile Media Gateway and the MediaServer Control model.Keywords: Media, Control, IMS, Mp, Mr, MGW, MRFP, MRFC, MRF i
  3. 3. AcknowledgementsI want to thanks the people who supported me to finish this work: my family inPanama and here in Finland, my friends and my colleagues in Ericsson. Their bestcontribution was to provide me with their precious time.I would also like to thank Johan Torsner for his patience and advices.Finally, my gratitude to Gonzalo Camarillo, who made and excellent work as a tutorbesides the difficulties found during this work development.Otaniemi, February 4th, 2008Edgar Ramos ii
  4. 4. To my beloved ones, with whom I share my challenges and rewards.
  5. 5. ContentsAbbreviations ixList of Figures xiList of Tables xii1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 32 IP Multimedia Subsystem 5 2.1 Overview of the IMS Architecture . . . . . . . . . . . . . . . . . . . 5 2.2 The IP Multimedia Core Network Subsystem . . . . . . . . . . . . . 6 2.3 Signaling plane interfaces . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 IMS/CS relationship (3GPP view) . . . . . . . . . . . . . . . . . . . 11 2.5 Media Plane Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 2.6 Application Plane Considerations . . . . . . . . . . . . . . . . . . . . 133 Multimedia Resource Function Processor 14 3.1 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1 Media Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 14 iv
  6. 6. 3.1.2 Media Transport . . . . . . . . . . . . . . . . . . . . . . . . . 154 Media Gateway 17 4.1 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Transport and Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3 The Mobile Media Gateway (M-MGW) . . . . . . . . . . . . . . . . 22 4.3.1 Connectivity Packet Platform . . . . . . . . . . . . . . . . . . 23 4.3.2 Hardware Structure Overview . . . . . . . . . . . . . . . . . . 24 4.3.3 Application Overview . . . . . . . . . . . . . . . . . . . . . . 255 Control Protocol for Media Servers 30 5.1 Multimedia Resource Function, Media Servers and Physical nodes Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Media Server Control Interface Criteria 34 6.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.3.1 3GPP Requirements . . . . . . . . . . . . . . . . . . . . . . . 36 6.3.2 IETF requirements . . . . . . . . . . . . . . . . . . . . . . . . 387 Media Server Control Interface Analysis 41 7.1 3GPP Proposed Protocols for Control of Media Servers . . . . . . . 41 7.2 IETF Proposed Protocols for Control of Media Servers . . . . . . . . 42 7.3 Media Server Control Protocols . . . . . . . . . . . . . . . . . . . . . 43 7.3.1 ITU Recommendation H.248 (Megaco Protocol) . . . . . . . 43 7.3.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . 53 7.3.3 Media Sessions Mark-up Language (MSML) . . . . . . . . . . 62 7.3.4 Media Server Control Mark-up Language (MSCML) . . . . . 68 7.4 Traffic Scenario Implications . . . . . . . . . . . . . . . . . . . . . . . 75 7.5 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 v
  7. 7. 7.6 Preferred model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 Prototype 82 8.1 Mobile-MGW VoIP prototype . . . . . . . . . . . . . . . . . . . . . . 82 8.2 M-MGW prototype considerations . . . . . . . . . . . . . . . . . . . 82 8.3 Affected User-Plane Control application subsystems . . . . . . . . . 83 8.3.1 Signalling Transport Converter (STC) . . . . . . . . . . . . . 83 8.3.2 GCP Termination (GCPT) . . . . . . . . . . . . . . . . . . . 83 8.3.3 Connection Coordinator . . . . . . . . . . . . . . . . . . . . . 84 8.4 M-MGW Prototype testing . . . . . . . . . . . . . . . . . . . . . . . 84 8.4.1 H.248 flows between M-MGW and SBC . . . . . . . . . . . . 85 8.4.2 Call setup procedure. . . . . . . . . . . . . . . . . . . . . . . 86 8.4.3 Call Release Procedure . . . . . . . . . . . . . . . . . . . . . 86 8.4.4 MGW Cold startup flow . . . . . . . . . . . . . . . . . . . . . 869 Conclusions and Future Work 89 9.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 vi
  8. 8. Abbreviations(A-F)3G 3rd Generation3GPP 3rd Generation Partnership ProjectAAL1 ATM Adaptation Layer - 1AAL2 ATM Adaptation Layer - 2AAL5 ATM Adaptation Layer - 5AMR Adaptive Multi-RateAS Application ServerATM Asynchronous Transfer ModeATIS Alliance for Telecommunications Industry SolutionsBGCF Breakout Gateway Controller FunctionBICC Bearer Independent Call ControlB-ISUP Broadband ISDN User PartBSC Base Station ControllerCAMEL Customized Applications for Mobile network Enhanced LogicCAP CAMEL Application PartCN Core NetworkCOPS Common Open Policy Service protocolCPP Connectivity Packet PlatformCS Circuit SwitchedCSCF Call Session Control FunctionDiffServ Differentiated ServicesDTMF Dual Tone Multi-FrequencyEDGE Enhanced Data Rates for GSM EvolutionFTP File Transfer Protocol vii
  9. 9. (G-M)GCP Gateway Control ProtocolGGSN Gateway GPRS Support NodeGPRS General Packet Radio ServiceGSM Global System for Mobile CommunicationGSM-FR GSM Full RateHSS Home Subscriber ServerHTTP Hypertext Transfer ProtocolIANA Internet Assigned Numbers AuthorityI-CSCF Interrogating - CSCFICP Internal Communication PathIETF Internet Engineering Task ForceIIOP Internet Inter-Object Request Broker ProtocolIMS IP Multimedia SubsystemIM-SSF IP Multimedia Service Switching FunctionIP Internet ProtocolIPsec IP securityISDN Integrated Services Digital NetworkISUP ISDN User PartITU International Telecommunication UnionIVR Interactive Voice ResponseMEGACO Media Gateway Control protocolMGC Media Gateway ControllerMGCF Media Gateway Control FunctionMGW Media GatewayMIME Multipurpose Internet Mail ExtensionsM-MGW (Ericsson) Mobile Media GatewayMRFC Multimedia Resource Function ControllerMRFP Multimedia Resource Function ProcessorMTP3 Message Transfer Part level-3MTP3b Message Transfer Part level-3 broadbandMSC Mobile-services Switching CentreMTP Message Transfer PartM3UA MTP3 User Adaptation Layer viii
  10. 10. (O-Z)OSA-CSC Open Service Access - Service Capability ServerO&M Operation and MaintenancePCM Pulse Code ModulationP-CSCF Proxy-CSCFPSTN Public Switched Telephone NetworkQoS Quality of ServiceRFC Request For CommentsRNC Radio Network ControllerRSVP Resource Reservation ProtocolRTP Real-Time Transport ProtocolSAAL Signaling ATM Adaptation LayerSCF Service Switching FunctionS-CSCF Serving-CSCFSCTP Stream Control Transmission ProtocolSGW Signalling GatewaySIP Session Initiation ProtocolSLF Subscription Locator FunctionSS7 Signalling System no. 7SSCF Service-Specific Coordination FunctionSSCOP Service-Specific Connection-Oriented ProtocolSRTP Secure RTPTCP Transmission Control ProtocolTDM Time Division MultiplexingTHIG Topology Hiding Inter-network GatewayTLS Transport Layer SecurityUDP User Datagram ProtocolUE User EquipmentUMTS Universal Mobile Telecommunications SystemVoIP Voice Over IPVPN Virtual Private NetworkXML Extensible Mark-up LanguageXCAP XML Configuration Protocol ix
  11. 11. List of Figures 1.1 Example of MGWs controled by the MSC . . . . . . . . . . . . . . . 2 2.1 Simplified IMS architecture . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 IMS reference points . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 MGW reference points and interfaces . . . . . . . . . . . . . . . . . . 20 4.2 Mc Interface/Reference point protocol stacks . . . . . . . . . . . . . 21 4.3 Nb Interface/Reference point Protocol stacks [3] . . . . . . . . . . . 22 4.4 IPBCP Tunneling [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.5 Control system structure of a CPP configuration with eight Board Processors (BP) and some Special Processors (SP) and a Main Pro- cessor Cluster (MPC) with three Main Processors (MP). [82] . . . . 24 4.6 M-MGW hardware structure. [33] . . . . . . . . . . . . . . . . . . . 26 4.7 M-MGW hardware structure. [33][41] . . . . . . . . . . . . . . . . . 27 4.8 Connection model in the Connection Coordinator. [41] . . . . . . . . 28 5.1 IMS Logical Nodes grouping used for the industry relative to the Media Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1 Example of a H.248 connection model. The asterisk box in each of the Contexts represents the logical association of Terminations implied by the Context[62]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.2 H.248 Message structure . . . . . . . . . . . . . . . . . . . . . . . . 46 7.3 H.248 Message size for a Representative Call Flow, based on a bench- mark test performed by the Erlang project in [81]. . . . . . . . . . . 49 x
  12. 12. 7.4 Encoding and Decoding measurements for H.248 binary encoded mes- sages based on a benchmark test performed by OSS Nokalva in [76]. (The message sizes are the same as for the corresponding messages shown in figure 7.3 for binary encoding) . . . . . . . . . . . . . . . . 507.5 SIP Message processing delay of 4 Proxy implementations. Source: [28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.6 MSML Object classes’ relationship . . . . . . . . . . . . . . . . . . . 647.7 MSML Core Package Hierarchy . . . . . . . . . . . . . . . . . . . . . 657.8 MSCML Advanced Conference Model . . . . . . . . . . . . . . . . . 707.9 MSCML Media Server Connection Model . . . . . . . . . . . . . . . 717.10 Possible deployment of the Analyzed Media Server Control Protocols on the 3GPP interfaces of IMS (The ISC interface is not present for simplicity). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.11 Selected preferred Model for Media Server Control (The ISC interface is not present for simplicity) . . . . . . . . . . . . . . . . . . . . . . . 818.1 H.248 Context view targeted to the prototype connection model . . 838.2 H.248 Call setup flow used for the Prototype . . . . . . . . . . . . . 878.3 H.248 call release and cold start-up flows used for the prototype . . 88 xi
  13. 13. List of Tables 4.1 Example of MGW’s features [43] . . . . . . . . . . . . . . . . . . . . 18 7.1 H.248 Commands [62] . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.2 H.248 Descriptors [62] . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.3 SIP Request Methods from the core specification[23] . . . . . . . . . 55 7.4 SIP Request Methods from extensions to the Core specification [23] 56 7.5 SIP headers defined in the Core Protocol . . . . . . . . . . . . . . . 57 7.6 MSML object classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.7 MSML mandatory and conditional packages . . . . . . . . . . . . . . 66 7.8 MSCML Request Methods for advanced conference . . . . . . . . . . 72 7.9 MSCML Request Methods for IVR . . . . . . . . . . . . . . . . . . . 73 7.10 Comparison of the characteristics of the Analyzed Media Control Pro- tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.11 Functionality comparison of the analyzed Media Server Control Pro- tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 xii
  14. 14. Chapter 1Introduction1.1 BackgroundThe IP Multimedia Subsystem (IMS)[14] has been seen as the clear evolution ofthe packet-switched domain in the cellular world, specifically for the 3G networks.The operators and manufacturers have mainly driven this evolution through thestandardization bodies. They have agreed on standards and technologies that shouldallow the shift from the old systems to the new ones. This involves costs andinvestments from both parties (operators and manufacturers) for the developmentand the deployment of such technologies and sometimes the process specified by therecommendations and agreements is not providing a smooth enough transition forthe real environments. From now on, we will be referring to the 3G networks as the ones defined forUMTS (Universal Mobile Telecommunications Service) and driven by 3GPP (ThirdGeneration Partnership Project) recommendations and the IMS as associated withit. The Mobile Softswitch has been defined as the architectural model for the mobilecore network where the call control and the switching functions are found in differentnodes. It is based in the 3G Partnership Project’s (3GPP) release 4. The MediaGateway (MGW) and the MSC Server (Mobile Switching Center) are the main play-ers for this concept, where the MSC works as a controller for the MGW (see figure1.1). The MGW handles: the media stream processing, switching, transcoding andthe resources for transport (the links of the connectivity layer) while the MSC isresponsible for the mobility management and the call control. The IMS has been introduced in the 3GPP’s release 5, providing to the 3G net-works with an infrastructure to offer QoS (Quality of Service), charging, coordina- 1
  15. 15. CHAPTER 1. INTRODUCTION 2 MGW IP – ATM MGW MGW Backbone MGW Connectivity Layer Control Layer MSC Figure 1.1: Example of MGWs controled by the MSCtion and integration of services and security for the packet switch domain. Part ofthe media plane is handled through the Media Resource Function (MRF), whichis divided in two functions or logical nodes: the MRFC (Media Resource FunctionController) that is in charge of interpreting the SIP (Session Initiated Protocol)messages from the AS (Application Server) and the S-CSCF (Serving Call/SessionControl Function), and the control of the other MRF function, the MRFP (MediaResource Function Processor). The last is in charge of the media stream processingand mixing, playing announcements and controlling bearers on the Mb referencepoint [13].1.2 Problem DescriptionThere are strong synergies between the functions performed by the MGW and thefunctions expected from the MRFP. Both are capable of doing media stream process-ing, transcoding and control of the media transport. Already it has been proposed
  16. 16. CHAPTER 1. INTRODUCTION 3the possibility of merging these logical nodes in one physical node: the Mobile MediaGateway (M-MGW) [43]. The Mp interface that is used for the MRFC to controlthe MRFP has not been standardized at the moment of writing this work. TheMGW already uses the protocol H.248 (known by IETF as MEGACO) for the Mcinterface with the MSC. Therefore, this work will analyze the different existing pro-posals for the Mp interface and Media server control. Also it will consider how they ˇcould impact the M-MGWSs User Plane Control Function (UPCF) Application andpropose an implementation based in the H.248 protocol for the Mp interface througha prototype.1.3 ObjectivesTo provide a comparison between the proposed protocols and models for MediaServer control. Additionally, to explore the implementation synergies between theM-MGW and the MRFP by constructing a prototype. The intention is to providea better understanding of the integration of the IMS network as an evolution of the3G networks by the gradual introduction of the IMS functions in the core network.1.4 ScopeThe thesis is limited to the Media Gateway (MGW) and the Mp interface of theMRF (Media Resource Function) contained in the 3GGP’s Release 6 specifications.The H.248 version discussed is version 2 released by ITU and IETF. In the MGW, the scope is limited to the application that handles the User PlaneControl Functions (UPCF) although some hardware specific details are mentioned.The outcomes and test environment are presented despite the prototype implemen-tation is not provided. The test environment is using an adaptation of a 3G networksuitable for our analysis purposes.1.5 Structure of the ThesisFollowing to the introduction chapter, the IMS is presented in chapter 2. There,important elements to the 3G’s Circuit Switched Network and IMS interactionsare reviewed; the media plane and the services using such interactions are alsosummarized. The access network and the terminals are irrelevant for our purposestherefore we will concentrate on the Core Network Subsytem of the IMS. Chapter 3introduces to the Multimedia Resource Function Processor (MRFP) tasks and the
  17. 17. CHAPTER 1. INTRODUCTION 4signaling that goes through the node. On chapter 4, the Media Gateway (MGW)implementation is described, its functions over the media plane, media transportand signaling combined with hardware and software overview. Chapter 5 providesan overview of the control protocols for Media Servers and the different modelsassociated to media server control. Later, the criteria of evaluation for the analysisprovided by this work can be found in chapter 6. The analysis itself of the differentprotocols alternatives , final comparison and selection of the preferred model is inchapter 7. The practical implementation of the prototype is presented in the finalchapter 8. Then the conclusions and future work are provided.
  18. 18. Chapter 2IP Multimedia SubsystemThe mobile networks have been traditionally built in the Circuit Switched (CS)domain copying the model from the Public Switched Telephone Networks (PSTN).After the GPRS (General Packet Radio Service) launch for GSM, the interest for thetransport of data using the mobile core network was evident. The packet switchingbecame then an important part of the Core Network specifications that can be fullyrealized in the 3GPP vision for the ”All IP Architecture” [11]. In this frame, theIP Multimedia Subsystem (IMS) was defined based in the provision of multimediaservices that are bound to the packet data transmission. It is conformed for all thenecessary elements on the Core Network (CN) using the Packet Switch (PS) domainto deliver the different types of multimedia [13] [71].2.1 Overview of the IMS ArchitectureThe IMS follows a layered architecture consisting of three different layers or planes[78]: application, control and connectivity & user’s plane. An example of the IMSlayered architecture is provided by figure 2.1. The application layer basically consists on the SIP Application Servers, whichprovide the content and value-added services to the users. The independence of thislayer with respect to the others allows the services being provided regardless of theaccess used. The control layer handles the registration, setup and release of calls and ses-sions. It also supplies functional control of the user’s plane servers (like MGWsand MRFPs). A big part of the network signaling is produced and received by thislayer, including the O&M (Operation and Management), charging, and network’sinterworking support. 5
  19. 19. CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 6 Finally, the connectivity & user’s plane manages and processes the media sentby the end-points. This layer is in charge of the media traffic transport, routing,switching and network translation (protocol conversions). 3GPP has standardized functions or what we could call logical nodes. This isdifferent from the physical nodes offered by the vendors, which can merge severalfunctions in a physical node or split them in several entities[24]. In essence, thearchitecture of the IMS is defined by the logical nodes and the standardized interfaceslinking them. AS CS Network CSCF BGCF HSS MRFC MGCF SGW Access Network MRFP MGW UE Media Traffic Signalling Traffic Figure 2.1: Simplified IMS architecture2.2 The IP Multimedia Core Network SubsystemThe IP Multimedia Core Network Subsystem according to 3GPP ”comprises of allCN elements for the provision of IP multimedia applications over IP multimediasessions” [12].For this purpose the CN includes: 1. User data base(s): One or several HSS (Home Subscriber Server), which can be considered as the evolution of the GSM node HRL (Home Location Register).
  20. 20. CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 7 It stores and handles the subscriber and services related information. Some of the information includes: security items, location data, profiles and S-CSCF (Serving Call Session Control Function) allocated to the subscribers. The SLF (Subscriber Location Functions) is used in case of the need to split the information stored by the HSS into several of them. The function of the SLF is to map the addresses of the subscribers into the corresponding HSS containing the information needed for the particular subscriber [24]. 2. The CSCFs (Call/Session Control Functions). They are SIP servers in charge of routing and session management. The entities grouped in this category are: ˆ P-CSCF (Proxy Call Session Control Function). It is the first signaling contact point within the Core Network (CN) with the terminal. It takes care of accepting requests (SIP messages) and processing them itself or forwarding them into the CN depending on what is required. It may include a PDF (Policy Decision Function) that could be implemented in a separated node [14]. ˆ I-CSCF (Interrogating CSCF). It is a SIP proxy, serving as a contact point within an operator’s network for all the connections from a subscriber of the network or a roaming subscriber located in the network operator’s service area at the moment. It has an interface using the Diameter pro- tocol to the SLF and the HSS. It can hide some domain information by encrypting parts of the SIP message. This last feature is known as THIG (Topology Hiding Inter-Network Gateway) and it is optional [14]. ˆ S-CSCF (Serving CSCF). It is the main control entity in the signaling plane. Basically, it executes the session control services for the User Equipment and maintains the session’s states needed to support the op- erator’s services. The S-CSCF analyzes the terminal’s SIP messages and decides to route them to the correct application servers that would be able to provide the service to the subscribers. Another function of the S-CSCF is the routing services, for example translations of telephone numbers provided instead of SIP URIs (Universal Resource Identifier)as addresses. The enforce of network’s policies to the users is also done by the S-CSCF depending of the user service profile and operator’s policy configuration [14] [24]. 3. The ASs (Application Servers), which provide and hosts the multimedia ser- vices and comprise the application plane. Three types of ASs have been de-
  21. 21. CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 8 fined: ˆ SIP AS: It is a native Application Server that executes multimedia ser- vices based on SIP. It will become the most used type for the development of new IMS specific services [24]. ˆ OSA-CSC (Open Service Access - Service Capability Server): This type of application server supplies an interface for the OSA (Open Service Access) framework Application Server and interfaces the S-CSCF with SIP at the same time. It is an important mechanism to provide secured and standardized access for a third party AS to the IMS. ˆ IM-SSF (IP Multimedia Service Switching Function): It is a specialized application server designed to support CAMEL (Customized Applications for Mobile network Enhanced Logic) services for legacy reasons. It acts as a SCF (Service Switching Function) on one side, interfacing the gsmSCF by using CAP (CAMEL Application Part) and allowing it to handle an IMS session. On the other side, it behaves as a SIP server interfacing the S-CSCF. 4. BGCF (Breakout Gateway Control function). The network can have one or more of them. It is a point for breakout to the Circuit Switched network from the IMS. It is used when an IMS subscriber is trying to access the CS network. Despite being a SIP server, it uses the phone number and routes the request to the MGCF (Media Gateway Control Function) if the breakout takes place in the same network, or to one BGCF on the destination network [24][78]. 5. PSTN (Public Switched Telephone Network) - CS (Circuit Switched) gate- ways. They are decomposed into: ˆ MGCF (Media Gateway Control Function). It is a control and signal- ing node. It maps the SIP protocol to ISUP (ISDN User Part) or BICC (Bearer Independent Call Control), both over IP. Also, the MGCF con- trols the MGW resources using the H.248 protocol. ˆ SGW (Signaling Gateway). Sometimes it is needed to transfer requests to the CS networks from the IMS and vice versa. The SGW is in charge to do the low-level protocol conversion to make compatible the transport and mutual understanding in the signaling network. Basically, it converts the MTP (Message Transfer Part) into SCTP (Stream Control Transmission Protocol) over IP[24].
  22. 22. CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 9 ˆ MGW (Media Gateway). It does the media plane conversion between the IMS and the CS networks. The conversion can include change of transport protocol (for example, from RTP to AAL2), transcoding (i.e., from AMR to G.711) or stream processing (echo cancellation, playing of announcements, DTMF, etc). It receives control instructions from the MGCF. 6. MRP (Multimedia Resource Function). It is divided into two logical nodes: ˆ The MRFP (Multimedia Resource Function Processor) provides the nec- essary resources to support the user-plane services requiring media pro- cessing in the IMS domain. It is capable of performing conference mixing, transcoding, media analysis, stream treatment, and providing the media to play announcements, for example. ˆ The MRFC (Multimedia Resource Function Controller) controls the MRFP resources using H.248 and acts as a SIP User Agent [24]. It was designed to grant the separation between the control plane and the user plane for the IMS’ media resources.2.3 Signaling plane interfacesThe signaling in IMS takes place over the reference points (see figure 2.2). Theyare links between the different IMS logical nodes using protocols that 3GPP haschosen to standardize. The protocols deployed at the reference points have beenstandardized by IETF (Internet Engineering Task Force) and ITU (InternationalTelecommunication Union). The reference points (we will also call them interfaces)in IMS grouped by protocols are [13]: 1. Reference’s points using Diameter (specified in RFC 3588 [22]) : ˆ Cx Interface. It is implemented between the I-CSCF or S-CSCF and the HSS. Mainly, it is used to allocate the S-CSCF, retrieve user information and for authentication purposes. ˆ Dx Interface. It is implemented between the I-CSCF or S-CSCF and the SLF. It is used to find the HSS where the user’s data is allocated. ˆ Dh Interface (Release 6). It is implemented between the AS and the SFL. It is used by the AS to find the right HSS to contact in a multi-HSS environment.
  23. 23. CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 10 ˆ Sh Interface. It is implemented between the AS and the HSS. It is used by the AS to access the HSS records. ˆ Si Interface. It is implemented between the HSS and the IM-SSF. It is used by the AS to query CAMEL subscription information from the HSS. ˆ Gq Interface (Release 6). It is implemented between the P-CSCF and the PDF. It is used to exchange policy decision and information between both entities. 2. Reference points using SIP (specified in RFC 3261 [86]) : ˆ Mw Interface. It is implemented between two CSCFs. It is used as a communication channel (SIP proxy) between the CSCFs. ˆ ISC Interface. It is implemented between the S-CSCF and an AS. ISC stands for IMS Service control and it is used to carry charging informa- tion. ˆ Mi Interface. It is implemented between the S-CSCF and the BGCF. It is used by the CSCF to forward a session to the BGCF when the session needs to be routed to the CS domain. ˆ Mj Interface. It is implemented between the MGCF and the BGCF. When the BGCF selects the CS network where the breakout will happen, if it is happening in the home network, the Mj interface is used to forward the session to the MGCF. ˆ Mk interface. It is implemented between two BGCFs. It is used when the CS breakout happens in a network different from the home network. Then the session is forwarded to the BGCF in that network. ˆ Mr Interface. It is implemented between the S-CSCF and a MRFC. It is used by the S-CSCF to activate bearer related services. The functionality is not fully standardized. ˆ Mg Interface. It is implemented between the MGCF and a I-CSCF. The MGCF uses this interface to forward CS sessions to the IMS domain after converting the ISUP signaling to SIP. ˆ Mm Interface. It is implemented between the I-CSCF and another SIP terminal or server. In general, it is used by the IMS (specifically by the I-CSCF) to communicate with another multimedia IP networks by using SIP.
  24. 24. CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 11 ˆ Gm Interface. It is implemented between the UE (in reality the access network) and the P-CSCF. It is used as the connection between the UE and the IMS. The interface allows three type of procedures: registration, session control and transactions [78]. The UE registers to the P-CSCF sending information about the supported security mechanisms and ex- changing authentication data with the network. This procedure implies the registration of user identities and the set up of secure ways of com- munication between the UE and the IMS. Re-authentication requests or network initiated de-registration are also handled by this interface. After this, a session can be established and handled using the Gm inter- face (UE terminated or originated) to forward the requests. And finally, stand-alone requests and responses are also sent into the interface by the transaction procedures. 3. Reference points using MEGACO (ITU-T Recommendation H.248)[62]: ˆ Mp Interface. It is implemented between the MRFC and the MRFP. It is used by the MRFC to control the resources and media streams in the MRFP. ˆ Mn Interface. It is implemented between the MGCF and an IMS-MGW. It is used by the MGCF to control the resources and MGW functions. 4. Reference point using COPS (Common Open Policy Service protocol specified in RFC 2748 [31]): ˆ Go Interface. It is implemented between the PDF (P-CSCF) and the GPRS network. It is used for QoS authorization and charging correlation between the IMS and the GPRS. 5. Reference point using HTTP (HyperText Transfer Protocol) and XCAP (XML Configuration Protocol): ˆ Ut Interface (Release 6). It is implemented between the UE (in reality the access network) and one (or several) AS. It is used to allow data manipulation for configuration purposes from the UE.2.4 IMS/CS relationship (3GPP view)Even when the IMS operates in the packet switch domain, it needs to keep a rela-tionship with the circuit switch domain for several reasons: backwards compatibility
  25. 25. CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 12 Visited IMS AS Network P-CSCF Mk Si BGCF Home IMS HSS ISC Network Cx Mj Mi Cx S-CSCF Mw Mg Mw SGW I-CSCF MGCF Dx Mr MRFC Mw Mn Ut SLF PDF Mp P-CSCF MGW Gi Go MRFP Mb Access Network Nb Gm GGSN Mb Mb CS Network IP Multimedia Network UE Figure 2.2: IMS reference pointsand legacy, interworking with other networks and UEs, and inability to provide sup-port for certain services (i.e. emergency calls in the earlier phases). Although suchcompatibility is not mandatory from the specifications point of view, it is clearly ofimportance for the operators to be able to interact between both domains [74]. As has been stated, the PSTN/CS Gateway is the one that provides the inter-face for IMS toward a CS network. It handles the calls terminated and originatedin the CS domain where the IMS takes part. This Gateway has its counterpartin the CS domain, which in practical terms can be the same entity. Concerningthis, the 3GPP’s Technical Specification TS 23.002 reminds that the packet switchdomain and the circuit switch domain ”...are overlapping, i.e. can contain some com-mon entities”[13]. Also in TS 23.228 ”The IP multimedia subsystem is independentof the CS domain although some network elements may be common with the CSdomain”[13]. The specifications make a difference between the IMS-MGW and the CS-MGW(Circuit Switch MGW) as the MGW operating on the packet switch domain orthe one from the circuit switch domain. The reason for such separation is mainly
  26. 26. CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 13based on the media processing done in the CS domain and the possibility of it beingperformed in the PS domain (to adapt media for the CS domain, i.e. echo canceling).The pure media processing for the IMS has been specified as a task of the MRFP anda media connection can be established between both entities (MGW and MRFP),allowing media processing in one and protocol transcoding in the other one. TheCS MSC (Mobile-services Switching Center) and the IMS MGCF have also commonfunctions when is about the MGW control. Excluding some particular things properof the network characteristics, the MGW handling and control could be consideredidentical.2.5 Media Plane ConsiderationsThe IMS follows the signaling and media separation model, being able to offer aguaranteed QoS (Quality of Service), media services, and flexible charging. Re-gardless, IMS is still an IP network and the transport and routing of the mediais done following the IP principles. Because the IMS is an interconnected networkinterworking with another networks (i.e. Internet), the mechanism established toprovide the expected features requires the special handling of the packages (usingRSVP or DiffServ for QoS) and even specialized protocols (RTP, SRTP, SCTP,IPsec, etc). The media transverses an IP network by following a channel set by asession control. The media may or may not transverse network nodes (for examplethe MRFP or the MGW) depending if it is necessary any treatment to adequate itfor the communications purposes. For our study, we will concentrate on the caseswhen it is necessary to use the MRFP and the MGW in the IMS.2.6 Application Plane ConsiderationsThe Application Servers (ASs) perform the storage and service provisioning func-tions. Sometimes this implies the processing and analysis of media. For that reasonit makes sense in practice to fusion the MRFC functionality with the specific ASthat needs to do the media processing. In this way the media processing is done bythe MRFP controlled by an AS. From this point of view, the MRFC could seem tobelong to the application plane, because the media processing is done as part of aservice provided by the IMS or as the service itself. But in the strict meaning of theMRFC’s function it acts as a controller for the MRFP and for that reason we willconsider it in the control plane.
  27. 27. Chapter 3Multimedia Resource FunctionProcessorThe MRFP is a part of the general Multimedia Resource Function. It is controlledby the MRFC using the Mp reference point. By this interface it receives ordersfrom the Application Servers (AS) and indirectly through the S-CSCF. It is alsoconnected using the Mb interface with other MRFPs, MGWs, other IMS networksand the GGSN (Gateway GPRS Support Node) for the media processing.3.1 FunctionThe 3GPP specifications [13, 14] define the task of the MRFP as follows: ˆ Bearer control on the Mb reference point. ˆ Mixing of media streams (video and audio, multiparties, etc). ˆ Source of media (i.e. announcements, tones, etc). ˆ Processing of media streams (e.g. transcoding, analysis of media) ˆ Resources provisioning for the MRFC control. In practice the MRFP will be used as a support node for the provisioning ofmultimedia services. The implementation of the functions are very open for themanufacturers, as well as the capacity and service parameters.3.1.1 Media EncodingThe media encoding is relative to the digital handling of media. Video and audioare digitalized with several technologies and their interworking has to be secured 14
  28. 28. CHAPTER 3. MULTIMEDIA RESOURCE FUNCTION PROCESSOR 15by transcoding mechanisms and translating techniques. Also the media could needmanipulation to provide a service to the subscribers or the mixing of several mediatypes or media streams to achieve a simultaneous transmission-reception of mediafrom several sources at the same time. One example is provided when an AS willcontrol the MRFP to adapt the media sent to one subscriber from a media server byperforming transcoding and mixing of the streams in a conference call. In this case,the MRFP can produce the media or transcode the media from a media server some-where in the network (or other interconnected IP network). Then the mixing couldbe done for several subscribers sharing the session. 3GPP has specified which codecsmust be supported in their IMS terminals [5]. This are AMR (Adaptative Multi-Rate) speech codec and H.263 video codec. Those terminals that support real timetext conversational services must use T.140 (ITU-T Recommendation T.140 [53])and the ones providing wideband services support AMR-WB (AMR WideBand). Onthe other hand, some non-3G terminals could support different codecs. The morecommon ones for speech are G.711 [54], also known as PCM (Pulse Code Modula-tion) and GSM-FR (GSM Full Rate) [35] implemented in all the GSM terminals,and for video: MPEG (Motion Picture Experts Group) video standards (MPEG-1[45], MPEG-2 [46] and MPEG-4 [44]) and H.261[47] used by the H.320[55] video-teleconferencing framework as well [24].3.1.2 Media TransportThe MRFP takes care of the congestion and QoS for the bearer control. It couldalso handle the security associations for the media transport and the establishmentand release of connections over IP. This is useful considering the Mb reference pointconnections to other IP networks, i.e. GPRS, to set VPN (Virtual Private Networks)relationships and other IP connection services. Because of the IP properties, otherprotocols are used on top of it to provide the services not available with pure IP.Themost important protocols used for the MRFP are : RTP, TCP, UDP and SCTP. The RTP (Real-Time Transport Protocol) [88] is used to transmit digitalized me-dia that are sensitive to delay and time continuity [26]. For this purpose, it providessequence numbers in the packages and timestamps. The first lets the receiver findout when a loss of packages has happened and the correct order of the packages inthe receiving buffer. The second allows playback control and delay handling. RTP is used over UDP (User Datagram Protocol) datagrams mainly for con-currence reasons, allowing one equipment to handle several RTP streams at thesame time. RTCP (RTP Control Protocol) is used together with RTP. RTCP com-plements the RTP’s real-time functions. It provides an out-band communication
  29. 29. CHAPTER 3. MULTIMEDIA RESOURCE FUNCTION PROCESSOR 16between the sender and the receiver, with information about the performance of thenetwork and additional information about the media sent using the RTP packages.It is transported over UDP and uses the next port number following the port numberused by the RTP stream. For specific messages, the SCTP (Stream Control Transmission Protocol) protocolspecified in RFC 2960 [90] is used. This protocol is connection-oriented, which meansthe establishment of startup associations between two end points that provide a setof transport addresses to send and receive the messages. The basic function ofSCTP is to offer a reliable transport for messages between the peers avoiding thedisadvantages of TCP and UDP. Mainly these are: the capacity of multihoming,better DoS protection than TCP, and handling of multiple streams. In our studythe use of SCTP will be mainly seen in the signaling plane, where it is used totransport the H.248 messages over the Mp reference point. TCP (Transmission Control Protocol)[80] has been used traditionally for reliabletransport. It was created to provide IP with the possibility of transmitting data-grams to different processes in the same host with reliability. It is a connectionoriented protocol, by creating a virtual circuit connection reserving a port and au-thorizing the transmission from both parties with full duplex capabilities. It is astream-oriented protocol and is based in buffered transfer [26]. At the same time,UDP (User Datagram Protocol) [79] is a connectionless and unreliable protocol, butadds to IP the capacity of distinguishing among multiple processes in a destinationhost [26]. The application handling the UDP transmission have to take care of thedelays, loss and duplication of packages, sorting and reachability of the destination.In any case, UDP is used because of the low overhead and easy packets transmis-sion. UDP can cause network congestion when is used to transmit large quantitiesof data, because it lacks of congestion control. Other protocols like DCCP (Data-gram Congestion Control Protocol) [69] have been developed to handle the possiblenetwork congestion because of unreliable transport services.
  30. 30. Chapter 4Media GatewayTraditionally, Gateways have acted as translators between networks, allowing com-munication to be carried on even when the protocols, topologies and transmissionmedia are different. The Media Gateways also adapt the media transmitted in thepayload to be compatible with the different technologies used for digital transmis-sion and terminals communicating. 3GPP has included the Media Gateways as themain edges for connectivity in the Circuit Switched Core Network. They providethe access to the network backbone for the media (acting sometimes as a transitswitch), payload processing, media conversion and bearer control, to support theCircuit Switched services options [13]. This is especially important in the transi-tion of the GSM networks to the ”all-IP networks” vision, when there exists severalnetworks, which needs to communicate and interact between them. The MediaGateways realize this in the media plane and the evolution of the 3G networks willdefine the needs of this node depending on the development into the all IP-visionalready mentioned.4.1 FunctionThe Media Gateway function specified by 3GPP is split in two: the Circuit SwitchedMedia Gateway function and the Packet Switch (or IMS) Media Gateway function.The functions might or might not be implemented in the same node or implementedjust partially for each function (not the complete set for each type). In practice,the IMS-MGW and the CS-MGW can differ just in the transport used for thepayload, although only that fact is motive of important implementation differences.3GPP just outlines the MGW’s functions without giving an exact definition of thefeatures needed to ”...support the Iu options for CS services” [13] for the CS-MGW 17
  31. 31. CHAPTER 4. MEDIA GATEWAY 18and ”...will be provisioned with the necessary resources for supporting UMTS/GSMtransport media” [13] as is specified in the 3GPP’s Network Architecture TS 23.002.Then the specific features can be inferred from those requirements. Teemu Haresin his master thesis ”Adding multimedia resource function processor functionalityto Mobile Media Gateway” already identifies this and presents an example of MediaGateway features needed, which can be seeing in table 4.1. Table 4.1: Example of MGW’s features [43] Functions Features Switching/routing ATM switch Real-time IP router (support of IPv4 and IPv6) Signalling Signaling with H.248, SS7, BICC Protocol conversion Convert transport protocols Transcoding AMR speech Speech coded with other codecs Media Processing Echo cancellation Quality QoS handling Differentiated Services (DiffServ) Security IP Security (IPSec) Services Multiparty connections Tone sending/detection DTMF sending/detection Announcement handling Modem services and digital data access Cs data Charging information collection As specified, the control layer through the Media Gateway Control Function(MGCF), the Mobile-services Switching Centre (MSC) server and the Gateway MSC(GMSC) controls the Media Gateway. The Media Gateway interacts with thoseentities to implementing a termination and context view provided by the H.248abstraction. This will be further explained in section 7.3.1. Because the Media Gateway is at the border of the backbone and interacts withother networks, it needs to implement a dual routing/switching function. If thebackbone implements an ATM network, the MGW switches the cells originated bythe Radio Network to or from the backbone, and it even serves as a transit nodewhere the cells are routed to other MGW or ATM switches. In the case of the IPbackbone, the routing mechanism works different from ATM. The MGW processesthe packets only directed to itself, it does not acts as a transit node although is not
  32. 32. CHAPTER 4. MEDIA GATEWAY 19required by the topology of the network and a routing table includes such a MGWas a link to reach another MGW. Also, the MGWs must know where to send thepackets to reach the end destination, and maintain a QoS level by keeping an ownrouting table if necessary. In the case of being connected to different networks (PSTN, UTRAN, UMTS,ISDN, etc), the MGW could need to implement translation mechanisms to be ableto send the media with the right protocol format, data encoding and media frame toeach of the networks interacting with it. On the data transmission level, the mostcommon conversions are from ATM to IP and vice-versa, and from ATM internallayers AAL1 to AAL2 and vice-versa (mainly in the cases of TDM data, used mainlyfor PSTN and in some cases for GSM).4.2 Transport and SignalingThe Media Gateway has several interfaces and references points. From the circuitswitch domain: the Mc interface connecting to the GMSC and MSC server, andthe Nb interface connecting to other MGWs in the network. The Mc interface(reference point) also connects the MGCF from the IMS to the MGW, and theMb interface connects the MGW with the MRFP and the GGSN from the GPRSnetwork. The radio network is connected by the IuCS interface, and the BSC canuse the A interface directly to the MGW as well.This can be seen in figure 4.1. The Mc interface transports the H.248 signaling messages to control the MGW.The rest of the protocol stack is mentioned in the 3GPP specification TS 29.232”Media Gateway Controller (MGC) - Media Gateway (MGW) interface” [4]. TheATM or IP transport is handled as a mix of both or in ”pure” mode. In the pureATM transport, the H.248 is transported on top of MTP3b (Message Transfer Partlevel-3 broadband)[51] that provides the point-to-point link communication and thecapacity of sharing load and changeover between a set of links. The rest of the stackis SSCF (Service-Specific Coordination Function)[50] and SSCOP (Service-SpecificConnection-Oriented Protocol)[48] conforming to the Signaling ATM AdaptationLayer (SAAL) [49] on top of AAL5 (ATM Adaptation Layer - 5). In the pureIP transport mode, the stack is simpler by having the H.248 on top of the SCTP(Stream Control Transmission Protocol)[90] over IP providing the connection ori-ented relation needed to compliant with the redundancy and load handling of thesignaling. The specification also warns about not to use IPsec for the Mc interfacebecause SCTP provides the necessary security. In the case when both signalings areused, the M3UA (MTP3 User Adaptation Layer) [6] shall be added to the SCTP
  33. 33. CHAPTER 4. MEDIA GATEWAY 20 Radio Network Nodes PSTN IMS Nodes CS Domain Nodes MGCF GPRS Nodes PSTN MRFP MSC + VRL Mb Mc MGW Nb GGSN MSC A IuCS MGW BSC RNC Figure 4.1: MGW reference points and interfacesstack providing the necessary interworking with all the systems. It might also beadded in a pure IP network, looking for a more flexible implementation of the nodes.Figure 4.2 illustrates the possible stacks for the Mc interface. The Iu-CS interface is connecting the Media Gateway with the Radio NetworkController (RNC) and the Base Station Controller (BSC). This interface is alsoconnecting the Radio Access Network (UTRAN) to the Core Network. ATM andIP can be used as a transport for this interface [7]. When the Iu-CS interface is not implemented for the BSC (Base Station Con-troller), the A-interface can be used instead [1]. It was designed for the EDGE(Enhanced Data Rates for GSM Evolution) Radio Access Network connection tothe MSC, and only the user’s data is routed to the MGW. The backwards com-patibility with GSM and the MSC split (MSC-Server/MGW) makes this interfaceappear into the 3G networks’ layout. The Nb interface provides the transport for user plane data between MGWs and
  34. 34. CHAPTER 4. MEDIA GATEWAY 21 H.248 H.248 H.248 M3UA MTP3b SCTP SCTP SSCF SSCOP AAL5 IP IP ATM IP-Transport IP - ATM ATM-Transport Transport Figure 4.2: Mc Interface/Reference point protocol stacksbearer control [3]. It can use ATM and IP transport, and the protocol stack variesfor the transport network user plane or the transport network control plane. Inthe first, the ATM case, the stack is AAL-2 SAR SSCS (AAL type 2 Segmenta-tion And Reassembly Service Specific Convergence Sublayer)[52]/AAL2 [57]/ATM.In the IP case, the stack is RTP/UDP/IPv4 or IPv6. The transport network con-trol plane for ATM uses AAL2 connection signaling (ITU-T Q.2630.2 [56])/AAL2Signaling Transport Converter for MTP3b (ITU-T Q.2150.1 [61])/MTP3b/SSCF-NNI/SSCOP/AAL5/ATM. The IPBCP (IP-Bearer Control Protocol)[60] shall betunneled as specified in 3GPP TS 23.205 ”Bearer-independent circuit-switched corenetwork” [2]. The figures 4.3 and 4.4 show the Nb stacks and the IPBCP tunnelingroute. The Mb interface/reference point provides access for the IPv6 network servicesto transport user data[13]. According to the specification, the Mb interface can bethe same as the Gi interface from the GPRS network. Therefore, the MGW keeps atransport link with the GPRS network (specifically the GGSN) and with the MRFPfrom the IMS. The PSTN interface connects the MGW to the PSTN network. The interface isused for the media gateway just to transport the user plane media. The controlsignaling goes to the MSC server or the GMSC. From the transport point of view,the MGW is considered to be one ISDN external exchange point for the PSTNnetwork.
  35. 35. CHAPTER 4. MEDIA GATEWAY 22 AAL2 connection AAL-2 signalling RTP RTCP (Q.2630.2) SAR SSCS AAL2 STC for MTP3b MTP3b UDP AAL2 SSCF-NNI SSCOP AAL5 IPv4 IPv6 ATM ATM IP-Transport ATM Transport ATM Transport User Plane User Plane Control Plane Figure 4.3: Nb Interface/Reference point Protocol stacks [3]4.3 The Mobile Media Gateway (M-MGW)The specifications do not standardize the implementation of the different functions inthe networks (that we know as ”logic nodes”). Instead they give a set of requirementsand tasks that must be accomplished by the logical entities. The manufacturers andoperators can choose the way how these functions are implemented; i.e. severallogical nodes can be grouped into one physical node. The circuit-switched MGWfunctions are implemented in the Mobile Media Gateway (M-MGW) together withsome useful extra functionality. The M-MGW can be used as a Signaling Gateway(SGW), an ATM packages handler (in addition to the switching point), real-timeIP router and media stream handler. The evolution of the 3G networks especially from operators within the ”incumbentGSM adding WCDMA” and ”greenfield” [34] scenarios, has given to the M-MGWthe opportunity to develop as an important part to be considered by the operatorsin their network planning. The flexibility and versatility of the node, which allowsto change or upgrade the capacity or functions implemented physically, even duringoperation (or short operation breakages), is an attractive feature in the competitivemarket. These facts make feasible the study of the node possibilities to include IMS
  36. 36. CHAPTER 4. MEDIA GATEWAY 23 Nc IPBCP: Q.1970 MSC-Server MSC-Server Tunnel: Q.1990 Mc Mc BICC: Q.765.5 MGW MGW TS 29.232 Nb Figure 4.4: IPBCP Tunneling [3]functionalities into its features. Many of the M-MGW characteristics are possiblethanks to the ”Connectivity Packet Platform” (CPP), former ”Cello Packet Platform”[68].4.3.1 Connectivity Packet PlatformThe CPP is a proprietary platform for execution and transport, providing interfacesto be used by applications using its services and executing on top of it. CPP hasbeen designed to provide support for redundancy, scalability, distributed executionenvironment and transport services. It includes a real-time operative system, a dis-tributed real-time database and O&M (Operation and Maintenance) support. CPPis built up for software and hardware modules [82] and consist of two big parts: TheCPP platform and the CPP development environment. The first contains supportfor ATM switching, IP routing, SS7 (Signaling System no. 7), B-ISUP (BroadbandISDN User Part) and Q.2630 [56] for AAL2 connections. The second provides ap-plication interfaces, libraries and software execution control for the multiprocessorenvironment.
  37. 37. CHAPTER 4. MEDIA GATEWAY 244.3.2 Hardware Structure OverviewIn general, the CPP nodes are composed by a backplane acting as a bus wheredifferent processor boards are attached and communicating between them. Theprocessors follow a hierarchic model (figure 4.5 and are placed in specialized boardswith specific functions and purposes. BP ICP BP BP ICP ICP MP ICP ICP ICP MP BP BP ICP ICP MP ICP ICP MPC BP ICP BP ICP BP ICP SPSP BP SPFigure 4.5: Control system structure of a CPP configuration with eight Board Pro-cessors (BP) and some Special Processors (SP) and a Main Processor Cluster (MPC)with three Main Processors (MP). [82] The Main Processors (MPs) form a cluster (referred to the Main Processor Clus-ter) where several Board Processors (BPs) are attached using a star topology. Theyuse an Internal Communication Path (ICP) to communicate with the cluster andcan control several Special Purpose Processors (SPs). The MPs inside a clustercommunicate but the SPs only with the BP they are connected to. Although this ishierarchic system, there is not a master-slave relationship, since in case of MP restartor crash, another MP will take over the critical processes immediately. The proces-sors can find where the processes are executed, querying a name server provided byCPP that publishes the task and services running in the MPC [82]. The backplane of the M-MGW is able to switch up to 622Mps duplex non-blocking
  38. 38. CHAPTER 4. MEDIA GATEWAY 25between the boards attached to the backplane(figure 4.6. The boards have a specificfunction and purpose, and they contain the different processor types depending ontheir function. The different types of boards that can be found in the M-MGWstructure are [33]: ˆ General Purpose Boards (GPB). They have a hard disk and can be configured as a Main Processor (MP) or to provide Interactive Messages (IM). ˆ Special Purpose Boards (SPB). The SPB has been provided with several pow- erful microprocessors and can be used to execute any application. One of its typical task is the packet handling. ˆ Media Stream Boards (MSB). The MSBs are controlled by the applications and are composed of Digital Signal Processors (DSPs), memory, and control processors. ˆ Exchange Terminals (ET-x). There exists different types of Exchange Termi- nals and then named depending on the transmission technology used. They are named ET-MC1, ET-M4, ET-C4, ET-FE1, ET-FE4 and ET-FET, and each of them adapts to a different type of physical medium (i.e. Ethernet, ATM, TDM, SONET, SDH, etc). ˆ Switch Core Board (SCB). The SCB has three functions: it works as an ATM switch core, it distributes the system clock and connects the subracks together using the Inter-Subrack Link (ISL). ˆ Switch Extension Boards (SXB). They are used to expand the M-MGW ca- pacities. In large nodes, the SXB interconnects subracks where the use of a SCB is not enough. ˆ Timing Unit Board (TUB). It provides the clock reference for the M-MGW. Also it is synchronized with the public network and has long term stability. ˆ Pooled Forwarding Engine. Used to handle the packet IP traffic over ATM.4.3.3 Application OverviewThe M-MGW application is a software layer built on top of the CPP platform, usingits services to interact and communicate. The application is the one that instructsthe M-MGW hardware the task that must be done, and implements an abstractenviroment to handle call data, protocols, instructions and services. Part of this
  39. 39. CHAPTER 4. MEDIA GATEWAY 26 ET- MC 1 ET MC - 41 ET- M4 ET- C4 ET- FE1 ET- FE4 ET- Bac FET SCB kpla ne SXB TU B SPB GPB ET-X Exchange Terminals SCB Switch Core Board MS SXB Switch Extension Board B TUB Timing Unit Board PFE SPB Special Purpose Board GPB General Purpose Board MSB Media Stream Board PFE Pooled Forwarding Engine Figure 4.6: M-MGW hardware structure. [33]abstraction is the Virtual Media Gateway (VMGW). With the VMGW, the M-MGW node can serve several MGC (Media Gateway Controllers) making possiblethe sharing of the physical resources and services[41]. The application is structured in three big parts: ˆ User Plane Control Functions (UPCF). The User Plane Control Functions consist of Signaling Transport Converter (STC), GCP Termination (GCPT) and Connection Coordinators. ˆ User Plane Functions. It consist of the media stream and media framing resources software. ˆ Operation and Maintenance application (O&M). Provides the software inter- face for Operation and Maintenance of the node.User Plane Control FunctionsThe User Plane Control Functions (UPCF) can be seen as the brain of the M-MGWnode. Its functions go from terminating the H.248 protocol, by interpreting and
  40. 40. CHAPTER 4. MEDIA GATEWAY 27 H.248 MGW Application Signaling Transport Converter User Plane GCP Terminations Virtual Control Functions MGWs API Connection Coordinators Operation and API Maintenance User Plane Media Stream Media Framing Functions Function Function API API CPP Bearer Termination External Bearer Control Real-time Routing Switching Function Signalling Gateway Physical Interfaces Figure 4.7: M-MGW hardware structure. [33][41]replying the commands, administering the resources of the node, ordering connec-tions, selecting transport systems and controling stream functions. It is divided intothree subsystems: 1. Signaling Transport Converter. This subsystem handles the transport of H.248 between the M-MGW and the MGC (any Media Gateway Controller; i.e. MSC server, MGCF, etc) fulfilling the recommendation Q.2150 from ITU-T [61]. It provides: Independence from the transmission media, service’s availability reports, and transparency of the information transferred [91]. 2. GCP Termination. GCP stands for ”Gateway Control Protocol” and it is yet another name for H.248 (or MEGACO). The GCPT subsystem is decoding and encoding the H.248 message in binary mode, using the ASN.1 (Abstract Syntax Notation One) [64] and encoding applying the Basic Encoding Rules (BER) [63]. It also handles the H.248 messages by breaking them into M-MGW internal data and vice versa, checks the syntax of the messages and controls the timers implemented for the H.248. Load balancing between several Connection Coordinators (CCs) following the H.248 rules and load balancing algorithms is part of its functionality as well [91].
  41. 41. CHAPTER 4. MEDIA GATEWAY 28 3. Connection Coordinator. The Connection Coordinator is responsible for map- ping the H.248 view to the user plane view. In other words, the CC interprets the H.248 instructions and maps them into device reservations, connections, stream processing commands for the platform and event monitoring. The re- sources database is also updated by the CC to keep control of the hardware and software resources used in the different calls. Figure 4.8 illustrates an example call where the CC has implemented a chain of reserved functions for stream processing and transport adaptation. Logical View Resource Component Database Connection Coordinator Voice Echo ATM AAL2 IuFH Coder Canceller RTP UDP IP Media Framing Media Stream Media Framing Resource Component Connection Chain Figure 4.8: Connection model in the Connection Coordinator. [41]User Plane FunctionsThe User Plane Functions system can be divided into two parts: the media streamfunctions and the media frame functions. The media stream functions are relative tothe necessary media stream processing in the user plane. It can be a stream addition(tones, interactive messages, DTMF sender), stream modification (echo canceling,speech coders), media analysis (DTMF detector, tones detector) or data modula-tion (asynchronous non-transparent circuit switched data, etc). The media framefunctions does the work of adapting the media frames into the different transport
  42. 42. CHAPTER 4. MEDIA GATEWAY 29systems, by framing the media and fixing it into the adequate protocol stack forthe transmission. Basically, it packs and unpacks the media arriving as payload tothe node, facilitates the media stream processing if needed, and converts from onetransport system to another.Operation and Maintenance applicationThe O&M application allows the administration of the M-MGW node and the con-figuration of many of their parameters. It provides support for upgrades and resourceadministration, keeps logs and informs about the status of the node. It can be op-erated remotely or locally using a Graphical User Interface (GUI). A web browserusing a Java Virtual Machine (JVM) can access the GUI and the client can com-municate with the node by HTTP (Hypertext Transfer Protocol), IIOP (InternetInter-Object Request Broker Protocol) and FTP (File Transfer Protocol).
  43. 43. Chapter 5Control Protocol for MediaServers5.1 Multimedia Resource Function, Media Servers and Physical nodes ImplementationMedia Server is a term used by the industry for referring to the Multimedia Re-source Function as a physical node. The Media Servers could include several of thefunctionalities specified by 3GPP for the IMS logical nodes in one box and not onlythe MRF. Sometimes, the control part is totally split from the processing part, andsometimes is considered an integral part of it. The most common desired groupingsof functions are (see figure 5.1): ˆ MRFC-MRFP or MRF. Comprises the Media Resource Function in a physical node. The standardized communication interface in use by this node would be the Mr interface, which according to the specification 3GPP TS 23.228[14] uses the SIP protocol specified by IETF RFC 3261[86]. In this case, the Mp interface could be omitted, and one would use a proprietary interface to control the Media Resources available in the node. ˆ MRFC-MGC. Associating the MRFC with the MGC could be considered a good alternative in terms of stack reuse since both use H.248 to control their slaves nodes as masters. Also, some of the state machinery and the control logic have strong synergies, and there exists similar points in their functionalities (see 2.1). One of the strongest arguments that could affect this association is the difference in cardinality. Some experts believe that the cardinality between MRFC-MRFP is many-to-one, meanwhile, the MGC-MGW is one-to-many. 30
  44. 44. CHAPTER 5. CONTROL PROTOCOL FOR MEDIA SERVERS 31 This is a valid scenario if we compare with a CS-MGW to which every UE has to get a connection. There is then a need for many MGWs for reasons of capacity, load balancing and even geographic location for the user plane processing. Meanwhile only a MGC could be deployed to take care of the signaling. In the IMS case where the MRFP is expected to be used, there is not a need for each UE to access a MRFP. In this case, an architecture with a more centralized approach for a Media Processing Server is expected to be deployed, at least in the initial IMS phases. Also several ASs will expect to have access to control the MRFP resources to serve their clients. ˆ AS-MRFC. This kind of associations add an additional value to the previous point, where the AS is integrated and has direct access to the MRFP. Signaling reduction in the network, easier integration and clearer routing management are some of the advantages brought by this association. On the other hand, this kind of close architecture could represent a risk of inter-vendor compatibility and interworking, i.e, for other AS accessing the MRFP or interworking with the AS embedded in this entity. ˆ MRFP-MGW. The MGW and the MRFP have strong synergies in the media processing area. Integration studies have already been published for this asso- ciation [43] providing many arguments for the merging of the functionalities in one node. The control of both nodes is driven by H.248, and their associations with the masters is very similar. The merging of MRFC-CSCF means basically the addition of the MRFC func-tionality to the CSCF. The main concerns with respect to this type of associationare about the H.248 signaling that has to be generated to control the MRFP. TheCSCF and the MRFC deploy a SIP stack in their input interfaces, and the handlingof a H.248 stack for output might seem superfluous and therefore not practical. The idea of grouping the functions has caused discussion in the industry forums(i.e., 3GPP and IETF ) to look into alternative interfaces to control the MediaServers. The 3GPP specifications [14] locate the media resources per se in theMRFP, and define the Mp interface as the control interface from the MRFC. Despiteof this, the utility and feasibility of the Mp interface has been questioned by somemanufacturers and developers in several forums (IETF, ATIS, 3GPP, etc) and whitepapers (i.e. Convedia [27]and Brooktrout [20]). The main arguments for those claimsare: ˆ Increasing of the network complexity by using the master-slave relationship between MRFP and MRFC. The H.248 master-slave model forces the MFR
  45. 45. CHAPTER 5. CONTROL PROTOCOL FOR MEDIA SERVERS 32 AS AS CS Network CS Network CSCF CSCF BGCF BGCF HSS HSS MRFC MGCF SGW MRFC MGCF SGW Access Network Access Network MRFP MGW MRFP MGW UE Media Traffic UE Media Traffic Signalling Traffic Signalling Traffic AS CS Network CSCF BGCF HSS MRFC MGCF SGW Access Network MRFP MGW UE Media Traffic Signalling Traffic AS AS CS Network CS Network CSCF CSCF BGCF BGCF HSS HSS MRFC MGCF SGW MRFC MGCF SGW Access Network Access Network MRFP MGW MRFP MGW UE Media Traffic UE Media Traffic Signalling Traffic Signalling TrafficFigure 5.1: IMS Logical Nodes grouping used for the industry relative to the MediaServer
  46. 46. CHAPTER 5. CONTROL PROTOCOL FOR MEDIA SERVERS 33 split and limits the possibility of direct control from the Application Servers to the MRFPs. ˆ Lack of flexibility for the implementation of the media services. Low level con- trol and direct processing commands are specified in H.248’s packages, making the realization of services and application level resources more restricted. ˆ Development redundancies for the node commercial releases. The limited use of H.248 for 3GPP networks for the specific cases of MRFPs and MGWs repre- sents an extra effort for support and maintenance and a waste of opportunities to converge protocols used commonly in different standardized media networks, specifically in the case of SIP. The production of commercial nodes merging several capabilities and providing support for several network architectures is limited because of this aspect.
  47. 47. Chapter 6Media Server Control InterfaceCriteria6.1 MethodologyThe analysis of the protocols is based on the different scenarios implying the MRFCand the MRFP for IMS networks. As the aim of this thesis is to study the feasibilityof the implementation of the Mp interface for the M-MGW, the impacts that theprotocols have on the node are then considered as well. The scenarios are used to provide some of the basic requirements. At the sametime, these provide the evaluation parameters for the comparison of the protocols.The comparisons are done on a theoretical level, since some of the protocols are stillin draft stage or not fully standardized. The criteria used to evaluate the protocolsare based on: ˆ Network specifications and standards (3GPP, IETF, ITU) ˆ Articles and technical reports ˆ Test results when available These items provide the information to analyze the different aspects of the pro-tocols: 1. Functionality. Analyzes the different functions and services provided by the protocols. 2. Architecture specifics. Looks at the different configurations details and the environment setup necessary for the protocols to workt’, and also into the associated protocols and transport. 34
  48. 48. CHAPTER 6. MEDIA SERVER CONTROL INTERFACE CRITERIA 35 3. Performance. Evaluates different aspects inherent to this category: Bandwidth consumptions, delays, processing power needed, load variation and error han- dling. 4. Extensibility. Reviews the possible extensions to be used with the protocols to improve their capabilities and add functionality. 5. Scalability. Analyzes the handling of overload situations, connection associa- tions and deployment of several instances. 6. Security. Lists the security features of the protocol restricted by the security needs for the Mp interface. 7. Interoperability. Analyzes the possibility of deployment in several areas (other than the Mp interface), legacy and configuration compatibility. 8. Development. Presents the future trends and state of the protocols at this moment.6.2 EvaluationThe final result of the analysis is provided by the evaluation criteria. Even when it isdifficult to quantize the extent of the protocol’s commitment to every requirementfor the Mp interface and other analyzed aspects, several aspects can be defineddepending on the inherent characteristics. The aspects used for the study are: 1. Flexibility. It denotes the degree of adaptability for changing environments, different configurations or deployment extent. 2. Capacity. It ranges the capabilities measurement to equivalent categories for the protocols. 3. Reliability. It measures the reliability of the protocols for the different analyzed aspects. 4. Complexity. It evaluates the level of complexity for the implementation of each protocol and necessary setup arrangements to make it work. 5. Abstraction level. This measurement shows the rank of abstract concepts used by the commands in the protocols implementation. This gives an idea of the degrees of freedom for the implementation of the protocol’s commands by the handling applications.
  49. 49. CHAPTER 6. MEDIA SERVER CONTROL INTERFACE CRITERIA 366.3 Requirements6.3.1 3GPP RequirementsAccording to the last published stage of the TS.23.333 “Multimedia Resource Func-tion Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mpinterface: Procedures Descriptions” [9] at the moment of writing this text, the MFRfunction has been split into MRFC and MRFP and their tasks defined as follows: The tasks of the MRFC may consist of the following: ˆ Control the media stream resources in the MRFP. ˆ Interpret information coming from an AS and S-CSCF (e.g. session identifier) and control the MRFP accordingly. ˆ Generation of CDRs (Call Data Records). Tasks of the MRFP may consist of the following: ˆ Control of the bearer on the Mb reference point. ˆ Provide resources to be controlled by the MRFC. ˆ Mixing of incoming media streams (e.g. for multiple parties). ˆ Media stream source (e.g. for multimedia announcements). ˆ Media stream processing (e.g. audio transcoding, media analysis). ˆ Floor Control (i.e. manage access rights to shared resources in a conferencing environment). Also, the next functional requirements have been defined: ˆ Play Tones. The MRFP should be able to send specific tones upon request of the MRFC. It shall be able to play the tone, continuously until a stop request is sent or for a requested length of time. Also, it shall be able to send notifications and detect a DTMF with the possibility of triggering tones actions. ˆ Play Announcement. The announcements shall be played with the same re- quirements as the tones, with the addition that requests of predefined fixed announcements can also be received. Furthermore, several predefined vari- ables (such as date, time, currency, etc) could be provided by the MRFP in the announcement under request.