GMI 2008

GMI 2008

Application and Service testing in global

Next Generation Networks

2 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’

Abstract

This white paper provides a summary of the MultiService Forum’s (MSF) Global MSF Interoperability 2008 event (GMI 2008), which took place from October 20-31, 2008.

GMI 2008 is the fourth in a series of biannual events designed to test standards compliance in network scenarios of interest to major Service Providers and to gauge vendor support for emerging technolo-gies. Building on the success of previous events, GMI 2008 provided the first ‘real network’ multi-vendor trial of innovative new services deployed over a converged Internet Protocol (IP) Multimedia Subsystem (IMS) infrastructure.

Incorporating an IMS core compatible with the Third Generation Partnership Project (3GPP) Release 7 (R7) standards, the MSF Release 4 (R4) architecture introduces the concept of access tiles to support a range of both fixed and wireless access technologies. The IMS core provides the basis for introducing a range of service capabilities, including IMS-based IP television (IPTV), Service Oriented Architecture (SOA) gateways, and Location services. Voice over IP (VoIP) softswitches are also supported to main-tain backward compatibility with previous MSF architecture releases and to reflect real life deploy-ments in Service Provider networks.

During the event it was observed that most of the defined interfaces were mature and interoperable, however configuration issues needed to be resolved. Calls were successfully established across all access technologies and between most combination pairs. Roaming was also successfully tested for most relevant access types. Although essential standards are reasonably mature, the overall architec-ture is very complex, and requires significant choices to be made in local configurations. Events like GMI highlight these difficulties and prove the validity of the MSF approach to developing Implementa-tion Agreements (IAs) as an aid to achieving multi-service interoperability.

White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 3

Contents

Executive Summary 4The MultiService Forum (MSF) 4GMI 2008 4Key Objectives of GMI 2008 4Key GMI Statistics 5Key Results 5

Introduction 6

Part I: Participants and Planning 8Host Sites 8Vendor Participants 10ATIS IIF Partnership 10

Part II: GMI 2008 Execution 11The Six Network Test Scenarios 12

Part III: Results and Issues 14Future Work 15

Appendix A: The Six Test Scenarios 16Test Environment 16Scenario 1 – End-to-End Session Control 16Scenario 2 – End-to-End Session Control with QoS 18Scenario 3a – IMS IPTV 20Scenario 3b – ATIS IIF IPTV Tests 22Scenario 4 – Location Based Services 26Scenario 5 – Web Based Services 27Scenario 6 – Management 28

Appendix B: MSF R4 Implementation Agreements 30

Appendix C: The Benefits of MSF Membership 33


Executive Summary

The MultiService Forum (MSF)

The MSF is a global association with a membership drawn from the world’s leading IP communications companies. The MSF promotes the testing of interoperability based on open standards. The GMI events are a key component of this program.

GMI 2008

GMI 2008 is the fourth in a series of biannual events designed to test standards compliance in network scenarios of interest to major Service Providers. Building on the success of previous events, GMI 2008 provided the first ‘real network’ multi-vendor trial of innovative new services deployed over a con-verged IP Multimedia Subsystem (IMS) infrastructure.

Building on the MSF Release 3 (R3) architecture, the MSF R4 architecture added:

1. Third Generation Partnership Project (3GPP) Release 7 (R7) and European Telecommunications Standards Institute (ETSI) Telecoms & Internet converged Services & Protocols for Advanced Net-work (TISPAN) defined network elements, as well as Alliance for Telecommunications Industry Solu-tions (ATIS) IPTV capabilities

2. Support for a range of fixed and wireless access technologies connected to the same IMS core, including support for end-to-end Quality of Service (QoS)

3. Support for IMS-based IP television (IPTV)

4. Location-based services

5. Service Oriented Architecture (SOA) gateways

6. Performance Management and 3GPP defined off-line billing.

Backward compatibility with previous MSF architecture releases was maintained to reflect real life deployment of VoIP softswitches.

The MSF R4 architecture is supported by over 40 MSF IAs that are based on corresponding ATIS IPTV Interoperability Forum (IIF), ETSI TISPAN Next Generation Network (NGN) Release 1 and 3GPP R7 speci-fications. These IAs provide the detailed specifications for the key interfaces tested in GMI 2008.

Interoperability testing was conducted within each lab and between labs, using a total of 87 test cases organized into six test scenarios. Given the breadth and depth of the tests it was necessary to develop a customized tool to record the test results. This gave the MSF a unique capability to capture, automatically aggregate, and analyze globally distributed test results.

Key Objectives of GMI 2008

IMS provides a comprehensive architecture that allows all users to connect to a variety of IP-based multimedia services in a consistent way. In addition it facilitates the rapid development of coherent services across a variety of underlying infrastructures and eliminates the need for vertical service ‘stovepipes.’ Demonstrating this capability in action was a key overarching objective of GMI 2008. In addition, GMI 2008 was designed to:


Demonstrate that an IMS network manages end-to-end call session control with a variety of access network technologies (fixed and wireless access)

Demonstrate support for user-level, end-to-end QoS control across the different access network types.

Demonstrate the implementation of new service types using the converged IMS core, including:

IPTV Service over an IMS core

Location-based services with an access-network-agnostic Access Location Server (ALS) that delivered precise location information about the IMS user for use by Emergency Call and other location-based routing services.

Demonstrate support of a SOA service layer that enables Web-based services to access the IMS core, thereby allowing software developers to create communications-enabled applications in much shorter timeframes

Demonstrate the ability of network operators to:

Gather IMS network element Performance Management data that helps address network issues and maintain customer satisfaction, resulting in increased average revenue per user (ARPU)

Remotely Configure and Manage IPTV Set-Top-Boxes.

Key GMI Statistics

GMI 2008 involved five major Service Provider as well as independent labs in the US, Asia and Europe (Verizon, National Communications System (NCS), University of New Hampshire Interoperability Lab (UNH-IOL), China Mobile and BT/Vodafone).

Over 225 network components from 22 participating vendors were tested by 125 test engineers using over 600 pages of test plans and working around the clock during this 12-day event.

The six physical scenarios incorporated a total of 87 basic test cases, with over 400 related sub-test cases. During the event a total of 700 test results and associated trace files were uploaded into MERLIN – the MSF’s in-house test scheduling and recording tool.

IPTV was a key focus of GMI, with 38 test cases designed to rigorously test the capability and robust-ness of IPTV solutions.

Key Results

IMS protocols are generally mature and IMS products interoperate across Service Provider environ-ments.

IMS products employing QoS enable an end-user experience that is superior to best effort Internet services.

IMS demonstrated the ability to provide a platform for convergence of a wide range of innovative services such as IPTV.

Though the IMS standards are mostly mature, the overall architecture is complex and the choice of implementation significantly impacts interoperability.


Introduction

GMI 2008 was designed to build on the work done in GMI 2006 and substantiate a range of innovative new services on a converged IMS infrastructure that supports a variety of access mechanisms.

The GMI 2008 test environment was based on:

(1) IMS as the basis of Service Provider-grade session control

(2) QoS control as an essential underpinning for content-intensive services

