
2/32

Copyright 2006 by Ixia

All rights reserved

Ixia26601 West Agoura Road, Calabasas, CA 91302(877) FOR-IXIA

This Test Plan contains a general outline for testing a particular technology.Not all the capabilities of Ixia technology have been exposed in this document.Please feel free to contact us if additional capabilities are required.


3/32


4/32


5/32


6/32

IPTV Channel Change Test Plan

2006 by Ixia p.2 www.ixiacom.com

Background

In the telecommunications marketplace today, traditional cableand telephone operators are aggressively staging and deployingconverged networks that can deliver data, voice, and video

services to their rapidly expanding customer base. Such networksare referred to as Triple Play networks.

The effective delivery of the video component of Triple Playservices, called IPTV, has a fundamental requirement to operatewithin a multicast-capable network, delivering broadcast servicetelevision over the IP network by ensuring the efficient use ofnetwork resources. Using this technology, IPTV services aredelivered directly to the home and are intended to replace thetraditional video delivery network.

The figure below is a simplified view of a multicast network used

to deliver a single channel (using a single multicast address) to anumber of group members (or viewers of a particular channel).The flow of data from the Group Source to the Group Membersfollows the multicast routing tree. A multicast routing protocol suchas PIM-SM/DM is used to create an efficient routing path for thedelivery of multicast packets between routers. The host to edge-router communication is generally facilitated using IGMPv2/v3.

IP MulticastNetwork

Group Source

GroupMember

GroupMember

Non-Member

GroupMember

Non-Member

Non-Members

Core/AggregationRouter 1

EdgeRouter 1

AggregationRouter 2

EdgeRouter 2

EdgeRouter 3

Figure 1. Simple multicast tree used to deliver single channelmulticast traffic to hosts


7/32



What is channel changing or channel zapping?

Channel changing or channel zapping in the IPTV domainis the equivalent of surfing channels on a television set in thetraditional sense. Channel changing, then, always entails leaving

one TV channel and joining/watching the next.

Why is it important?

In the traditional cable television network, channels werealways present on the wire. For this reason, channel changingperformance was generally not an issue. Switching from onechannel to the next was usually instant, typically was not asource of user dissatisfaction.

For satellite TV providers, on the other hand, the inherentdistance that the video signals had travel always introduced adelay in switching between channels. The usual approach toreduce the perceived delay was to provide some kind of on-screen feedback when switching channels so that the user knewthe channel change request had been received.

Now, with video being delivered over an IP network, one thatwas not necessarily designed with video transport as a key goal,several optimizations and novel methods are being deployedthroughout a providers network to improve the perceivedinstant channel change behavior that is expected by traditional

television consumers.IGMP is the industry standard protocol used for host to routercommunication in a multicast network. Therefore, channelchanging (CC) performance measured at an edge router or anaggregation device is intricately tied to inherent implementationand fine tuning of the IGMP protocol. The CC performanceis also a function of the emulated end device receiving themulticast stream for final output, such as a set-top box. For thisreason, channel changing performance is vital in characterizingperformance for devices such as DSLAMS or CMTS and is

equally important for an end-to-end IPTV test.

For more information on the specific performance metricsattainable by using channel changing profiles to test the IPTVnetwork, refer to the Performance Metrics section later inthis document.


8/32



What are the channel changing (CC) requirements?

The channel changing performance in an IP network is primarilythe result of end-to-end processing of associated multicastprotocols, packet switching, and the end-devices ability to

decode or show the video with relative consistency.

A deployed system must be able to performance predictably ina sustained mode. A sustained mode of operation refers to arealistic load condition, not a best-performance condition withlight use.

In addition to sustained performance, a deployed system must beresilient to fault conditions where peak loads may easily exceedthe sustained performance limits. For a system to be resilient, itmust be able to perform acceptably well and be able to recover

from an overloaded condition.

Channel surfing presents varying load conditions for a multicastnetwork. For example, if there is a sudden power outage in aneighborhood on a typical Sunday game day, a mass floodof traffic will be injected into the IP network requesting networkconfiguration information followed by several channel changesto tune back to a desired channel by hundreds, if not thousands,of viewers at almost the same time. Testing such realistic loadconditions is critical in ensuring optimal QoS on the network andhelp tune device settings.

