MSF VoLTE Interoperability Event Report

  • 2,890 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,890
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. MSF VoLTE Interoperability Event 2011Multivendor testing in global LTE& IMS NetworksBacked ByHost SitesGold SponsorsSilver Sponsors Page 1
  • 2. AbstractThis white paper provides a summary of the Voice over LTE (VoLTE) Interoperability2011 event which took place from September 12th – 30th, 2011. The event wasorganised by the Multi-Service Forum (MSF) and backed by the GSMA.The event builds on the major success of the previous MSF LTE InteroperabilityEvent that took place during March 2010 and reflects the industry’s drive to continueto deliver major carrier driven events that benefit all its members in their quest tokeep pace with an ever faster moving industry. The MSF VoLTE Interoperability 2011event validated key network interfaces to support multi-vendor deployment strategiesfor LTE/EPC/IMS technology. The main objective was to validate the work of theGSMA as part of its global VoLTE initiative, focusing on Voice over LTE includingRoaming and Interconnect, as specified in the GSMA’s technical recommendationsPRD IR.92 (“IMS Profile for Voice and SMS”), PRD IR.65 (“IMS Roaming andInterworking Guidelines”), and PRD IR.88 (“LTE Roaming Guidelines”).The GSMA technical recommendations are based on The Third GenerationPartnership Project (3GPP) standards. 3GPP introduced the Evolved Packet Core tosupport LTE access with the IMS core network providing the application layer forwhich services (e.g. voice) may be deployed. The EPC and IMS core interact withthe Policy and Charging Control (PCC) infrastructure to enable Quality of Service forthe bearers.The event was conducted in two host sites; the Vodafone Test and Innovation Centrein Düsseldorf, Germany and the China Mobile Research Institute Laboratory inBeijing, China.The event demonstrated that the GSMA technical recommendations, based on the3GPP specifications, for providing end to end VoLTE were mature and interoperable.However some specific interoperability issues were discovered and will beconsidered for recommending potential updates to specifications where appropriate.In some cases, backwards incompatibility was observed between implementations ofdifferent versions of 3GPP specifications. Implementations that were not fully-compliant to the 3GPP specifications were found. Finally, in some cases it wasdifficult to re-configure the network components when testing different multi-vendorconfigurations.It is important to identify and understand the factors that limit interoperability withcommercially available equipment, from both a Vendors perspective and anOperators perspective. Vendors benefit from identifying issues and improvingproducts to become more commercially viable, and Operators need to be aware ofany backwards incompatibility aspects to take into account for vendor selection anddeployment strategy.Events such as the MSF VoLTE Interoperability event highlight these issues andprove the validity of the MSF approach to achieving multi-vendor interoperability.It is worth noting that the re-configuration issue is mainly related to the test networkand the desire to test various different multi-vendor configurations. It is therefore notseen as a major issue for network deployments.Highlights of the event included:- Page 2
  • 3.  VoLTE calls were successfully completed within each host site (including MMTel services) as well as between the host sites to demonstrate network inter-connect. LTE Roaming between host sites was successfully demonstrated, utilizing dynamic policy control between home and visited networks employing DRAs (Diameter Routing Agents). Multi-vendor testing, a key component of all MSF IOT events, was conducted at each site, incorporating interworking between different vendors’ UE, eNodeB, Sec-GW, EPC, IMS, MMTEL AS, DRA and PCC technology. The IMS Soft Clients interworked successfully with the LTE data dongle for LTE Attach and additionally with the IMS Core Network and MMTel AS to provide IMS services to the end user. LTE Handover was successfully demonstrated with S1 and X2 based handovers performed. Security Gateways (Sec-GWs) were utilized in the test network to enable secure communications between the eNodeBs and the EPC network. Robustness Testing was completed to demonstrate robustness of network nodes at the IP-level for the S-GW and P-GW, as well as SIP/UDP robustness for P-CSCF and I-CSCF. The use of Diameter Routing Agents enabled the simplification of diameter routing within the PLMN. DRAs were also shown to provide interworking between different transport layer protocols. Page 3
  • 4. ContentsExecutive summary p. 6 The MultiService Forum (MSF) p. 6 The VoLTE Interoperability Event p. 6 VoLTE Architecture of the VoLTE Interoperability Event 2011 p. 6 Optimised VoLTE Architecture of VoLTE Interoperability Event 2011 p. 9 Key Objectives of the VoLTE Interoperability Event p. 12 Key Statistics p. 13 Key Results p. 13Introduction p. 15Part I: Participants and Planning p. 17 Host Sites p. 18 Vodafone p. 18 China Mobile p. 18 Vendor Participants p. 19 Observing Companies / Organisations p. 23Part II: LTE Interoperability Execution p. 24 The Network Test Scenarios p. 26 Test Scenario Validation p. 28 Testing infrastructure support p. 28Part III: Results and Issues p. 30 Future Work p. 34Appendix A: The Test Scenarios p. 35 Basic Interoperability p. 35 Security Gateway p. 39 Roaming & Interconnect p. 40 Handover p. 45 Robustness p. 46Appendix B: Interfaces Tested p. 52Appendix C: The Benefits of MSF Membership p. 54 Page 4
  • 5. Appendix D: Participants in the VoLTE Interoperability Event p. 55 Page 5
  • 6. Executive SummaryThe MultiService Forum (MSF)The MSF is a global association with a membership that includes the world’s leadingInternet Protocol (IP) communications companies. The MSF promotes the testing ofinteroperability based on open standards within a defined end-to-end architecture.The VoLTE Interoperability Event 2011The VoLTE Interoperability Event 2011 was designed to test standards complianceof Long Term Evolution (LTE) , Evolved Packet Core (EPC), and IMS networkscenarios in support of the provision of Voice over LTE (VoLTE). Such networkscenarios are of interest to major Service Providers, and the event is intended togauge standards maturity and vendor support for this technology. This event buildson the previous MSF LTE Interoperability Event which took place in March 2010 andprovided the first global “real network” multi-vendor trial of the Evolved Packet Coreinfrastructure. This event is backed by the GSMA and seeks to validate a number ofGSMA technical recommendations, namely:  PRD IR.65 - IMS Roaming and Interworking Guidelines,  PRD IR.88 - LTE Roaming Guidelines,  PRD IR.92 - IMS Profile for Voice and SMS.Interoperability testing was conducted in 2 labs; the Vodafone Test and InnovationCentre in Düsseldorf and the CMCC Research Lab in Beijing. The two labs wereinterconnected via a VPN. Conducting the tests in two interconnected labs made itpossible to test more vendor combinations, and also allowed realistic testing ofimportant roaming and interconnect scenarios.A total of 89 test cases were written across 4 test scenarios. The test scenarios wereas follows:  Basic Interoperability,  Roaming & Interconnect,  Handover,  Robustness testing.VoLTE Architecture of the VoLTE Interoperability Event 2011The VoLTE architecture allows users to connect to the network via the LTE high-speed wireless infrastructure and access voice services provided by a MultimediaTelephony (MMTel) Application Server on an IMS framework. This allows access tothe applications and services that todays sophisticated users demand, whileproviding the necessary Quality of Service management and mobility functions. Page 6
  • 7. The basic intra-PLMN VoLTE architecture is shown in the Figure below: IMS Core Ut Ut MMTel AS Sh I Cx S C S6a HSS P-CSCF Mw I/S-CSCF UE IMS UA Rx LTE-Uu MME PCRF UE S1-MME LTE-Uu S11 Gx IMS UA S1-U S-GW S5 P-GW SGi eNodeB Figure 1. Basic Intra-PLMN VoLTE Architecture NOTE: The Gm interface (UE to P-CSCF) is a focus for testing although not explicitly shown in the above figure.  UE (User Equipment). The User Equipment that is used to connect to the EPS, and is an LTE capable UE accessing EPC via the LTE-Uu radio interface.  eNodeB. The evolved RAN (E-UTRAN) consists of a single node, the eNodeB that interfaces with the UE. The eNodeB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Convergence Protocol (PDCP) layers that include the functionality of user- plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL QoS, cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packed headers.  MME (Mobility Management Entity). The Mobility Management Entity (MME) is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedures including retransmissions. It is involved in the bearer activation / deactivation process and is also responsible for choosing the S-GW (see below) for the UE at the initial attach and at time of intra-LTE handover involving Core Network node relocation. It is responsible for authenticating the user (in conjunction with the HSS). The NAS (Non-Access Stratum) signalling terminates at the MME which is also responsible for the generation and allocation of temporary identities to the UEs. The MME validates the permission of the UE to camp on the service provider’s PLMN (Public Land Mobile Network) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signalling and handles security key management. Lawful interception of signalling is also a function provided by the MME. The MME provides the control plane function for mobility between LTE and 2G/3G access networks and interfaces with the home HSS for roaming UEs. Page 7
  • 8.  S-GW (Serving Gateway). The S-GW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state UE, the S-GW terminates the DL data path and triggers paging when the DL data arrives for the UE. It manages and stores UE contexts and performs replication of the user traffic in case of lawful interception. It is likely that the S-GW and P-GW functions would be realized as a single network element. P-GW (Packet Data network Gateway). The P-GW provides connectivity between the UE and external packet data networks, it provides the entry and exit point of traffic for the UE. A UE may have simultaneous connectivity with more than one P-GW for accessing multiple Packet Data Networks. The P- GW performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening. The P-GW also acts as the anchor for mobility between 3GPP and non-3GPP technologies such as WiMAX or DSL. It is likely that the S-GW and P-GW functions would be realized as a single network element. PCRF (Policy Charging and Rules Function). The PCRF provides policy control decisions and flow based charging controls. The PCRF determines how a service data flow shall be treated in the enforcement function (P-GW in this case) and ensure that the user plane traffic mapping and treatment is in accordance with the user’s profile. HSS (Home Subscriber Server). The HSS is a network database that holds both static and dynamic data elements related to subscribers. The HSS provides user profile information to the MME during user authentication. P-CSCF (Proxy Call Session Control Function). The P-CSCF is the initial point of contact for session signaling for the IMS-enable VoLTE UE. The P- CSCF behaves as a SIP proxy by forwarding SIP messages the UE and the IMS Core Network, maintains the security associations between itself and the VoLTE UE, incorporates the Application Function aspect of PCC to enable binding of the IMS session with the bearer for applying dynamic policy and receiving notifications of bearer level events. I/S-CSCF (Interrogating/Serving Call Session Control Function). The I- CSCF is the contact point within an operators network for all connections destined to a user of that network. On IMS Registration, it interrogates the HSS to determine which suitable S-CSCF to route the request for registration. For Mobile Terminating calls, it interrogates the HSS to determine which S- CSCF the user is registered on. The S-CSCF provides session set-up, session tear-down, session control and routing functions. It generates records for billing purposes for all sessions under its control, and invokes applications using Application Servers. The S- CSCF acts as SIP registrar for VoLTE UEs that the HSS and I-CSCF assign to it. It queries the HSS for the applicable subscriber profiles and handles calls involving these end points once they have been registered. The S-CSCF uses subscription information to determine the appropriate onward routing for calls originating through it. Page 8
  • 9.  MMTel AS (Multimedia Telephony Application Server). The MMTel AS is an IMS Application Server providing support for multimedia telephony services as defined by 3GPP e.g. supplementary service functionality.Optimised VoLTE Architecture of VoLTE Interoperability Event 2011In addition to the above VoLTE Architecture, functions that secure communicationsbetween access and core network and functions that optimise the routing ofDiameter messages were included in the test scenarios. These are discussed indetail below.Diameter RoutingLTE and IMS networks require the exchange of information among network elementsfor each subscriber data, voice, video, IM or other type of SIP session. Morespecifically, subscriber and session authentication, authorization, location, chargingand quality of service (QoS) information must be exchanged among HSS, PCRF,MME, CSCF and other elements within a single service provider’s network. Thisinformation must also be exchanged between visited and home networks for roamingsubscribers. Diameter is the IP signalling protocol that supports this policyinformation exchange in all-IP networks.The Diameter Routing Agent defined by 3GPP and GSMA, is a new network elementthat controls Diameter signalling, enabling the seamless communication and controlof information between network elements within LTE or IMS networks and acrossLTE network borders. A DRA reduces the mesh of Diameter connections thatnegatively impacts network performance, capacity and management.As LTE networks grow with new elements, the resulting provisioning and routingupdates in a very interconnected network element, is costly in two dimensions: itincreases OPEX and it slows down growth. DRAs are needed to:  Reduce processing load on Diameter elements from having to handle too many SCTP and TCP transport layer connections  Distribute and load balance traffic to effectively use existing Diameter agent capacity  Prevent element overload and service interruption  Simplify the provisioning and troubleshooting of connectivity between core Diameter elements  Enforce business logic through AVP-driven routing as well as manipulation of Diameter AVPs  Interwork transport protocols and IP version between core Diameter elements  Ensure seamless interworking among Diameter interfaces at the transport and application layers.  Provide security mechanisms at the network edge by utilising IPSec encryption, Denial-of-Service protection, Network topology hiding, etc. Page 9
  • 10. Security in LTE NetworksLTE has been developed from an architectural point of view as well as industry de-facto deployments to run over Next Generation Networks: All-IP transport capabilitybuilt on the Internet Protocol family of standards and giving rise to separate domainsof security when implementing end-end networks. Domain A MME AAA / HSS NMS S-GW EPC S-GW Backhaul/Transport Network P-GW S-GW Domain B Domain C Figure 2. Architecture Domains of Security in a typical LTE deploymentUnlike previous technologies such as Circuit-Switched PDH/SDH and Packet-Switched ATM transport networks, IP protocols in their own right do not authenticatecustomer premises or remote site equipment (such as Base Stations) with their corenetwork components, and vice-versa, in the same way that SS7 did and so this givesrise to potential security threats such as "man in the middle" and denial of serviceattacks. In particular, but not exclusively, such attacks to the control/signaling andoperations and maintenance planes can have disastrous impact on network stability,not to mention exploit fraud opportunities.As an additional requirement, very often LTE network providers will need to procurebackhaul connectivity from Base Station sites, Femto & Pico Cells from 3rd-partyproviders and would wish to secure the data (signaling, O&M and data plane) fromsnooping or interception which could be used for gathering intelligence for exampleon traffic volumes and transactions being processed.A Security Gateway (Sec-GW) acts as the “Inter Domain Police” between each of thedomains of security: The RAN, the backhaul and the EPC. For non-Trustedintegration to the EPC, the Sec-GW can also protect other access networks such asWi-Fi and is capable of delivering the following functions:  Network attachment authentication and authorization from site equipment  Separation and specific QoS treatment of the different planes within LTE , namely S1-MME (signaling and control), Operations and Maintenance, S1-U (data) and X2 (handover)  Aggregation function for eNodeB, Pico and Femto Cells requirement the same security functions (authentication, authorization)  Encryption of sensitive data and control planes, e.g. S1-MME and O&MThe Sec-GW is used to originate and terminate secure associations between thosecomponents that are “under threat” or where security risks exist. IPsec tunnels are Page 10
  • 11. established both inside the home network (Zb) and between home and visitednetworks (Za) with pre-shared security keys, which can take a number of differentformats. 3GPP TS 33.210 mandates that the IPsec tunnels enforce traffic encryption,for added protection, according to the parameters exchanged between the twoparties during tunnel setup.For the home network it is envisaged that the security gateway will be used to secureS1-MME, S1-U and X2 interfaces to the eNodeB.An EPC Core is typically owned by an individual mobile operator and therefore isconsidered secure. Similarly the LTE air interface is encrypted (secure) between theUser Equipment and an eNodeB. Across the LTE access backhaul networkencryption of Network Access Stratum (NAS) signalling is performed between theUser Equipment (UE) and the MME. This maintains the security of NAS signallingbetween the UE and the EPC core. However, encryption of user data from the UE isterminated at the eNodeB. This obviously presents a security risk for user-plane databetween the Serving Gateway (S-GW) deployed in a secure site and the remoteeNodeBs. Figure 3. Identifying the Security Risk in LTE NetworkUn-encrypted user data is subject to being tapped or "sniffed" within an open /shared backhaul network, as well as at the eNodeB interface (particularly inphysically unsecured deployments such as in-building eNodeBs), therefore there is apotential for cyber-attacks, such as Denial of Service, on eNodeBs and S-GWs (e.g.from a device placed at the eNodeB site or within the access backhaul sitemasquerading as an eNodeB or S-GW). Page 11
  • 12. Optimised VoLTE ArchitectureThe Figure below shows the optimised intra-PLMN VoLTE Architecture incorporatingSec-GW and DRA technology. IMS Core Ut Ut MMTel AS Sh I Cx S C HSS Cx P-CSCF Mw I/S-CSCF Sh Rx S6a DRA UE S6a Rx IMS UA Gx PCRF LTE-Uu Gx MME UE S1-MME LTE-Uu Sec- S11 IMS UA GW S1-U eNodeB S-GW S5 P-GW SGi Figure 4. Optimised Intra-PLMN VoLTE Architecture NOTE: The Gm interface (UE to P-CSCF) is a focus for testing although not explicitly shown in the above figure.Key Objectives of the VoLTE Interoperability Event 2011It is vital that operators have confidence in the multi-vendor interoperability of EPCand IMS components as a solid basis for VoLTE before volume deployment canbegin. Demonstrating this capability in action was a key overarching objective of theVoLTE Interoperability Event 2011. The following equipment types (and associatedvendor instances) participated in the event:  In Germany, the equipment types included UE (3), eNodeB (2), MME (5), S- GW (5), P-GW (5) , PCRF (5), HSS (4), IMS Core (4), MMTel AS (3), P- CSCF (6), DRA (4), IBCF (4) and Security GW (1).  In China, the equipment types included UE (2), eNodeB (1), MME (1), S-GW (2), P-GW (2), PCRF (1), HSS (1), IMS Core (1), MMTel AS (1), P-CSCF (1), DRA (1) and IBCF (1).In addition, the VoLTE Interoperability Event 2011 was designed to:  Validate the maturity of EPC network interfaces to enable multi-vendor support.  Demonstrate that an EPC network can manage session control with an applied Quality of Service for default and dedicated bearers. Page 12
  • 13.  Validate the maturity of IMS network interfaces to enable multi-vendor support,  Demonstrate the support for user roaming between different networks.  Validate VoLTE and MMTel services for both home registered and roaming UEs,  Validate VoLTE and MMTel services over an interconnect between IMS networks,  Demonstrate the LTE Handover capability  Demonstrate the Robustness capability of EPC network nodesKey StatisticsThe VoLTE Interoperability Event 2011 was held from September 12th – 30th, 2011,at two major Service Providers labs; China Mobile Research Institute Laboratory inBeijing, China and Vodafone Test and Innovation Centre in Düsseldorf, Germany.Over 65 network components from 19 participating vendors were tested by 60 testengineers using approximately 200 pages of test plans during this 15-day event.The test scenarios incorporated a total of 89 test cases. Taking account of differentvendor combinations, the 89 test cases resulted in a total of 561 scheduled testsbeing defined. Of the 561 defined tests, a total of 204 were executed of which 163tests were successfully completed and 41 failed. In those cases where defined testswere not run, it was due to a combination of lab configuration limitations, equipmentlimitations or lack of time. Appendix A gives a detailed summary of the test results.Key Results  VoLTE calls and supplementary services, based on GSMA recommendations, are a viable solution for providing voice services for LTE access, including for Roaming and Interconnect scenarios.  This test event showed basic interoperability between the different nodes in a multi-vendor configuration.  The IMS Soft Clients interworked successfully with the LTE data dongle for LTE Attach and additionally with the IMS Core Network and MMTel AS to provide IMS services to the end user.  Interaction with service layer (IMS and MMTel AS) was successfully demonstrated, with binding of Quality of Service to EPC bearers utilising Policy and Charging Control (PCC), providing relevant QoS for signalling and voice on the default bearer and dedicated bearers respectively.  Diameter routing within the PLMN was greatly simplified by utilizing Diameter Routing Agents. DRAs were also shown to provide interworking between different transport layer protocols. Diameter Roaming interfaces S6a and S9 were routed successfully across the network interconnect via Diameter Routing Agents.  IPSec security between eNodeB and MME/S-GW can be achieved utilizing a Sec-GW with complete transparency to signaling and media and no impact to other network elements. Page 13
  • 14.  GTP protocol and S9 protocol proved to be mature and stable with no issues identified. The event showed that implementations based on different versions of the 3GPP Release 8 specifications are not fully interoperable, as there are backward incompatible protocol versions (observed for Gx and Rx interfaces) By using a commercial layer2 and above traffic capture and monitoring system with multiple connections points in to the System Under Test (SUT), the End2End packet path of the testing was greatly enhanced by capturing the path of packets through various Network Elements (NE’s) such that packets from various parts of the system could be analysed by the commercial test tools – thus greatly aiding the interoperability effort as well as results analysis after the completion of the event. The commercial test tools used provided uncompromising visibility to all End to End procedures allowing rapid analysis and the ability to test the robustness of the various networks nodes. Page 14
  • 15. IntroductionThe VoLTE Interoperability Event 2011 test environment was based on: 1. Proving multivendor interoperability of Evolved Packet Core network nodes; 2. QoS control as an essential underpinning for services using PCC architecture and binding to the application layer in IMS; 3. Proving multivendor interoperability between IMS network nodes; 4. Proving VoLTE, including MMTel services via EPC and IMS, including interaction with the PCC architecture; 5. Roaming between EPC capable networks, including proving VoLTE and MMTel services for the roaming UE, 6. Proving VoLTE, including MMTel services, via the interconnect between IMS networks, 7. Intra-LTE Handover. 8. Robustness testing of EPC network nodes;Publishing the results of the VoLTE Interoperability Event 2011 provides valuablefeedback to the industry as a whole. Based on tests carried out in real worldnetworked scenarios, specific feedback was also provided to the StandardsDevelopment Organization (SDO) community and to GSMA. Figure 5. The results from the testing and interoperability programs are fed back to the relevant standards bodies, i.e. there is a virtual circle.The key relationship between the MSF and relevant standards bodies is illustrated inFigure 5. As can be seen, there is a virtuous circle between testing based on theMSF architectural framework and IA’s, and the feedback provided to the SDOs.This white paper is organized into three parts and four appendices. In Part I, theplanning that went into the VoLTE Interoperability Event 2011 is discussed. Part IIdiscusses the three-week event, while Part III discusses the key results obtainedfrom the VoLTE Interoperability 2011 Event. Page 15
  • 16. Appendix A provides more details on the test scenarios; Appendix B highlights theinterfaces that were tested, Appendix C discusses the benefits of MSF membershipand Appendix D provides a brief resume of the participating companies. Page 16
  • 17. Part I: Participants and PlanningThe VoLTE Interoperability Event 2011 involved a diverse group of IPcommunications professionals whose common goal was to test the currentcapabilities of LTE and EPC products operating in real world Service Providerenvironments. In particular, the event focussed on Voice over LTE (VoLTE) via3GPP LTE/EPC technology based on GSMA technical recommendations, whichwere endorsed by the MSF. The MSF developed a number of testing scenarios tovalidate core network interfaces in multi-vendor deployment scenarios for VoLTE.This testing allows vendors to improve their products, Service Providers to acceleratetheir service deployment strategies, and the MSF to identify standards shortfalls tothe appropriate SDOs.A three-week test event involving two inter-networked lab sites, 19 vendors, over 60participants, 65 network components and 200+ pages of test plans requires carefulplanning. A committee of 5 people, along with numerous volunteers, spent over 12months preparing for the event.Planning for the VoLTE Interoperability Event 2011 began in September 2010 byidentifying scenarios and tests for the event. The scope of the event is defined in theTesting Scenarios document MSF- VoLTE-SCN-001-FINAL which is publiclyavailable at http://www.msforum.org/techinfo/approved.shtml. A total of 5 scenarioswere initially defined covering VoLTE, Roaming & Interconnect, non-LTE access toEPC, Handover and 3GPP Self-Organising Networks (SON). Each of the 5 mainscenarios included a number of sub-scenarios. A sixth scenario was subsequentlyadded to cover robustness testing. Test plans were developed for the majority of theidentified sub-scenarios. During event planning, it became clear that commercialequipment was unlikely to be available with the functionality required for all testscenarios. Effort was thus focussed on the highest priority tests, and in some casesit was decided to postpone the writing of some test cases. This White Paper willtherefore only detail the test scenarios that were executed during the VoLTEInteroperability Event 2011.Inter-lab testing was a key objective of the VoLTE Interoperability Event 2011 withtesting focussing on tests where inter-lab connectivity reflected real worlddeployment scenarios (i.e. roaming and interconnect). In addition, the initial activityfocused on testing permutations of vendor-provided EPC technology within each lab.Given the complexity of the event and to help prioritize demand, the VoLTE PlanningCommittee developed a test schedule to maximise inter-vendor testing and vendorparticipation for all sessions. In particular, due to the large amount of equipment inthe Vodafone site, it was decided to split the equipment between two logical siteswhich enabled parallel testing sessions at the Vodafone site as well as runningroaming and interconnect tests between the two logical sites. Access to both theSUT and the NE’s was provided by VSS Monitoring’s intelligent tap solutions. Thiswas facilitated with multiple connection points in to the network itself and on both theingress and egress ports of several key functional nodes. Trace analysis and testequipment supplied by JDSU and EXFO received the monitored traffic flow from theintelligent taps and provided insight and analysis in to the operation of the networkand the underlying interoperability of the actual NE’s themselves. HP Quality Centretool was employed as the results recording tool. Page 17
  • 18. Test planning, host site selection, preparation and network interconnectivity allneeded to be completed before the start of testing. Regular VoLTE PlanningCommittee meetings were held and vendor participation calls kept the participantsinformed of the preparation progress and their needed inputs and activities.Preparation activities peaked two weeks before the VoLTE Interoperability Event2011 started, as participant engineers arrived at the host sites to ensure that thecomponents were installed so that testing could commence on time. The two weekset up period also encompassed a level of pre-testing, whereby connectivity andconfiguration between vendors equipment was performed.Host SitesVodafone and CMCC provided host sites in Germany and China respectively,thereby allowing the various tests and scenarios to be deployed in an environmentthat replicates a live global network. Testing was structured to enable both intra-siteand inter-site testing and a test schedule was devised to enable structured testing tobe performed at each site as well as co-ordinating activity between the two sites forthe roaming and interconnect scenarios.The two host sites were:-Vodafone provided the host site at the Test and Innovation Centre in Düsseldorf,Germany. The availability of the other site in China provided the opportunity for theVoLTE Interoperability Event 2011 to prove "real-life" roaming and interconnectscenarios. In addition, due to the amount of equipment in the Düsseldorf lab, it wasdecided to partition the lab into two logical labs and split the equipment between thetwo logical labs.China Mobile provided the host site at the CMCC Research Lab in Beijing, China.The VoLTE Interoperability Event 2011 allowed China Mobile to establish a testnetwork with the other host-site and establish ”real-life” roaming and interconnectscenarios. Page 18
  • 19. Vendor ParticipantsNineteen vendor companies participated in the VoLTE Interoperability Event 2011The network equipment vendors were: Page 19
  • 20. The Network protocol and call-flow analysis test equipment vendors were:-The Robustness testing equipment was provided by:The Test environment infrastructure & Traffic monitoring equipment was provided by:Tables 1 and 2 show the components provided by the vendor participants at theDüsseldorf and Beijing sites respectively. Page 20
  • 21. Vendor LTE eNodeB Sec MME S- P-GW PCRF HSS P-CSCF IMS MMTel DRA IBCF Test UE GW GW Core AS EqptALU X X X XAcme Packet X X XAlepo X XAmdocs X X(Bridgewater)Cisco X X X X XCodenomicon XD2 Tech XExfo XGenband X XHuawei X X X X XJDSU XIPneo XMetaswitch X XSamsung X X X X X XStoke XTellabs X X XTraffix XZTE X X X X X X X X X X X Table 1. The VoLTE Interoperability vendor participants in the Vodafone host-site in Düsseldorf, Germany. Page 21
  • 22. Vendor LTE eNodeB MME S- P-GW PCRF HSS P-CSCF IMS MMTel DRA IBCF Test UE GW Core AS EqptALU X X X X X XAcme Packet X X XCMCC X X XD2 Tech XJDSU XTellabs X XNote:- The elements tagged in tagged as “CMCC” are other vendor elements already in the CMCC lab and which are beingused in the VoLTE IOT event. Table 2. The VoLTE Interoperability vendor participants in the China Mobile host-site in Beijing, China.. Page 22
  • 23. Observing Companies / OrganizationsMSF rules permit non-vendor companies to attend its interoperability events asobservers. For the VoLTE Interoperability Event 2011, invitations were extended toMSF non-vendor members, GSMA members and partner fora/organizations. Thefollowing companies/organisations attended the VoLTE Interoperability Event 2011as observers:- Page 23
  • 24. Part II: The VoLTE Interoperability Event 2011 ExecutionThe VoLTE Interoperability Event 2011 involved two major Service Providers, onebased in China, and the other in Europe. The test scenarios involved the connectionof the host labs via an IP Security (IPSec) Virtual Private Network (VPN). The IPSecVPN tunnel was established and maintained to provide full connectivity between thetwo sites for the duration of testing. The previous successful LTE InteroperabilityEvent had used IPSec VPN tunnels and thus the same technique was selected forthe VoLTE IOT 2011 event.The use of a flexible VPN also allowed each site to give participating vendors remoteaccess to their equipment during the event. This was an important capability becauseit allowed vendors to complement onsite staff with personnel at home locations. Theability to support secure access from remote locations enhances flexibility andreduces cost for vendors.Figure 6 presents a high-level diagram of the test environment used for the VodafoneDüsseldorf host-site. Page 24
  • 25. MME ZTE 10.3.1.6/ MMTel AS MMTel AS MMTel AS MMTel AS S11 10.3.2.6 HSS ZTE Genband Huawei Samsung Cx 10.3.1.1/ S10 ZTE Sh 10.3.2.1 S6a MME Sh S6a S1-MME CISCO Sh Sh S6a ISC IBCF-DUS HSS ISC ISC ISC GEN, HUA, S6a Sh Huawei Cx ISC ACME, MME S11 ISC S1-MME META Tellabs Cx S10 S6a S1-MME I/S-CSCF I/S-CSCF I/S-CSCF I/S-CSCF S11 HSS Sh Mx CxeNodeB (1) S6a CISCO ZTE Huawei Samsung S1-MME MME ALU S6a Amdocs Cx ZTE Mx Cx Mw Mw Mw Mw MME Sh S1-MME Samsung Diameter Sh P-CSCF P-CSCF P-CSCF P-CSCF P-CSCF S6a Agent NNIIci/Izi Rx ZTE Huawei ACME CISCO Samsung Rx 0 Mw p= S9 Mw Ap S1-MME/S1AP SGi SGi SGi Rx Rx Rx Rx To Gx Rx S1-U Beijing SGi Gx Rx RxeNodeB (2) Sec-GW SGi S9 S5 PCRF P-CSCF ZTE Stoke S-GW ZTE S5 P-GW ZTE Gx Rx S11 ZTE Metaswitch S1-U Gx IBCF X2 Beijing S11 S1-U SGI PCRF Rx S-GW P-GW Gx S5 Gx Alepo CISCO S5 CISCO S9eNodeB (3) Samsung GX S1-U S-GW S5 P-GW SGi Gx PCRF Rx S5 Amdocs Tellabs Tellabs S9 S11 S11 SGieNodeB (4) PCRF Rx S-GW ALU S5 P-GW ALU Gx Samsung S1-U S5 Gx ALU S9 S1-U S11 S-GW S5 P-GW S5 SGi Samsung Samsung Gx Figure 6. Test environment used for the Vodafone Düsseldorf host-site Page 25
  • 26. Figure 7 presents a high-level diagram of the test environment used for the China Mobile, Beijing host-site. HSS IMS Core/MMTel AS ALU S6a Mw P-CSCF/SBC/IBCF Acme S6a Rx Mw MME ALU PCRF S9 ALU S1 CP S6a Gx DRA SGi Acme eNB ALUTD-LTE data card S11 SGi IP VPN+ D2Tech IMS UA P-GW IP VPN Tunnel S1 UP ALU S-GW P-GW Tunnel ALU Tellabs Note: IMS client is S5 connected to TD -LTE S8 data card via WiFi AP, therefore a NAT is S-GW sitting between IMS Tellabs client and P-CSCF Figure 7. Test environment used for the China Mobile Beijing host-site The Network Test Scenarios Figure 8 is a high-level view of the EPC framework. The EPC network provides capabilities to attach multiple access technologies into a single core network infrastructure. These include LTE, legacy wireless access technologies (2G/3G), non-3GPP wireless access and fixed access. The common infrastructure provides a converged way to access a common service layer (e.g. Internet, IMS) and apply a consistent method of Quality of Service management and mobility management. Page 26
  • 27. IMS Internet SC MM Evolved Packet Policy Core Evolved 3GPP Packet AAA .. Legacy Core System ... Non 3GPP Access .. E-UTRAN System Figure 8. The Evolved Packet CoreThe Evolved Packet Core can be accessed using all mainstream wireline andwireless access technologies, for connection to the application/service layer (e.g.IMS, Internet). This high-level architecture formed the basis of the scenarios for the VoLTE Interoperability Event 2011. These scenarios were:  Basic Interoperability: o VoLTE (Attachment/Detachment of an LTE capable UE to the Evolved Packet Core via an eNodeB and creation/deletion of a default bearer with related Quality of Service applied utilising PCC architecture, IMS Registration, IMS Session establishment and teardown utilising a dedicated bearer with related Quality of Service applied utilising PCC architecture and MMTel Service Configuration and usage).  Roaming & Interconnect: o Roaming with Local Breakout in visited network (Visited P-CSCF) incorporating Attachment/Detachment of an LTE capable UE, IMS Registration, IMS Session establishment and teardown and MMTel Service Configuration and usage). o Interconnect between two UEs in their respective home PLMNs incorporating IMS Session establishment and teardown and MMTel Service usage. Page 27
  • 28.  Handover: o S1 and X2 based Handover between eNodeBs.  Robustness: o Core network traffic between S-GW, P-GW and IMS Core Network nodes. These scenarios are discussed in more detail in Appendix A.Test scenario validationJDSUThe JDSU Signalling Analyzer solution, in a multi-user setup, was used to validatethe completed test scenarios at both the Vodafone and China Mobile sites. Thismulti-user setup provided the participants of the Interoperability Event a real-time endto end view of the test scenarios as they were being executed.The Signalling Analyzer provides support for the requirements outlined in GSMAIR.92 specifications for delivering Voice services over LTE (VoLTE).The Signalling Analyzer provided a number of key capabilities:- End to End EPC and IMS Core Network Sub-System Visibility Real-Time Multiple Interface end to end Call Session Correlation and Measurements Real-time control-plane and user-plane correlation Access to common data source (probe) with the ability to perform independent functions/operations LTE/SAE security - EPS real time NAS Encryption deciphering Generic file sharing of the test scenarios results (both in JDSU proprietary format and Wireshark .pcap format)The Signalling Analyzer supports an extensive set of LTE/EPC/2G/3G/IMS CNinterfaces and is able to validate the outcome of each test case in real-time. After thevalidation of each individual test scenario the trace file was saved for possible futurereference and traceability.EXFOThe EXFO solution was used to validate the completed test scenarios at theVodafone site.Testing infrastructure supportVSS MonitoringVSS Monitoring provided the Distributed Traffic Capture System as a traffic capturemonitoring system. All packets generated during the event passed through the VSSMonitoring equipment and could then be passed on as appropriate to other elements(including the signalling analyser test tools). In this way, all traffic was properlysegregated and all participants protected from having their packets snooped by otherparticipants to whom there was no direct information exchange. Page 28
  • 29. Figure 9. Monitoring system showing various connection points to the test networkVSS Monitoring also has the capability to provide the Test Acceleration Systemwhich enables the interoperability test equipment to be connected to the VSSMonitoring equipment. The introduction of the TAS would mean one pass at thephysical cabling and the test network configuration. The re-configuration to providethe myriad of different combinations of network element setups, is realised bysoftware configuration of the tool rather than having to physically re-cable and re-configure the complex network settings. Figure 10. Example of how TAS could be deployed to speed up testing Page 29
  • 30. Part III: Results and IssuesThe event demonstrated that the GSMA technical recommendations, based on the3GPP specifications, for providing end to end VoLTE were mature and interoperable.The event proved that VoLTE is a viable solution for providing voice services overLTE access technology, and can be deployed with roaming and interconnectfunctionality to provide equivalent service as CS-based voice services today.Utilisation of Diameter Routing Agents provided optimisation of diameter routingwithin the core network and across the interconnect between network operators.The inclusion of a Security Gateway provided a mechanism for securecommunications between the eNodeB and Evolved Packet Core network withtransparency for signalling and media.However some issues were discovered and feedback may be provided to therelevant standards organizations where appropriate. In some cases, backwardsincompatibility was encountered between implementations of different versions of3GPP specifications (specifically Gx and Rx interfaces). Problems were alsoencountered with implementations that were not fully-compliant to the 3GPPspecifications. Finally, in some cases it was difficult to re-configure the networkcomponents when testing different multi-vendor configurations.The extensibility mechanism standardised by 3GPP for the Diameter-basedinterfaces has been utilised to provide a level of granularity only per 3GPP Releasefor the Gx and Rx interfaces. This reduces the level of interoperability ofimplementations that use different versions within the same 3GPP Release.Implementations should implement all mandatory aspects of protocol interfaces inorder to achieve full-compliancy and achieve maximum interoperability.The re-configuration issue is mainly related to the test network and the requirementto test numerous different multi-vendor configurations, so it is not seen as a majorissue for network deployments. While it may not be an issue once a network isoperational and stabilized, it is however an issue during long cycle of testing andinitial roll-out which justify the need for some interworking capabilities both atsignaling (SIP/Diameter) and transport layers to ease those processes.Though essential standards are reasonably mature, Service Providers will need totake care to clearly specify which version of the Release 8 specifications they aredeploying. Events such as the MSF LTE Interoperability event highlight suchdifficulties and prove the validity of the MSF approach to achieving multi-vendorinteroperability.It is anticipated that backwards compatibility issues will be resolved as all nodes andinterfaces are aligned to the 3GPP Release 9 and will be backwards compatible withthis baseline release. The accuracy of this claim may be validated at subsequentInteroperability events.Basic Interoperability:In this scenario, intra-network testing utilised a single VoLTE architecture createdusing components from different vendors. Testing included LTE attachment anddetachment from the network, SIP registration (to IMS), SIP session establishment, Page 30
  • 31. SIP session teardown, MMTel Service Configuration across the Ut interface, andMMTel Service usage as specified by GSMA IR.92.This test scenario demonstrated that VoLTE calls and supplementary services,based on GSMA IR.92, are a viable solution for providing voice services for LTEaccess. Testing consisting of equipment from different infrastructure vendors workedproperly over the applicable 3GPP standardized interfaces.It was shown that the IMS Soft Clients interworked successfully with the LTE datadongles for LTE Attach and additionally with the IMS Core Network and MMTel AS toprovide IMS services to the end user.Diameter routing within the PLMN was greatly simplified by utilizing DiameterRouting Agents. DRAs were also shown to provide interworking between differenttransport layer protocols.IPSec security between eNodeB and MME/S-GW can be achieved utilizing a Sec-GW with complete transparency to signaling and media and no impact to othernetwork elements.Although basic interoperability was achieved, it was noted that implementationsbased on different versions of the Rel-8 Rx and Gx interfaces are not backwardscompatible. Some implementations were discovered not to be fully compliant to3GPP specifications, with missing mandatory functionality on various interfaces.Appendix A provides more details on the test results.Roaming & Interconnect:The Roaming test scenario represents the test architecture where two subscribers, ofthe same Operator, perform an end to end call whilst one subscriber is in the HPLMNand the other is roaming in a VPLMN. The roaming subscriber attaches in the visitednetwork where local breakout is applied, a Visited P-CSCF and home IMS servicesas defined in GSMA IR.65 and IR.88.The Interconnect test scenario is where two subscribers, of different operators,perform an end to end call whilst in their respective PLMNs as defined in GSMAIR.65.RoamingThis test scenario was designed as an inter-site test with the subscriber roaming in avisited network. The LTE UE, eNodeB, MME, SGW, PGW and V-PCRF werephysically in the visited network whilst the H-PCRF and HSS were physically locatedin the Home Network. Whilst the IMS Core was configured in the home network, theP-CSCF was configured in the Visited Network. This roaming model aligns withGSMA specifications IR.65 and IR.88.The focus of these tests was to verify the roaming interfaces between the H-PLMNand V-PLMN required for roaming with VoLTE. Specifically the utilisation of aDiameter Routing Agent for routing Diameter messages between the MME in thevisited network and the HSS in the home network with S6a and between the visitedPCRF to home PCRF interaction across the S9 interface. Additional roamingaspects are the PCC interaction in the visited network (Rx and Gx interfaces) and theSIP interconnect between the P-CSCF in the visited network to the Session BorderController in the home network. Page 31
  • 32. This scenario tests LTE attachment and detachment of the visiting UE as well as IMSregistration, IMS session establishment & teardown MMTel Service Configuration,and MMTel Service usage; as specified in GSMA IR.92, IR.65 and IR.88.This test scenario demonstrated that the VoLTE architecture is a viable solution forproviding voice services for LTE access for a user whilst in a roaming network. Thetesting consisted of equipment from different infrastructure vendors, and workedproperly over the applicable 3GPP standardized interfaces.The Diameter Roaming interfaces of S6a and S9 were routed successfully across thenetwork interconnect via Diameter Routing Agents. It was shown that the S9interface proved to be mature and stable for installing PCC and QoS rules.IMS Registration was successful when the user was roaming validating theconnectivity of a roaming UE to a home IMS Core Network (via a P-CSCF in a visitednetwork to an SBC in the home network).Although basic interoperability was achieved, it was noted that someimplementations were discovered not to be fully compliant to 3GPP specifications,with missing mandatory functionality on various interfaces.Appendix A provides more details on the test results.InterconnectThis test scenario tests IMS session establishment, IMS session teardown plusMMTel Service Configuration, and MMTel Service usage for LTE UEs registered intheir respective home PLMNs and interacting across the Ici/Izi reference points.Compliance against GSMA PRD IR.65 was tested.This test scenario demonstrated that the VoLTE architecture is a viable solution forproviding voice services for LTE access between users on different PLMNs. Thetesting consisted of equipment from different infrastructure vendors, and workedproperly over the applicable 3GPP standardized interfaces.Although basic interoperability was achieved, it was noted that someimplementations were limited in how they performed the routing of SIP messages,i.e. based on IP Address only rather than IP Address and port number.Appendix A provides more details on the test results.Handover:This test scenario was designed to validate the different handover cases. Theprimary focus included Intra-Radio Access Technology handover for LTE; includingS1-based handover, X2-based handover, and MME/SGW relocation.The focus of testing for this scenario was to demonstrate handover between LTEaccess (S1-based, X2-based, MME/SGW Relocation).X2-based handover tests were successfully executed with a level of basicinteroperability achieved.S1-based Handover and SGW/MME relocation were successfully executed with alevel of basic interoperability achieved.SGW/MME Relocation could not be tested due to only one MME being available andtherefore MME Relocation could not be performed. Page 32
  • 33. Appendix A provides more details on the test results.Robustness:Robustness testing is based on the systematic creation of a very large number ofprotocol messages (tens or hundreds of thousands) that contain exceptionalelements simulating malicious attacks. This method provides a proactive way ofassessing software robustness, which, in turn, is defined as "the ability of software totolerate exceptional input and stressful environment conditions". A piece of softwarewhich is not robust fails when facing such circumstances. A malicious intruder cantake advantage of robustness shortcomings to compromise the system running thesoftware. In fact, a large portion of the information security vulnerabilities reported inpublic are caused by robustness weaknesses. Robustness problems can beexploited, for example, by intruders seeking to cause a denial-of-service condition byfeeding maliciously formatted inputs into the vulnerable component. Certain types ofrobustness flaws (e.g., common buffer overflows) can also be exploited to runexternally supplied code on the vulnerable component.The following robustness testing was performed during the event:-  Robustness testing for core network traffic between S-GW, P-GW and IMS Core Network nodes.The objective was to test the robustness of the LTE and IMS core network order toensure that the Core network is robust against malformed traffic sent bymalfunctioning or badly interoperating Core elements or UEs. Malfunctioning Coreelements could send anomalous data to other surrounding elements, affecting overallnetwork stability. The goal is that the LTE and IMS network can handle anomaloustraffic that is sent intentionally or unintentionally by other elements.The S-GW testing was done with IPv4 robustness testing of the IP implementationwithin the module. The expectation of this test was a very clean result with no majorfailures as the IPv4 stack is one of the most tested network element.The P-GW testing was done with IPv4 robustness testing of the IP implementationwithin the module. The expectation of this test was a very clean result with no majorfailures as the IPv4 stack is one of the most tested network element.The IMS core network testing focused on testing the two elements P- and I-CSCF.These elements were tested through SIP UAS and IPv4 plain UDP test tools. Theexpected outcome was that there would be some issues with the SIPimplementations.The test results imply that there are potential issues in the network. Further testing isneeded to fully characterize and address these issues. This is especially important inthe S-GW and P-GW components and their IPv4 deployments. Since IPv4 is one ofthe most tested protocols there shouldn’t be any major issues within it and as thesetwo components are the ones that face the customer and the Internet thus they arethe components receiving the first impact of all the traffic and failures.The IMS core is a bit more secure and it can be made more secure through filteringthe traffic that reaches the components. The filtering can be done on malformed SIPpackets but occasionally the filtering fails or hasnt been implemented at all. Thus SIPdeployments should be mainly tested that they can manage the proper packets thatthey are likely to receive and make sure that the IMS core can handle the different Page 33
  • 34. issues without causing issues to the end users trying to access or gain servicesthrough the IMS core.Appendix A provides more details on the test results.Future Work Interest has been expressed on continuing work in this area by way of a future MSF VoLTE Interoperability Event. The focus of such an event may initially be on the test cases that were not able to be executed in this event. These are as follows:-  Non-LTE Access via S4-SGSN  Non-LTE Access via legacy SGSN  2G/3G handover via S4-SGSN  2G/3G handover via legacy SGSN  Automatic Neighbour Relation/Self Organising Networks In addition, there are additional potential features that could also be part of a future IOT event:-  SRVCC,  SMS over IP  Emergency Call,  Network Interconnect via IPX  RCS/RCSe  non-3GPP access  Performance Measurements The timeframe of any future IOT event would be dependent on availability of UEs and network nodes supporting the required functionality as well as Service Provider interest in seeing such functionality tested in a multi-vendor environment. Page 34
  • 35. Appendix A: The Test ScenariosThis appendix provides a detailed description of each of the test scenarios andpresents the test results on a per-lab, per-scenario basis. When presenting theresults, the following category types are defined to define the results of the test casesin the VoLTE Interoperability Event:- • Passed – Test case was scheduled to be run and Passed the criteria defined within the Test Plan • Failed – Test case was scheduled to be run and Failed the criteria defined within the Test Plan • Not Run – Test Case was scheduled to be run, however due to lack of time this was not possible • N/A – Test Case was identified to be not applicable to be scheduled (e.g. duplication of test case functionality) • Restricted – Test Case was scheduled to be run, however due to issues with configuration or other limitations (UE and equipment restrictions) it was not possible.Basic Interoperability - VoLTEThis test scenario demonstrated the attachment and detachment from the network,IP-CAN session establishment, SIP registration (to IMS), SIP sessionestablishment/termination, and invocation/configuration of MMTel Services. IMS Core Ut Ut MMTel AS Sh I Cx S C HSS Cx P-CSCF Mw I/S-CSCF Sh Rx S6a DRA UE S6a Rx IMS UA Gx PCRF LTE-Uu Gx MME UE S1-MME LTE-Uu Sec- S11 IMS UA GW S1-U eNodeB S-GW S5 P-GW SGi Figure 11 Test Configuration – Basic Interoperability VoLTE. NOTE: The Gm interface (UE to P-CSCF) is a focus for testing although not explicitly shown in the above figure. Page 35
  • 36. The network architecture for VoLTE Basic Interoperability is shown in Figure 11above. The interfaces for which interoperability were tested are shown in red (i.e.S1-MME, S1-U, S5, S11, S6a, Gx, Rx, Gm, Mw, ISC, and Ut).Test Objectives 1. To demonstrate the ability to perform UE Attach (IP-CAN Session Establishment) and UE Detach (IP-CAN Session Tear Down). This covers inter-working between eNodeB-EPC, between the EPC elements, MME-HSS and P-GW-PCRF for creation of a default bearer for IMS Signalling. 2. To demonstrate the ability to perform UE IMS Registration, and IMS Voice Session Establishment, IMS Voice Session Termination as defined by GSMA IR.92. This covers inter-working between UE, IMS Core Network, MMTel AS and PCC for creation of a dedicated bearer for voice. 3. To demonstrate the ability to perform MMTel Service Configuration over the Ut reference point for an attached UE. 4. To demonstrate inter-working between the UE, IMS Core and IMS-AS for MMTel Service usage as defined by GSMA IR.92. 5. To demonstrate the ability to provide a secure transport mechanism between the eNodeB and EPC elements utilising the Sec-GW to provide an IPSec tunnel. 6. To demonstrate the ability to provide an optimised solution for routing of Diameter messages within the core network utilising the DRA functionality.Test Results and ObservationsThe Basic Interoperability – VoLTE test plan defined 28 basic test cases. By pairingdifferent vendors’ equipment in the various network configurations, the basic testcases were expanded to 224 test case instances scheduled in the VodafoneDüsseldorf lab, and 112 test case instances scheduled in the CMCC Beijing lab. TheVodafone Düsseldorf lab configuration included connections to one HSS and one S-GW located in the CMCC Beijing lab.The following table summarizes the VoLTE test results.No Run Passed N/A Failed Restricted Total Lab 69 32 28 8 87 224 Düsseldorf 0 76 0 12 24 112 Beijing Table 3. Basic Interoperability – VoLTE Test ResultsThe “No run” test cases were largely due to lack of time to execute those test cases.The “N/A” test cases were due to duplication of test scope already specified in othertest cases.The “Failed” test cases were largely due to backwards incompatibility betweenimplementations of different versions of 3GPP specifications, implementations thatwere not fully-compliant to the 3GPP specifications, and the difficulty in re- Page 36
  • 37. configuring the network components when testing different multi-vendorconfigurations.The “Restricted” test cases were due to missing functionality that did not enable thetest case to be executed.Basic Interoperability – VoLTE demonstrated:-  Multi-vendor interoperability of UE, eNodeB, Sec-GW, EPC, IMS/MMTEL, DRA and PCC technology.  VoLTE calls and supplementary services, based on GSMA IR.92, are a viable solution for providing voice services for LTE access.  The IMS Soft Clients interworked successfully with the LTE data dongle for LTE Attach and additionally with the IMS Core Network and MMTel AS to provide IMS services to the end user.  GTP protocol proved to be mature and stable with no issues identified.  Diameter routing within the PLMN was greatly simplified by utilizing Diameter Routing Agents. DRAs were also shown to provide interworking between different transport layer protocols.  IPSec security between eNodeB and MME/S-GW can be achieved utilizing a Sec-GW with complete transparency to signaling and media and no impact to other network elements.Several issues were encountered during the test execution of Basic Interoperability -VoLTE:  PCC Issues  On Gx and Rx interfaces, it was discovered that some implementations do not implement the Supported Features AVP. On both Rx and Gx interfaces, a Mandatory Supported Feature is introduced per 3GPP Release (e.g. Rel8). However it was discovered that Release 8 compliant implementations were not implementing this functionality. This resulted in an error code being returned to the originator of the message, with resultant Gx and Rx commands being rejected. The sender may optionally fall-back to an earlier 3GPP Release of the interface, however this would have resulted in Release 7 behavior.  Backwards incompatibility between different versions of the same 3GPP Release was discovered on the Rx interface. Between version 8.4.0 and 8.6.0 of the Rx interface, backwards incompatible changes were introduced when the Specific-Action AVP was modified to introduce new events. As the Rx interface Supported Features introduces mandatory features per 3GPP Release, it lacks the granularity that is required to enable backwards compatibility between implementations based on the two different versions.  Mandatory AVPs were missing on the Gx and Rx interfaces in some implementations. The Bearer-Control-Mode and QoS-Information were missing on some implementations of the CCA of the Gx interface. Page 37
  • 38. Precedence, Allocation-Retention-Priority and Rating-Group were missing on some implementations of the RAA of the Gx interface. The Auth- Application-ID was missing on some implementations of the AAR on the Rx interface.  Triggering of relevant Gx and Rx messages (CCR/AAR) were not performed by some implementations of P-GW and P-CSCF respectively. This results in lack of appropriate QoS being applied on the EPC bearer, and no session binding being performed in the PCRF between the IMS and EPC bearer. IMS Issues  On the Cx interface, it was discovered that an HSS implementation did not implement the Supported Features AVP. For Release 8 compliant implementations, a mandatory Supported Feature (Alias Indication) is standardized. Non support of this mandatory Supported Feature results in an error code being returned to the S-CSCF, with the SAR/SAA command being rejected – IMS Registration fails. The sender may optionally fall- back to an earlier 3GPP Release of the interface, however this would have resulted in Release 7 behavior.  The Sh interface was not supported on all implementations of HSS and MMTel Application Server. Whilst the Sh interface is optional, as user service information may be stored locally on the MMTel AS, it was discovered that some implementations of MMTel AS require the Sh interface to store user service information in the HSS. Without the support of the Sh interface, there is an interoperability issue between MMTel AS and HSS for some vendor combinations.  The Ut interface was not supported on all MMTel ASs in order to provide supplementary service configuration. Note that this is mandatory within GSMA PRD IR.92.  The Cx interface UAR/UAA command was found to fail in one configuration due to an incorrect implementation in the I-CSCF related to the setting of the Proxy-Bit in the command header. The Proxy-Bit is mandated to be set in both the request and answer messages, but was not being set by the I-CSCF.  3rd Party Registration requests were not being sent by all implementations of S-CSCF to the MMTel AS. The 3rd party Registration is required to register the user on the MMTel AS and its availability for supplementary services.  The tests showed that there are ambiguities in the specifications for user authentication across the Ut interface. Specifically, it is not specified whether the username should be input as “user@domain” or simply as “user”. Similarly, it is not specified whether username and password should be case sensitive, or case insensitive. EPC Issues  Fragmentation issues were seen when the MTU size exceeded that specified by 3GPP for e.g. 1500 octets in the transport network, providing Page 38
  • 39. a link MTU value of 1358 octets to the MS as part of the IP configuration information from the network. During the IOT event, it was necessary to also reduce the size of the SIP INVITEs (e.g. by reducing the number of codecs being offered).  Transport Issues  SCTP was not initially supported by all DRAs, TCP was the transport protocol supported. 3GPP Diameter interfaces are based on SCTP for the transport protocol. This was resolved during the 3 week test period with SCTP being implemented.  The SCTP solution of one of the HSSs did not support dynamic local port allocation.  Difficulty was experienced when re-configuring the network components for testing the different multi-vendor configurations. The issue is mainly related to the test network configuration and the desire to test various different multi- vendor configurations; it is not seen as a major issue for network deployments.Security Gateway TestingThere are two modes in which IPSec tunnels can be established, both making use ofIKE:  Network-Network / Lan2Lan whereby static IP addresses are used, for the establishment of the tunnel during the authentication/authorization phase. Either end of the tunnel can initiate the process.  Client-Server, whereby the customer premises equipment, typically the Femto gateway, is the only node allowed to setup tunnels. The additional advantage of the client-server model is that IP addresses can be allocated dynamically from a pool of addresses or by allocation from a DHCP server via the Sec- GW. The scalability of client-server mode can in theory be much larger (10x) but this has to be balanced with the total amount of traffic /throughput to be processed as the two requirements are related at least for peak operation.Both of these were in use within the MSF VoLTE IOT and a single Sec-GW was usedto serve both vendors/types of eNodeBs.The tunnel establishment protocol is the “Internet Key Exchange” protocol or IKE.IKE presently has version 1 and version 2. The Sec-GW used within the MSF wasable to support both but the only version supported by the eNodeB suppliers at thisevent was IKE v1.0. In summary, as with any newer versions, is that IKE v2.0provides additional flexibility and security, for example support for NAT traversal,dead peer detection and Extensible Authentication Protocol (EAP) whilst IKE onlysupport pre-shared keys. Page 39
  • 40. The following table summarizes the Sec-GW test results.Security Gateway ProceduresProcedure Tested Result Notes/Issues encounteredTunnel (IKE) Yes Passed Minor issue with IP addressingcreation, including subnet mask (changed eNodeBcookies physical address subnet mask from /16 to /24)Tunnel tear down Yes PassedTunnel (Child SA) Yes PassedcreationSA Rekeying Yes Passed Complete test with only one eNodeB vendor, time constraintsChild SA rekey Yes Passed restricted full testing with other. Table 4. Sec-GW Test ResultsTests were executed based on IKE v1.0 and using client-server (“sessions”)configuration, similar to Femto-cell deployment: eNodeB only can initiate IPsecsetup, with ability to have dynamic IP address allocated from a pool of IP addressesheld by the SSX. Tunnels were established successfully and operated for 2.5 dayswith no issuesTests were executed based on IKE v1.0 and using lan2lan (“network-network”)configuration, suitable for macro base station deployment, large traffic pipes. eNodeBor Sec-GW can initiate IPsec setup, with static IP addressing. Tunnels wereestablished successfully and operated for 2 weeks with no issues.Roaming & InterconnectThis test scenario demonstrates roaming (i.e. LTE attachment and detachment, IMSregistration, IMS session establishment/teardown, MMTel Service configuration andMMTel Service usage for roaming UEs) and interconnect (IMS sessionestablishment/teardown and MMTel Service usage between 2 LTE UEs registered intheir respective home PLMNs).This scenario was broken down into two sub-scenarios that are further detailed. Page 40
  • 41. Roaming Figure 12. Test Configuration for Roaming NOTE: The Gm interface (UE to P-CSCF) is a focus for testing although not explicitly shown in the above figure.The network architecture for the Roaming test scenario is shown in Figure 12 above.The interfaces for which interoperability were tested are shown in red (i.e. S6a, S9,Rx, Gx, Mw, Gm, Ut and ISC).Objectives 1. To demonstrate roaming with the UE in a Visited Network (i.e. eNodeB, MME, S-GW, P-GW, V-PCRF and P-CSCF in the VPLMN and the HSS, H-PCRF and IMS core in the HPLMN). Specifically, the ability to perform interworking between the MME and PCRF in the VPLMN with the HSS and PCRF in the HPLMN respectively, and the PCRF and P-CSCF in the visited network by performing UE Attach (IP-CAN Session Establishment) and UE Detach (IP- CAN Session Tear Down). Thus validating the Diameter roaming interfaces and DRA functionality for S6a and S9 as defined by GSMA IR.88. 2. To demonstrate UE IMS Registration, and IMS Voice Session Establishment, IMS Voice Session Termination as defined by GSMA IR.92, whilst roaming in a visited network. 3. To demonstrates the ability to perform MMTel Service Configuration over the Ut reference point for an attached UE, whilst roaming in a visited network. Page 41
  • 42. 4. To demonstrate inter-working between the UE, IMS Core and IMS-AS for MMTel Service usage as defined by GSMA IR.92, whilst roaming in a visited network.Testing Results and ObservationsThe Roaming test plan defined 27 basic test cases. However, due to lack of timeand available MMTel Application Servers, the IMS supplementary service test caseswere not executed, and therefore the focus was on 5 basic test cases. By pairingdifferent vendors’ equipments in the various network configurations, the 5 basic testcases were expanded to 45 test case instances scheduled in both the VodafoneDüsseldorf and CMCC Beijing labs.The following table summarizes the test results.No Run Passed N/A Failed Restricted Total Lab 16 7 0 2 0 25 Düsseldorf 14 2 0 4 0 20 Beijing Table 5. Roaming Test ResultsThe “No run” test cases were largely due to lack of time to execute those test cases,and MMTel Application Servers not being available.The “Failed” test cases were due to implementations that were not fully-compliant tothe 3GPP specifications and the difficulty in re-configuring the network componentswhen testing different multi-vendor configurations.Roaming demonstrated:-  Successful LTE Attach and LTE Detach was performed demonstrating the Diameter Roaming interfaces of S6a and S9 were routed successfully across the network interconnect via Diameter Routing Agents.  The S9 interface proved to be mature and stable for installing PCC and QoS rules. No issues were identified.  IMS Registration was successful when the user is roaming validating the connectivity of a roaming UE to a home IMS Core Network (via a P-CSCF in a visited network to an SBC in the home network).Issues were encountered during the test execution of Roaming:  Mandatory Event-Trigger AVP with value of UE_IP_ADDRESS_ALLOCATE within the CCR on the Gx interface was not understood by one instance of a PCRF. This resulted in the CCR being rejected and the LTE Attach failing.  The optional "warning header" within the Authentication Header was not understood by one of the UEs. This resulted in failure of IMS Registration.  Due to time limitations and lack of MMTel ASs, no testing related to VoLTE calls and supplementary services could be performed. Page 42
  • 43.  Difficultly was experienced when re-configuring the network components for testing the different multi-vendor configurations. The issue is mainly related to the test network configuration and the desire to test various different multi- vendor configurations, it is not seen as a major issue for network deployments.Interconnect IMS Core Ut MMTel AS Sh I Cx S C HSS Cx P-CSCF Mw I/S-CSCF Mx IBCF/TrGW Sh Rx S6a DRA S6a Rx Gx PCRF MME Gx UE S1-MME LTE-Uu Sec- S11 IMS UA GW Ici/Izi S1-U eNodeB S-GW S5 P-GW SGi IMS Core Ut MMTel AS Sh I Cx S C HSS Cx P-CSCF Mw I/S-CSCF Mx IBCF/TrGW Sh Rx S6a DRA S6a Rx Gx PCRF Gx MME UE S1-MME LTE-Uu Sec- S11 IMS UA GW S1-U eNodeB S-GW S5 P-GW SGi Figure 13. Test Configuration for Interconnect NOTE: The Gm interface (UE to P-CSCF) is a focus for testing although not explicitly shown in the above figure.The network architecture for Interconnect is shown in Figure 13 above. Theinterfaces for which interoperability were tested are shown in red (i.e. Mw, Mx, Gm,Ut, ISC and Ici/Izi). Page 43
  • 44. Objectives 1. To demonstrate interconnect between two UEs registered in their respective home PLMNs. Specifically, the ability to perform interworking between the IBCF/TrGWs in the respective PLMNs validating the Ici/Izi interfaces and GSMA IR.65. 2. To demonstrate IMS Voice Session Establishment and IMS Voice Session Termination as defined by GSMA IR.92 and IR.65, with voice sessions established with a subscriber in a different PLMN. 3. To demonstrate the usage of MMTel Services as defined by GSMA IR.92, across a network-to-network-interconnect validating Ici/Izi.Testing Results and ObservationsThe Interconnect test plan defined 20 basic test cases. However, due to lack of timeand available MMTel Application Servers, the IMS supplementary service test caseswere not executed, and therefore the focus was on 2 basic test cases By pairingdifferent vendors’ equipments in the various network configurations, the basic testcases were expanded to 106 test case instances scheduled in both the VodafoneDüsseldorf and CMCC Beijing labs.The following table summarizes the test results.No Run Passed N/A Failed Restricted Total Lab 19 6 0 1 0 26 Düsseldorf 72 8 0 0 0 80 Beijing Table 6. Interconnect Test ResultsThe “No run” test cases were largely due to lack of time to execute those test cases,and MMTel Application Servers not being available.The “Failed” test cases were due to implementations that were not fully-compliant tothe 3GPP specifications and the difficulty in re-configuring the network componentswhen testing different multi-vendor configurations.Interconnect demonstrated:-  VoLTE calls, based on GSMA IR.92 and IR.65, are a viable solution for providing voice services for LTE access between Mobile Network Operators.  Multi-vendor interoperability of IBCF/TrGWs was achieved.Issues were encountered during the test execution of Interconnect:  Routing of SIP messages was only based on IP Address but not port number in one of the IBCFs. In implementations that contain P-CSCF, I-CSCF and S-CSCF within the same physical node, the IP Address is common, and the port number is utilized to distinguish between the different functional nodes. Therefore routing SIP messages only on IP Address, causes SIP messages Page 44
  • 45. to be routed to the incorrect destination, resulting in IMS voice calls not being established.  Due to time limitations and lack of MMTel ASs, no testing related to MMTel supplementary services could be performed.  Difficultly was experienced when re-configuring the network components for testing the different multi-vendor configurations. The issue is mainly related to the test network configuration and the desire to test various different multi- vendor configurations; it is not seen as a major issue for network deployments.Intra-LTE HandoversThis test scenario demonstrates LTE-LTE handover, both with registered terminalsand with active sessions. IMS Core Sh MMTel AS ISC Cx S6a HSS P-CSCF Mw I/S-CSCF S1-MME LTE-Uu eNodeB (x) MME (a) PCRF Rx X2 S1-U UE S11 Gx LTE-Uu IMS UA S-GW (a) S10 S5 P-GW SGi eNodeB (y) LTE-Uu S11 S5 X2 UE LTE-Uu IMS UA MME (b) S6a S-GW (b) S11 eNodeB (z) Figure 14. Test Configuration for Intra-LTE HandoverThe network architecture is shown in Figure 14 above. The interfaces for whichinteroperability were tested are shown in red (i.e. S1-MME, S1-U, S10, S11, andS6a).Test Objectives 1. To demonstrate handover of registered UEs, including those involved in active sessions, intra-LTE including between eNBs, MME re-location and S- GW re-location.Testing Results and ObservationsThe Intra-LTE test plan defined 9 basic test cases. By pairing different vendors’equipments in the various network configurations, the basic test cases wereexpanded to 36 test case instances in the CMCC Beijing lab. Page 45
  • 46. The following table summarizes the test results.No Run Passed N/A Failed Restricted Total Lab 0 24 0 0 12 36 Beijing Table 7. Intra-LTE Handover Test ResultsThe “Restricted” test cases were due to only one MME being available and thereforeMME Relocation could not be performed.Intra-LTE Handover demonstrated:-  The interoperability between eNB and EPC is verified  Multi-vendor eNB environment is not available for this scenario due to lack of other eNB vendorsRobustnessThis test scenario demonstrated the usage of robustness testing in a LTE contextand provided an overview of protocol implementation level vulnerabilities. Therobustness test tool was physically located in the Düsseldorf lab and targetequipment in the Beijing lab was tested remotely via use of the VPN.The focus was mainly on the components that interact and effect the end userdirectly, the components tested within this environment where the S-GW, P-GW andIMS Core Services (I-CSCF, P-CSCF and S-CSCF). The test scenario did limit theprotocol scope also to three main protocols (IPv4, UDP and SIP) due to thelimitations in time and possible interoperability issues. Although this limitation wasdone it is suggested that the vendors taking part of this event would also includetesting of the other core protocols in LTE networks mainly GTPv2 and SCTP.This scenario was broken down into three sub-scenarios that are detailed below (S-GW Robustness, P-GW Robustness, and IMS Robustness). A common testconfiguration was used in all cases as shown below.As an outcome of this testing it was noticeable that issues were found within allcomponents, which from end user and provider perspectives raises some concernsin two ways were end users cannot gain access to the services and providers willlose revenues through this. Page 46
  • 47. Robustness testing configuration IMS Core SGW PDN S1‐U S5/S8 Figure 15. Test Configuration for RobustnessDefinitions for Robustness resultsNo Interoperability contains that the test target allowed the test cases to comethrough but there were some failures within the configuration between the test targetand test system. Most issues related to the fact that the user or callee was notrecognized.Full Interoperability means that the test target contained all the necessary informationthat allowed the test system to confirm all the settings without possible failuresNot Available means that the target system was not available for testing during theevent due to other constraints.Denial-of-Service is the amount of time the test target was out of communication.This was validated through sending first an anomalized request and then a validrequest. If the test target failed to reply to the valid request then the test systemrecords a failure and Denial-of-Service timer starts. The denial of service timerepresents the maximum amount of time the system was unavailable with one testcase out of all the failed cases.Fail/Pass criteria. Within the MSF test scenarios test target got a pass verdict if therewas no failures detected. Fail is recorded if the test target has even one failed casethis is because to limited time in the test event thus regression testing or failed caseanalysis was not done within this test event with the Vendors.Robustness testing of the S-GWThe objective was to test the robustness of the LTE core network when trafficoriginates from the end user. The goal is that the LTE network can handleanomalous traffic that is sent intentionally or unintentionally by the end userequipment. Thus the testing equipment will be simulating end user in the networkconfiguration in figure 15.The S-GW testing was done with IPv4 robustness testing of the IP implementationwithin the module. There were five vendors that had provided their solutions to thisnetwork component. Out of the five vendors, four were available for robustness Page 47
  • 48. testing. The expectation of this test was a very clean result with zero to few failuresas the IPv4 stack is one of the most tested network element.It should be noted that UDP and IPComp failed to Interoperate with all the solutions(RFC 3173), thus these were left out on this scenario.This test contained the default test case amount from the tool that would represent21% coverage of potential test cases that can be generated through the tool.Below is a list of the vendors and the results: Test Verdict Result Notice Configuration 1 Pass 0 fails 2 Fail 1 fail 1.5s Denial of Service time 3 Fail 8670 fails 11.5s Denial of Service time 4 Fail 1 fail 11.5s Denial of Service time 5 Inconclusive N/A Not Executed Table 8. S-GW Robustness Test ResultsRobustness testing of the P-GWThe objective was to perform robustness testing for the S11 interface in order toensure that the Core network is robust against malformed traffic sent bymalfunctioning or badly interoperating Core elements. Malfunctioning Core elementscould send anomalous data to other surrounding elements, affecting overall networkstability.The P-GW testing was done with IPv4 robustness testing of the IP implementationwithin the module. There were five vendors that had provided their solutions to thisnetwork component. Out of the five vendors testing was executed on all five, but oneP-GW was physically the same machine as the S-GW thus it was not retested withinthis test scenario. The expectation of this test was a very clean result with zero to fewfailures as the IPv4 stack is one of the most tested network element.It should be noted that UDP and IPComp failed to Interoperate with all the solutions(RFC 3173), thus these were left out on this scenario.This test contained the default test case amount from the tool that would represent21% coverage of potential test cases that can be generated through the tool.Below is a list of the results: Test Verdict Result Notice Configuration 1 Pass 0 fails 2 Fail 3 fails 1.5s Denial of Service time Page 48
  • 49. 3 Skipped Same device as SGW 4 Fail 1 fail 11.6s Denial of Service time 5 Fail 2 fails 1.8s Denial of Service time Table 9. P-GW Robustness Test ResultsRobustness testing of the IMS CoreThe objective was to perform robustness testing for the SIP and UDP interfaces inorder to ensure that the IMS Core network is robust against malformed traffic sent bymalfunctioning or badly interoperating Core elements. Malfunctioning Core elementscould send anomalous data to other surrounding elements, affecting overall networkstability.Within the IMS core the tests focused on testing the two elements P- and I-CSCF.These elements were tested through SIP UAS and IPv4 plain UDP test tools. Theexpected outcome was that there would be some issues with the SIPimplementations but it should be noted that full Interoperability was not achieved withall the vendors and this might have an effect of the test outcomes by giving betterresults through dropping packets that are coming from a not known host.The test scenario with SIP UAS represented 5% test coverage of the potentialmaximum test cases that can be generated through the tool. It should be noted thatone vendor requested the tests to be stopped and their test coverage at the time ofcancellation would represent 2.65% coverage. This scenario was only for theOptions-Sequence within SIP with possibility to test another 19 different sequences.This means the test coverage is below 1% within the MSF VoLTE test event.The UDP test scenario had 29% test coverage of the potential maximum test casesthat could be generated through the tool.For the P-CSCF and I-CSCF testing, four of the five test configurations wereavailable for I-CSCF testing, and five out of ten test configurations were available forP-CSCF testing. Both P- and I-CSCF were tested utilizing SIP and UDP test tools.Generally the results were what were expected with some failures without any majorDenial of Service time but as combined with the low coverage it should be noted thatthis requires further evaluation to be done before a comprehensive answer can begiven.Below is a list of the results: I-CSCF Test Verdict Result Notice Configuration (SIP) 1 Fail 1 fail No full Interoperability 2 Fail 13 fails 0.5s Denial of Service time. Full Interoperability 3 Inconclusive N/A Not available 4 Inconclusive N/A No Interoperability Table 10. I-CSCF SIP Robustness Test Results Page 49
  • 50. I-CSCF Test Verdict Result Notice Configuration (UDP) 1 Fail 78 fails 2 Inconclusive N/A No Interoperability 3 Pass 0 fails 4 Inconclusive N/A No Interoperability Table 11. I-CSCF UDP Robustness Test ResultsBelow is a list of the results for the P-CSCF: P-CSCF Test Verdict Result Notice Configuration (SIP) 1 Fail 14 fails 33.7s Denial of Service time, full interoperability 2 Inconclusive N/A Not available 3 Fail 460 fails 3.6s Denial of Service time 4 Fail 1883 fails 11.6s Denial of Service time 5 Fail 12 fails 0.5s Denial of Service time 6 Inconclusive N/A No interoperability 7 Inconclusive N/A No Interoperability 8 Inconclusive N/A Not available 9 Inconclusive N/A No Interoperability 10 Fail 1 fail 0.5s Denial of Service time Table 12. P-CSCF SIP Robustness Test Results P-CSCF Test Verdict Result Notice Configuration (UDP) 1 Pass 0 fails 2 Inconclusive N/A No Interoperability 3 Inconclusive N/A No Interoperability 4 Inconclusive N/A No Interoperability Page 50
  • 51. 5 Pass 0 fails 6 Inconclusive N/A No interoperability 7 Pass 0 fails 8 Pass 0 fails 9 Inconclusive N/A No Interoperability 10 Pass 0 fails Table 13. P-CSCF UDP Robustness Test ResultsRobustness Tests ObservationsThere are two main scenarios that can be viewed through the testing results: a) aperson with malicious intent willingly wants to bring down the network withanomalous packets or b) there is a component issue within the network and starts tosend malformed packets which has a direct effect on the quality of the services withinthe network.The test results imply that there are issues in the network protocol deployments thatneed to be tested further to validate these results. The priority is to focus on the S-GW and P-GW components and the IPv4 implementations within them. Thesecomponents are facing the end user and potentially the Internet thus making themsusceptible to attacks or malformed traffic.The IMS core is more secure and it can be made even more secure through filteringthe traffic that reaches these components. Filtering can be done to target specificallyon malformed SIP packets but in cases where the filtering fails or it hasn’t beenimplemented at all the SIP deployments within the IMS-core should be tested andmake sure that the IMS core can handle the potential malicious packets withoutcausing issues to the end users trying to access or gain services through the IMScore.Robustness Tests ConclusionBased on the results seen through the robustness testing it is quite obvious thatfurther testing in the network components is needed since there are issues found.There is a clear importance of verifying IPv4 robustness is verified as a first priorityissue since it will be in the core of the whole solution thus if it fails the whole networkwill become unusable for the end users. This creates loss of revenue for theoperators and then annoyance towards the end users as they cannot reach theservices needed. Page 51
  • 52. Appendix B: Interfaces Under TestThe following is a set of references for the interfaces tested in the VoLTEInteroperability Event 2011 :  LTE-Uu (UE – eNodeB) 3GPP TS 36.300 (E-UTRAN protocol)  S1-MME (UE – MME) 3GPP TS 24.301 (Non Access Stratum)  S1AP (eNodeB-MME) 3GPP TS 36.413 (S1 Application Protocol)  S1-U (eNodeB - S-GW) 3GPP TS 29.281 (GTPv1-U)  X2 (eNodeB – eNodeB) Signaling 3GPP TS 36.423 (X2 Application Protocol). User Plane 3GPP TS 29.281 (GTPv1-U)  S3 (S4 SGSN – MME) 3GPP TS 29.274 (GTPv2-C)  S4 (S4 SGSN – S-GW) Control Plane 3GPP TS 29.274 (GTPv2-C). User Plane 3GPP TS 29.281 (GTPv1-U).  S5 (S-GW - P-GW) User Plane 3GPP TS 29.281 (GTPv1-U) Control Plane 3GPP TS 29.274 (GTPv2-C)  S6a (HSS – MME)  3GPP TS 29.272 (Diameter)  S6b (P-GW – 3GPP AAA) 3GPP TS 29.273 (Diameter)  S6d (HSS – S4 SGSN) 3GPP TS 29.272 (Diameter)  S8 (S-GW – P-GW) User Plane 3GPP TS 29.281 (GTPv1-U) Control Plane 3GPP TS 29.274 (GTPv2-C)  S9 (PCRF – PCRF) 3GPP TS 29.215 (Diameter).  S10 (MME – MME) 3GPP TS 29.274 (GTPv2-C). Page 52
  • 53.  S11 (MME – S-GW) 3GPP TS 29.274 (GTPv2-C) S12 (UTRAN – S-GW) 3GPP TS 29.281 (GTPv1-U, utilized for direct tunnel model). Gx (PCRF – P-GW) 3GPP TS 29.212 (Diameter). Rx (PCRF - IP Application [P-CSCF for IMS]) 3GPP TS 29.214 (Diameter). Gr (SGSN – HSS) 3GPP TS 29.002 (MAP) Gn (SGSN – MME / SGSN – P-GW) Control Plane 3GPP TS 29.060 (GTPv1-C) User Plane 3GPP TS 29.281 (GTPv1-U) Gm (UE – P-CSCF) 3GPP TS 24.229 (IMS SIP) Mw (x-CSCF – x-CSCF) 3GPP TS 24.229 (IMS SIP) ISC (S-CSCF – AS) 3GPP TS 24.229 (IMS SIP) Ut (UE – AS) 3GPP TS 24.623 (XCAP) SGi (EPC based PLMN and another packet data network) 3GPP TS 29.061 (IP) Page 53
  • 54. Appendix C: The Benefits of MSF MembershipThe MSF is a global association of service providers, system suppliers, testequipment vendors, and users committed to developing and promoting open-architecture, multiservice Next Generation Networks. Founded in 1998, the MSF isan open-membership organization whose members are drawn from the worldsleading IP communications companies. Historically, the MSF developedImplementation Agreements (IAs), promoting worldwide compatibility andinteroperability of network elements, and encouraging input to appropriate nationaland international standards bodies. However, this role has become less of a focusas a standard architecture has emerged and protocol profiles are being defined inother SDOs and industry fora (e.g. 3GPP). The MSF primarily focuses on runningIOT events to facilitate the deployment of next-generation multi-service networks,driven by its member needs. In addition, in 2009, the MSF decided to complement itsestablished biennial Global MSF Interoperability (GMI) events by more targeted testevents focused on critical and timely issues associated with deployment of IPcommunications. The VoLTE Interoperability Event 2011 is the third test event ofthis nature. For a history of MSF IOT events as well as information on plannedupcoming IOT events, see http://www.msforum.org/interoperability/GMI.shtml..The advantages of MSF membership include:  Access to more than ten years of ground-breaking industry work with input from key service providers and vendors,  The experience of some of the world’s leading scientists and engineers,  The opportunity to leverage the external talent pool active in the MSF to more efficiently implement a validated architecture built on industry-standard protocols,  The ability to validate product implementations in industry-leading interoperability events.In addition, service providers and equipment vendors that actively participate in MSFIOT events learn how multivendor next-generation products and networks willinteroperate in the real world. That information translates into several financialbenefits:  Reduced time to market for deployment of interoperable solutions,  Decreased costs and resources to resolve interoperability issues,  Improved protocol documentation through facilitating clarifications in the tested standards via feedback to the appropriate SDOs ,  Thoroughly evaluated architectural framework for cooperatively designing end-to-end networking solutions.The MSFs IOT program is designed to facilitate implementation of NGNs and todeliver the Forum’s mission statement that “We make Next Generation Networkswork”. MSF IOTs validate products in the latest standards-based architecturalframework using network deployment scenarios that are meaningful to ServiceProviders. Page 54
  • 55. Appendix D: The ParticipantsThis appendix provides a brief resume of the participant companies in the LTEInteroperability Event:-Acme PacketAcme Packet (NASDAQ: APKT), the leader in session delivery network solutions, enables thetrusted, first-class delivery of next-generation voice, data and unified communicationsservices and applications across IP networks. Our Net-Net product family fulfills demandingsecurity, service assurance and regulatory requirements in service provider, enterprise andcontact center networks. Based in Bedford, Massachusetts, Acme Packet designs andmanufactures its products in the USA, selling them through over 200 reseller partnersworldwide. More than 1,525 customers in 107 countries have deployed over 14,000 AcmePacket systems, including 90 of the top 100 service providers and 36 of the Fortune 100. Formore information visit www.acmepacket.com.Alcatel-LucentThe long-trusted partner of service providers, enterprises, strategic industries andgovernments around the world, Alcatel-Lucent is a leader in mobile, fixed, IP and Opticstechnologies, and a pioneer in applications and services. Alcatel-Lucent includes Bell Labs,one of the worlds foremost centres of research and innovation in communicationstechnology.With operations in more than 130 countries and one of the most experienced global servicesorganizations in the industry, Alcatel-Lucent is a local partner with global reach.The Company achieved revenues of Euro 16 billion in 2010 and is incorporated in France andheadquartered in Paris.For more information, visit Alcatel-Lucent on: http://www.alcatel-lucent.com, read the latestposts on the Alcatel-Lucent blog http://www.alcatel-lucent.com/blog and follow the Companyon Twitter: http://twitter.com/Alcatel_Lucent.AlepoAlepo provides core network & business management solutions across next generationservices and technologies, including LTE, WiMAX, Wi-Fi and Femto, as well as gateways intolegacy technologies like UMTS, GSM, CDMA2000. With over 15 years of experience workingdirectly with leading telecommunications service providers to bring the latest technologies andservices to market quickly and cost-effectively, Alepo’s innovation and expertise spans real-time policy & charging, fixed mobile convergence, packet core evolution, devicemanagement, mobile data offloading, carrier Wi-Fi hotspots and more.www.alepo.comtwitter.com/AlepoUSAfacebook.com/AlepoUSAAmdocsAmdocs is the market leader in customer experience systems innovation. The companycombines business and operational support systems, service delivery platforms, proven Page 55
  • 56. services, and deep industry expertise to enable service providers and their customers to domore in the connected world. Amdocs offerings help service providers explore new businessmodels, differentiate through personalized customer experiences, and streamline operations.A global company with revenue of approximately $3.0 billion in fiscal 2010, Amdocs has over19,000 employees and serves customers in more than 60 countries worldwide. Amdocscompleted the acquisition of Bridgewater Systems in August 2011 and now offersBridgewater’s industry leading network and subscriber control solutions as part of the AmdocsData Experience Solution Business Unit. For more information, visit Amdocs atwww.amdocs.com.CiscoAbout CiscoCisco Systems, Inc. is the worldwide leader in networking for the Internet. Today, networksare an essential part of business, education, government and home communications, andCisco Internet Protocol-based (IP) networking solutions are the foundation of these networks.Cisco hardware, software, and service offerings are used to create Internet solutions thatallow individuals, companies, and countries to increase productivity, improve customersatisfaction and strengthen competitive advantage. The Cisco name has becomesynonymous with the Internet, as well as with the productivity improvements that Internetbusiness solutions provide. At Cisco, our vision is to change the way people work, live, playand learn.Cisco’s Mobile Internet Technology Group, MITG, is responsible for helping mobile operatorsmanage the deluge of mobile data and migrate to next generation networks. This groupprovides the most intelligent, high-performance IP mobile networks enabling customers todeliver rich multimedia services. MITG solutions provide seamless integration and migrationacross a range of 2.5G, 3G, and 4G wireless radio access technologies with the highestquality and reliability.CodenomiconCodenomicon, the first commercial venture to utilize fuzzing technology to allow Customersgain visibility into potential vulnerabilities. Codenomicon solutions can be used in softwaresecurity testing and network management situations. With Codenomicon’s proactive securitytesting software and situation awareness tools you can discover and react to the problems atthe earliest possible moment.Proactive security testing. Codenomicon Defensics is a proactive testing solution for findingand mitigating both known and unknown vulnerabilities in software even before deployment,improving application and network security. In the core of the solution is fuzz testing, amethod where invalid input are fed to the system under test to expose vulnerabilities.www.codenomicon.com/defensicsSituation awareness. The management of critical infrastructure requires making fast andinformed decisions. Thus, it is essential to acquire relevant information, and understand therelationship between individual events. The problem is that there is too much informationavailable, making it extremely challenging to separate significant facts from irrelevant data.Codenomicons situation awareness tools help with collecting, automatic filtering and Page 56
  • 57. visualizing the information, and alerting stakeholders in real time, allowing you to make theright decisions.www.codenomicon.com/clarifiedCodenomicon’s solutions are used by top governments and leading software companies,operators, service providers and manufacturers to secure critical networks and to providerobust and reliable products and services.D2 TechnologiesD2 is the recognized leader in converged IP communications software for devices used innext-generation networks such as 4G LTE and WiMAX. Manufacturers and service providersrely on D2 software to deliver carrier-grade IP communications across any network (WiFi,WiMAX, LTE, cellular, broadband, PSTN), service (voice, video, IM chat, SMS,presence/status, etc.) and system (IP PBX, UC, carrier, OTT, social network, etc.) for a broadrange of fixed and mobile devices. From processing billions of VoIP minutes each month toadding enhanced IP communications for Android™, learn how D2 software is convergingcommunications at www.D2Tech.com or follow the company on Twitter @D2Tech.ExfoEXFO (NASDAQ: EXFO, TSX: EXF) is among the leading providers of next-generation testand service assurance solutions for wireless and wireline network operators and equipmentmanufacturers in the global telecommunications industry. The company offers innovativesolutions for the development, installation, management and maintenance of converged, IPfixed and mobile networks — from the core to the edge. Key technologies supported include3G, 4G/LTE, IMS, Ethernet, OTN, FTTx, and various optical technologies (accounting for anestimated 35% of the portable fiber-optic test market). EXFO has a staff of approximately1800 people in 25 countries, supporting more than 2000 telecom customers worldwide.For more information, visit www.EXFO.com.GenbandAbout GENBANDGENBAND is a global leader of IP infrastructure solutions, enabling enterprise, service andcontent providers around the world to evolve communications networks through IP innovation.The Company offers market-leading Switching, Applications, Networking and Servicesolutions, with products deployed in over 600 customer networks spanning more than 80countries. GENBAND is headquartered in Frisco, Texas, and has operations in 50 countries.To learn more, visit us on the web at www.genband.com.GENBAND, the GENBAND logo and icon are trademarks of GENBAND.HuaweiHuawei is a leading global information and communications technology (ICT) solutionsprovider. Through our dedication to customer-centric innovation and strong partnerships, wehave established end-to-end advantages in telecom networks, devices and cloud computing. Page 57
  • 58. We are committed to creating maximum value for telecom operators, enterprises andconsumers by providing competitive solutions and services. Our products and solutions havebeen deployed in over 140 countries, serving more than one third of the world’s population.Huaweis vision is to enrich life through communication. By leveraging our experience andexpertise in the ICT sector, we help bridge the digital divide by providing opportunities toenjoy broadband services, regardless of geographic location. Contributing to the sustainabledevelopment of the society, economy, and the environment, Huawei creates green solutionsthat enable customers to reduce power consumption, carbon emissions and resource costs.IPNeoIPneo provides innovative solutions that bring tomorrow’s IP technologies to the hands oftoday’s users. Focusing on IP Multimedia Subsystem (IMS), IPneo delivers standardizedclient software solutions enabling rich communication capabilities for end- users. IPneo clientsolutions pave the way for operators and OEMs to quickly attain their goals towards aconvergent All-IP-Network in order to leverage the end-user satisfaction and to drive newstreams of revenues easier than ever before.At IPneo we value the growing needs for IP-based applications. Therefore, we provide ourcustomers with a set of IMS features/APIs for RCS and VoLTE, that are all fully compliantwith the IMS standards, quality-proven through a series of Inter-operability tests, andseamlessly portable to the leading handset equipment and mobile operating systemsincluding: Android, iOS, and Windows Phone 7.JDSUJDSU (NASDAQ: JDSU; and TSX: JDU) innovates and markets diverse technologies thatenhance the way people experience the world every day. We enable fast, high-qualitycommunications, secure financial transactions, reliable consumer electronics, green energy,differentiated brands and a host of other solutions. We provide these solutions through threebusiness segments: Communications Test and Measurement, Communications andCommercial Optical Products, and Advanced Optical Technologies. To learn more aboutJDSU, please visit www.jdsu.com and www.jdsu.tv and follow us on JDSU Perspectives,Twitter, Facebook and YouTube.MetaswitchMetaswitch Networks powers over 600 network operators worldwide and is a leading providerof the technologies and solutions that are empowering the migration of communicationsnetworks to open, next-generation architectures. For over 30 years, Metaswitch has beeninnovating solutions to simplify communications, add next-gen functionality and services,while addressing the challenges of converging networks and devices.SamsungSamsung Electronics Co., Ltd. is a global leader in semiconductor, telecommunication, digitalmedia and digital convergence technologies with 2010 consolidated sales of US$135.8 billion.Employing approximately 190,500 people in 206 offices across 68 countries, the companyconsists of nine independently operated business units: Visual Display, MobileCommunications, Telecommunication Systems, Digital Appliances, IT Solutions, Digital Page 58
  • 59. Imaging, Memory, System LSI and LCD. Recognized as one of the fastest growing globalbrands, Samsung Electronics is a leading producer of digital TVs, semiconductor chips,mobile phones and TFT-LCDs. For more information, please visit www.samsung.com.StokeAbout Stoke, Inc.Stoke is the mobile industry’s only transformation platform, delivering future-focused thinkingand solutions for 3G and 4G mobile broadband infrastructures. Stoke enables mobileoperators, through the application of Business-Crossover™ thinking, to overcome limitationsinherent in legacy approaches and architectures, helping them tackle the new realities of 3Gmobile data service delivery today and successfully navigate their transition to 4G servicesplatforms tomorrow. For more information, visit www.stoke.com.TellabsTellabs innovations advance the mobile Internet and help our customers succeed. Thats why43 of the top 50 global communications service providers choose our mobile, optical,business and services solutions. We help them get ahead by adding revenue, reducingexpenses and optimizing networks.Tellabs Smartcore® 9100 series is a purpose-built mobile packet core platform offeringunmatched performance with integrated network intelligence. So you can deploy smartHSPA, LTE and WiMAX networks that optimize network resources, deliver new revenuegenerating services and monetize the mobile Internet.Traffix SystemsTraffix Systems was born in the wake of the telecommunications industrys adoption of theDiameter signaling protocol as the preferred signaling protocol to enable the users to connect,move, use and pay for network resources and services in next-generation architecture suchas LTE, IMS and HSPA+.While acclaimed for its high bandwidth and the promise of exciting new data services, LTEintroduces substantial core network complexity due to the addition of many more networkelements, advanced services and new policy and charging schemes. Operators own the taskof managing all this complexity, the most challenging of which occurring in the Diametercontrol plane.Since 2005, the Traffixs team of experienced telecommunications experts has focused onsolutions for the Diameter control plane with a portfolio of Diameter products including aDiameter Gateway, Diameter Load Balancer and Diameter Router.With the adoption of HSPA+, IMS and LTE as the technologies of choice for mobile data andDiameter as the underlying signaling protocol, there is an increasing need for carrier-grade,Diameter signaling products. Traffixs products fulfill these needs, as well as each and everyoperator challenge for seamless and cost-effective signaling related to connectivity,scalability, routing, failover management and overload control, security and messagenormalization and visibility, performance monitoring and troubleshooting. Page 59
  • 60. In 2011, Traffix announced a market-first: The Signaling Delivery Controller (SDC), a singleplatform consolidating fully-featured solutions of a Diameter Gateway, Diameter LoadBalancer and Diameter Router to deliver a truly convergent solution. With its SDC technology,Traffix has set the industry benchmark for Diameter signaling solutions.In addition to Diameter, the SDC supports a multitude of additional protocols, e.g. SS7,RADIUS, GTP’, LDAP, HTTP, JMS. This makes it an attractive solution when interaction withlegacy equipment is required.With much of the groundwork already completed, Traffix strives to bring to marketevolutionary signaling products that enable intelligent and simplified network control,management and advanced subscriber context awareness for operators to unleash the fullpotential of their 4G networks.For more information, please visit www.traffixsystems.com or write info@traffixsystems.com.VSS MonitoringVSS Monitoring is the world leader in Network Intelligence Optimization, providing a visionary,systems-approach for optimizing and scaling the connectivity between network switching andthe entire network intelligence ecosystem of analytics, inline security, and WAN accelerationtools. For more information, visit www.vssmonitoring.com.ZTEZTE is a publicly-listed global provider of telecommunications equipment and networksolutions with the most comprehensive product range covering virtually every sector of thewireline, wireless, service and terminals markets. The company delivers innovative, custom-made products and services to over 500 operators in more than 140 countries, helping themto meet the changing needs of their customers while achieving continued revenue growth.ZTE’s 2010 revenue led the industry with a 21% increase to USD10.609 billion. ZTE commits10 percent of its revenue to research and development and takes a leading role in a widerange of international bodies developing emerging telecoms standards. A company withsound corporate social responsibility (CSR) initiatives, ZTE is a member of the UN GlobalCompact. ZTE is China’s only listed telecom manufacturer, publicly traded on both the HongKong and Shenzhen Stock Exchanges (H share stock code: 0763.HK / A share stock code:000063.SZ). For more information, please visit www.zte.com.cn. Page 60