(3) Representative services deployed on the converged IMS core, including: (a) IPTV as a key content-intensive service (b) Location-based services.

(4) Service-Oriented Architecture as a mechanism for rapid service creation with access to IMS ses-sion control

(5) The management of these services.

Publishing the results of GMI 2008 provided valuable feedback based on tests carried out in real world networked scenarios that were of great interest to the Standards Development Organizations (SDO) community. The key relationship between the MSF and relevant standards bodies is illustrated in Figure 1. This figure illustrates the virtuous circle from the development of the MSF R4 architectural framework and supporting MSF IA’s, to the testing provided by GMI, and finally to the feedback pro-vided to the SDOs responsible for the original standards.

Figure 1 The results from the testing and interoperability programs are fed back to the relevant standards bodies, i.e. there is a virtuous circle.


Users expect new services and features to be provided in ‘Internet’ time. Recognizing this fact, the ATIS IIF looked to the MSF to jointly test its emerging IPTV standards so that subtle issues could be identified and corrected before its standards were finalized. ATIS jointly developed GMI 2008 IPTV test plans with the MSF and were participants in the testing. This first hand experience was immediately fed back into its IIF standards effort. This approach shortened the typical MSF – SDO feed forward / feed back loop by 6 to 12 months.

This white paper is organized into three parts and three appendices. In Part I, the planning that went into GMI 2008 is discussed. Part II discusses the two-week event, while Part III discusses the key results obtained from the GMI event. Appendix A provides more details on the six test scenarios. Appendix B identifies the MSF Release 4 IA. Appendix C discusses the benefits of MSF membership.


Part I: Participants and Planning

GMI 2008 involved a diverse group of IP communications professionals whose common goal was to test the current capabilities of IMS products and services operating in real world Service Provider environ-ments. These tests would allow vendors to improve their products, Service Providers to accelerate their service deployment strategies, and the MSF to identify standards shortfalls to the appropriate SDOs.

A two-week test event involving five inter-networked lab sites, 22 vendors, 125+ participants, 225+ components and 400+ test plans requires careful planning. A dedicated committee of 14 people, along with numerous volunteers, spent over 18 months preparing for the event.

Planning for GMI 2008 started in January 2007 with the creation of task forces to identify scenarios and tests for GMI 2008. Creation of the test plans was an iterative process with details being added as planning progressed.

Inter-lab testing was a key objective of GMI 2008. There were five labs that spanned the globe, but active testing of all permutations of vendor-provided IMS cores and access tiles across all sites would have required testing well beyond the available two-week test window. Given the complexity of the event and to help prioritize demand, a Scheduling Committee was created to develop a test schedule acceptable to all participants

In addition to test planning, host site selection, preparation and network interconnectivity needed to be completed before the start of testing. Biweekly network planning meetings among the host sites, and six vendor participation calls kept the GMI 2008 participants informed of the preparation progress and the required inputs and activities. Preparation activities peaked the week before GMI started, as participant engineers arrived at the host sites to ensure that the components were installed so that testing could commence on time.

Host Sites

Tier 1 Service Providers provided GMI host sites in the US, UK and China, thereby allowing the various tests and scenarios to be deployed in an environment that replicated a live global network. In GMI, however, there were no subscribers; instead engineers made extensive use of test tools and emulation to actively monitor product performance and track, identify and fix issues.

Testing was structured to enable both intra-site and inter-site testing, with each host site first carrying out testing against up to six scenarios in isolation before carrying out collaborative networked testing with other labs.

BT and Vodafone

BT and Vodafone joined forces to provide the UK host site at BT’s Adastral Park Laboratory, Ipswich, UK. GMI’s focus on ‘real-life’ deployment scenarios taking place in multiple sites around the world pro-vided the opportunity to prove ‘real-life’ roaming and nomadic scenarios that would not be possible in single lab test events. In addition, BT and Vodafone were able to demonstrate practical applicabil-ity of Fixed Mobile Convergence with two major Service Providers working together to prove service interoperability within a coherent IMS Core Network solution. Given the ‘network of networks’ aspect of any practical deployment, the inclusion of tests to demonstrate end-to-end QoS across a multiplic-ity of access tiles was of particular importance. Other pioneering work at this site included Location Management tests appropriate to a fully converged IP NGN.


Verizon

Verizon provided a host site at its Waltham, Massachusetts Laboratory in order to advance the imple-mentation of industry standards and to assess the maturity of IMS services, applications and other NGN technologies including IPTV, SOA, Charging, IMS transit network, QoS, and network and service management.

IPTV was particularly important and Verizon wanted to find the additional interfaces and devices that would be required for an NGN to support IMS-based video services. Verizon also wanted to explore the architecture for and potential of SOA since it allows Service Providers to offer a wide range of services. SOA is an architecture paradigm that enables components from both IMS and non-IMS infrastructures to be used as part of new application and service developments.

The importance of charging is self-evident and flexible charging models are required. IMS transit net-works are relevant from the wholesale traffic perspective. The importance of QoS is also self-evident; it provides a way of service differentiation and a good Quality of Experience (QoE) is mandatory for multimedia services such as IP Video.

China Mobile

GMI 2008 allowed China Mobile to establish a test network with other host-sites and that gave them the ’real-life’ roaming and nomadic environment to gain experience of interoperability with other Ser-vice Providers. The most important difference between IP communication networks and the Internet is the provision of a guaranteed QoS. The end-to-end QoS test scenario was therefore of particular interest and was considered to be the best way to validate QoS solutions within an IMS core network, especially under the demanding conditions of long-distance roaming environments.

NCS

The National Communications System (NCS), part of the Department of Homeland Security, is the US Government agency responsible for providing priority communications for Continuity of Government and Continuity of Operations during times of national and man-made disasters.

Analysis has shown that using the Public Switched Telephone Network (PSTN) to make priority calls is more cost effective and resilient than any private Government network, especially since disasters can occur anywhere in the US. However, during times of disaster, the PSTN may become congested when call attempts and traffic can reach ten times the normal engineered load. It is during these times that the priority calls must be completed. As the PSTN evolves using NGN technology, it is important that the priority features of the PSTN continue to work. In addition, NGN technology can provide additional priority services.

NCS worked with vendors at GMI events to demonstrate the interoperability of priority communica-tions under congestion conditions. The benefits of participating included a better understanding of the QoS capabilities being demonstrated in the GMI 2008 access tiles and a demonstration of end-to-end Emergency Telecommunication Services capabilities under GMI QoS scenarios. The resulting informa-tion will be used to refine IMS and Access Networks Industry Requirements documents being developed by the NCS; this information will then be supplied to Standards Organizations.

UNH-IOL

The University of New Hampshire InterOperability Laboratory (UNH-IOL) sees GMI events as an oppor-tunity to help the industry foster and adopt quality, interoperable NGN and IMS solutions. As part of the network design team, the UNH-IOL saw GMI 2008 as an opportunity to expose undergraduate and graduate students to the ongoing technical advancements in the IP communications industry through practical, real-world deployment scenarios. The UNH-IOL also saw GMI 2008 as an opportunity to test today’s networking equipment with the engineers of tomorrow and in that way help educate the next generation of industry professionals.


Vendor Participants