Requirements of good channel performance are characterizedusing the metrics in the Performance Metrics section later in thisdocument.


9/32



Performance Metrics

To determine channel changing performance, severalperformance metrics are used. The following terms are definedand used to provide objective performance. Note that the terms

defined here comprise generally accepted industry terms andprotocol-specific terms that help characterize the performance.

IGMP Join Latency- The time between a request to join amulticast group and the receipt of the first byte of data for amulticast group.

IGMP Leave Latency The time between a request to leave amulticast group and the receipt of the last byte of data for themulticast group

Channel Overlap The duration of time when data is receivedfor a new joined multicast group and a previously left multicastgroup. This time is usually zero units.

Channel Switch Delay (STB dependent) An internal IGMPprocessing delay between a Leave and Join request. This value isideally insignificant; however, it can be otherwise.

Channel Change/Zap Delay The inter-channel change delay,which is the time between a channel Leave request sent and thereceipt of the first byte of data from the new multicast channel.

It is the IGMP Join Latency + Channel Switch Delay (STBdependent). This value is ideally very close to the IGMP JoinLatency; however, the STB can introduce a significant delay.

The following timing diagrams outline the delays for 2 channels.

Figure 2. IGMP Join and Leave latency timing diagram


10/32



The specific metrics outlined above must be available on a per-channel/per-subscriber basis. The various metrics make up theparts of a sum that help provide an at-a-glance health check forevery subscriber and the channels being watched.

It is not sufficient, though, to use such metrics alone tocharacterize the performance of an IPTV network/device. Toisolate adverse network conditions causing unacceptable channelchange performance, network centric measurements must beavailable to provide an at-a-glance health check of the networkon a per-channel/per-subscriber.

Media Delivery Index (MDI) A scoring mechanism thatcombines packet delay variation (jitter) and media packet lossto determine the quality of the network to transport good qualityvideo. It is measured in milliseconds.

MDI:DF (Delay Factor) Defined as cumulative IP jitter. Itrepresents the time it would take to drain an output buffer andensure good video playback.

MDI:MLR (Media Loss Rate) Defined as the packet loss rate dueto dropped packets, bad/corrupted packets, or out-of-sequencepackets.

The Media Delivery Index (MDI) is important because itcharacterizes the performance of the network and its ability tohandle good video streams. The index provides two measuresseparately so that each IPTV device can be tested with variouschannel change patterns to help insolate device-specific issues.By identifying problems on an IPTV network device, it becomeseasy to troubleshoot and optimize the configuration to provideoptimal performance end-to-end.

This approach can be extended to characterize the end-to-endchannel change performance of an IPTV deployment.


11/32



1. Test 1 Optimal Channel Change Performance

Objective

This test setup focuses on determining the optimal channel changeperformance with IPTV traffic running across one or more DUTs.

Since IPTV subscriber has a different usage pattern, it is necessaryto determine the end users experience based on realisticchannel change patterns. It is also important to determine howthe subscribers channel change performance changes as thecomplexity of the subscribers behavior (channel change profile)increases and as the number of subscribers increase.

The variability of the CC patterns will have a direct impact on theperformance of devices supporting such traffic. The importanceof determining the optimal performance of an IPTV DUT is toensure that it is within operating limits of providing excellentchannel change performance experienced by subscribers.For example, is there channel overlap when users are rapidlysurfing channels? How does poor jitter experienced by onevideo stream affect the others on the same link? How is thetransport of video streams affected by a growing number ofsubscribers? These are just some of the questions that can beanswered by emulating realistic user channel change behavior todetermine various acceptable levels of performance.

This test emulates typical load conditions of 1000s of subscriberswith multiple channel changing profiles and 100s of videostreams. Several iterations of the test will help ensure that thedevice/network has sufficient raw bandwidth to support the load,reveal at localized congestions, and assist in fine-tuning devicesfor maximum performance.

The maximum number of users supported by the DUT/networkdoes not necessarily translate to optimal channel changeperformance. For this reason, there is a trade-off between thebest channel change performance with realistic subscriber loads

