View
233
Download
0
Category
Preview:
Citation preview
7/30/2019 Iptv Channel Change IxL
1/32
26601 W. Agoura Rd.Calabasas, CA 91302
(Toll Free US) 1.877.FOR.IXIA
(Int'l) +1.818.871.1800(Fax) 818.871.1805
www.ixiacom.com
Test Plan
IPTV Channel Change Testing
7/30/2019 Iptv Channel Change IxL
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.
7/30/2019 Iptv Channel Change IxL
3/32
7/30/2019 Iptv Channel Change IxL
4/32
7/30/2019 Iptv Channel Change IxL
5/32
7/30/2019 Iptv Channel Change IxL
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/30/2019 Iptv Channel Change IxL
7/32
IPTV Channel Change Test Plan
2006 by Ixia p.3 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
8/32
IPTV Channel Change Test Plan
2006 by Ixia p.4 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
9/32
IPTV Channel Change Test Plan
2006 by Ixia p.5 www.ixiacom.com
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
7/30/2019 Iptv Channel Change IxL
10/32
IPTV Channel Change Test Plan
2006 by Ixia p.6 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
11/32
IPTV Channel Change Test Plan
2006 by Ixia p.7 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
12/32
IPTV Channel Change Test Plan
2006 by Ixia p.8 www.ixiacom.com
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
7/30/2019 Iptv Channel Change IxL
13/32
IPTV Channel Change Test Plan
2006 by Ixia p.9 www.ixiacom.com
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
7/30/2019 Iptv Channel Change IxL
14/32
IPTV Channel Change Test Plan
2006 by Ixia p.10 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
15/32
IPTV Channel Change Test Plan
2006 by Ixia p.11 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
16/32
IPTV Channel Change Test Plan
2006 by Ixia p.12 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
17/32
IPTV Channel Change Test Plan
2006 by Ixia p.13 www.ixiacom.com
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
7/30/2019 Iptv Channel Change IxL
18/32
IPTV Channel Change Test Plan
2006 by Ixia p.14 www.ixiacom.com
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.
IP Multicast Network
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
7/30/2019 Iptv Channel Change IxL
19/32
IPTV Channel Change Test Plan
2006 by Ixia p.15 www.ixiacom.com
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
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.
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 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
7/30/2019 Iptv Channel Change IxL
20/32
IPTV Channel Change Test Plan
2006 by Ixia p.16 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
21/32
7/30/2019 Iptv Channel Change IxL
22/32
IPTV Channel Change Test Plan
2006 by Ixia p.18 www.ixiacom.com
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.
IP Multicast Network
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
7/30/2019 Iptv Channel Change IxL
23/32
IPTV Channel Change Test Plan
2006 by Ixia p.19 www.ixiacom.com
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
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.
Unsolicited Response Mode
General Query/Group SpecificResponse Mode
Immediate Response
Suppress Reports
FTP client use Passive mode
SIP use UDP for signaling with RTPmedia (codec selectable)
Continued on next page
7/30/2019 Iptv Channel Change IxL
24/32
IPTV Channel Change Test Plan
2006 by Ixia p.20 www.ixiacom.com
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)
Client/Server Test Ports At least one. More ports can beused to scale the test
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
7/30/2019 Iptv Channel Change IxL
25/32
IPTV Channel Change Test Plan
2006 by Ixia p.21 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
26/32
IPTV Channel Change Test Plan
2006 by Ixia p.22 www.ixiacom.com
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
7/30/2019 Iptv Channel Change IxL
27/32
IPTV Channel Change Test Plan
2006 by Ixia p.23 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
28/32
IPTV Channel Change Test Plan
2006 by Ixia p.24 www.ixiacom.com
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.
7/30/2019 Iptv Channel Change IxL
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.
7/30/2019 Iptv Channel Change IxL
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: info@ixiacom.com
Investors: ir@ixiacom.com
Renewals: renewals@ixiacom.com
Sales: sales@ixiacom.com
Support: support@ixiacom.com
Training: training@ixiacom.com
Ixia USA SalesPhone: 1.866.355.4942 Email: sales@ixiacom.com
Ixia Canada SalesPhone: 1.877.367.4942 Email: salescanada@ixiacom.com
Ixia China SalesPhone: +86.10.84549199 Email: saleschina@ixiacom.com
Ixia Europe, Middle East, & Africa SalesPhone: +44.1753.722056 Email: salesemea@ixiacom.com
Ixia India SalesPhone: +91.80.25633570 Email: salesindia@ixiacom.com
Ixia Japan SalesPhone: +81.3.5365.4690 Email: salesjapan@ixiacom.com
Ixia Oceania SalesPhone: 1.818.292.1561 Email: salesoceania@ixiacom.com
Ixia South KoreaPhone: +82.11.897.1326 Email: salessouthkorea@ixiacom.com
Ixia Federal SalesPhone: 1.703.822.7527 Email: salesfederal@ixiacom.com
Contact Ixia
7/30/2019 Iptv Channel Change IxL
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.
7/30/2019 Iptv Channel Change IxL
32/32
Recommended