Real-World IPTV Network MeasurementsGeorgios Baltoglou

School of Technology and HealthKTH, Stockholm, Sweden

geobalt@ieee.org

Eirini KarapistoliDepartment of Electronics

Alexander TEI of Thessaloniki, Greeceikarapis@ieee.org

Periklis ChatzimisiosDepartment of Informatics

Alexander TEI of Thessaloniki, Greecepchatzimisios@ieee.org

Abstract—Internet Protocol Television or IPTV is defined asan alternate method of distributing television content over IP bya telecom carrier or an Internet service provider (ISP) and itis increasingly gaining market share in modern communicationnetworks. IPTV poses specific requirements on the network in-frastructure and at the same time it requires that several networkperformance characteristics are maintained under defined levelsin order for the end user to have an assured viewing experience.In this paper, our main motivation is to investigate how a reallife network performs in terms of distributing this inelastic andhigh-bandwidth type of service utilizing traffic measurements.Furthermore, our goal is to verify and analyze whether thestudied network is suited for multicast IPTV traffic.

I. INTRODUCTION

The latest entry into the television programming industry aretelecommunication companies or telcos - which have startedproviding television content over the internet commonly re-ferred to as IPTV. IPTV is a service with great expectations.It thrives to replace the former methods of TV broadcastingsuch as over the air, cable or satellite TV distribution, makinguse of the packet-switched Internet infrastructure. In orderto succeed, it also provides a variety of new services suchas Video-on-Demand (VoD) and VCR-like functionality forthe distributed TV media, together with the ability to co-existwith high rate data surfing and VoIP traffic in what is calleda triple-play service. Yet, the highly maladaptive to networkdeficiencies IPTV streams pose great demands in all separatelayers of the network architecture.

In modern network engineering problems dealing withinelastic traffic, such as IPTV, the efficient use of networkresources that satisfy the expected levels of Quality of Service(QoS) is a major issue. At the same time, Quality of Experi-ence (QoE) or how the QoS metrics are perceived by the endusers is also of vital importance. In order to respond to thatand to characterize the performance of an IP network, trafficmeasurements are utilized, which play very important roles forboth the ISPs, network and telecommunication operators, aswell as for the end users and even the measurement equipmentvendors.

From the telcos’ perspective, network measurements pro-vide the means for network monitoring. As different importantmetrics are gathered, such as traffic load and packet delay theoperators can identify the current state of the network and evenpredict eminent failures prior to happening. At the same timemeasurements are useful for network dimensioning. An under-provisioned network would result in dissatisfied customers

while an over-provisioned network might be expensive todeploy or have extravagant leasing costs. Finally, throughoutmeasurement data the optimal time for upgrade and the extentof the upgrade can be decided.

The relation between the service providers or telcos, and theend users can be summarized by what is called Service-LayerAgreement or SLA. The SLA is a form of contract containingthe responsibilities of both sides and the definition of the levelof service that has to be provided by the telcos and experiencedby the subscribed users. Again, measurements are of use.Inorder for the users to be able to observe the compliance of theoperator to the agreed level of provided service. In contrastto telcos, users are rarely interested in quantitative networkperformance metrics (i.e. packet loss rate, packet delay, delayvariation, etc.). What is of interest to them is the applicationperformance, a set of qualitative measurements that perplex theQoS measured by the operators with the overall experience ofthe end user. Modern traffic measurement techniques directlyprovide QoE results, allowing the users to evaluate if theircurrent level of service is in par with their expected level ofexperience.

This paper is organized as follows. In Section II, wediscuss the work that has already been accomplished andthe contribution of our paper. In Section III we describethe architecture of the studied real-world, commercial IPTVnetwork. In Sections IV and V we provide information onwhy active measurements are ideally suited for IPTV trafficalong with a description of the equipment used for holdingthe measurement sessions, as well as the metrics that wespecifically focus on to evaluate the network’s performance inIPTV deployment. Finally, Section VI illustrates the obtainedreal-time measurement results, accompanied by evaluationreports. The conclusion of the paper is found in Section VII.