and the maximum performance possible by the device/network.Both metrics have merit and both must be determined.

This test is applicable to an IPTV device and can be extended tocharacterize optimal end-to-end performance.


12/32



Setup

The setup requires at least 2 or more Ixia test ports to generatestateful IPTV traffic. A video server port is used to stream 100sof standard and high definition video streams. The topology

presented here is representative of a typical Triple Playdeployment network. There are several configurations possibleand this test setup is used as a guideline. The video subscribersare connected to an IGMPv3 enabled core router and the videoserver is connected to a carrier core router. The core multicastnetwork has a 4Gbps backbone and it runs BGP for routedetermination and PIM-DM as the multicast protocol.

IP Multicast Network

IxiaClientsPort(s)

IxiaServerPort(s)

IxLoadVideoClients

IxLoadVideoServer

MulticastStreams

IGMPControl

1 2

43

65

TrigOutGnd

LM1000GBIC-2

IXIA

Subscriber

Router

Carrier

Router

1 2

43

65

TrigOutGnd

LM1000GBIC-2

IXIA

LACP

4Gbit

Trunk

Figure 3. Topology for Test 1 Optimal Performance


13/32



Input Parameters

Parameter Description

Client Configuration 50 1000+ users per test port

Client Network One or more VLAN with untaggedand/or 802.1q tagged packets perVLAN

Client Channel ChangeProfiles

Sequential channel surfing for10 20 sec

Random channel surfing for 10 sec 20 min

Other random profiles as per testersrequirements

Client Command-list JOIN channels as per Channel

change Profile selected per runClient IGMP parameters The IGMP options below may be

configured as desired. Consider thespecific trade-offs for each optionsbefore enabling/disabling them.

Unsolicited Response Mode

General Query/Group SpecificResponse Mode

Immediate Response

Suppress Reports

Client/Server Test Ports At least one. More ports can beused to scale the test

Video Server At least one

Video ServerConfiguration

100+ video streams. Use MPEG2-TSwith synthetic payload at 3.75Mbps(for SD). Use higher bitrate videostreams to simulate HD streams(9.8Mbps+)

Multicast group address configurable as per network design.

Must have sufficient count to ensureall video streams have a multicastgroup address

Test Objective Iterative method to determine themaximum simulatedusers

Table 1. Input Parameters for Test 1 Optimal Performance


14/32



Methodology

1. Before starting the test, determine the baseline performancecharacteristics of the test equipment. This will ensure that theupper limits of the test equipment are known and that the

performance per-port or per-system is well defined.

2. Once the baseline is established using the test ports,configure the test setup network or the IPTV DUT.

To support multicast traffic, at least one switch will berequired to support IGMPv2 or v3. In addition, a multicastprotocol must be running to efficiently deliver multicast traffic.

3. Set up the test, and configure the parameters for the protocolsas outlined in Input Parameters for the Client Traffic.

Choose the version of IGMP supported by the switch. Also,ensure that the IGMP parameters are using default values asspecified in RFC 2236 (IGMPv2) or RFC 3376 (IGMPv3).

The command-list is where the channel changing profile canbe configured. The desirable options here are to run thetest iteratively and modify the channel changing profiles tosimulate different load conditions on the multicast fabric.

Some channel changing profiles can include:

A set of subscribers surfing through channels 1-50 for 10-20seconds each.

A set of subscribers surfing through channels 51-100 for 1-30seconds each.

A set of subscribers emulating a typical habit of watchingchannel A for 30 minutes with frequent channel surfing withinthat time for commercial breaks.

The channel-changing profiles must be iteratively set up to testthe multicast network and monitor an average subscriberschannel change performance. Ensure that there are sufficientports to run the test.

4. Configure the video server traffic to serve 100s of videostreams. Refer to the Input Parameters to configure the streamcontents appropriately.


15/32



5. Configure the Client and Server networks to ensure end-to-end connectivity. Confirm that multicast protocol is runningand reachable end-to-end.

6. Set up the test objective to determine the maximum number of

sustained users.

