Application and Service testing
Next Generation Networks
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.
2 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
Executive Summary 4
The MultiService Forum (MSF) 4
GMI 2008 4
Key Objectives of GMI 2008 4
Key GMI Statistics 5
Part I: Participants and Planning 8
Host Sites 8
Vendor Participants 10
ATIS IIF Partnership 10
Part II: GMI 2008 Execution 11
The Six Network Test Scenarios 12
Part III: Results and Issues 14
Future Work 15
Appendix A: The Six Test Scenarios 16
Test Environment 16
Scenario 1 – End-to-End Session Control 16
Scenario 2 – End-to-End Session Control with QoS 18
Scenario 3a – IMS IPTV 20
Scenario 3b – ATIS IIF IPTV Tests 22
Scenario 4 – Location Based Services 26
Scenario 5 – Web Based Services 27
Scenario 6 – Management 28
Appendix B: MSF R4 Implementation Agreements 30
Appendix C: The Benefits of MSF Membership 33
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 3
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 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:
4 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
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
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
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.
IMS protocols are generally mature and IMS products interoperate across Service Provider environ-
IMS products employing QoS enable an end-user experience that is superior to best effort Internet
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.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 5
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-
(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.
6 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
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.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 7
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
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
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.
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.
8 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
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
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.
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.
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
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.
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.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 9
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
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
10 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
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.
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.
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
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.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 11
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.
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.
This high-level architecture formed the basis of the six scenarios for the GMI 2008 event. These sce-
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).
12 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
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.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 13
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
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-
14 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
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.
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.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 15
Appendix A: The Six Test Scenarios
Figure 4 presents a high-level diagram of the test environment used for the six test scenarios.
Figure 4 A high-level view of the GMI 2008 test environment.
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)
Broadband (DSL & Fiber)
16 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
Figure 5 End-to-end session control across seven access types.
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-
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
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.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 17
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-
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
Scenario 2 Objectives
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.
18 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
Figure 6 QoS added to end-to-end session control.
Scenario 2 Testing Results and Observations
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
Total Tests Run Intra/Inter Site 131 / 6
Table 3 S2 Test Results
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
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 19
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.
Figure 7 The IAs for this test scenario are shown in green.
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).
20 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
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.
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.
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
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
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 21
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
Total Tests Run Intra/Inter Site 84 / 0
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-
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
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
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
22 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
Figure 8 The ATIS IIF test scenario.
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.
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
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
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 23
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-
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
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.
24 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
Total Tests Run 11
Total Tests Run Intra/Inter Site 11 / 0
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
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
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 25
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.
Figure 9 The MSF Architecture for location services.
Scenario 4 Objectives
1 Support storage of location information received from the intermediate network elements at the
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 Testing Results and Observations
Scenario 4 involved 10 basic test cases with no further distinction into sub-test cases. Four of the 10
basic test cases were covered.
26 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
Total Tests Run 6
Total Tests Run Intra/Inter Site 2/4
Table 6 S4 Test Results
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-
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.
Figure 10 The MSF Architecture for SOA-based services.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 27
Scenario 5 Objectives
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.
Scenario 5 Testing Results and Observations
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
Total Tests Run Intra/Inter Site 30 / 1
Table 7 S5 Test Results
Table 7 shows the S5 test results. Analysis of the S5 tests:
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
Scenario 6 Objectives
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.
Scenario 6 Testing Results and Observations
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.
28 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
Total Tests Run 22
Total Tests Run Intra/Inter Site 22 / 0
Table 8 S6 Test Results
Table 8 shows the S6 test results. Analysis of the S6 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-
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
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 29
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.
Figure 9 The MSF Architecture for location services.
Based on this Architecture, Table 9 provides the list of IAs applicable to GMI 2008.
Table 9 Designation
MSF ETSI /3GPP Description
TC-0 Gq' DIAMETER-based protocol to query QoS- MSF-IA-DIAMETER.004-FINAL
(IF-2) controlled bandwidth availability.
TC-1 Ia H.248-based protocol for NAT and gate MSF-IA-MEGACO.016-FINAL
(IF-3) control, QoS allocation.
TC-5 3GPP Gx DIAMETER-based protocol for admission MSF-IA-DIAMETER.009-FINAL
control, QoS allocation in 3GPP .
30 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
MSF ETSI /3GPP Description
TC-6 Rx DIAMETER-based protocol for admission MSF-IA-DIAMETER.010-FINAL
control, QoS allocation in 3GPP
TC-7 Ty DIAMETER-based protocol for admission MSF-IA-DIAMETER.014-FINAL
control, QoS allocation in 3GP2
TC-8 Tx DIAMETER-based protocol for admission MSF-IA-DIAMETER.013-FINAL
control, QoS allocation in 3GPP2
TC-9 Rq Diameter based protocol for admission MSF-IA-DIAMETER.005-FINAL
control, QoS allocation in TISPAN
TC-10 Gx DIAMETER-based protocol for admission MSF-IA-DIAMETER.012-FINAL
control, QoS allocation in WIMAX
TC-11 E4 Diameter based protocol for user MSF-IA-DIMATER.011-FINAL
profile access in TISPAN networks
TR-5 Xd Interface between IMS IPTV UE and MSF-IA-MEDIA.001-FINAL
SESS-7 Xc Interface between IMS IPTV UE and MSF-IA-RTSP.001-FINAL
MGC-0 -- MGCP-based protocol for access line to MSF-IA-MGCP.001-FINAL
(IF-1c) packet connection setup and takedown, MSF-IA-MGCP.002-FINAL
line signal detection and output. MSF-IA-SDP.002-FINAL
MGC-1 H.248-based protocol for access line to MSF-IA-MEGACO.005-FINAL
(IF-1c or packet connection setup and takedown, MSF-IA-MEGACO.007-FINAL
IF-1d) line signal detection and output. MSF-IA-MEGACO.008-FINAL
(UK market only)
MGC-2 Mn H.248-based protocol for inter- MSF-IA-MEGACO.011-FINAL
(IF-13) exchange circuit-to-packet connection MSF-IA-SDP.002-FINAL
setup and takedown.
SESS-0 -- SIP-based protocol for call signaling MSF-IA-SIP.002-FINAL
(IF-1e) across the UNI. MSF-IA-SIP.003-FINAL
SESS-1 -- SIP with encapsulated ISUP for PSTN MSF-IA-SIP-I.001-FINAL
(IF-6) bridging and emulation,
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, SIP with IMS extensions for call signaling MSF-IA-SIP.016-FINAL
Mj, Mg 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 MSF-IA-RTSP.001-FINAL
SESS-8 Y2 Interface between S-CSC and SS-MCF for MSF-IA-SIP.018-FINAL
IPTV Media Control Function
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 31
MSF ETSI /3GPP Description
APP-0 SESS-5 with additional modifications for MSF-IA-SIP.005-FINAL
(IF-7) invocation of services
APP-1 ISC /Ma SESS-4 with additional modifications for MSF-IA-SIP.017-FINAL
invocation of services.
APP-1a ISC IPTV specific extensions MSF-IA-SIP.020-FINAL
APP-2 -- SIP-based control interface to Media MSF-IA-SIP.014-FINAL
Resource Broker to request assignment
of Media Server resources.
APP-4 -- Parlay API MSF-IA-PARLAY.003
APP-5 -- Parlay X API MSF-IA-PARLAY.005
APP-7 Mp H.248 based control interface to MSF-IA-MEGACO.015-FINAL
the Multimedia Resource Function
Controller to the Multimedia Resource
DB-0 Cx, Dx, Dw, DIAMETER-based protocol to retrieve MSF-IA-DIAMETER.006-FINAL
Wx and update subscriber service profiles.
DB-2 Sh, Dh DIAMETER-based protocol to pass MSF-IA-DIAMETER.003-FINAL
information between the Application
block entities and the HSS.
BI-1 Rf Diameter based interface for transfer of MSF-IA-BILLING.001-FINAL
Billing Record information
LOC-1 E2 Diameter based protocol to retrieve MSF-IA.DIAMETER.008-FINAL
MI-1 Interface used to measure Video MSF-IA-RTCP.001-FINAL
performance metrics and determine
near-term performance of IPTV service
MI-2 Interface used for IPTV STB Remote
MI-3 Interface used to pass RTP media
metrics from Media Plane to the Control MSF-IA-RTCP.002-FINAL
Plane, over H.248
MI-6 Interface used to pass RTP media
metrics from the Control Plane to the MSF-IA-RTCP.003-FINAL
MI-9 Interface for Reporting SIP session
metrics from Control Plane to MSF-IA-SFTP.001-FINAL
STB-1 Xa Interface used to retrieve service MSF-IA-XML.002-FINAL
32 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’
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
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-
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.
White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’ 33
34 White Paper ‘GMI 2008: Application and Service testing in global Next Generation Networks’