Twenty-two companies participated in GMI 2008:

The network equipment vendors were Acme Packet, Alcatel Lucent, Fujitsu, Huawei Technologies, Motorola, NEC, Nokia-Siemens Networks, Nortel, Sonus, Starent Networks, Tekelec, TELES, and the ZTE Corporation.

The test equipment vendors were Codenomicon, Empirix, Ixia, JDSU, MuDynamics, OSI, Spirent, Tektronix and Telchemy.

ATIS IIF Partnership

ATIS is an SDO whose mission is the rapid development and promotion of worldwide technical and operations standards for information, entertainment and communications technologies using a prag-matic, flexible and open approach. ATIS priorities include Home Networking, Service-Oriented Net-works, Convergence and IPTV Interoperability.

The ATIS IIF is developing the industry’s end-to-end solution for IPTV – a suite of globally acceptable standards for the delivery of live broadcast video, content on demand and interactive TV. To meet the overarching goal of rapid development and deployment, the IIF joined with the MSF to test and vali-date the IIF’s emerging IPTV standards. This partnership was seen as shortening the typical standards development cycle (specify, prototype, test, correct and augment specifications) by six to twelve months.


Part II: GMI 2008 Execution

GMI 2008 involved four major Service Providers based in China, Europe and the US, as well as a US Government agency test lab and a university test lab. The test scenarios involved the connection of five host labs: one in the UK, three in North America, and one in China. The sites were connected using a full mesh of IP Security (IPSec) Virtual Private Networks (VPNs). The IPSec VPN tunnels were estab-lished and maintained to provide full connectivity between all sites for the duration of GMI testing.

The GMI 2008 network used a different technical solution to that of earlier events. In the past, connec-tivity was provided using dedicated leased lines between each of the sites, with core routers enabling interconnection. This provided a highly reliable infrastructure, but it had two key disadvantages: it was very expensive, and it did not provide the flexibility possible with VPNs.1

The use of flexible VPNs provided important advantages. It allowed each site to give participating vendors remote access to their equipment in GMI. This was an important capability because it allowed vendors to complement onsite staff with personnel at home locations. Some sites enabled this by providing participants remote access via PC, client-based remote access (e.g., Nortel Contivity), while others took advantage of the VPN capabilities of the secure routers to provided the participants with a unique publicly routable IP address to assign to their equipment as needed. The VPN routers provided each vendor with secure access to their equipment from any remote location. The ability to support secure access from remote locations will enhance flexibility and enable ad hoc testing in future interoperability events.

1 Nortel’s Secure Router 4134 is a modular, multi-service platform that integrates multiple networking functions, including routing, WAN, Ethernet switching, security and VoIP into a single device. The platform’s design ensures the consistently high throughput required by voice, data or unified communications applications. It was an ideal approach to provide the connectivity required to support a global event such as GMI.

Figure 2 A new feature of the GMI 2008 network was the inclusion of VPN IPsec tunnels. These are enabled by Nortel routers at each site. Additional functionality included PSK encryption with a common key and dynamic routing.


An out-of-band management network was also set up at some of the sites to merge the remote access and local access for each participant and create vendor-specific management networks. The local access to the management network provided participants with secure connectivity to their equipment even though testing was conducted from control rooms outside the actual lab. The management net-work was designed with security in mind; it was essential that participants would not be able to access each other’s equipment over the management interfaces.

The use of VPNs was judged to be a major success for GMI 2008. They provided more secure, flexible, and cost effective connectivity than the leased line approach used for previous GMI events. The VPNs were set up using secure routers, provided by Nortel, deployed at each site .

The Six Network Test Scenarios

Figure 3 is a high-level view of the R4 architectural framework. The end-to-end IMS network is shown by the IMS core ‘hexagon’ and surrounding access technologies. Signaling and control for QoS is instan-tiated in the end-to-end IMS network. Specific applications, such as IPTV, build upon this foundation. Coordinated management of all applications and network components is key to providing superior services to the user.

This high-level architecture formed the basis of the six scenarios for the GMI 2008 event. These sce-narios were:

S1 - end-to-end session control – focused on the end-to-end IMS network. S1 built upon the IMS core testing done in GMI 2006 (the red hexagon in Figure 3) with additional IMS vendor cores and with a range of access technologies.

Access tiles included baseband, broadband, 3GPP, 3GPP2, WiMAX, and Time Division-Synchro-nous Code Division Multiple Access (TD-SCDMA) (shown in the yellow squares in Figure 3).

Figure 3 This shows how the IMS core can be accessed using all mainstream wireline and wireless access technologies. A QoS layer is added to underpin the IPTV, Web and Location services. And a management layer completes the picture.


Wireline / wireless convergence, nomadic (roaming) users, and PSTN and non-IMS Session Initia-tion Protocol (SIP) endpoints were tested to ensure backward compatibility with previous test-ing and real world implementations.

S2 - end-to-end session control with QoS – built on S1 by testing the TISPAN Resource and Admission Control Subsystem (RACS) / Network Attachment Subsystem (NASS) and 3GPP / WiMAX Policy and Charging Rules Function (PCRF) interfaces. (This is the light blue box in Figure 3).

S3 - IPTV – included two sub-scenarios:

S3a – IMS-based IPTV: conformance and Interoperability tests, covering the modules within the IPTV Apps server, Video media server, and IMS-based IPTV UE.

S3b – ATIS IIF-based IPTV conformance tests that focused on key IIF standards covering authen-tication and initialization of IPTV Terminal Function (ITF) and validation of QOS metrics as outlined in ATIS specifications.

S4 - location-based services – covered the capture of correct location information of an endpoint and its usage in such services as emergency calls and location-based routing.

S5 - SOA gateway – covered the inclusion of Web-based applications in a service-oriented architec-ture over a converged SIP / IMS infrastructure.

S6 - management – involved management of IPTV Set-Top Boxes, collection of IPTV-related statis-tics and off-line billing.

These scenarios are discussed in more detail in Appendix A.


Part III: Results and Issues

Most of the issues encountered during GMI were related to routing and configuration rather than protocol problems. IMS protocols are now fairly mature, which seems reasonable given that 3GPP is currently working on R8. Calls were successfully established across all access types and between most combination pairs. Roaming was also successfully tested for most relevant access types. Though essential standards are reasonably mature, the overall architecture is very complex, and requires significant local configuration. Events like GMI highlight such difficulties and prove the validity of the MSF approach to developing IAs as an aid to achieving multi-vendor interoperability.

There was no support on commercial UEs for 3GPP extensions. Fortunately, IMS edge devices (Proxy-Call Session Control Function (P-CSCF) and Session Border Gateway (SBG)) on the cores tolerate the lack of support of these headers. This reinforces the fact that IMS deployments must be backward compatible with SIP clients, since this is likely to be the case for some time. This also points to the need to support a flexible and extended transition from SIP to IMS, with each step of the transition being driven by solid business rationale.

Only digest authentication was tested. No AKA authentication via Universal Integrated Circuit Card (UICC) / IP Multimedia Services Identity Module (ISIM) was tested, even though IMS cores typically support both methods. This has been identified as an important technical area and will be a focus of future MSF testing.