7. Run several iterations of the test to determine the maximumperformance of the DUT/network (in handling # ofsubscribers and # of simultaneous channels).

However, consider that the maximum number of subscriberssupported by the DUT/network does not necessarily translateto optimal channel change performance. There is a trade-offbetween the best channel change performance with realisticsubscriber loads and the maximum performance possible

by the network. Both metrics have merit and both must bedetermined.

8. Adjust the IGMP parameters to optimize channel changelatency.

Vendor implementations of IGMP may vary and specificoptimized configurations must be determined fromconfiguration and user guides.


16/32



Results

This test was used to characterize various subscriber loadconditions and determine the channel change performanceexperienced by each subscriber. In addition, network flow

quality of video streams were examined per stream to determinehow the device/system performed when it was incrementallyloaded with more subscribers, more channels, and more complexsubscriber channel change patterns.

The optimal channel change performance was a trade-offbetween the maximum performance possible by the DUT/network without packet loss and the acceptable channel changelatencies under realistic load conditions. Both metrics have merit.Knowing the peak performance of the DUT/network ensures thatextreme load conditions are serviceable during failure or startup

times. However, at peak performance a subscribers channelchanging performance may be less than optimal.

Optimal channel changing performance was measured atan equilibrium point that was below the maximum deviceperformance but still simulated realistic subscriber loadconditions.

A brief result of three runs is presented below:

Stat Name Stream BitRate (bps) MDI-DF(us) MDI-MLR MPEG2TS Loss Jitter (ns)

Inter Pkt

ArrivalTime (ns)

Packet

Latency(ns)

Join

Latency(ms)

Leave

Latency(ms)

RUN 1/ User 1Channel 1

3750007 2835 0 0 280 2805680 38160 69 8479

RUN 2/User 1Channel 1

3750007 2835 0 0 1780 2807180 38320 108 8460

RUN 3/UserChannel 1

3750007 2835 0 0 300 2216420 38540 100 5045

Table 2. Test 1 channel change performance for multiple runs

The first run simulated 300 users watching 100 channels for 10-

20 seconds each. The second run increased the number of usersto 1200. The jitter increased considerably with the increase insubscriber count. The third run reduced the subscriber count to800 and modified the channel change behavior for different setsof subscribers.


17/32



If the subscribers were increased to more than 1200, there wereMPEG2 TS losses seen. The optimal configuration for the networkwas 800 subscribers all having different channel changing profiles.

To further characterize the channel change performance, real-

timestatistics of the Channel Change/Zap Delaywere activelymonitored. A snippet of these real-time statistics for the third runis presented below.

Figure 4. Real-time channel change/zap delay for test 1, run 3

The average jitter distribution for several channel requests ispresented below for the third run, and 99.87% of the packetshad jitter below 50 us, which is very good.

Figure 5. Jitter distribution for test 1, run 3


18/32



2. Test 2 Single Subscriber Experience

This test is composed of a series of runs with 1000s ofsubscribers with various channel change patterns. The test willassess the experience of a single subscriber who is watching a

few channels while several other subscribers place different loadrequirements on the multicast network. In this way, the test setupwill assess the join/leave latency and the channel change/zapdelay, including MDI scores.

Setup

The setup will require at least 2 or more Ixia test ports togenerate stateful IPTV traffic. A video server port is used tostream 100s of standard and high definition video streams. The

topology presented here is representative of a typical Triple Playdeployment network. There are several configurations possibleand this test setup is simply used as a guideline. The videosubscribers are connected to an IGMPv3 enabled core routerand the video server is connected to a carrier core router. Thecore multicast network has a 4Gbps backbone and it runs BGPfor route determination and PIM-DM as the multicast protocol.


IxiaClientsPort(s)

IxiaServerPort(s)

IxLoadVideoClients

IxLoadVideoServer

MulticastStreams

IGMPControl

1 2

43

65

TrigOut

Gnd

LM1000GBIC-2

IXIA

Subscriber

Router

Carrier

Router

1 2

43

65

TrigOut

Gnd

LM1000GBIC-2

IXIA

LACP

4Gbit

Trunk

Figure 6. Topology for Test 2 Single Subscriber Experience


19/32



Input Parameters





1 subscriber with fixed channelchange pattern

Other random profiles as per testersrequirements

Client Command-list JOIN channels as per Channelchange Profile selected per run

Client IGMP parameters The IGMP options below may be

configured as desired. Consider thespecific trade-offs for each optionsbefore enabling/disabling them.



Immediate Response

Suppress Reports


Video Server At least oneVideo ServerConfiguration

100+ video streams. Use MPEG2-TSwith synthetic payload at 3.75Mbps(for SD). Use higher bitrate videostreams to simulate HD streams(9.8Mbps+)

Multicast group address configurable as per network design.Must have sufficient count to ensureall video streams have a multicast

group addressTest Objective Iterative method to determine

the optimal single subscriberperformance (using maximumsimulated users)

Table 3. Input Parameters for Test 2 Single SubscriberExperience


20/32



Methodology

1. Configure the test setup network or the IPTV DUT.

To support multicast traffic, at least one switch will berequired to support IGMPv2 or v3. In addition, a multicast

protocol must be running to efficiently deliver multicast traffic.

2. Set up the test, and configure the parameters for the protocolsas outlined in Input Parameters for the Client Traffic.

Choose the version of IGMP supported by the switch. Alsoensure that the IGMP parameters are using default values asspecified in RFC 2236 (IGMPv2) or RFC 3376 (IGMPv3).

The command-list is where the channel changing profile canbe configured. The desirable options here are to run thetest iteratively and modify the channel changing profiles tosimulate different load conditions on the multicast fabric.

Some channel changing profiles can include:

One subscriber (pilot) watching a few channels for longdurations.

A set of subscribers emulating many channel change patternsto stress the multicast network differently. The channel-changing profiles must be iteratively set up to test the multicastnetwork to monitor a single subscribers channel changeperformance for the iterations. Depending on how the clients

profiles, ensure that there are sufficient ports to run the test.

3. Configure the video server traffic to serve 100s of videostreams. Refer to the Input Parameters to configure the streamcontents appropriately.

4. Configure the Client and Server networks to ensure end-to-end connectivity. Confirm that multicast protocol is runningand reachable end-to-end.

5. Set up the test objective to determine the maximum number of

sustained users.

6. Run several iterations of the test to determine the channelchange performance for a single pilot subscriber.

Change the multicast load conditions by iteratively changingthe other subscribers channel change patterns and monitorthe pilot users Join/Leave and Change Change/Zap delays.


21/32


22/32



3. Test 3 Triple Play TrafficThis test extends the IPTV channel change performance test byprovisioning data and voice traffic on the same link as the videostreams to assess the performance of this additional traffic.

In a deployed network, the convergence of data, voice, andvideo traffic creates a realistic scenario where the video streamsare sharing resources with data and voice traffic. The traffictypes are very different from each other, and each requires adifferent level of service from the network.

To ensure that each of the devices on the converged networkis working properly as part of the IPTV solution, it is necessaryto test several Triple Play scenarios where the channel changebehavior of several subscribers creates realistic load conditions.This is in addition to the data and possibly voice traffic that

must transit the same link, either from the same subscriber orother subscribers sharing an uplink from an aggregate router.By emulating various load conditions on the Triple Play network,optimizations can be made to ensure that the QoS on the devicesin the network is working as expected.

Setup

The setup will require at least 3 or more Ixia test ports to generatestateful Triple Play traffic. A video server port will be used tostream 100s of standard and high definition video streams. Asecond server port will accept data and voice traffic. At least

one client test port will generate stateful video, voice, and datatraffic based on the conditions in the Input Parameters table. Thetopology presented here is representative of a typical Triple Playdeployment network. There are several configurations possibleand this test setup should be used as a guideline. The videosubscribers are connected to an IGMPv3 enabled core router andthe video server is connected to a carrier core router. The coremulticast network has a 4Gbps backbone, and it runs BGP forroute determination and PIM-DM as the multicast protocol.


IxiaClientsPort(s)

IxiaServerPort(s)

IxLoadVideoClients

IxLoadVideoServer

MulticastStreams

IGMPControl

1 2

43

65

TrigOutG

nd

LM1000GBIC-2

IXIA

Subscriber

Router

Carrier

Router

1 2

43

65

TrigOutG

nd

LM1000GBIC-2

IXIA

LACP4Gbit

Trunk

Figure 7. Topology for Test 3 Triple Play Traffic


23/32



Input Parameters





Sequential channel surfing for10 20 sec

Other random profiles as pertesters requirements

Client Command-list JOIN channels as per Channelchange Profile selected per run

FTP traffic varying bandwidthto simulate typical and adverseconditions

HTTP traffic varying pageretrievals

SIP traffic to simulate voice-over-IPcalls

Client Parameters The IGMP options below may beconfigured as desired. Consider the

specific trade-offs for each optionsbefore enabling/disabling them.



Immediate Response

Suppress Reports

FTP client use Passive mode

SIP use UDP for signaling with RTPmedia (codec selectable)

Continued on next page


24/32



Traffic Impairment(optional)

Introduce traffic impairment such aslatency, jitter, packet drop profilesand duplicate packets (to furtherstress the edge devices in processing

packets with errors or inherentdelays/jitter than may causequeuing problems on the interfacebuffers)


Video Server At least two. A dedicated videoserver port and a dedicated dataand voice traffic port

Video ServerConfiguration 100+ video streams. Use MPEG2-TS with synthetic payload at3.75Mbps (for SD). Use higherbitrate video streams to simulate HDstreams (9.8Mbps+)

Multicast group address configurable as per network design.Must have sufficient count to ensureall video streams have a multicastgroup address

Test Objective Iterative method to determine themaximum simulated users

Table 4. Input Parameters for Test 3 Triple Play Traffic


25/32



Methodology

1. Configure the test setup network or the IPTV DUT.

For multicast traffic, at least one switch is required to supportIGMPv2 or v3. In addition, a multicast protocol must be

running to efficiently deliver multicast traffic.

2. Set up the test, and configure the parameters for the protocolsas outlined in Input Parameters table for the Client Traffic.

Choose the version of IGMP supported by the switch. Also,ensure that the IGMP parameters are using default values asspecified in RFC 2236 (IGMPv2) or RFC 3376 (IGMPv3).

The command-list is where the channel changing profileshould be configured. The desirable options here are to runthe test iteratively, and then modify the channel changingprofiles to simulate different load conditions on the multicastfabric. Include data traffic such as FTP and/or HTTP withvarious page retrievals. Also, enable SIP voice-over-IP traffic(1 call per subscriber).

3. Configure the video server traffic to serve 100s of videostreams. Refer to the Input Parameters table to configure thestream contents appropriately. Also configure the SIP calleeand FTP server side traffic profile.

4. Configure the Client and Server networks to ensure end-to-end connectivity. Confirm that a multicast protocol is runningand reachable end-to-end.

5. Set up the test objective to determine the optimal subscriberchannel change performance. The test Objective will varyfor each of the activities defined (video, voice and data),depending on the activity and test iteration. The objectiveswill reflect the load conditions required to effectivelydetermine how background data and voice traffic affect anaverage subscribers channel change performance.

6. To test the capability of the edge routers in handlingmalformed packets and being able to manage its interfacebuffer queues properly, introduce impairment such as latency,jitter, duplicate packets or random drop packets.


26/32



Results

The objective of this test was to determine the subscriberschannel change performance on a converged network that isrunning video and voice traffic.

Several test runs were conducted. Two of the runs are examinedhere.

The results below show successful SIP calls during one of the testrun 2 with 200 subscribers.

Figure 8. Completed SIP calls for test 3


27/32



HTTP transactions are presented below for the same test run.

Figure 9. HTTP transactions for test 3

The HTTP transaction latency for two runs is given below. Thetransaction latency increased on the second run as the FTP

throughput was increased from 1.6Mbps to 24Mbps. The FTPtraffic directly impacted the HTTP traffic (and the video traffic).

Figure 10. HTTP transaction latency for multiple runs

A similar trend was seen on the voice calls. The per-call jitterincreased an average of 18% between the first and second run.


28/32



The impact of background data traffic was also apparent on thevideo streams.

Figure 11. Channel change/zap delay comparison betweenmultiple runs

The channel change/zap delay increased between runs as thedata traffic on the link increased. In deployed systems, however,such behavior can be mitigated by designing and implementingstrict QoS policies at the edge of the network. In addition, a per-subscriber QoS model must be used to ensure that different trafficoriginating from the same subscriber is treated differently by theedge routers. This will allow predictable behavior to ensure that

data traffic does not impede other more sensitive traffic such asvideo streams.


29/32

About Ixia

Ixia is a leading provider of performance test systemsfor IP-based infrastructure and services. Its highlyscalable solutions generate, capture, characterize, andemulate network and application traffic, establishingdefinitive performance and conformance metrics

of network devices or systems under test. Ixias testsystems are used by Network and Telephony EquipmentManufacturers, Semiconductor Manufacturers, ServiceProviders, Governments, and Enterprises to validatethe functionality and reliability of complex IP networks,devices, and applications. Ixias Triple Play test systemsaddress the growing need to test voice, video, anddata services and network capability under real-world conditions. Ixias vision is to be the worldspre-eminent provider of solutions to enable testingof next generation IP Triple Play networks. Ixias test

systems utilize a wide range of industry-standardinterfaces, including Ethernet, SONET, ATM, andwireless connectivity, and are distinguished by theirperformance, accuracy, reliability, and adaptability tothe industrys constant evolution.


30/32

For more information, contact Ixia or visit our Web Site athttp://www.ixiacom.com .

Ixia Worldwide Headquarters

Corporate Center26601 W. Agoura Rd.Calabasas, CA 91302

(Toll Free North America)1.877.367.4942(Outside North America)+1.818.871.1800

(Fax) 818.871.1805

www.ixiacom.com

Info: [email protected]

Investors: [email protected]

Renewals: [email protected]

Sales: [email protected]

Support: [email protected]

Training: [email protected]

Ixia USA SalesPhone: 1.866.355.4942 Email: [email protected]

Ixia Canada SalesPhone: 1.877.367.4942 Email: [email protected]

Ixia China SalesPhone: +86.10.84549199 Email: [email protected]

Ixia Europe, Middle East, & Africa SalesPhone: +44.1753.722056 Email: [email protected]

Ixia India SalesPhone: +91.80.25633570 Email: [email protected]

Ixia Japan SalesPhone: +81.3.5365.4690 Email: [email protected]

Ixia Oceania SalesPhone: 1.818.292.1561 Email: [email protected]

Ixia South KoreaPhone: +82.11.897.1326 Email: [email protected]

Ixia Federal SalesPhone: 1.703.822.7527 Email: [email protected]

Contact Ixia


31/32

1998-2006 Ixia. All rights reserved.

This publication may not be copied, in whole or in part, without Ixias consent.

Ixia and its licensors retain all intellectual property rights in all products identified in this publication. Such products may becovered by one or more patents and/or pending patent applications, including but not limited to the following U.S. patents:6,717,917; 6,408,335; 6,397,359; 6,061,725; 5,937,165; 5,881,237; and 5,838,919. All software and relateddocumentation identified in this publication is licensed, not sold, pursuant to a separate license agreement between Ixia and therecipient. The recipients use of such software and documentation is subject to the terms of that agreement.

Restricted Rights Legend

Use, duplication, or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of theRights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.

THIS PUBLICATION IS PROVIDED AS IS AND WITHOUT ANY WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED.IXIA SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,OR NONINFRINGEMENT. THE INFORMATION HEREIN IS FURNISHED FOR INFORMATIONAL USE ONLY, IS SUBJECT TOCHANGE BY IXIA WITHOUT NOTICE, AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY IXIA. IXIA ASSUMESNO RESPONSIBILITY OR LIABILITY FOR ANY ERRORS OR INACCURACIES CONTAINED IN THIS PUBLICATION.

Ixia, the Ixia four petal logo, and IxLoad are either trademarks or registered trademarks of Ixia in the United States and/orother countries. All other trademarks belong to their respective owners.


32/32

Documents

Iptv Channel Change IxL