II. IPTV MEASUREMENTS AND CONTRIBUTION

Obtaining traffic measurements, especially for IPTV, inflictscertain problems that need to be researched:

• Different types of network measurements exist, namelyactive and passive, each having its own advantages anddisadvantages. As IPTV multicast traffic is peculiar anddemanding, not all traffic measurements are suited forassessing the IPTV’s network performance.

• Real life networks resemble great heterogeneity. In termsof QoS implementation, multiple architectures exist such

978-1-4577-0681-3/11/$26.00 ©2011 IEEE 830

����

�����������

�������� �����������������

����� �

��

���������

������ !���� !�"� �#

�$%$&'(�)��$&��"*$��'��

��&� ��������� ��

��&�

$ ��"+,��

�,-�-

���.�/��.�%��0�.1 (���.�23���%%��0�.1 $�����%��0�.1

�,-�-

���

�(456-)7 ���

,)7*�7� ���

,���7���� ���

,�)7���� ���

����4�$('�%(

� 7�8$9

� 7�829

Fig. 1. Studied Network Map

as ATM, MPLS, IPv4, IPv6, and others. As such, ob-taining measurements of only a specific network layerprovides little with regard to the end-user QoS/QoE. Atthe same time, end-to-end measurements including totallyunknown portions of a network provides poor informationfor the subsequent analysis of the obtained data.

• While substantial work on traffic measurements and net-work performance concerning IPTV has been made ([1]and [2]), they focus on P2P traffic and passive mea-surements, or they are usually produced via simulationsoftware ([3] and [4]), mathematical modeling [5], orstudying proof of concept lab networks, which have amore predictable behavior [6].

• Studying only the performance of a high-level QoSpriority class, as given in IPTV multicast traffic, is usuallynot enough for the end-user expectations. As IPTV ismarketed in triple play bundles, including VoIP and datatraffic, successive studies on these lower priority classesare important, since they might be affected by the highpriority class.

From the above analysis, it is evident that no compre-hensive study that we know of, has so far presented activemeasurements of a real-world commercial IPTV network. Assuch, this is our work’s main contribution. Furthermore, withthe obtained results of our measurement scenarios and theirsubsequent analysis we intend to:

a provide tangible information and present the reasons whya network architecture as the one studied, verifies as beingan exemplary IPTV distribution infrastructure.

b be able to pinpoint the parts of the network that aresources of problems for IPTV delivery.

c use them as a reference point for evaluating other net-works and assessing the distributed IPTV service quality.

III. STUDIED NETWORK

In this section the exact network architecture of the real-lifecommercial IPTV network, on which our measurements wereconducted. A full network map was designed for this reason,depicted in Fig. 1. The IPTV streams in the studied networkare originating from Stockholm, Oslo and Copenhagen. Thetransportation and interconnection of these cities is providedby the network provider Norrsken. Norrsken uses optical fibersto connect several cities within Sweden and in Scandinaviain general, in an SDH ring topology. They use STM-16transmission frames, yielding a bitrate of 2.4 Gbps. The IPTVstreams transported to the city Borlange are by the serviceproviders Canal-Digital and FastTV. Canal-Digital is transmit-ting multicast IPTV streams with 700 Mbps bandwidth, whileFastTV uses 500 Mbps.

A. Metro / Core

The Metro/Core layer is a Gigabit Ethernet network overoptical fibers interconnecting cities Borlange (where the IPTVstream is firstly received) and Falun. The link has a bandwidthof 10 Gbps and on its edges lie Cisco 7600 Series routers.These routers were specifically chosen when the networkwas designed because they deploy high-performance CarrierEthernet, IP/MPLS features and Enterprise WAN aggregationand core routing over 10 Gbps interfaces. Additionally, theysupport interface processors capable of controling voice, video,and data, offering a rich set of QoS features as specificallyneeded. Moreover, the Metro/Core routers have been config-ured with MPLS creating a QoS-guaranteed network.

B. Distribution

The Distribution network is composed of 1 Gbps Ethernetlinks carried over optical fiber. The Distribution networksituated in Falun consists of five redundantly interconnectedCisco 3750 ME switches featuring hierarchical QoS, trafficshaping, intelligent 802.1Q tunneling, VLAN mapping and

978-1-4577-0681-3/11/$26.00 ©2011 IEEE 831

MPLS. Spanning Tree Protocol is further implemented toprevent switching loops. All provided services are dividedinto different VLANs and each VLAN supports different QoSclasses. The highest priority class is given to the IPTV VLANfollowed by VoIP, Management and finally the Internet VLAN.

C. Access

On the Falun Access network the nodes are connectedusing 100 Mbps Ethernet links, originating from cabinets thatsupport 350 customers each. As the Distribution network linksare optical fibers, the Access network can be considered asa Fiber-To-The-Node Access network. Having Ethernet forlast mile connection poses great advantages, in comparisonto other technologies such as DSL (i.e. higher bandwidth,simplified network architecture, utilization VLANs as theservice delivery mechanism over the entire access-network,etc.). The Access network supports currently 2000 clients, outof which approximately 400 have also VoIP services enabled.The providers of CPE devices are Allied Telesis and Packet-Front. Each Ethernet port on the CPE connects the client tothe respective VLANs of IPTV, VoIP and Data traffic. TheEthernet link from the CPE is directly connected to a specificport on the (Allied Telesis) Distribution Switch. Finally, allIPTV subscribers use Motorola STBs for the reception of theIPTV services as it is used by both Canal-Digital and FastTV.

IV. ACTIVE MEASUREMENTS AND EQUIPMENT

The approach of active measurements requires inserting testpackets into the network for measurements purpose. As thegenerated traffic will traverse the same network infrastructure,it will eventually be affected by it, with the same manner thatthe real traffic is. Introducing artificial (emulated) packets tothe network provides the advantage of having absolute controlof the nature of the traffic parameters. As such, parameters canbe adjusted to have traffic of an exact amount of volume, gen-eration intervals, sampling frequency, scheduling, packet sizesand types. Yet, active measurements do create extra traffic asthe packets are inserted into the network. If the extra generatedvolume is too high, problems arise, appointing the obtainedmeasurements inaccurate. Despite that, active measurementsremain the ideal type of measurements for the inelastic IPTVmulticast traffic. As such, unlike the passive measurements thatneed to capture all types of packets, including packets that donot need to be monitored, active measurements can generatetraffic to reflect only the data of the studied application service.

To conduct our active measurement study we used theProsilient Technologies PTAnalyzer; a distributed probe-basedend-to-end Service Performance Management, QoS measure-ment and SLA supervision system. It consists of one or moreprobes, one or more reflectors and the PTAnalyzer client,which is a graphical user interface (GUI) application provid-ing the functionality to configure and control a supervisiondomain, retrieve and present status and result information ingraphical as well as textual formats.

V. METRICS OF INTEREST

Due to the fundamental design of IP networks as a best-effort delivery platform independent of application require-ments, packets and data are susceptible to loss. For the inelas-tic nature of the IPTV service, packet losses are a major issue.As mentioned, IPTV deployments commonly transport packetsvia UDP, providing no protection to packet loss. Packet lossof the audio stream can be exhibited as dropouts, squeakingnoises, variations in sound volume, and skipping. For the videostream, the impact is varying, depending on the video framethat was affected. The effects result from a mild pixelizationon the viewed content to blocked pixels for a duration of afew frames, unnecessary elongation or repetition of frames(stuttering), frame freezes, or in worst case, freezing of theset-top-boxes (STBs).

In contrast to the other metrics that follow, measuring lossover long term periods and analyzing the average is inappro-priate. To exemplify, an impulse noise that usually occurs inbursts of 10 to 50 milliseconds, would be hidden in a sampleof one hour as a 0.001% packet loss. While the operatorwould pay no attention to such a value identifying it as a goodmeasurement, the end-user might in fact have an undesirableviewing experience. As such, packet loss measurement shouldbe conducted with regard to both the frequency of occurrencesover a time period and of the occurring duration.

A. Latency and Jitter

Latency, or the time it takes for packets to traverse from thesource to the destination is another parameter that affects theIPTV content. High latency values result in corrupted images,picture blocking and frozen frames on the TV sets of the endusers. Due to the fact that the packet propagation delay is notconstant over time, latency across a network is varying. Themetric that measures this variability is named packet delayvariation or jitter. As the IPTV decoders and STBs requirea steady IP stream, jitter can cause both buffer overrun andunderrun. In the first case the end users might see pixelizationof the viewed content or horizontal/vertical lines, while in thelatter case, frame freezing is the most usual experienced issue.

B. Join and Leave Delay

In order to assess the performance of zapping, channel joinand leave delay metrics are used. Join delay is defined to be theelapsed time from issuing the IGMP join request until arrivalof the first packet in the multicast packet stream. The joinoperation will be said to fail if no packet has arrived when thetime has come to issue the IGMP Leave request. Accordingly,leave delay is defined to be the elapsed time from issuing theIGMP leave request until reception of the last packet in themulticast packet stream. These performance indicators dealingwith channel changing are the ones that greatly affect userperceived QoS. Inherently, IPTV can not achieve changingof channels instantaneously as supported by OTA and cableTV broadcasting, since the whole process of IPTV operationstarting at encoding and multicasting and ending at STB layerdecoding involves a certain number of delays.

978-1-4577-0681-3/11/$26.00 ©2011 IEEE 832

C. MOS

A subjective measurement indication is Mean Opinion Score(MOS), which ranks the perceived video and audio qualitybased on user feedback. In MOS users determine the videoquality by rating displayed video sequence on a scale of 1(very bad) to 5 (very good). The mean averages of multipleusers are taken and so the MOS value is computed. As such,the MOS provides a numerical value for the QoE of the enduser. When comparing MOS scores it is of vital importanceto consider that certain video types inherently produce ahigher level of quality than others, as viewers tend to formexpectations of quality based on the perceived capabilities ofthe medium. For example, HDTV delivers a higher resolutionand picture size than regular SDTV, so maintaining all otherfactors identical, the MOS for a HD video stream will behigher than the MOS for the same sequence delivered in SD.

D. IPTV Quality margins

From the above descriptions of the QoS/QoE metrics,it is evident that IPTV quality is not equally affected bythem. As a result, defining its tolerance margins and exactrequirements is more than a difficult task. While QoS classeshave been standardized [7], IPTV is comprised by differentservices, varying from simple streaming video to interactiveapplications. As such, no standardization has been made so farproviding the exact limits beyond which IPTV service qualityis not acceptable. Considering that PTV can be described asvery bandwidth demanding, very sensitive to packet loss, andsimply sensitive to latency and jitter, and based on [8], somemargins for the QoS/QoE metrics can be derived. As such,latency should be kept less than 200 ms, whereas PDV orjitter that can deteriorate the video quality at greater extendshould be kept under 50 ms. Packet loss for IPTV, that has thegreatest impact in video quality should be kept below 10−4.To further specify, as losses are bound to happen in bursts,the bandwidth stream of the IPTV video should be relatedto the loss rate tolerance. Data from [8] provide packet lossrate values for streams of bitrates varying from 3 Mbps up to5 Mbps. As a result, for the studied IPTV streams that averageabove 6 Mbps (as later described), a loss rate tolerance of6.98x10−5 is accepted, with the maximum duration of everysingle error not exceeding 16 ms.

Experience Join Delay Leave Delay

Excellent 50 250Good 150 750Fair 300 1500Poor 500 2500Bad 1000 5000

TABLE IZAP JOIN AND LEAVE EXPERIENCE MARGINS

Establishing margins of satisfactory performance for the“zapping” function, is more complicated. Generally, a timeless than 1 second can be safely called satisfactory, while avalue more than 2 seconds seems to exceed being characterized

as simply annoying by end users. Even so, currently there isno knowledge about the explicit relation between the channelzapping time and the user experience (QoE) as expressed withMean Opinion Score (MOS), but only approximate criteriaare given for its evaluation, [9]. The PTAnalyzer client thatcontrols the PT1404 probes, evaluates zap Join and Leavedelay using the time margins shown in Table I.

VI. MEASUREMENTS METHODOLOGY AND RESULTS

A. IPTV, VoIP and Data traffic

In order to conduct the measurement scenarios, our firstconcern was to identify the exact parameters of the IPTVtraffic that traverses the network. For this reason, Wiresharkpacket sniffing software was used. From the captured packetsthe transported video streams were analyzed, which pro-vided us with the necessary information to construct iden-tical traffic on the active probes. Specifically, the highestbitrate channel transported was 641 packets per second with1328 bytes per packet payload, yielding 6.854 Mbps includingIP overhead.The MPEG TS originating from the source wasencapsulated in UDP packets for transportation. The routerssituated in both sites were configured with PIM-sparse modeof Multicasting. The additional channel traffic that traversedthe network was accordingly constructed on the probes usingthe extracted bitrate, TTL and ToS values from the real traffic.

As it is common, IPTV is usually provided in a triple-play bundle, and as such it was interesting to evaluate theperformance of the VoIP and Internet traffic services on thesame network, identifying wether these services were affectedby the IPTV traffic. In order to obtain VoIP and data trafficmeasurements, in addition to that of IPTV, the probes wereconnected to the respective VLANs and required additionalconfiguration was made. The measurement scenarios held,were created with bi-directional data traffic transmissions, withvarying data-rates, and TCP protocol encapsulation, while theVoIP traffic was generated from probe A towards probe B,using G711 codec with 64 Kbps bitrate, in accordance withreal VoIP traffic traversing the network. Measurements for theprevious scenarios were obtained for fifteen consecutive days.

Having accurately synchronized probes is mandatory inorder for the obtained measurements to be valid. The graphshown in Fig. 2a shows the synchronization reliability that theprobes achieved, which was always maintained at very highlevels, between 87 and 91%, translating to an accuracy in theorder of 50μsec.

In the over-provisioned network of our study, packet lossesshould be expected to be at very low levels. In our measure-ment scenarios, 830.598.268 packets were sent and all werereceived, yielding a 0% packet loss. The obtained results forpacket delay and jitter are presented in Table II. As shown andexpected from the over-engineered network in study, packetdelays are kept at very low levels. Even the maximum valueof 8.125 ms is more than 95% lower than the margin of accept-able quality, which is 200 ms. The very low observed values isa direct outcome of the network architecture. By having a highdata-rate Ethernet last mile connection, mode conversions from

978-1-4577-0681-3/11/$26.00 ©2011 IEEE 833

Ethernet to ATM, common in DSL environments, are avoidedand so is the potential additional delay that they may cause.Jitter measurements show a great resemblance to packet delay,with the highest value obtained being 3.125 ms, or 93% lowerthan the proposed upper margin of 50 ms.

IPTV VoIPMetric Delay (μs) Jitter (μs) Delay (μs) Jitter (μs)

Min: 471 - 586 0 - 58 188 - 312 0 - 0Mean: 554 - 667 111 - 125 214 - 333 1 - 17Median: 548 - 662 73 - 126 208 - 330 1 - 2Max: 719 - 8185 232 - 3125 285 - 470 17 - 169

TABLE IIIPTV AND VOIP DELAY AND JITTER RESULTS

In addition, neither medium sensitivity VoIP traffic, norbest effort data delivery delays were affected by the highpriority IPTV streams. Zero packet losses were also foundin all measurement sessions of the triple-play services, whilepacket delay and jitter were also restricted within confinedmargins (Table II).

Overall, and as a direct outcome of the previous metrics,IPTV MOS values were constantly kept at 4.4, as presentedin Fig. 2a. This shows that statistically all the users receivingthe IPTV streams would be very satisfied with its quality andthat the network can sufficiently handle the inelastic servicescomprising the triple-play bundle. This was of course theinitial purpose of building such an over-engineered network,with IPTV distribution being a primary concern.

B. HD Channel measurements

While at the time that the measurements were held, onlySD channels were being multicasted to IPTV subscribers,we decided to generate some multicast traffic the size andproperties of which would resemble a HD channel, verifyingthe fact that the network would have no problem supporting itsdistribution. For that reason, one HD channel was created onprobe A, with a bitrate of 14 Mbps. The measurement sessionthat we conducted had the same outcome: zero packet losses,a mean delay of 555-675μs and a mean jitter of 112-131μs,yielding an overall “excellent” QoS chart (a chart that showsthe amount of time spent in the different QoS levels, in percentof the complete test period).

C. “Zapping” Measurements Scenarios

The same configuration as in the previous scenarios wasused for the “zapping” measurements session. For this scenariomore channels had to be created using PTAnalyzer GUI,originating from probe A. Again, the Wireshark output thatwas captured and analyzed in the previous case was used toreplicate channels with parameters identical to the real IPTVchannel characteristics. As a result five more channels wereemulated with the same attributes and datarates ranging from6.211 up to 6.737 Mbps.

In contrast to the first scenarios that were held for con-secutive days, we created several zapping sessions, and ob-tained multiple different measurements ranging from 2 up to24 hours. As the network has been engineered in order to

circumvent possible QoE degrading issues, fast-leave has beenimplemented on the Access network switches. This importantaddition to the original IGMP protocol, that was includedin the second version of RFC2236, allows the switch toremove an interface from the forwarding-table entry withoutthe need of previously sending out group specific queries to theinterface. The VLAN interface is pruned from the multicasttree for the multicast group specified in the original leavemessage. Fast-leave processing ensures optimal bandwidthmanagement for all hosts on a switched network, even whenmultiple multicast groups are in use simultaneously. ThisIGMP feature can only be used in VLANs where exactly onehost is connected to each interface, as it is in our case. Ifour network design had VLANs in which more than one hostwas connected to a switch interface, fast-leave would cause thehosts to be dropped inadvertently. With the fast-leave enabled,our measurements in channel leave time are expected to beshort.

While a lot measurement scenarios were held, they all had acommon behavior concerning zap Leave delays. An indicativegraph is depicted in Fig. 2b. As observed zap Leave times werekept at very low levels. In most cases zap Leave delay was inthe vicinity of 100 ms, with very low values in the proximity of10 ms not being absent. These results illustrate that indeed fast-leave IGMP snooping implementation played an important rolein decreasing zapping Leave delay. These times could havebeen even lower, if the probe was connected to a CPE thatsupported IGMP “fast-leave”. Additionally, the zapping Joindelay showed great resemblance in the distribution uniformity.However, while zapping leave times were sufficiently low forthe channel leave experience to be characterized as “excellent”,the same cannot be said about the channel Join delays.Evidently from Fig. 2c, Join times frequently surpassed 150 msyielding a “good” channel experience. Furthermore, there weremeasurement sessions with a more peculiar behavior, such asthe one depicted in Fig. 3a. Taking into account that 430 msof zapping time (zap Join plus Leave delays) translates toa MOS value of 3.5, it is evident that delays of 1005 msand 492 ms, depicted in the aforementioned figure are simplyunsatisfactory.

It should also be noted that in few isolated measurement sce-narios there were even Join failures, as depicted in Fig. 3b, inwhich At 14:04:38.124 (UTC time) of our zap measurementssession, it is reported that no join packet is received. Whilethis result cannot be considered poor due to the low numberof cases that it happened, it mandates that certain things needto be examined to further understand and optimize zap Joindelay. For instance, in our traffic measurement session, thereis only one subscriber to the multicast channel, as only oneprobe was to our availability. As we are zapping through ourgenerated channel list, Leave messages stop the stream at theswitches that are connected to the CPE, but the IGMP messagestill travels upwards, reaching the metro router situated in thecity of Falun. At that point however, that router notifies themetro router in Borlange that there are no subscribers for themeasurements multicast group, causing the multicast stream to

978-1-4577-0681-3/11/$26.00 ©2011 IEEE 834

Fig. 2. a) Synchronization and Mean Opinion Score chart, b) Zapping Leave delay chart and c) Zapping Join delay chart graph