The lack of implementations of the MSF-defined interface, LOC-1, precluded testing of S4 (Loca-tion Services). The MSF Loc-1 IA has been the basis for robust and substantial contributions in this area into the appropriate SDOs (ETSI and the UK Network Interoperability Consultative Committee (NICC)).

The partnership between the MSF and the ATIS IIF for GMI 2008 made it possible to test early implementations of key IPTV standards in a realistic network deployment scenario. This provided early visibility of the effectiveness of the base protocols and an opportunity to identify areas for optimization. The insight from these tests is being fed back into IIF and the standards are being updated as a result.

ATIS-0800017 stipulates three options for Automatic Configuration Server (ACS) device discovery, involving mechanisms by which the Dynamic Host Control Protocol (DHCP) server informs the ACS of service provider information. With the industry moving towards the adoption of Techni-cal Report (TR) 069 enabled devices for remote Set Top Box (STB) management, this poses a fundamental issue in that TR-069 enabled-devices require a fully-qualified Uniform Resource Locator (URL) issued in an INFORM. Options 1 and 2 do not provide sufficient information for a TR-069 device to construct the ACS URL without having additional information. The likely result to emerge in the IIF specification is the mechanism by which the DHCP Server provides the full URL of the ACS in DHCP Option 43.

Testing of ATIS 0800017 IPTV also yielded some crucial information on service provider provision-ing on a device. The specification stipulates that for a TR-069 device, a single string parameter should be populated with an instance of the eXtensible Markup Language (XML) schema defined in IIF-WT-028R9_CDDC_Metadata for IPTV service providers. This is not a tractable solution for TR-069 devices because the string would need to be entirely encoded to prevent parsing errors. It also diverges substantially from standard TR-069 mechanisms.

This was the first ever IMS IPTV interoperability event, and was an important validation of the potential for IMS as the basis for multimedia service convergence.

The ETSI IPTV specifications allow two distinct methods for establishing an IPTV session, and one of the methods allowed three sub-options. This complicated interoperability significantly. It is recom-


mended that future interoperability events evaluate the relative effectiveness of each method to determine the best approach for large-scale deployment of the service.

In many cases, MSF IAs do not provide guidance on the appropriate transport protocol to use. This led to a number of instances where equipment needed to be reconfigured before testing could pro-ceed. While this did not prevent interoperability, it did complicate it. Specification of these details in future IAs would improve interoperability. Specific instances where this occurred included:

Diameter: Transmission Control Protocol (TCP) vs. Stream Control Transmission Protocol (SCTP)

SIP signaling: User Datagram Protocol (UDP) vs. TCP.

When testing roaming scenarios, a number of implementation issues were discovered that com-plicated interoperability. In most cases, these issues were addressed by using the Session Border Gateway (SBG) to normalize protocols. This shows that more attention to implementations in sup-port of roaming will be required. The problems, in general, related to the improper use, or absence of Path Header, Service Route, Route Header and P-Headers.

For Network-to-Network Interface (NNI) scenarios, P-Header manipulation (e.g. stripping and inserting network specific headers) is a key function at the network boundary. There were a number of instances where implementations did not perform P-Header manipulation correctly. Although there is no standards impact, it reinforces the importance of robustness and security testing as a future focus for the MSF.

The Parlay-X Application Programming Interfaces (APIs) were found to be highly interoperable between a range of vendors. However the ISC interface between the SOA Gateway and the IMS core was found to be much less open. Some implementations had vendor specific restrictions that precluded interoperability. It appears this is a function of the maturity of the products, rather than an issue with the standards.

Building on our tradition of testing in real world scenarios, GMI 2008, for the first time ever, included performance management testing. This added an important dimension to the testing and it will become increasingly important as the base interoperability becomes widely available.

In one test the configuration parameters for VoIP performance management were not specified explicitly in the IA. Interoperability was not possible until these were agreed. This will be incor-porated into the IA.

The ITU-T standards list a wide range of performance metrics that could be monitored, but they do not recommend the specific ones that must be monitored. Going forward, firm recommenda-tions will be required, either in the standards, or in MSF IAs.

Future Work

GMI 2008 showed that interoperability is not an impediment to providing new services. However, to provide a superior user experience relative to best effort Internet services, attention must be paid to QoS, network and application management, and security. New services using service-provider infor-mation (such as location) require both APIs and rules for how and when the information can be used. Working with SDOs to shorten the standards development cycle is also key to delivering services in Internet time. This reality dictates how the MSF will evolve. Interim testing will occur during 2009, and we anticipate that GMI 2010 will focus on applications versus network transport. This adaptation will allow the MSF to continue to provide value to its members.


Appendix A: The Six Test Scenarios

Test Environment

Figure 4 presents a high-level diagram of the test environment used for the six test scenarios.

Scenario 1 – End-to-End Session Control

Scenario 1 demonstrated the ability of the IMS Core to simultaneously support a wide range of access network types and manage end-to-end session control across the different access network types. It also added the capability of the 3GPP defined ‘Transit Function’ network element and its capability to intelligently route calls from a peering network to a wholesale-IP user, PSTN user and IMS user. The following access network types were supported:

Baseband (via ISDN terminating on an IMS terminal adaptor)

WIMAX Radio Access Network (RAN)

TD-SCDMA RAN (3G radio technology)

3GPP RAN

3GPP2 RAN

Broadband (DSL & Fiber)

Emulated PSTN

Figure 4 A high-level view of the GMI 2008 test environment.


Scenario 1 Objectives

1 Validate User Equipment (UE) network attachment over different access network types and suc-cessful registration with the IMS core.

2 Make end-to-end IMS calls between different access networks supported by the same / different IMS core networks (over Network-to-Network Interconnect Interfaces using Session Border Control-lers).

3 Make calls to other IMS users, 3GPP / 3GPP2 RAN vendors used RAN emulators and emulated UEs.

4 Validate IMS roaming when an IMS user from vendor 1 roamed into another vendor’s IMS core. In this case registration and calls to / from roaming users from home and visited networks over the NNI Interface were tested.

5 Demonstrate the priority handling of calls using the US Government-defined Resource Priority Header (RPH) as part of the Government Emergency Telecommunications Service (GETS) standard.

6 Demonstrate the 3GPP-defined Transit Function capability that enables the network operators to intelligently route calls from peering networks to IMS core / PSTN / other Wholesale IP peering networks.

7 Demonstrate WiMAX RAN solutions and the capability to interwork with IMS, and to validate the R6 interface between the HA and ASN-Gateway, as defined by the WiMAX Forum.

8 Demonstrate support for the TD-SCDMA RAN solutions and the capability to interwork with IMS.

Scenario 1 Testing Results and Observations

The Scenario 1 test plan defined 17 basic test cases. The basic test cases were expanded into 289 sub-test cases to distinguish sessions between the different technology access types, home / visited network combinations, and set-up / teardown. Teardown was independently tested because prior test-ing has shown that issues can occur with SIP signaling during call termination. While not all sub-test cases were executed during GMI, 15 of the 17 basic test cases were covered.

Figure 5 End-to-end session control across seven access types.


The global end-to-end nature of GMI, a key objective of testing, was fully achieved, with nearly half of the tests executed intersite. Table 2 summarizes the S1 test results.

Total Tests Run 409

Total Tests Run Intra/Inter Site 211 / 198

Table 2 S1 Test Results

Analysis of the Scenario 1 tests:

Testing results reflected the increasing maturity of IMS cores and related control protocols, although ease of network element configuration options in a multi-vendor network solution remains a chal-lenge.

Based on the fact that most of the vendors used IMS-enabled soft clients / commercial IP-enabled phones at the event, authentication testing was limited to Hypertext Transfer Protocol (HTTP) Digest or Message Digest algorithm 5 (MD5).

The P-Visited-Network-ID header was not included by the visited IMS in some roaming scenarios, leading to registration failures.

Based on fact that standards can be ambiguous, in some cases interworking issues were encoun-tered and were resolved by manipulating SIP headers at the SBG leading to specific configuration profiles for each pair of IMS cores.

Some clients did not correctly apply the codec selected during negotiation. In spite of negotiating an A-law codec, these clients then used their default Mu-law codec.

Scenario 2 – End-to-End Session Control with QoS

Building on the network architecture validated in Scenario 1, Scenario 2 demonstrated how network operators can evolve their IMS cores to add support for QoS using the access and core network archi-tecture defined by 3GPP, 3GPP2, TISPAN, TD-SCDMA and WiMAX to deliver a rich end user Quality of Experience (QoE).


1 Demonstrate dynamic QoS support over different access network types and the IMS core.

2 Maintain end-to-end QoS session requests in the access and core networks for audio and video ses-sions. This was done for both intra- and inter-IMS calls.

3 Demonstrate session modification resulting in changes to existing end-to-end QoS resources.

4 Demonstrate priority calling for Emergency Telecommunications Services through support of the US Government-defined RPH as part of the GETS standard. The RPH allows for priority to be granted for video calls and the ability to maintain the priority over inter-IMS calls that involve more than one network provider.

5 Demonstrate support for dynamic QoS in Broadband, Fiber To The Home using the TISPAN RACS model and 3GPP2 access using Services-Based Bearer Control (SBBC) model and interworking with the IMS Core.

6 Demonstrate support for static QoS in the WiMAX RAN and the IMS network.

7 Demonstrate support for dynamic QoS in TD-SCDMA RAN and the IMS network.



The Scenario 2 test plan defined 10 test cases. Based on the need to test support for QoS across the various access network type combinations and the need to test home / visited network and call setup / teardown, 48 sub-test cases were defined. While not all sub-test cases were executed during GMI, 7 of the 10 basic test cases were covered.

Total Tests Run 137



Table 3 shows the S2 test results. Analysis of the S2 tests shows:

WiMAX participants used Static QoS with the exception of one vendor who demonstrated a TISPAN-based dynamic QoS solution at the event. The dynamic QoS architecture defined by the WiMAX Forum as part of the NWG Rel 1.5 program could not be validated at the event due to its completion just before the event occurred.

Interworking issues on the TISPAN-defined H.248 Ia interface between the Services-based Policy Decision Function (SPDF) and the Border Gateway Function (BGF) were resolved by having specific configuration profiles for each pair of SPDF and BGF. This was due to the standard not being specific enough, allowing vendor interpretation of the requirements in some scenarios,.

Testing across the Gq’ and Rx interfaces was not successfully completed due to incompatibility between versions of the Gq’ specification. It is expected that the industry will standardize on the latest version, and this problem will be resolved.

Scenario 3a – IMS IPTV