Fig. 3. a) Excessive Join delays Chart, b) Zapping Join failure and c) Overall QoS Join delay experience.

be stopped right at Borlange. Because of that, when a new JoinIGMP message is issued, it has to travel up to the latter router,in order to start receiving the multicast traffic. In reality, thereis a quite high probability that there more than one subscribersper channel exist, meaning that the multicast traffic never stopsat router located in Borlange. This could actually be one reasonfor the good but not excellent zap Join values.

To further locate points that could add delay to IPTVzapping, we can refer to all the interconnected devices ofFig. 1 in the studied network map. In case the Join delayis caused at the router, then the problem might be a PIM-SM multicast routing misconfiguration. Accordingly, if delayis caused at the Distribution switches, then an IGMP snoopingmisconfiguration might be causing it. Yet, these types of errorswould probably create more serious problems and far morefrequent Join failures. As a result, the most probable point thatfurther degrades channel zap times, are the CPE and STBsconnected to it. Since a large number of prioritized packetstraverse through the CPE, it is logical in case of very highCPU utilization, for packets to be delayed, or even dropped.At the same time we acknowledged the fact that continuouszapping for a long time, stresses the STB to its limits, causingadditional delays and freezes.

The cumulative channels result of zapping Join experienceis represented in Fig. 3c, illustrating that even in this over-engineered network IPTV zap frailties still exist, limiting theexcellent zap channel Join experience under 5% and yieldingan overall 91% Good zapping Join QoE.