Building on the network architecture validated in Scenario 1 and 2, Scenario 3 demonstrated how network operators can evolve their IMS core to add support for IMS-enabled IPTV services using an architecture based on protocols defined by TISPAN over different access network types. S3a covered a variety of IMS-base IPTV testing (including linear / broadcast TV, Video on Demand (VOD), and

Figure 6 QoS added to end-to-end session control.


network-based Personal Video Recorder (nPVR)) and interoperability scenarios. S3a also demonstrated the session initiation and bandwidth reservation capabilities of IMS, the program guide and service control capability of the ‘Service Selection Function (SSF) and Apps-Server’ (modules within IPTV Apps Server), and the high quality video transmission capability between IMS-IPTV-UE (user equipment) and MDF, a part of the Video Media Server (VMS) or head ends. The test scenario includes both M1 and M2 variants (i.e. the mechanism by which the Real Time Streaming Protocol (RTSP) channel and the associ-ated media channel is negotiated.

Service Selection and service provider discovery

Service selection and service provider discovery provides information necessary for the UE to select IPTV services. Service discovery provides the service attachment information. If multiple providers are available, the Service Delivery Function (SDF) provides all information identifying which services the UE subscribes to for each service provider.

With this test case, GMI 2008 verified and examined the service selection and service provider discov-ery using IPTV-related components in the MSF R4 architecture.

Broadcast TV service with trick play

Broadcast is one of the basic services provided by IMS-based IPTV. In IMS-based IPTV, the broadcast program is under the control of IMS. Before starting to receive broadcast programs, a UE initiates SIP signaling to select a channel package. And when the UE starts or stops watching broadcast programs or changes channels, appropriate SIP messages are issued by the UE. This mechanism ensures that IMS has the latest watching status and can collect statistics for future extended services.

Broadcast services are coupled with a trick play feature to allow the user to pause or rewind the broadcast program in any time within a certain viewing window (say 72 hours)

In this test case, GMI 2008 verified the user experience watching broadcast programs, changing chan-nels, and using trick play functions (forward and rewind at various speeds).

Figure 7 The IAs for this test scenario are shown in green.


VoD Service

VoD is an important service provided by IMS-based IPTV. In the session initiation phase, IMS allocates network resources (e.g. bandwidth) for each VoD session to guarantee quality of service. Currently, in the ETSI TISPAN IPTV Standards, there are two methods defined for VoD session initiation sequences, Method-1 and Method-2. Method-1 uses a subset of the RTSP methods defined in RFC 2326, interpret-ing a SIP INVITE and SIP BYE as triggers for RTSP Session Initiation and termination. Method 2 is compli-ant with RFC 2326 and uses the RTSP methods defined in it. Within Method-2 various options have also been defined which take advantage of the SIP methods and messages. The variety of techniques for initiating VOD service in the ETSI TISPAN IPTV specifications highlighted the importance of interoper-ability testing in events such as GMI.

This test case covered all specified mechanisms for user initiated VoD sessions, and for administrative termination by the service provider.

nPVR Service

The nPVR test cases cover the initiation and termination of nPVR sessions. Two types of record requests have been defined in ETSI Standards: ‘impulsive capture request’ to record the live content currently being watched, and ‘off-line capture request’ to record live content unrelated to any active broadcast sessions, e.g. based on an electronic program guide (EPG). This test case also included the ‘park and pick-up’ scenario which is typically implemented by bookmarking a live broadcast stream / program.

Management

QoS and QoE are key performance aspects for IPTV. Even though IMS reserves network resources during session initialization, the measurement of QoS / QoE is still important. This test case confirmed the abiliy to measure video, audio and voice quality and relate the metrics to QoE. The ATIS IIF QoS / QoE metrics were verified and it was observed that even very low levels of packet loss (less than 0.5%) can cause significant impairment of perceived video quality.

Scenario 3a Objectives

1 First testing of IMS-based IPTV.

2 Validate the promise of IMS as the control plane for TV and TV-based enhanced (personalized, por-table, secure) multimedia services.

3 Understand the plethora of methods and options in IPTV network elements for service control and management to recommend preferred methods for standardization.

4 Use the IMS core for IPTV to help unify control plane standards for the emerging multimedia and blended services.

5 Demonstrate that the unified user and service profile in IMS can be used to support personalized, portable, and secure multimedia services.

6 Validate the IMS-enabled STB ability to perform service selection and service provider discovery and its ability to select IPTV services.

7 Validate broadcast service delivery over an IMS-based IPTV network which allows the STB to receive broadcast programs, select channels, start / stop watching, change channels, pause, and rewind programs using appropriate SIP messages.

8 Validate VoD service delivery over a TISPAN-defined IMS-based IPTV network. Understand and ana-lyze the for two different methods (Method 1 and 2) for VoD session initiation allowed.

9 Validate the nPVR service and its capability to initiate and terminate recordings at the user’s request.


10 Measure the user experience over an IMS network that supports QoS versus best effort.

Scenario 3a Testing Results and Observations

The scenario 3a test plan defined 24 test cases and incorporated 40 sub test cases. The higher number of sub-test cases wa due to various methods and options (within a method) supported for session con-trol and management. The IPTV tests covered a number of capabilities. While not all sub-test cases were executed during GMI, 21 of the 24 basic test cases were covered.

Total Tests Run 84


Table 4 S3a Test Results

Table 4 shows the S3a test results. Analysis of the S3a tests:

There are two methods and one has three options, which creates interoperability challenges. Fur-ther study is needed to determine which method is more robust.

Due to early prototypes used for STB emulation, SBCs were required for SIP message normalization towards the IMS core.

Lack of IMS compliant IPTV test tools prevented measurement of IMS and access network perfor-mance.

The trigger for the service request from the IPTV application server needs to be more streamlined.

This scenario successfully demonstrated interoperability of basic and advanced IMS-based IPTV Ser-vices. Further narrowing down of the options would accelerate the end-to-end service implementation and deployment. The results of this testing are being fed back to the relevant stakeholders.

Scenario 3b – ATIS IIF IPTV Tests

ATIS IIF

The MSF partnered with the ATIS IIF for GMI 2008, to test the key IPTV protocols that will be used as the basis for scaleable IPTV deployment. Without a robust architecture, service providers do not have a practical, deployable solution, but with a well-structured architecture, implementing the actual service becomes a relatively easy process, i.e. a series of clearly defined tasks. Thus, the key GMI 2008 objective in the case of IPTV was to test key protocols at the heart of the IIF IPTV architecture.

A number of ATIS deliverables for IPTV have already been published. They include: IPTV architecture requirements and an IPTV roadmap; a framework for QoS metrics and measurements supporting IPTV services; IPTV packet loss and the remote management of devices. In addition 19 standards and speci-fications are under development in five technical committees that deal with an overarching reference architecture, security solutions, metadata and transaction deliver, quality of service metrics, and test-ing and interoperability. The standards are quickly maturing and ATIS concluded that it was important to test these standards as soon as possible to ensure they met service provider requirements in a live network environment.

MSF and ATIS selected two key areas as the focus of their IPTV testing in GMI 2008: (1) network attach-ment and initialization and (2) QoE.

The initial test area in scenario 3B emulated the end user’s initial experience when purchasing an IPTV service. This architecture is based on the ‘retail model’ where the user goes to a retail outlet that sells STBs, which can be connected to any one of a number of IPTV service providers. The user purchases an STB and takes it home. Any one of a variety of mechanisms can be used to subscribe to an IPTV service and obtain an ID and password. Once the STB is connected to the TV and the Net, the user enters the


subscription information and the STB automatically connects to the appropriate service provider, and is configured for the subscribed services. Similarly, if the user moves to a new house, or simply wants to temporarily take the STB to another location, when the box is connected, it will be configured automatically. Configuration will also be automatic if the STB is replaced or if there is a hard reset caused by power failure.

The official term for this process is network attachment and initialization. The overall process of network attachment is different for IMS and non-IMS environments, but the core steps are common to both, and can be tested in a single test configuration. The test plan for GMI 2008 applied to both IMS and non IMS IPTV, based on ATIS-0800017. The data model for this test was based on Broadband Forum TR-135 for a TR-069 enabled STB.

QoE

In order to ensure that an IPTV network is performing correctly, service providers must have a means of correlating QoS measurements (from test equipment) with QoE (the quality as perceived by the end user).

The QoS and QoE tests to do this were based on ATIS-0800008, which defines the metrics to be mea-sured and how to relate these to the user experience. This allowed the various test equipment vendors to follow the same process for a given degradation and thereby find out if everybody gets the same numbers, or, if there was a difference, find out why it occurred. For example, differences can occur if there is a mistake in the way the standard was specified, or if the standard was not sufficiently detailed.

Figure 8 The ATIS IIF test scenario.


The obvious objective of a standard is to enable everybody to perform these important tests in the same way, i.e. there should be no ambiguity. Information that comes from these tests will be fed back to ATIS IIF Quality of Metrics Committee and if necessary there will be a revised version of the standard. Specifying a standard is one thing, but the various tests that they embrace have to be useful, so GMI 2008 allowed the vendors to provide feedback as to whether they provided a useful metric or not.

It is hard to overstate the importance of QoE. Subscribers will not accept an IPTV experience that is inferior to that of regular broadcast services: in fact, they will have chosen IPTV because they expected something better. Thus, QoE and network attachment / initialization are, from the subscrib-ers’ perspective, two of the most-important issues, which is why they were selected for GMI 2008.

Remote STB Management

Remote STB management encompasses configuration, remote diagnostics, and performance manage-ment.

Configuration takes place when the service is accessed for the first time and in an ideal world every-thing works faultlessly. When it does not, or when there is a subsequent problem, remote diagnostics are employed to trouble-shoot and address the issue. The ability to remotely manage the STB is criti-cally important for the reasons outlined earlier, i.e. service providers cannot afford truck rolls.

Performance management is equally important since the business case for IPTV would start to break down if subscribers did not get the expected QoE. This test allowed the service provider to monitor the QoS and QoE parameters and to take action before subscribers start to complain. It is also used to track the services that are being used.

These three use cases are a subset of the TR-135 data model.

The test cases were designed to validate the interoperability between the Remote Management Sys-tem / Auto Configuration Server (ACS) and the STB through the successful collection and reporting of specific parameters, and to validate the ACS’s ability to issue commands to the STB. This allowed the test cases to validate the protocols specified in TR-069 and the data model specified in TR-135.

Scenario 3b covered the authentication and initialization of CPE and validation of QOS metrics as outlined in ATIS specifications.

Scenario 3b Objectives

1 Validate the network attachment and initialization standards as specified in ATIS-0800017.

2 Validate the mechanisms for relating QoS to QoE as specified in ATIS-0800008, which defines the metrics to be measured and how to relate these to the user experience.

3 Test STB management in three key areas:

a Configuration; initial configuration of a STB and collection of baseline information

b Remote Diagnostics; including both the fault management and trouble management aspects of TR-135

c Performance Management; monitoring of STB performance, such as QoS parameters, QoE param-eters, and usage statistics.

Scenario 3b Testing Results and Observations

Scenario 3b involved 13 basic test cases with no further distinction into sub-test cases. Six of the 13 basic test cases were covered.


Total Tests Run 11


Table 5 S3b Test Results

Table 5 shows the S3b test results. Analysis of the S3b:

The testing provided an effective proof of concept test for the basic registration and initialization mechanisms defined by IIF.

The correlation of metrics for QoS with the QoE as experienced by the end user was effectively tested.

ATIS-0800017 stipulates three options for ACS device discovery, involving mechanisms by which the DHCP server informs the ACS of service provider information. With the industry moving toward the adoption of TR-069 enabled devices for remote STB management, this poses a fundamental issue in that TR-069 enabled devices require a full URL to issue an INFORM. Options 1 and 2 do not provide sufficient information for a TR-069 device to construct the ACS URL without having additional infor-mation. The likely result to emerge in the IIF specification is the mechanism by which the DHCP Server provides the full URL of the ACS in DHCP Option 43.

Testing of ATIS 0800017 IPTV also yielded some crucial information on service provider provisioning on a device. The specification stipulates that for a TR-069 device, a single string parameter should be populated with an instance of the XML schema defined in IIF-WT-028R9_CDDC_Metadata for IPTV service providers. This is not a tractable solution for TR-069 devices because the string would need to be entirely encoded to prevent parsing errors. It also diverges substantially from standard TR-069 mechanisms.


Scenario 4 – Location Based Services

Building on the network architecture validated in Scenario 1, Scenario 4 demonstrated how network operators can evolve their IMS core to add support for Location Based Services and Emergency Call Handling using the architecture defined by TISPAN NASS. It also helps ensure that privacy of location information is enforced appropriately at the network boundaries.


1 Support storage of location information received from the intermediate network elements at the ALS.

2 Support location information retrieval over the LOC-1 interface by the Proxy Call Session Control Function (P-CSCF) on successful IMS UE Registration in the IMS core and for emergency calls.

3 Support location information retrieval over the LOC-1 interface by the Presence Server to trigger Location Based services and advertising.

4 Retrieve location information of UE’s attaching to the IMS core (received earlier over the a2 inter-face from the DHCP Server during network attachment).

5 Deliver user presence information via a Presence server.

6 Retrieve the location information and use it to target local ads or information, using a combination of an Application Server and Presence Server,


Scenario 4 involved 10 basic test cases with no further distinction into sub-test cases. Four of the 10 basic test cases were covered.

Figure 9 The MSF Architecture for location services.


Figure 10 The MSF Architecture for SOA-based services.

Total Tests Run 6



Table 6 shows the S4 test results. Analysis of the S4 tests:

Standards based interfaces to provide access location data were not supported and it was not pos-sible to configure an end-to-end system for testing. As an alternative, it was agreed to use static provisioning of Location Information / User IP Address within the ALS.

It was not possible to test TISPAN-defined e4 interface from the ALS to push the user network attachment towards the A-RACS.

Vendors have implemented TISPAN NGN Release 1 solution (i.e. TISPAN e2 without the extensions for location information).

With the exception of one vendor there was lack of implementation of LOC-1 on the P-CSC or inclu-sion of information into the SESS4 interface.

There was no implementation of LOC-1 on P-CSC or inclusion of information into the SESS2 inter-face.

The MSF work in this area has been ahead of standards. As a consequence, available implementations were incomplete. It is anticipated that future product releases will incorporate extensions for location information as being defined in TISPAN R2, based on input from the MSF.

Scenario 5 – Web Based Services

Building on the network architecture validated in Scenario 1 earlier, Scenario 5 demonstrated how network operators can add support for Web enabled services with a Service Oriented Architecture (SOA) Gateway to offer end-to-end session control independent of the underlying IMS infrastructure.



1 Validate interworking from a Web Service using the Simple Object Access Protocol (SOAP) interface to the SOA Gateway and its capability to interwork with the IMS Core or SIP Application Server (AS) as well as its ability to deliver session control, presence and location based services.

2 Validate the SOA Gateway capabilities to interact with non-IMS entities like the Multimedia Message Service (MMS) and Short Message Service (SMS) Gateway to deliver value added services.


The Scenario 5 test plan defined 9 test cases and incorporated 19 sub-test cases. The higher number of sub-test cases is due to a service being broken down into its constituent parts (e.g. Send SMS, Get SMS etc). Five of the 9 basic test cases were covered.

Total Tests Run 31




The Parlay-X APIs were found to be highly interoperable

Lack of a MMS / SMS server prevented testing in this area

The scope of the south-bound interface from the SOA Gateway to the IMS and non-IMS elements needs to be clarified.

Scenario 6 – Management

Building on the network architecture validated in Scenario 1, Scenario 6 demonstrated how network operators can enable data collection points within their IMS core network elements and the IP network to gather network performance data to manage their IMS network. It also added support for 3GPP defined Charging Collection Function (CCF) with the focus for Offline Charging by defining a Offline Charging Server (OFCS) to collect Charging data for IMS calls, and support for an Auto Configuration Server using the TR-069 standard to allow the network operator to remotely manage and configure IMS-based STBs.


1 Configure, collect and evaluate performance data within the IP layer and IMS-defined network ele-ments to monitor and optimize the performance of the IMS network.

2 Gather accounting records from network elements that support the 3GPP defined ‘Rf’ interface for offline charging and generate Call Data Records (CDR) for billing purposes.

3 Validate the capabilities of the Auto Configuration Server (ACS) as a network element to configure and manage STBs installed in customers premises over the TR-069 interface.


The Scenario 6 test plan defined 3 basic test cases and incorporated 19 sub-test cases. The higher number of sub-test cases is due to different diagnostic options in the management tests and different call combinations in the case of off-line billing. While not all sub-test cases were executed during GMI, all 3 basic test cases were executed.


Total Tests Run 22




Testing results reflected the increasing maturity of IMS cores and related control protocols, although ease of network element configuration options in a multi-vendor network solution remains a chal-lenge.

Once configuration issues were resolved the network elements (NE) were able to generate and col-lect the performance data. Due to the lack of a defined interface from the NE to the management plane and proprietary implementations in most of the cases, performance data was provided via ftp, external storage or email.

Vendors used different file formats to report performance data, with no commonality on file format or data structures used in the file.

A variety of performance metrics were reported by vendors; a common minimal set that utilizes the same data representation and data precision would be helpful.

Call performance data was reported in different ways by the vendors (i.e., aggregated statistics for calls, per call performance data, multiple call detailed records for a call).

The Rf interface was not exposed for interop by many vendors


Appendix B: MSF R4 Implementation Agreements

The MSF R4 architecture for 3GPP access networks is shown in Figure 11. Similar architecture exist for the other access network technologies.

Based on this Architecture, Table 9 provides the list of IAs applicable to GMI 2008.

Table 9

DesignationDescription Applicable Implementation

AgreementsMSF ETSI /3GPPref.

TC-0 (IF-2)

Gq' DIAMETER-based protocol to query QoS-controlled bandwidth availability.

MSF-IA-DIAMETER.004-FINAL

TC-1 (IF-3)

Ia H.248-based protocol for NAT and gate control, QoS allocation.

MSF-IA-MEGACO.016-FINAL

TC-5 3GPP Gx DIAMETER-based protocol for admission control, QoS allocation in 3GPP networks

MSF-IA-DIAMETER.009-FINAL.

Figure 9 The MSF Architecture for location services.




TC-6 Rx DIAMETER-based protocol for admission control, QoS allocation in 3GPP networks


TC-7 Ty DIAMETER-based protocol for admission control, QoS allocation in 3GP2 networks


TC-8 Tx DIAMETER-based protocol for admission control, QoS allocation in 3GPP2 networks


TC-9 Rq Diameter based protocol for admission control, QoS allocation in TISPAN networks


TC-10 Gx DIAMETER-based protocol for admission control, QoS allocation in WIMAX networks


TC-11 E4 Diameter based protocol for user profile access in TISPAN networks

MSF-IA-DIMATER.011-FINAL

TR-5 Xd Interface between IMS IPTV UE and SS-MDF

MSF-IA-MEDIA.001-FINAL

SESS-7 Xc Interface between IMS IPTV UE and SS-MCF

MSF-IA-RTSP.001-FINAL

MGC-0 (IF-1c)

-- MGCP-based protocol for access line to packet connection setup and takedown, line signal detection and output.

MSF-IA-MGCP.001-FINAL MSF-IA-MGCP.002-FINAL MSF-IA-SDP.002-FINAL

MGC-1 (IF-1c or IF-1d)

H.248-based protocol for access line to packet connection setup and takedown, line signal detection and output.

MSF-IA-MEGACO.005-FINAL MSF-IA-MEGACO.007-FINAL MSF-IA-MEGACO.008-FINAL (UK market only)MSF-IA-MEGACO.010-FINAL (other markets)MSF-IA-SDP.002-FINAL

MGC-2 (IF-13)

Mn H.248-based protocol for inter-exchange circuit-to-packet connection setup and takedown.

MSF-IA-MEGACO.011-FINAL MSF-IA-SDP.002-FINAL

SESS-0 (IF-1e)

-- SIP-based protocol for call signaling across the UNI.

MSF-IA-SIP.002-FINAL MSF-IA-SIP.003-FINAL MSF-IA-SDP.002-FINAL

SESS-1 (IF-6)

-- SIP with encapsulated ISUP for PSTN bridging and emulation,

MSF-IA-SIP-I.001-FINAL

SESS-2 Gm SIP with IMS extensions for call signaling across the UNI.

MSF-IA-SIP.016-FINAL

SESS2a Gm Gm for IMS based IPTV MSF-IA-SIP.021-FINAL

SESS-4 Mw, Mr, Mi, Mj, Mg

SIP with IMS extensions for call signaling between network components.


SESS-5 Ic SIP for signaling between Call Agents. MSF-IA-SIP.019-FINAL

SESS-7 Xc Interface between IMS IPTV UE and SS-MCF

MSF-IA-RTSP.001-FINAL

SESS-8 Y2 Interface between S-CSC and SS-MCF for IPTV Media Control Function





APP-0 (IF-7)

SESS-5 with additional modifications for invocation of services


APP-1 ISC /Ma SESS-4 with additional modifications for invocation of services.


APP-1a ISC IPTV specific extensions MSF-IA-SIP.020-FINAL

APP-2 -- SIP-based control interface to Media Resource Broker to request assignment of Media Server resources.


APP-4 (IF-11)

-- Parlay API MSF-IA-PARLAY.003

APP-5 (IF-12)

-- Parlay X API MSF-IA-PARLAY.005

APP-7 Mp H.248 based control interface to the Multimedia Resource Function Controller to the Multimedia Resource Function Processor

MSF-IA-MEGACO.015-FINAL

DB-0 Cx, Dx, Dw, Wx

DIAMETER-based protocol to retrieve and update subscriber service profiles.


DB-2 Sh, Dh DIAMETER-based protocol to pass information between the Application block entities and the HSS.


BI-1 Rf Diameter based interface for transfer of Billing Record information

MSF-IA-BILLING.001-FINAL

LOC-1 E2 Diameter based protocol to retrieve location information

MSF-IA.DIAMETER.008-FINAL

MI-1 Interface used to measure Video performance metrics and determine near-term performance of IPTV service

MSF-IA-RTCP.001-FINAL

MI-2 Interface used for IPTV STB Remote Managment MSF-IA-HTTPS.001-FINAL

MI-3 Interface used to pass RTP media metrics from Media Plane to the Control Plane, over H.248


MI-6 Interface used to pass RTP media metrics from the Control Plane to the Management Plane.


MI-9 Interface for Reporting SIP session metrics from Control Plane to Management Plane

MSF-IA-SFTP.001-FINAL

STB-1 Xa Interface used to retrieve service selection data.

MSF-IA-XML.002-FINAL


Appendix C: The Benefits of MSF Membership

The MSF is a global association of service providers, system suppliers, test equipment vendors, and users committed to developing and promoting open-architecture, multiservice Next Generation Net-works. Founded in 1998, the MSF is an open-membership organization whose members are drawn from the world’s leading IP communications companies. The MSF’s activities include developing Implemen-tation Agreements, promoting worldwide compatibility and interoperability of network elements, and encouraging input to appropriate national and international standards bodies.

MSF is a well-established forum with a balanced mix of service providers and vendors that integrates specific work from multiple standards into a holistic network and services architecture. The MSF architecture and solution framework combines legacy and next-generation services in a single uni-fied network. Further, since all MSF participants implement the same baseline features and functions, members can eliminate the guesswork that technology development typically involves.

The advantages of MSF membership include:

Access to more than eight years of groundbreaking industry work with input from key service pro-viders 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 imple-ment 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 GMI events learn how multivendor next-generation products and networks will interoperate in the real world. That informa-tion translates into several financial benefits:

Reduced time to market for deployment of interoperable solutions

Decreased costs and resources to resolve interoperability issues

Improved protocol documentation through clarifications in the MSF IAs and standards process

Thoroughly evaluated architectural framework for cooperatively designing end-to-end networking solutions.

In 2007 the MSF introduced two important, complimentary programs:

1 The Next Generation Networks (NGN) Interoperability Test Bed provides the industry with a perma-nent test bed for testing emerging NGN interfaces

2 The MSF Certification Program provides vendor independent certification of critical NGN function-ality.

Each program is a key element in a three-pronged strategy designed to facilitate implementation of NGNs and to deliver the Forum’s mission statement that ‘We make Next Generation Networks work’. GMI ties everything together by validating products in the latest standards-based architectural frame-work using global network deployment scenarios that are meaningful to Tier 1 Service Providers.


GMI 2008

Technology

msf release

msf ias

msf r4 architecture

event gmi

msf approach

gmi eventsare

key objectives of gmi

ims iptv