VII. CONCLUSIONS

In this paper, we investigated how a real life networkperforms in terms of distributing inelastic and high-bandwidthIPTV data utilizing active traffic measurements. The obtainedresults of this ideally suited IPTV distributing network can actas a benchmark for evaluating different network architecturesin the same operations and identify problematic sources,leading to problem-free network infrastructures and changingthe way IPTV content is consumed.

REFERENCES

[1] T. Hossfeld and K. Leibnitz, “A qualitative measurement survey ofpopular internet-based iptv systems,” June 2008, pp. 156–161.

[2] Y. Won, M.-J. Choi, B.-C. Park, J. Hong, H.-W. Lee, C.-K. Hwang, and J.-H. Yoo, “End-User IPTV Traffic Measurement of Residential BroadbandAccess Networks,” April 2008, pp. 95–100.

[3] E. Shihab, F. Wan, L. Cai, A. Gulliver, and N. Tin, “Performance Analysisof IPTV Traffic in Home Networks,” 2007, pp. 5341 – 5345.

[4] D. Agrawal, M. Beigi, C. Bisdikian, and K.-W. Lee, “Planning andManaging the IPTV Service Deployment,” in Integrated Network Man-agement, 2007, pp. 353–362.

[5] D. Emir, E. Mohamed, and B. Ammar, “Network performance evaluationusing traffic measurements,” 2004, pp. 523–526.

[6] L. Ciavattone, A. Morton, and G. Ramachandran, “Standardized ActiveMeasurements on a Tier 1 IP Backbone,” IEEE Communications, pp.90–97, 2003.

[7] ITU-T Recommendation, “Network Performance Objectives for IP-BasedServices,” ITU-T Y.1541 Recommendation, Feb 2003.

[8] D. Forum, “Triple-play Services Quality of Experience (QoE) Require-ments,” Technical Report TR-126, Dec 2006.

[9] X. L. et al., “Channel Zapping in IP over Optical Two-layer Multicastingfor Large Scale Video Delivery,” Dec. 2007, pp. 1–4.

978-1-4577-0681-3/11/$26.00 ©2011 IEEE 835