iptv delivery networks: next generation architectures for live and video-on-demand services

372

Upload: others

Post on 11-Sep-2021

7 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services
Page 2: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Delivery Networks

Page 3: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Delivery Networks

Next Generation Architectures for Live andVideo-on-Demand Services

Edited bySuliman Mohamed FatiFaculty of Information Technology and Science, INTI InternationalUniversity, Malaysia

Saiful AzadFaculty of Computer Systems & Software Engineering, UniversityMalaysia Pahang, Malaysia

Al-Sakib Khan PathanCSE Department, Southeast University, Bangladesh

Page 4: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

This edition first published 2018© 2018 John Wiley & Sons Ltd

All rights reserved. No part of this publication may be reproduced, stored in a retrievalsystem, or transmitted, in any form or by any means, electronic, mechanical,photocopying, recording or otherwise, except as permitted by law. Advice on how toobtain permission to reuse material from this title is available athttp://www.wiley.com/go/permissions.

The right of Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan to beidentified as the authors of the editorial material in this work has been asserted inaccordance with law.

Registered OfficesJohn Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USAJohn Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO198SQ, UK

Editorial OfficeThe Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK

For details of our global editorial offices, customer services, and more informationabout Wiley products visit us at www.wiley.com.

Wiley also publishes its books in a variety of electronic formats and byprint-on-demand. Some content that appears in standard print versions of this bookmay not be available in other formats.

Limit of Liability/Disclaimer of WarrantyWhile the publisher and authors have used their best efforts in preparing this work,they make no representations or warranties with respect to the accuracy orcompleteness of the contents of this work and specifically disclaim all warranties,including without limitation any implied warranties of merchantability or fitness for aparticular purpose. No warranty may be created or extended by sales representatives,written sales materials or promotional statements for this work. The fact that anorganization, website, or product is referred to in this work as a citation and/orpotential source of further information does not mean that the publisher and authorsendorse the information or services the organization, website, or product may provideor recommendations it may make. This work is sold with the understanding that thepublisher is not engaged in rendering professional services. The advice and strategiescontained herein may not be suitable for your situation. You should consult with aspecialist where appropriate. Further, readers should be aware that websites listed inthis work may have changed or disappeared between when this work was written andwhen it is read. Neither the publisher nor authors shall be liable for any loss of profit orany other commercial damages, including but not limited to special, incidental,consequential, or other damages.

Library of Congress Cataloging-in-Publication data applied for

ISBN: 9781119397915

Cover design by WileyCover image: © Robert Daly/Getty Images

Set in 10/12pt WarnockPro by SPi Global, Chennai, India

10 9 8 7 6 5 4 3 2 1

Page 5: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

‘To my parents, whose utmost efforts and prayers are always with meTo my beloved wife, and my kids – Suhail and Sama’

Suliman Mohamed Fati

‘To my beloved late father, for his constant encouragement,love and belief ’

Saiful Azad

‘To my two little daughters – Rumaysa and Rufaida’Al-Sakib Khan Pathan

Page 6: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

vii

Contents

List of Contributors xviiEditor Biographies xxiPreface xxiiiAcknowledgement xxvii

Part I IPTV Delivery Networks Fundamentals 1

1 IPTV: Delivering TV Services over IP Networks 3Suliman Mohamed Fati and Putra Sumari

1.1 Overview 31.2 Internet Protocol Television 41.3 Evolution of TV to IPTV 61.3.1 IPTV Services 71.3.2 IPTV Standardisation 81.3.3 General Architecture of IPTV 91.4 IPTV Delivery Network 101.5 Evolution of the Delivery Network 111.5.1 IPTV Delivery Network Characteristics and Challenges 151.6 The Key Issues of IPTV Delivery Networks 171.7 Conclusion 18

References 19

Page 7: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

viii Contents

2 IPTV Streaming Classification 25Miguel Masciopinto, Pedro Comesaña, and FernandoPérez-González

2.1 Introduction 252.2 Framework 292.2.1 IPTV Description 302.2.2 IPTV Bitrate Footprint 322.3 Classification Scheme 332.3.1 SVM Classifier 362.4 Experimental Setup 362.4.1 Database Construction 372.4.2 Training/Test Set-Partitioning 382.4.3 Classification Performance Measures 412.5 Experimental Results 442.5.1 TSS vs. OFS Classification 452.5.2 TSS Ternary (DVD vs. DVB-S vs. DVB-T) Classification 472.5.3 TSS Binary (DVB-S vs. DVB-T) Classification 502.5.4 OFS Binary (DVB-S vs. DVB-T) Classification 532.5.5 Relevance of the Used Statistics 552.6 Conclusions 59

Acknowledgement 60References 60

3 Efficient IPTV Delivery over EPON 65AliAkbar Nikoukar, I-Shyan Hwang, and Andrew Tanny Liem

3.1 Introduction 653.2 Broadband Access Network Technologies 673.3 Live IPTV Delivery over EPON 763.3.1 Hardware Architecture 783.3.2 Multicast Protocol Design 803.3.3 Pre-request Broadcasting Mechanism 813.3.4 Performance evaluation 853.4 Conclusions 88

References 88

4 Content Awareness in IPTV Delivery Networks 93Suliman Mohamed Fati and Putra Sumari

4.1 Introduction 934.2 The Key Challenges in IPTV Delivery Networks 97

Page 8: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contents ix

4.2.1 Request Distribution Algorithms in IPTV DeliveryNetworks 97

4.2.2 Cost Reduction in IPTV Delivery Networks 1024.2.2.1 Replica Placement Schemes in IPTV Delivery

Networks 1034.2.2.2 Resource Allocation Schemes in IPTV Delivery

Networks 1054.3 Content Status Issue in IPTV Delivery Networks 1084.3.1 Unawareness of Content Status in Replica Placement

Schemes 1094.3.2 Unawareness of Content Status in Request Distribution

Algorithms 1104.3.3 Unawareness of Content Status in Resource

Allocation 1104.4 IPTV Content Status Modelling: A New Direction 1114.4.1 IPTV Content Status Modelling 1124.4.2 Experimental Results 1144.5 Conclusion 118

References 119

Part II QoS and QoE for IPTV DeliveryNetworks 127

5 Zapping Delay Reduction in IPTV Systems 129Alireza Abdollahpouri

5.1 Introduction 1295.2 A Review of the Existing Studies 1315.2.1 Reduce I-Frame Acquisition Delay 1315.2.1.1 Use Additional Stream 1315.2.1.2 Inserting Extra I-Frames and Reduction in the Size of

GOP 1325.2.2 Prediction-Based Mechanisms 1335.2.3 Techniques Based on Scalable Video Coding 1345.2.4 Techniques Based on IGMP Schemes 1345.3 Prediction-Based Prejoining Method in WiMAX

Networks 1365.3.1 Modelling the Behaviour of a Single IPTV User, During an

ON Session 1375.4 Performance Evaluation 142

Page 9: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

x Contents

5.5 Future Directions for Research 1465.6 Conclusion 147

References 147

6 Channel-Zapping Time in IPTV: Challenges andSolutions 151Sajjad Zare, Seyyed Mohammad Hosseini Verki, and AkbarGhaffarpour Rahbar

6.1 Introduction 1516.1.1 IPTV Network Infrastructure 1516.1.1.1 Basic IPTV System 1526.1.1.2 IP Multicast in IPTV Architecture 1536.1.1.3 P2P IPTV Architecture 1536.1.2 Business Models 1546.1.2.1 Free to Air (FTA) 1546.1.2.2 PPV 1556.1.2.3 Subscription 1556.1.2.4 A La Carte 1556.2 Challenges in Channel-Zapping Time 1556.2.1 Jitter 1566.2.2 Limited Bandwidth 1566.2.3 Elements of Zapping Delay 1566.3 Proposed Methods for Reducing Channel-Zapping

Time 1586.3.1 Client-Based Methods 1586.3.1.1 Pre-Joining Neighbouring Channels 1586.3.1.2 Tracking User Behaviour 1596.3.1.3 Ordering Pre-Join Channels in the List 1616.3.2 Content-Based Methods 1636.3.3 Network-Based Methods 1676.3.3.1 Improving Zap Response Time for IPTV 1696.3.3.2 A Novel Channel Switching Scenario in Multicast IPTV

Networks 1696.3.3.3 IGMP for IPTV Services in Passive Optical Networks 1706.3.3.4 Implementation of EIGMP for Fast IPTV Channel Change

in GEPON 1716.3.3.5 Advanced Scheme to Reduce IPTV Channel-Zapping

Time 1726.3.4 Hybrid Methods 172

Page 10: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contents xi

6.3.4.1 An Effective IPTV Channel Control Algorithm ConsideringChannel-Zapping Time and Network Utilisation 172

6.3.4.2 Multicast Instant Channel Change (ICC) in IPTVSystems 174

6.3.4.3 IPTV Channel Switching Delay Reduction ThroughPredicting Subscribers’ Behaviours and Preferences 175

6.3.5 Programme-Based Methods 1766.4 Discussion 1776.5 Summary 180

References 180

7 Delivering High-Definition IPTV Services overIP-Based Networks 185Seongik Hong

7.1 Introduction 1857.2 HD Video Compression 1887.2.1 Issues for HD Video Transmission 1887.2.1.1 Issue 1: Large Bandwidth Requirements 1887.2.1.2 Issue 2: QoS 1897.2.1.3 Issue 3: Network Responsiveness/Instant Channel

Change 1897.2.2 Solutions 1907.2.2.1 Solution 1: Solving Large Bandwidth Requirements 1907.2.2.2 Solution 2-1: QoS: Protocols and Networks 1927.2.2.3 Solution 2-2: QoS: Reducing Packet Loss 1947.2.2.4 Solution 3: Solving Instant Channel Change Issue 1977.3 Future Trends 1987.4 Conclusion 199

References 199

8 IPTV Network Security: Threats andCountermeasures 203M. S. A. Noman Ranak, Saiful Azad, B. M. F. Kamal Ruhee, N. NourinNisa, Nazrul Kabir, Mohammed Mostafizur Rahman, and Kamal Z.Zamli

8.1 Introduction 2038.2 Threats on IPTV Delivery Networks 2048.2.1 Theft or Abuse of Network Assets 2068.2.2 Theft of Service 206

Page 11: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xii Contents

8.2.3 Theft of IPTV-Related Data 2088.2.4 Disruption of Service 2088.2.5 Privacy Breach 2098.2.6 Compromise of Platform Integrity 2098.3 Security Issues of IPTV Delivery Networks 2098.3.1 Protocols Vulnerabilities 2148.3.1.1 IGMP 2158.3.1.2 PIM 2158.3.1.3 MBGP 2168.3.1.4 MSDP 2178.3.1.5 RTP and RTP Control Protocol (RTCP) 2188.4 Countering the Threats 2198.5 Open Research Issues 2218.6 Conclusions 222

References 222

9 Anomaly Detection and Big Data in IPTVNetworks 225Mohiuddin Ahmed and Md. Niaz-Ul Haque

9.1 Introduction 2259.1.1 Chapter Roadmap 2279.2 Complex Data in IPTV Networks 2289.3 Anomaly in the Context of IPTV Networks 2299.3.1 HHH 2309.3.2 Succinct Hierarchical Heavy Hitter (SHHH) 2319.3.3 Time Series 2319.3.4 Definition of Anomaly 2319.4 A Case Study of Anomaly Detection Technique in IPTV

Networks 2329.4.1 Limitations of Anomaly Detection in IPTV Networks 2339.4.2 Experimental Data 2349.4.3 Experimental Analysis 2359.5 Future Research Directions: Big Data 2359.5.1 Three Vs of Big Data 2359.5.2 Big Data in the IPTV Industry 2379.5.3 The Challenges Associated with Big Data in IPTV 2399.5.4 Contributions of IPTV Service Providers in the Realm of Big

Data 2419.6 Conclusions 242

References 243

Page 12: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contents xiii

Part III Mobility and Next-Generation DeliveryNetworks 245

10 Taxonomy of Intra-Domain Mobility ManagementSchemes in Wireless Mesh Network forImplementing Mobile IPTV 247Abhishek Majumder, Subhrajyoti Deb, and Sudipta Roy

10.1 Introduction 24710.2 Classification 25010.2.1 Tunnelling-Based Schemes 25110.2.1.1 ANT 25110.2.1.2 Mesh Mobility Management (M3) 25310.2.1.3 Static Anchor Scheme 25510.2.1.4 Dynamic Anchor Scheme 25610.2.1.5 SMR-Based Scheme 25710.2.2 Routing-Based Schemes 25810.2.2.1 Infrastructure Mesh (iMesh) 25810.2.2.2 OLSR-FastSync 25910.2.2.3 Ad Hoc on-Demand Distance Vector and Mesh and MEsh

Networks with MObility Management(AODV-MEMO) 260

10.2.2.4 Mobile Party 26310.2.2.5 Wireless Mesh Mobility Management (WMM) 26410.2.2.6 LMMesh 26510.2.2.7 Forward Pointer-Based Routing (FPBR) 26610.2.3 Multicasting-Based Scheme 26710.2.3.1 SMesh 26710.3 Advantages and Disadvantages 26810.4 Open Research Issues 27910.5 Conclusion 280

Acknowledgement 280References 280

11 Towards Multi-Operator IPTV Services Over 5GNetworks 283Gergely Biczók, Manos Dramitinos, Håkon Lønsethagen, Luis M.Contreras, George D. Stamoulis, and Laszlo Toka

11.1 Introduction 28311.2 Single-Provider IPTV Services 28411.2.1 Customer-Centric Challenges and Technical Issues 285

Page 13: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xiv Contents

11.2.2 Business Issues and Challenges 28811.2.3 Operators’ Solutions and Architecture 29011.3 IPX Multi-Service Internetworking 29311.4 Multi-Operator IPTV Services in 5G Networks 29411.4.1 Technical Issues and Challenges 29511.4.1.1 SDN and NFV Exploitation 29511.4.1.2 Lack of QoS Assurance – SLAs 29611.4.1.3 Lack of Monitoring and SLA-Based Rewards 29711.4.1.4 Wholesale and Retail Market Coordination 29711.4.1.5 Pricing and Charging Layers 29911.4.2 Business Issues and Challenges 30011.4.2.1 Generic Issues and Challenges 30011.4.2.2 IPTV Distribution of ‘Small/Medium‘ Live Events 30211.4.2.3 User-Generated Content 30311.4.3 Solutions and Architecture: The 5GEx Approach 30411.4.3.1 5GEx Exchange: An Open Multi-Service Internetworking

Approach 30411.4.3.2 Roadmap and Coordination Models 30711.4.3.3 Pricing and Charging Solutions 30811.5 Future Research 31011.6 Conclusions 311

Acknowledgement 312References 312

12 Technologies and Architectures for Future IPTelevision Services 315Lucile Sassatelli and Marie-José Montpetit

12.1 Introduction 31512.2 The Evolution of Users’ Experience: Usage, Expectations and

Reluctances 31612.2.1 Broadcast Versus OTT: Towards a Spurious

Opposition 31612.2.2 The Multi-Screen Multi-Device Anywhere Experience 31712.2.3 Business Experiences and Inevitable Evolution for the

Stakeholders 31912.3 Architectural Evolution of IPTV: Towards a Smart Meld

with OTT 32012.3.1 The Main Overhauls of IPTV: HTML5, Cloudification,

Software-Defined Video 320

Page 14: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contents xv

12.3.2 Legacy IPTV Extending its Reach by Inspiring OTTEvolution: Multicast, Caching, Peer-to-Peer (P2P) 323

12.3.3 Coordinating the OTT delivery entities to enforce IPTV-likequality of experience: Collaboration between ISPs, CDNsand CPs 329

12.4 Technical focus 33112.4.1 P2P assistance to CDNs, caching and ICN 33212.4.2 The Wireless Video Challenge: In-Home WiFi and

Offloading of Cellular Networks 33512.4.3 VR: The greatest technological challenge ahead? 337

References 338

Contributor Biographies 345Index 357

Page 15: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xvii

List of Contributors

Alireza AbdollahpouriDepartment of ComputerEngineeringUniversity of Kurdistan,Sanandaj, Iran

Mohiuddin AhmedUniversity of New South WalesCanberra, Australia

Saiful AzadFaculty of Computer Systems &Software EngineeringUniversity Malaysia Pahang,Malaysia

Gergely BiczókBudapest University ofTechnology and EconomicsDepartment ofTelecommunications and MediaInformaticsBudapest, Hungary

Pedro ComesañaSignal Theory andCommunications DepartmentUniversity of Vigo, E. E.Telecomunicación, Spain

Luis M. ContrerasDistrito TelefónicaMadrid, Spain

Page 16: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xviii List of Contributors

Subhrajyoti DebDepartment of ComputerScience & EngineeringTripura University,Suryamaninagar, Tripura, India

Manos DramitinosAthens University of Economicsand BusinessAthens, Greece

Suliman Mohamed FatiFaculty of InformationTechnology and ScienceINTI International University,Malaysia

Niaz-Ul HaqueMediaroom Field EngineeringOntario, Canada

Seongik HongAmazon Web ServicesCambridge, Massachusetts, USA

I-Shyan HwangDepartment of ComputerScience and EngineeringYuan-Ze University, Taiwan

Nazrul KabirDepartment of ComputerScienceAmerican InternationalUniversity-Bangladesh, Dhaka,Bangladesh

Andrew Tanny LiemDepartment of ComputerScienceKlabat University, Manado,Indonesia

Håkon LønsethagenTelenor Research, Telenor GroupNorway

Abhishek MajumderDepartment of ComputerScience & EngineeringTripura University,Suryamaninagar, Tripura, India

Miguel MasciopintoSignal Theory andCommunications DepartmentUniversity of Vigo, E. E.Telecomunicación, Spain

Page 17: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

List of Contributors xix

Marie-José MontpetitResearch Laboratory ofElectronicsMassachusetts Institute ofTechnologyCambridge, Massachusetts, USA

AliAkbar NikoukarDepartment of Mathematics,College of ScienceYasouj University, Yasouj, Iran

N. Nourin NisaDepartment of ComputerScienceAmerican InternationalUniversity-Bangladesh, Dhaka,Bangladesh

Fernando Pérez-GonzálezSignal Theory andCommunications DepartmentUniversity of Vigo, E. E.Telecomunicación, Spain

Akbar Ghaffarpour RahbarElectrical EngineeringDepartmentSahand University of TechnologyTabriz, Iran

Mohammed Mostafizur RahmanDepartment of ComputerScienceAmerican InternationalUniversity-Bangladesh, Dhaka,Bangladesh

M. S. A. Noman RanakFaculty of Computer Systems &Software EngineeringUniversity Malaysia Pahang,Malaysia

Sudipta RoyDepartment of ComputerScience & EngineeringAssam University, Silchar,Assam, India

B. M. F. Kamal RuheeDepartment of ComputerScienceAmerican InternationalUniversity-Bangladesh, Dhaka,Bangladesh

Lucile SassatelliUniversité Nice Sophia AntipolisFrance

Page 18: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xx List of Contributors

George D. StamoulisAthens University of Economicsand BusinessAthens, Greece

Putra SumariSchool of Computer SciencesUniversiti Sains Malaysia,Malaysia

Laszlo TokaBudapest University ofTechnology and EconomicsDepartment ofTelecommunications and MediaInformaticsBudapest, Hungary

Seyyed Mohammad Hosseini VerkiPayame Noor University ofQazvinQazvin, Iran

Kamal Z. ZamliFaculty of Computer Systems &Software EngineeringUniversity Malaysia Pahang,Malaysia

Sajjad ZarePayame Noor University inQazvinQazvin, Iran

Page 19: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xxi

Editor Biographies

First Editor

Name: Suliman Mohamed FatiPosition: Senior Lecturer, INTI International University, MalaysiaBiography: Suliman Mohamed Fati completed his bachelor’s andmaster’s degrees from Ain Shams University and Cairo University inEgypt, respectively. He received his PhD in computer sciences fromUniversiti Sains Malaysia, Malaysia, in 2014. After completing hisPhD, he joined as an assistant professor in Faculty of Informationand Communication Technology, Universiti Tunku Abdul Rahman,Malaysia. Currently, he is working as a senior lecturer (assistantprofessor) in Faculty of Information Technology and Sciences, INTIInternational University, Malaysia. The focus of his PhD work was onoptimising IPTV delivery networks. His current research interests arein multimedia applications, content distribution networks, optimi-sation, cloud computing and the Internet of Things. He has authoredmany papers in international conferences and peer-reviewed journals.He also serves as a reviewer for renowned peer-reviewed journals andconferences. He is a member of IEEE, ICIT and IAENG.

Second Editor

Name: Saiful AzadPosition: Senior Lecturer, University Malaysia Pahang, MalaysiaBiography: Saiful Azad received his PhD in information engineeringfrom the University of Padova, Italy, in 2013. He completed his BScfrom the Islamic University of Technology, Bangladesh, in computer

Page 20: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xxii Editor Biographies

and information technology, and his MSc from International IslamicUniversity Malaysia, in computer and information engineering.After completion of his PhD, he joined as a faculty member in theDepartment of Computer Science at American International Uni-versity – Bangladesh. He is currently with the Faculty of ComputerSystems and Software Engineering, University Malaysia Pahang,Malaysia. He started working on Underwater Acoustic Networksduring his PhD, and it remains the main focus of his research. Hisresearch interests also lie in designing and implementing commu-nication protocols for different network architectures, QoS issues,network security and simulator design. He is one of the developersof the DESERT underwater simulator. He is also the author of manyscientific papers published in renowned international peer-reviewedjournals and conferences. He is an editor/author of the 2014 bookPractical Cryptography: Algorithms and Implementations using C++(CRC Press, USA). He also serves as a reviewer and technical programcommittee member for many renowned peer-reviewed journals andconferences.

Third Editor

Name: Al-Sakib Khan PathanPosition: Associate Professor, Southeast University, BangladeshBiography: Al-Sakib Khan Pathan received his master’s degree and PhDin computer engineering from Kyung Hee University, South Korea, in2009, and his bachelor’s degree in computer science and informationtechnology from the Islamic University of Technology, Bangladesh, in2003. He is currently an associate professor at the Computer Scienceand Engineering department, Southeast University, Bangladesh.During 2010–2015, he was with the Computer Science depart-ment at the International Islamic University Malaysia, and, during2009–2010, with the BRAC University, Bangladesh. He also workedas a researcher at Networking Lab, Kyung Hee University, SouthKorea, during 2005–2009. His research interests include wirelesssensor networks, network security, cloud computing and e-servicestechnologies. He is the recipient of several recognitions and bestpaper awards, and has several notable publications in these areas. Heserves in various positions in renowned journals and magazines, andis the editor/author of 15 books. He is also a senior member of IEEE.

Page 21: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xxiii

Preface

At the onset, we would like to clarify that this is not a textbook. Weprefer to use the term ‘comprehensive guide’, as the book coversmany critical aspects of IPTV (Internet Protocol Television) andIPTV delivery networks. When thinking about working on such abook, we observed that most of the books available in the markethad covered only or mainly the basics of IPTV. There was no bookavailable for researchers, academicians, students and practitionersthat discussed in depth the IPTV delivery networks for both live andon-demand IPTV services. We also felt the pressing need to capturethe issues of delivering IPTV over various emerging networking andcommunications technologies in a book or volume that could beused as reference material – both by general readers of the topic andexperts in the field.

To introduce the theme of the book for general readers, let us saywhat IPTV is about. IPTV is basically a system that exploits high-speedbroadband networks to deliver TV services to subscribers. It hasbeen made possible today due to the advancements in high-speedbroadcasting networks and the great evolution in digital video broad-casting techniques. From the service provider viewpoint, the primechallenge in the IPTV system involves providing high-quality serviceat minimum costs through existing and emerging delivery networks.In fact, IPTV delivery networks have witnessed several developmentsstarting from the central architecture, which delivers content using asingle main server. Subsequently, it was replaced by server farms orclusters. Then, the hierarchical architecture was introduced, whichdistributes content from a set of cache servers. At a later stage, thedistributed architecture was proposed to replicate content into a setof servers distributed at different geographical locations. Given all

Page 22: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xxiv Preface

these past developments, a recent and one of the most promisingarchitectural solutions for IPTV delivery network is the cloud-basedarchitecture. These are the issues that we discuss in this book, sothat readers can understand the latest advancements alongside therequired basics. And hence, we call it a ‘comprehensive guide’.

We are glad that we were able to complete this book by incorporat-ing the contributions of researchers from around the globe, some ofwho are known names from renowned universities and institutions.We have divided the book into three main parts, each of which con-tains some chapters, organised as follows:

Part I: IPTV Delivery Networks Fundamentals

Chapter 01 – IPTV: Delivering TV Services over IP NetworksChapter 02 – IPTV Streaming ClassificationChapter 03 – Efficient IPTV Delivery over EPONChapter 04 – Content Awareness in IPTV Delivery Networks

Part II: QoS and QoE for IPTV Delivery Networks

Chapter 05 – Zapping Delay Reduction in IPTV SystemsChapter 06 – Channel Zapping Time in IPTV: Challenges and Solu-

tionsChapter 07 – Delivering High-Definition IPTV Services over IP-Based

NetworksChapter 08 – IPTV Network Security: Threats and CountermeasuresChapter 09 – Anomaly Detection and Big Data in IPTV Networks

Part III: Mobility and Next-Generation Delivery Networks

Chapter 10 – Taxonomy of Intra-Domain Mobility ManagementSchemes in Wireless Mesh Network for Implementing MobileIPTV

Chapter 11 – Towards Multi-Operator IPTV Services over 5G Net-works

Chapter 12 – Technologies and Architectures for Future IP TelevisionServices

As may be understood, the book has a total of 12 chapters. The firstpart (which contains four chapters) talks about the fundamental issuesof IPTV delivery networks. This part could give some basic idea to thegeneral readers of the topic whilst also being useful to experts. The sec-ond part (which contains five chapters) discusses Quality-of-Service

Page 23: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Preface xxv

(QoS) issues for IPTV delivery networks. We have also consideredmatters of security and anomaly detection as core issues related toquality. The last part addresses mobility issues and next-generationdelivery networks. This part has three chapters that expose the readersto some futuristic thoughts and visions. As technological advance-ments are very rapid in this field, more novel ideas and methods ofdelivering IPTV may emerge soon. However, in this book, we havecaptured the latest available and usable technologies at the time ofpublication. Hence, we hope that this book will be appreciated by read-ers as a reference material that has no parallel at this time.

The EditorsSuliman Mohamed FatiSaiful AzadAl-Sakib Khan Pathan

Page 24: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

xxvii

Acknowledgement

We would like to thank Almighty Allah for allowing us to completethis book, which has indeed taken a long time and continuous efforts.We are indebted to the chapter authors for their valuable contribu-tions to this book. Special thanks are owed to the Wiley editorial staff,who made the task easy for us and gave us timely assistance during thepreparation of the chapters. We would also like to sincerely thank ourfamily members, who inspire us to excel in our professional fields andextend us their mental support.

Page 25: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

1

Part I

IPTV Delivery Networks Fundamentals

Page 26: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

3

1

IPTV: Delivering TV Services over IP NetworksSuliman Mohamed Fati and Putra Sumari

1.1 Overview

When we watch television, it is not possible to ignore the vast changethat television service has undergone over time. In fact, televisionservices have been experiencing several developments since theinvention of the television. The first analogue colour television broad-cast was started in 1951 via terrestrial broadcast with only a singlechannel (Fink, 1951; Baker, 1984). Then, another television service wasdelivered via cable (Dees et al., 2007). After that, digital TV emergedwith the benefits of digital signal transmission and digital compres-sion techniques. These benefits let TV service providers broadcasta variety of channels with high quality within a limited bandwidth(Joshi and Maskara, 2012; Picard and Siciliani, 2013). Furthermore,digital TV bridged the gap between the TV industry and computingindustry as a result of the digital transmission of signals. Morerecently, Internet TV, also called online TV, has been delivering TVservices over the public Internet without any commitment on the partof Internet service providers. The user must surf the website of the TVservice provider and enjoy watching live and on-demand TV content(Simpson, 2013). YouTube is the dominant Internet TV provider, with85% of the Internet TV consumption in the USA (Lee et al., 2013).

With the prosperous evolution of digital video formats and broad-casting as well as the advent of high-speed broadband networks, a newera of TV system has emerged known as IPTV, which can be definedas ‘multimedia services such as television, video, audio, text, graphicsand data delivered over IP-based networks that provide the required

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 27: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

4 IPTV Delivery Networks

level of quality of service (QoS)/quality of experience (QoE), security,interactivity and reliability (International Telecommunication Union[ITU-T], 2006). In other words, IPTV is a television system thatdelivers its content to subscribers over a broadband network. Thebroadband network can be described as a communication networkover which all the voice, data, video and text services are deliveredto end-users instead of isolated delivery networks (Moore and SillerJr, 2004). As high-speed broadband networks exploit the digitalrepresentation of content, IPTV offers a wide variety of channels withhigh quality and interactivity compared with other TV systems. Inaddition, IPTV gives a simultaneous transmission of auxiliary data(e.g., subtitles, electronic programme guide [EPG]).

IPTV has recently become a popular trend in delivering TV servicesdue to the increasing number of broadband network users. Globally,many companies work as service providers offering IPTV services. In2009, there were almost 600 commercial IPTV operators worldwide(Nordström, 2009). According to Multimedia Research Group Inc.(MRG, 2012), this number was more than 930 operators worldwide.In Malaysia, only two competitive IPTV service providers have beenoperating. HyppTV is an IPTV service provided by Telekom Malaysia(TM). TM launched its IPTV services in 2004 after migrating theservice delivery to Malaysia’s High-Speed Broadband (HSBB) net-work. The second IPTV service provider in Malaysia is Astro Byondlaunched in 2011 and has been transmitting through fibre-opticbroadband. Astro Byond operates in partnership with Time DotcomBerhad and Maxis.

1.2 Internet Protocol Television

Due to the expeditious improvement of IP networks, along with thesignificant growth of users’ bandwidth, IPTV has become popularworldwide as a promising way of delivering TV-related servicesincluding live broadcasting, video on demand (VoD) and othercontinuous streaming services to end-users. The number of IPTVsubscribers globally grew from 2.03 million in 2005 to 4.56 millionin 2006 and reached 60 million in 2011. According to SNL Kagan,the number of IPTV subscribers reached 117.39 million by the endof 2014, and it is expected to reach 165 million by the end of 2017.According to Jacqui (2007), IPTV subscribers occupy currently more

Page 28: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 5

than a third of the TV-viewing market. In 2017, IPTV is consideredone of the most recent technological advancements made by humans.Moreover, IPTV is widely recognised as a proven and popular way ofproviding TV-related services including live broadcasting, VoD andother continuous streaming services over IP-based networks along-side the Internet, telephony, gaming and other home-networkingservices. According to an ITU-T focus group (ITU-T, 2006), IPTVcan be defined as ‘multimedia services such as television/video/audio/text/graphics/data delivered over IP-based networks that man-age to provide the required level of QoS/QoE, security, interactivityand reliability’.

The major advantages of IPTV are addressability and interactivity(GlobeComm, 2006). In a fast-paced world, subscribers love to watchwhat they want when they want to, instead of scheduled channelbroadcasting. IPTV grants this facility to subscribers by allowing themto choose only the channel they want to watch. Unlike most of thelegacies of TV systems, IPTV takes advantage of the two-way com-munication in IP-based networks to let end-users enjoy the unlimitedinteractivity feature. By means of the interactivity feature, users cansubscribe/unsubscribe to any channel or programme anytime withoutany intervention from the service provider. Besides, IPTV offers awide variety of high-definition channels, along with the streamingmedia on demand (VoD) and the simultaneous transmission ofauxiliary data (e.g., subtitles, EPG) as well. Consequently, IPTV hasrecently become a popular trend in delivering TV services. Globally,there are many companies offering IPTV services to end-users.Likewise, telecommunication companies (network providers) haveentered a hectic competition to increase their customer base andprofit by delivering IPTV services (Fati et al., 2014). In 2012, therewere almost 900 commercial IPTV operators worldwide (Nordström,2014). According to MRG (2014), this number was more than 1000operators worldwide.

Amidst such hectic competition, the key concern of serviceproviders is to provide high-quality services at lower costs. Thus,the challenge facing service providers is to build content deliverynetworks that use resources efficiently and diminish costs. However,designing such delivery networks is not an easy process. This isbecause IPTV content is huge in size and have an unsteady watchingpattern. Therefore, the delivery network design process is requiredto pay more attention to content characteristics, user behaviour and

Page 29: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

6 IPTV Delivery Networks

resource utilisation. Hence, the target in this chapter is to explorethe challenges that hinder IPTV delivery networks and the currentresearch directions that are looking at resolving these challenges inlight of content characteristics. Section 1.3 presents a brief historicaloverview on how the TV industry has been evolving over time to letIPTV become the most recent and dominant TV technology.

1.3 Evolution of TV to IPTV

Television services have experienced several developments since theinvention of television. In the 1930s, TV broadcasting started with alinear schedule. Such TV services were disseminated over ether to roofantennas. Broadcasting was national with central control of scheduling(Takayanagi, 2003). According to Dees et al. (2007), the first analoguecolour television broadcast was started in the 1950s via ether (terres-trial broadcast), and later via cable. Terrestrial and/or cable broadcastare/is still the primary means of delivering broadcast services, andhave a considerable market share in many countries (EBU, 2011).

With the advent of digital video formats and digital broadcasting,a new era of television has begun via cable, terrestrial or satellitebroadcasting. Digital television, proposed in the 1990s, has someadvantages over the analogue one (Valentin, 2004). For instance,digital television can provide more channels with better picture andsound quality. Moreover, digital broadcasting induces the possibilityof simultaneous transmission of auxiliary data (e.g., subtitles, EPG).

Due to the vast growth of broadband networks, the current trend isto turn into an ‘All-over-IP’ concept, wherein most service platformswill be unified into a single IP-based platform (Sabella, 2007). Forinstance, the existing IP-based networks deploy many services apartfrom high-speed Internet surfing. These services include IP-telephony(voice over IP), IP-surveillance, IP home appliance and IPTV. In the2000s, the first IPTV service started broadcasting commercially overIP-based networks (Davies and Delany, 2005; OECD, 2007).

Inasmuch as high-speed broadband networks utilise the digitalrepresentation of content, IPTV offers a wide variety of channels withhigh quality and interactivity as compared with other TV systems. Inaddition, IPTV gives a simultaneous transmission of auxiliary data(e.g., subtitles, EPG) along with many enjoyable services.

Page 30: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 7

Insofar as both IPTV and Internet TV use IP-based networks asa platform, it is worth mentioning that IPTV is completely differentfrom Internet TV. In Internet TV, the user must connect to the Inter-net and then access the entertainment website (e.g., YouTube.com)to watch or download video streams without any telecom operator’sresponsibility. In contrast, IPTV delivers the video streams to a set-topbox (STB), connected to a TV set, via IP-based networks under the fullresponsibility of a telecom operator. In the case of IPTV, the telecomoperator is responsible for network, service continuity, QoS, content,right management and user experience. In that sense, users shouldsubscribe to watch live and on-demand media services in a mannersimilar to that of current cable/satellite TV systems (Karantanis, 2009).

1.3.1 IPTV Services

IPTV providers mainly provide two streaming services: live channelsand VoD. The live channels are broadcast to all subscribers using themulticast streaming technique. The user joins the multicast tree of aparticular channel when he or she switches to this channel. In contrast,a dedicated connection is established between the user and streamingserver for a unicast stream. Another direction in multimedia broad-casting is P2P broadcasting, which is utilised to alleviate the load onthe servers by sharing the multimedia between the different set-topboxes directly. The different multimedia broadcasting techniques arenot discussed in this chapter.

In addition to live and on-demand streaming services, IPTV alsosupports a variety of information and control functions, such as usernotifications and content guide (CG). Open IPTV Forum (2009a)summarises the services that are provided by IPTV as follows:

Scheduled/linear TV services: Live TV and/or audio channels arebroadcast according to a predefined schedule. End-users can enjoywatching these live services and/or recording them. For privacy andsecurity purposes, these services can be protected using appropriateencryption techniques.Content on demand (CoD)/video on demand (VoD) services: Thiscategory of services allows users to watch on-demand content(videos). In other words, end-users can select an individual videofrom a list of available videos. Once the end-user issues a request,he/she can watch or download the requested content.

Page 31: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

8 IPTV Delivery Networks

Personal video recorder (PVR): This service enables users to recordscheduled TV programmes using local-based storage (PVR) ornetwork-based storage (nPVR). End-users can play the recordedcontent according to their convenience.Notification service: This service allows end-users to be informedof scheduled TV programmes (i.e., the starting time of a scheduledprogramme), emergency alerts or pre-configured reminders.Communication service: This service allows users a caller ID or shortmessage services (SMS) on screen, and also to chat with others whileenjoying IPTV services.Information service: This service provides end-users information ontheir subscription, management or the available content. This infor-mation may be delivered to either all or specific users.Advertisement service: This service enables advertisements to bedelivered to end-users. These advertisements can be customisedbased on the locations and preferences of end-users.

In addition, the European Telecommunications Standards Institute(ETSI) reports a diverse collection of IPTV services includingpersonal channels, user profiling and personalisation, servicediscovery, communications and messaging, notifications, interactionbetween users, targeted advertising, user-generated content andcontent recommendation (for further details, the reader can refer toETSI TS 183063).

1.3.2 IPTV Standardisation

To make IPTV a popular and a standard platform worldwide, stan-dardisations are conducted. IPTV standardisation aims to achievethe following purposes: interoperability, investment confidence andcost reduction (Fleury, 2006). For instance, end-users will often wantto access diverse content belonging to different service providersstored in a heterogeneous network. To let such heterogeneous IPTVcomponents interoperate smoothly, IPTV standardisation is required.Many organisations are involved in the process of standardisation ofIPTV services (Gaber and Sumari, 2012; Gaber, Sumari and Budiarto,2012). These organisations include Digital Video Broadcasting Project(DVB), International Telecommunication Union (ITU-T), EuropeanTelecommunications Standards Institute (ETSI), 3rd GenerationPartnership Project (3GPP), Open Mobile Alliance (OMA), Internet

Page 32: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 9

Engineering Task Force (IETF), Alliance for TelecommunicationsIndustry Solutions (ATIS), Cable Television Laboratories, Inc. (PacketCable), Open IPTV Forum and Home Gateway Initiative (HGI).

1.3.3 General Architecture of IPTV

The general IPTV architecture explains the different shareholders ofIPTV and the relationships among them (Mikoczy and Podhradský,2009; Open IPTV Forum, 2009b; Lee et al., 2009). Figure 1.1 depictsthe IPTV architecture and the involved domains.

Content provider domain: This domain, similar to film productioncompanies, collects content from different resources (or evenproduces content) and encodes them to a predefined media coding.Content providers own the intellectual property rights for contentsbelonging to them, and have the right to sell them to others (e.g.,service providers) through appropriate rights management andprotection mechanisms.Service provider domain: This domain purchases content fromdifferent content providers, packages them as services and thendistributes those services to end-users via the delivery network.Delivery networks are responsible for retrieving, protecting,

User preferences

User satisfaction

User devices

User subscription

management

Bandwidth codecs

Searching

Content production

Resource control

Delivery mode

User profile

management

Metadata

Digital rights

management

Contents

selection and

choices

End-user

4 6

1

3

5

2

Service ProviderContent Provider

Network Provider

Figure 1.1 IPTV domains (Lee et al., 2009).

Page 33: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

10 IPTV Delivery Networks

storing, distributing and delivering contents to the end-userdomain through the network provider domain.Network provider domain: In this domain, end-users and serviceproviders are connected via a shared underlying platform to interactwith each other. This platform consists of a variety of backbone andaccess networks according to the running network technologies.User authentication, charging and billing mechanisms should beprovided to service providers.End-user domain: This domain consists of related service terminalsthat allow the end-user to benefit from IPTV services. These ter-minals are connected to the network provider domain and receiveIPTV services from the service provider upon subscription.

According to Lee et al. (2009), a number of reference points (RPs)should be defined among the IPTV domains. Such RPs, denoted bynumbers in ovals in Figure 1.1, should control the relations amongthose domains. For instance, RPs 1, 4 and 6 show how the end-userinteracts with the network provider, service provider and contentprovider, respectively. Similarly, the interactions of the networkprovider with both the service provider and content provider arerepresented by RPs 2 and 5, respectively; whereas RP 3 depicts therelationship between the service provider and content provider.

With reference to Figure 1.1, the need for a unified platform thatcollaborates content providers, service providers, network providersand end-users is highly recommended to guarantee the integrity andconsistency between different shareholders. This unified platform iscalled an ‘IPTV delivery network’.

1.4 IPTV Delivery Network

The advent of IPTV has opened new avenues for content providers,service providers and network providers. Service providers benefit bydistributing their content, which is produced by content providers,to end-users. The network providers profit by delivering the contentover their network from the service provider to end-users (Lee et al.,2010). Service providers have two distribution options to deliverIPTV services to end-customers. The first option involves buildingtheir own private delivery network infrastructure, which is expensiveand requires extra effort for standardisation. The second option

Page 34: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 11

involves delivering their services using shared infrastructure. Shareddelivery networks are substrate networks where surrogate serversthat act transparently on behalf of the origin server are placed acrossthe network closer to the end-user for performance improvement.Contents from different service providers can be replicated from theorigin server to surrogate servers (Xu, 2009). A famous example ofshared delivery networks is the content distribution network (CDN).

1.5 Evolution of the Delivery Network

In their early days, video streaming services were provided by massivecentral data centres, as depicted in Figure 1.2a. Once the number ofincoming requests increases, this architecture suffers from the designflaw known as ‘single point of failure’ (SPoF) (Cho et al., 2008; Meng,Liu and Yin, 2010). In addition to SPoF, the other main shortcomingsof this architecture are prolonged delay and network congestion(Golubchik et al., 2001; Mir, 2011; Nair and Jayarekha, 2010). A scal-able model called ‘server cluster’ or ‘server farm’ is built by arrangingmultiple servers together such that the burden/load can be distributedamong them. This model is also augmented by a request dispatcher(e.g., layer-4 or layer-7 dispatchers). This dispatcher examines the

Cashe

server

Central

server

Set-top box

Set-top box

Set-top box

Set-top box

Set-top boxSet-top boxSet-top box

Set-top box

(a) Centralized Architecture (b) Distributed Architecture

Set-top box

Figure 1.2 Central and distributed delivery network architecture.

Page 35: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

12 IPTV Delivery Networks

requests and then distributes them among the cluster (Pathan andBuyya, 2007). To alleviate the problems of prolonged delay andnetwork congestion at the central server or server cluster, content canbe cached in different local servers, as depicted in Figure 1.2b, to placethe content as close as physically possible to the end-users. Althoughcache proxies are allocated to different areas in the whole networkto tackle the problems associated with the centralised architecture,SPoF still remains a severe flaw at each cache server (Meng, Liu andYin, 2010).

Caching or replicating content from the main source to local serversleads to the concept of CDNs. A CDN is considered a modernisticway of allocating replicas of content among several distributed serversto improve the performance and scalability of the provided services(Borzemski and Zatwarnicki, 2008; Pathan, Buyya and Vakali, 2008;Passarella, 2012). Akami, Digital Island, Radar, SPREAD, Amazonand Globule are famous examples of popular CDNs that are deployedworldwide for website hosting. According to Pathan and Buyya (2007),the new generation of CDNs has moved to multimedia streamingincluding IPTV services, yet are commercially unavailable currentlyas this is still in the research stage.

On the other hand, the hierarchical architecture is proposed aimingat improving the reliability and QoS offered. In this architecture,the streaming servers are organised hierarchically, with a main datacentre at the root, as shown in Figure 1.3. Under this architecture, ifa local server at any level suddenly stops, the streaming requests willbe redirected to a server at a higher level. A streaming request maytravel from the leaf to the root in case of content unavailability at thecache levels. The growing number of levels and servers improves theQoS. However, this exponential growth leads to higher storage cost(i.e., further replicas must be stored for each popular content). Thishigher storage cost increases the cost of the provided service, which,in turn, may lead to user dissatisfaction.

A promising architecture for IPTV delivery networks called‘cloud-based architecture’ has appeared in the works of Meng, Liuand Yin (2010) and Li and Wu (2010). The iCloud architecture (Meng,Liu and Yin, 2010) overcomes SPoF by aggregating the servers intoservice groups, as depicted in Figure 1.4, based on a proximity-awarerule where the adjacent servers are grouped in a single service group.

A second architecture, called ‘peer-service area architecture’ (Li andWu, 2010), divides the delivery network into many service areas, as

Page 36: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 13

Level 0

Level 1

Level 2

STB STB STB STB STB STB STB STB

Figure 1.3 Hierarchical delivery network architecture.

Super Hub Office Super Hub Office

Service GroupService Group

Figure 1.4 iCloud network architecture (Meng, Liu and Yin, 2010).

Page 37: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

14 IPTV Delivery Networks

Type 1 Video

Servers

Type 1 Video

Servers

ADSL

SWSW

SW

SWSW

SW

STB

Type 1 Video

Servers

Types 1 and 2 Video

Servers

Types 1 and 2 Video

Servers

Types 1 and 2 Video

Servers

Figure 1.5 Peer-service area architecture (Li and Wu, 2010).

shown in Figure 1.5. According to Li and Wu (2010), two types ofservers serve each service area: ‘Type 1’ servers allocate the popularcontent, and ‘Type 2’ servers allocate the unpopular content.

The customer belongs to only one service area and can request anyvideo from any server within the service area. If a subscriber requestsa non-existent video in his/her service area, this request will be redi-rected to the nearest service area that contains this video.

Li and Wu (2010) point out that this architecture can satisfy theQoS requirement and reliability. Thus, this architecture is consideredparticularly suitable for delivering IPTV services. Moreover, thepeer-service area architecture can overcome the challenges men-tioned by Meng, Liu and Yin (2010); it overcomes SPoF by allocatingmore than one server in a service area. Moreover, interconnectingthe different service areas allows the requests to be redirected fromone service area to another. The purpose of such interconnection is toensure QoS and exploit cost-sharing among these service areas. Thepeer-service area architecture lacks request distribution and contentreplication mechanisms. Thus, this architecture suffers from a loadimbalance problem.

Page 38: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 15

1.5.1 IPTV Delivery Network Characteristics and Challenges

The advent of IPTV has created great opportunities for differentparties to participate and benefit. These parties include contentcreators, broadband network owners and service brokers. Theconnection between these parties is depicted in the functionalIPTV architecture. The general IPTV architecture consists of fourdomains – namely, content provider, service provider, networkprovider and, finally, the end-user (Open IPTV Forum, 2009a,b;Mikoczy and Podhradský, 2009). The service provider buys contentfrom the content provider and then distributes it to end-users overa shared delivery network provided by the network provider. In suchshared delivery networks, many providers contract with the networkprovider to allocate their contents and to handle incoming requests.In this situation, all that the customers need is a subscription thatallows them to enjoy the provided services belonging to differentproviders via a special STB device.

IPTV, as a promising technology, is growing rapidly in terms ofsubscribers and revenue to become the standard means of deliveringhome and business entertainment content (Yarali and Cherry, 2005).Thus, telecommunication companies (network providers) are in fiercecompetition to increase their customer base and profit by deliveringIPTV services (Yarali and Cherry, 2005; Lee, Muntean and Smeaton,2009). The key concern of service providers in this hectic competitionis to provide high-quality services at minimum costs.

However, there are many elements that influence the process ofbuilding an IPTV delivery network. The choice of network archi-tecture is one of the most important elements. In fact, the IPTVdelivery network has been witnessing several developments startingfrom centralised architecture, which delivers content using a singlemain server. After this was replaced by server farms or clusters,the hierarchical architecture that distributes content into a set ofcache servers arose. In addition, the distributed architecture isproposed to replicate content into a set of servers distributed indifferent places. The most recent and promising development is thepeer-service area architecture (Li and Wu, 2010). In this architecture,the delivery network is divided into a set of interconnected serviceareas with a cluster of servers for each. Li and Wu (2010) argue thatthis architecture satisfies most QoS and reliability requirements.

Page 39: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

16 IPTV Delivery Networks

Peer-service area architecture also can overcome the challenges thathinder other architectures – such as SPoF, cost-sharing and QoS(Meng, Liu and Yin, 2010). According to Gaber and Sumari (2012),load imbalance can occur because of improper content allocation andinaccurate request distribution that ignores the attributes of nodes. Inpeer-service area architecture, content is allocated among two types ofservers without replications. Allocating the popular content withoutreplication lets the servers become hotspots. Moreover, peer-servicearea architecture lacks appropriate request distribution techniquesto distribute the load among different servers. Based on these lim-itations, peer-service area architecture suffers load imbalance andrequires some enhancements to overcome the problem.

The second element contributing to building the IPTV deliverynetwork is load balancing, which is considered one of the mostimportant performance metrics of the IPTV system. Load imbalancemeans that some servers are heavily overloaded while others arerelaxed. This problem degrades the QoS for IPTV services. Loadimbalance usually happens as a result of inadequate content allocationand improper request forwarding, which is caused by not consideringthe non-uniform request access patterns of both content and users.Thus, replication and request dispatching techniques are designed toalleviate the load imbalance problem in IPTV systems. ‘Replication’here refers to the even duplication of popular content among servers,aiming at reducing the overload. In fact, replication and request dis-tribution strategies have become good choices to reduce overload onthe backbone delivery network, improve performance and efficientlysatisfy customer needs (Cranor et al., 2003).

On the other hand, cost reduction is a cause of concern for serviceproviders. Hence, cost reduction is another important elementthat should be considered during the designing of IPTV deliverynetworks. In delivery networks, many service providers may shareresources and compete to deliver good-quality services. However,IPTV content is characterised by its huge size and rapidly changingeffective period. IPTV systems also suffer sudden peak workloads.Allocating large amounts of resources to cope with sudden workloadleads to low resource utilisation at non-peak hours. On the otherhand, not considering the peak workload leads to user dissatisfactionduring peak hours. Thus, resource allocation and replica placementproblems are important issues that should be considered mutually.In other words, resource allocation and replica placement should be

Page 40: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 17

integrated (Laoutaris, Zissimopoulos and Stavrakakis, 2005). Suchintegration can help reduce the wastage of resources by allocatingthe resources according to the necessitated replication scheme. As aresult, the total cost can be reduced.

1.6 The Key Issues of IPTV Delivery Networks

Despite the great benefits of delivery networks to both serviceproviders and content consumers, designing efficient delivery net-works is not a trivial task and presents potential problems that mustbe resolved. Delivery network composition, content distribution andmanagement, resource allocation and request redirection are the mainissues that must be considered while building the delivery network.Delivery network composition includes delivery network placementand determining server specifications and interaction among servers.Content distribution and management includes content selectionand distribution based on demand and cache/replica management.Resource allocation chooses the type and size of resources that arerequired for each surrogate server. Request redirection includes thetechniques used to distribute the requests among servers, aimed atmaintaining load balance and avoiding traffic congestion (Pathanand Buyya, 2009; Xu, 2009). According to Neves et al. (2010), theseproblems can be solved by considering them as optimisation problems.The optimal solutions to these optimisation problems can be foundbased on the given objective functions, which represent one or acombination of business goals. These business goals must be achievedto satisfy the acceptable level of QoS, and must include scalability, ser-vice availability, reliability, responsiveness, security and load balancing(Pathan and Buyya, 2009; Xu, 2009; Sierra-LLamazares, 2009).

One of the concerns of the present thesis is load balancing. Inshared delivery networks, allocating content among the serverswithout considering their load status and/or performing inaccuraterequests dispatching could lead to load imbalance. Therefore, theload imbalance problem can be solved in two steps. The first step isto replicate content according to its expected load among servers tobalance the expected load. The second step is to evenly distribute theincoming requests across the servers to maintain load balance acrossthe video servers. During literature review, these steps are widelyinvestigated. In addition, allocating content efficiently will resolve

Page 41: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

18 IPTV Delivery Networks

IPTV Delivery Network Issues

Content placement

Replica placement problem

Partial replication Full replication

ReplicationDisk

striping

Dynamic

placement

Caching

Request distribution

Distributed-

based

iCloud-

based

Cluster-

based

Content-blended

Content-aware

Cost function Proposed solution

Cost reduction

QoS improvement Evolutionary

Heuristic

Hierarchical

based

Distributed-

based

Resources allocation

Figure 1.6 IPTV delivery networks issues taxonomy.

the resource allocation problem. Figure 1.6 depicts the taxonomyof the issues related to IPTV delivery networks, including requestdistribution, content placement and resources allocation problems.

1.7 Conclusion

In recent years, IPTV has been delivering live and on-demand TVservices over high-speed IP-based networks. As these high-speedbroadband networks exploit the digital representation of contents,IPTV offers a wide variety of channels with high quality and interac-tivity as compared to other TV systems. Thus, IPTV has been growingrapidly in terms of subscribers and revenue. Telecommunicationoperators have engaged in stiff competition to deliver IPTV servicesto their customers. However, service providers need to increase theviewing rates of their content, and customers need to watch a widevariety of high-quality channels/content.

From the service provider’s viewpoint, the challenge in IPTV sys-tems is to build delivery networks that exploit the available resourcesefficiently and reduce service costs. However, designing such deliverynetworks is affected by many factors, including choosing the suitablenetwork architecture, balancing load, managing wastage of resourcesand reducing costs. Furthermore, IPTV content characteristics,particularly size, popularity and interactivity, play important roles in

Page 42: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 19

balancing the load and avoiding the wastage of resources for deliverynetworks. Accordingly, the focus of this chapter is to formulateand evaluate the load status of IPTV contents aiming at buildingcontent-aware IPTV delivery networks.

Building a delivery network for allocating large volumes of interac-tive content characterised by fluctuating popularity and non-uniformrequest patterns is challenging. Ignoring such characteristics can leadto load imbalance and affect the system’s performance. Therefore,modelling the status of content according to the characteristics ofIPTV content is very important in designing IPTV delivery networks.Such modelling helps to balance load by distributing incomingrequests based on the anticipated load of both content and servers.

References

Baker, W.R.G. (1984). The future of color television. Transaction onConsumer Electronics. IEEE, CE-30(2), 184–186.

Borzemski, L. and Zatwarnicki, K. (2008, September). CDNs with globaladaptive request distribution. In Knowledge-Based IntelligentInformation and Engineering Systems, 12th International Conference(KES 2008), Zagreb, Croatia, September 3–5, 2008, Proceedings PartII. (Lecture Notes in Computer Science; Vol. 5178). Springer, Berlin /Heidelberg, pp. 117–124.

Cho, D.H., Lee, K.Y., Choi, S.L., Chung, Y.D., Kim, M.H. and Lee, Y.J.(2008). A request distribution method for clustered VOD serversconsidering buffer sharing effects. Journal of Systems Architecture,54(1), 335–346.

Cranor, C.D., Ethington, R., Sehgal, A., Shur, D., Sreenan, C. andvan der Merwe, J.E. (2003, June). Design and Implementation of aDistributed Content Management System. Proceeding of the 13thInternational Workshop on Network and Operating Systems Supportfor Digital Audio and Video (NOSSDAV 2003). ACM, New York, NY,USA, pp. 4–11.

Davies, C. and Delany, J. (2005). IPTV VOD Market Analysis, TechnicalReport, Ovum.

Dees, E., VU, F.B., Voskuil, J. and Bode, R. (2007). Decentralizedadvertisement recommendation on IPTV. Master Dissertation. VrijeUniversiteit Amsterdam.

EBU (2011). The Future of Terrestrial Broadcasting. Technical Report.European Broadcasting Union, Switzerland.

Page 43: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

20 IPTV Delivery Networks

Fati, S.M., Budiartu, R. and Sumari, P. (2014, January). ProvisioningVirtual IPTV Delivery Networks Using Hybrid Genetic Algorithm.Proceedings of the 8th International Conference on UbiquitousInformation Management and Communication. ACM, p. 106.

Fink, D.G. (1951). Alternative approaches to color television. Journal ofCommunications and Electronic Engineering, 39(10), 1124–1134.

Fleury, J. (2006). IPTV related standardization activities in DVB, ITU-TIPTV Global Technical Workshop, Seoul, Korea.

Gaber, S.M.A. and Sumari, P. (2012). Predictive and content-aware loadbalancing algorithm for peer-service area based IPTV networks.Multimedia Tools and Applications, 1–24.

Gaber, S.M.A., Sumari, P. and Budiarto, R. (2012). Balanced contentallocation scheme for peer-service area CDN architecture for IPTVservices. Journal of ICT , 11, 131–146.

GlobeComm (2006). The IPTV Revolution: New Opportunities,New Challenges for Satellite Communications Systems, www.globecommsystems.com.

Golubchik, L., Muntz, R.R., Chou, C.F. and Berson, S. (2001). Design offault-tolerant large-scale VOD servers: with emphasis onhigh-performance and low-cost. Transactions on Parallel andDistributed Systems, IEEE, 12(4), 363–386.

ITU-T Focus Group IPTV, I. P. T. V. (2006). Service Requirements.Retrieved from: http://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-IPTV-2008-1-PDF-E.pdf.

Jacqui, C. (2007). Report: One-third of TV Watching to beVideo-on-Demand by 2012, Report, Ars Technica, http://arstechnica.com/uncategorized/2007/09/report-one-third-of-tv-watching-to-be-video-on-demand-by-2012/.

Joshi, S. and Maskara, S.L. (2012). Evolution and future generation of TV.International Journal of Modern Education & Computer Science,4(4): 50.

Karantanis, S. (2009). IPTV evolution – strategic issues for an IPTVprovider in Greece. Master thesis, Athens Information Technology,Greece.

Laoutaris, N., Zissimopoulos, V. and Stavrakakis, I. (2005). On theoptimization of storage capacity allocation for content distribution.Journal of Computer Networks, 47(3): 409–428.

Lee, F.L.F., Leung, L., Qiu, J.L. and Chu, D.S.C. (eds) (2013). Frontiers inNew Media Research. Research in Information Technology and Society.Taylor & Francis/Routledge, New York.

Page 44: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 21

Lee, G.M., Lee, C.S., Rhee, W.S. and Choi, J.K. (2009). Functionalarchitecture for NGN-based personalized IPTV services.Broadcasting, IEEE Transactions, 55(2), 329–342.

Lee, G.M., Raj Bhandari, S. and Crespi, N. (2010). Content delivery forpersonalized IPTV services using peer to peer proxy. Journal ofInternet Engineering, 4(1).

Lee, S.B., Muntean, G. and Smeaton, A.F. (2009). Performance-awarereplication of distributed pre-recorded IPTV content. Broadcasting,IEEE Transactions, 55(2), 516–526.

Li, M. and Wu, C.H. (2010). A cost-effective resource allocation andmanagement scheme for content networks supporting IPTV services.Computer Communications, 33(1), 83–91.

Meng, S., Liu, L. and Yin, J. (2010, July). Scalable and reliable IPTVservice through collaborative request dispatching. In Web Services(ICWS), 2010 IEEE International Conference, pp. 179–186).

Mikoczy, E. and Podhradský, P. (2009). Evolution of IPTV architectureand services towards NGN, in Recent Advances in Multimedia SignalProcessing and Communications (231) (eds M. Grgic, K. Delac andM. Ghanbari), Studies in Computational Intelligence, Springer, Berlin/ Heidelberg, pp. 315–339.

Mir, N. (2011, January). Analysis of Reliable and ScalableVideo-On-Demand Networks. Proceeding of the 10th InternationalConference on Networks (ICN 2011), St. Maarten, NetherlandAntilles, pp. 430–435.

Moore, S.S. and Siller Jr, C.A. (2004, January). Foundations ofConvergence in IP Packet Networks. Proceeding of 1st Conference onConsumer Communications and Networking (CCNC 2004). IEEE,Las Vegas, NV, USA, pp. 187–192.

MRG (2012). IPTV Market Leader Report. Technical Report.Multimedia Research Group, Inc. Retrieved from: http://www.mrgco.com/reports/iptv-market-leader-report-2013.

MRG (2014). IPTV Market Leader Report. Technical Report.Multimedia Research Group, Inc. Retrieved from: http://www.mrgco.com/reports/iptv-market-leader-report-2014.

Nair, T.R. and Jayarekha, P. (2010). A rank based replacement policy formultimedia server cache using Zipf-like law. Journal of Computing,2(3), 14–22.

Neves, T.A., Drummond, L., Ochi, L.S., Albuquerque, C. and Uchoa, E.(2010). Solving replica placement and request distribution in content

Page 45: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

22 IPTV Delivery Networks

distribution networks. Electronic Notes in Discrete Mathematics, 36,89–96.

Nordström, E. (2009). Overview of IPTV Systems. Technical Report.Retrieved from: http://www.bizopt.se/resources/reports/iptv-system.pdf.

Nordström, E. (2014). Overview of IPTV Systems. Technical Report.Retrieved from: http://www.bizopt.se/resources/reports/iptv-system.pdf.

Open IPTV Forum (2009a). Functional Architecture, Technical Report.Approved January 15, 2008, http://www.openiptvforum.org.

Open IPTV Forum (2009b). Service and Platform Requirements,Technical Report. V 1.1,2008-05-07 Final, http://www.openiptvforum.org.

Organization for Economics Development (OECD) (2007). Convergenceand Next Generation Networks, DSTI/ICCP/CISP(2007)2/FINAL,http://www.oecd.org/dataoecd/25/11/40761101.pdf.

Passarella, A. (2012). A survey on content-centric technologies for thecurrent Internet: CDN and P2P solutions. Computer Communications,35(1), 1–32.

Pathan, A.M.K. and Buyya, R. (2007). A taxonomy and survey of contentdelivery networks. Grid computing and distributed systemslaboratory. Technical Report. University of Melbourne.

Pathan, M. and Buyya, R. (2009). Architecture and performance modelsfor QoS-driven effective peering of content delivery networks.Multiagent and Grid Systems, 5(2), 165–195.

Pathan, M., Buyya, R. and Vakali, A. (2008). Content Delivery Networks:State of the Art, Insights, and Imperatives. In Content DeliveryNetworks. (Lecture Notes Electrical Engineering Vol. 9). Springer,Berlin / Heidelberg, pp. 3–32.

Picard, R.G. and Siciliani, P. (2013). Is There Still a Place for PublicService Television? Effects of the Changing Economics ofBroadcasting. Technical Report. Reuters Institute for the Study ofJournalism, University of Oxford.

Sabella, R. (2007). Network Architecture Evolution: Towards ‘All-IP’, the3rd EuroNGI Conference on Next Generation Internet Networks,Trondheim, Norway, pp. xviii–xix.

Sierra-LLamazares, K.G. (2009). An adaptive admission control and loadbalancing algorithm for a QoS-aware Web system. DoctoralDissertation, Universitat de les Illes Balears, Spain.

Page 46: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV: Delivering TV Services over IP Networks 23

Simpson, W. (2013). Video Over IP: IPTV, Internet Video, H. 264, P2P,Web TV, and Streaming: A Complete Guide to Understanding theTechnology. Elsevier/Focal, Amsterdam. Print.

Takayanagi, K. (2003). The Dawn of TV Broadcasting in Japan, BroadcastTechnology Magazine 14, Japan.

Valentin, R. (2004). Digital TV Broadcasting Handbook, ABE ElettronicaS.p.A.

Xu, S. (2009). Replica Placement Algorithms for Efficient InternetContent Delivery. Doctoral dissertation, University of Adelaide,Australia.

Yarali, A. and Cherry, A. (2005, November). Internet Protocol Television(IPTV). Proceeding of the Annual Technical Conference of IEEE(IEEE TENCON 2005). IEEE, Melbourne, Australia, pp. 1–6.

Page 47: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

25

2

IPTV Streaming ClassificationMiguel Masciopinto, Pedro Comesaña and Fernando Pérez-González

2.1 Introduction

Until the past decade, video distribution was predominantly focusedon specific broadcasting channels (satellite, terrestrial, cable) andhardware devices (video-tapes, compact disks (CDs), DVDs). In sharpcontrast, video distribution over nontraditional channels has beensuccessful in the past few years. The foremost among those newdistribution channels are VoD (Little and Venkatesh, 1994) over IP(Internet Protocol; Information Sciences Institute, 1981) networksand IP multicast systems (Deering, 1989), which have achievedspectacular commercial success, as epitomised by the US-basedon-demand streaming media provider Netflix, Inc. (Netflix, 2007).Both VoD and IP multicast systems make rational use of networkresources, as they use IP networks for delivering content whilethey are being consumed (in technical words, content is streamed),instead of requiring the full reception of the content for the clientto start playing it. Additionally, as IP networks have been massivelydeployed during the past decades, the necessary infrastructure isalready in place, so these multimedia distribution systems are verycost-effective. Furthermore, because IP networks can also be usedfor delivering other types of data and different kinds of multimediacontent (e.g., audio, images, video and so on), data-independence (ingeneral, multipurpose independence) becomes another key feature.Consequently, multimedia content distribution technologies basedon IP networks have achieved huge success in the entertainmentindustry. A good proof of this relevance is the online distribution of

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 48: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

26 IPTV Delivery Networks

movie premieres, streaming-specific TV series and live events withgreat social impact.

Depending on the scheduling nature, video streams are typicallyclassified as:

• VoD services, where the user asks for the content to be delivered. Themain advantage of these systems is that they allow users to selectthe multimedia content on demand (i.e., there are no schedulingconstraints). Therefore, they are typically related to the time-shiftedstreaming of multimedia content.

• Multicast services, where the content is scheduled for delivery andusers ask to be included in the destination list. In this case, usersare not allowed to select the multimedia content (i.e., the user mustaccept scheduling constraints). They are typically used for perform-ing on-the-fly streaming of content.

While both scheduling choices may be used for transmitting videocoming from terrestrial and satellite channels, typically only VoD isused for distributing prerecorded content, for example, those readfrom a DVD.

The new IP network video distribution paradigm brings numerousadvantages both to customers and content providers. From the pointof view of the customers:

• These new distribution schemes are easy to use.• In contrast to previous platforms based on cable, terrestrial and

satellite distribution, customers can choose from a wider variety ofvideo content.

• Pause, play, rewind and forward functions are available.• In some business models, customers just pay for the content they

consume.• Specific hardware is not required.

And from the point of view of content providers:

• The market is potentially unlimited.• Infrastructures are cheaper and faster to deploy.• The technology is well-known, thoroughly tested and widely used.

Unfortunately, due to the simple and cheap infrastructure, virtuallyanyone can become a content provider, and, consequently, thisvideo distribution technology raises new legal and technical prob-lems related to the copyright of the delivered multimedia content.

Page 49: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 27

Of course, the technological ability to transmit a content does notimply that rights are granted to do it; copyright restrictions onthe involved content must still be observed. Indeed, illegal contentdelivery causes huge damages to the legitimate right owners, whoare therefore interested in tracing back the origin of the unlawfullystreamed versions of their content as a means of learning about theunauthorised providers and thus avoiding illegal uses. Two relevantexamples are Kienzle (2013), where losses resulting from multimediapiracy are reported, and Johnson (2013) where losses that would becaused to the National Football League and the Major Baseball Leagueby the IP streaming service provided by the company are discussed(Aereo 2012).

With this need in mind, the contribution of this chapter is theproposal of a set of features that characterise the footprints leftby the video source and the streaming strategy (i.e., on-the-fly vs.time-shifted) of the content transmission in the IP packet dispatchtime distribution. Based on those features, in the first step thestreamed content is classified as on-the-fly or time-shifted; in thesecond stage, the content is classified according to its source assatellite, terrestrial or DVD. Due to geographical constraints, only theEuropean standards for digital video broadcast, namely, DVB-S andDVB-T are considered here.

To the best of the authors’ knowledge, Masciopinto and Comesaña(2012) is the only previous work in which the classification prob-lem of video streaming sources was addressed, where only DVB-Sand DVB-T sources were considered. In this chapter, the sourceclassification problem is extended by adding the DVD source; thus,a classification in three sources (satellite, terrestrial and DVD) isperformed. Furthermore, this chapter proposes for the first time inthe literature a classification method for identifying the streamingstrategy of a video stream (on-the-fly or time-shifted).

Concerning programme (meaning a collection of video, audioand other data streams, typically corresponding to a TV channel)delivery, the analysed streams comply with the Internet Protocoltelevision (IPTV) standard (ETSI Standard, 2009b), while VideoLanClient (VLC) libraries (VideoLAN, 2001) were used as IPTV servers.Moreover, no processing at the signal level is applied to the streamedvideo; specifically, neither video nor audio transcoding is considered.

In this chapter, we focus on IPTV-compliant streams based on theuse of User Datagram Protocol (UDP) and Real Time Protocol (RTP)

Page 50: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

28 IPTV Delivery Networks

(ETSI Standard, 2009b). Nevertheless, it is worth mentioning that alarge share of worldwide video streaming traffic over IP uses Trans-mission Control Protocol (TCP) (Sripanidkulchai, Maggs and Zhang,2004; Van der Merwe, Sen and Kalmanek, 2002). On the other hand,several studies forecast an increase of UDP-based IPTV, partly hingingon the current extensive use of this kind of video distribution in China(CAIDA, 2013). The increasing importance of UDP-IPTV is also illus-trated by the growing number of commercial headends (e.g., Arantia,2010; Cisco Systems, 2011; SoChuang, n.d.; Unitron, n.d.) and com-mercial software solutions (e.g., WOWZA 2007) that use this protocol.

Specifically, MacAulay, Felts and Fisher (2005) recommend theuse of the so-called ‘native RTP’ (i.e., the delivery of video streamsover UDP+RTP without any other packetisation of the DVB stream),leading to a very efficient video streaming solution. Other works (e.g.,Espeland et al., 2007; Zhao et al., 2013) propose to use a hybrid systemto benefit from the respective advantages of TCP and UDP videostreaming: It is well-known that TCP streams can go through firewallsand Network Address Translation (NAT) systems, thus guaranteeingdata delivery, while UDP+RTP streams avoid video delays due topacket retransmissions, provide jitter compensation and enable IPmulticast distribution (Wu et al., 2001). As an example of this hybridapproach, Espeland et al. (2007) propose to use UDP+RTP from theserver to a proxy that is located as close as possible to the client,while TCP is used from the proxy to the client (so the stream cango through firewalls in the network segment next to the client). Inanother example, in Zhao et al. (2013), the most important videobitstream parts (e.g., intra-coded frames or essential control data todecode a sequence of frames or the entire video stream) are deliveredover TCP, and the remaining video stream over UDP+RTP. For thereasons mentioned earlier, this work focuses on UDP+RTP streams,which is also sufficient to address the hybrid cases.

The remaining of this chapter is organised as follows: Section 2.2describes the studied framework, briefly summarises the relevantaspects of IP-based video distribution technology and introducesthe footprint that will be exploited for classification purposes. Then,Section 2.3 presents the classification algorithm, and Section 2.4describes the experimental framework used for evaluating it. Theobtained results are reported in Section 2.5, where the relevance ofthe different features is also analysed. Finally, our conclusions andfuture work are presented in Section 2.6.

Page 51: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 29

Hereinafter, boldface lowercase letters denote vectors (e.g., ‘a’),while the length of a generic vector is referred to by using such a vectoras the subindex of s (e.g., sa is the length of vector a); furthermore, a(i)stands for the ith component of vector a, and matrices are denoted bycapital letters.

2.2 Framework

The Moving Picture Experts Group (MPEG, 1988) defines an Elemen-tary Stream (ES) in (ISO/IEC Standard, 2000a) as one of the codedvideos, coded audios or other coded bit streams encapsulated in Pack-etised Elementary Stream (PES) packets (consequently, an ES is usuallythe output of a video or audio encoder). In turn, those PESs buildan MPEG2-Programme Stream (PS) or an MPEG2-Transport Stream(TS). These two kinds of entities differ on the allowed programmesand time bases; while the latter can be used for encapsulating multi-ple programmes with different time bases, the former only allows oneprogramme1 per stream (ISO/IEC Standard, 2000a), and the involvedPESs must share a common time basis.

Broadcasted multimedia content could be streamed on-the-fly orafter being saved to a storage device. Accordingly, video streams canbe classified as:

1. Time-shifted streaming (TSS): The main characteristic of thisvideo distribution strategy is that the contents to be streamed(films, documentaries, series, TV shows, and so on) are storedin the streaming server. Therefore, the following sources can beconsidered in this framework:• Multimedia content coming from a DVD or similar (MPEG2-PS

format).• Digital television (DTV) programmes (broadcast according to

the DVB standard, which makes use of the MPEG2-TS format)that produce a delayed retransmission – that is, time-shiftedplaying. Two types of DVB sources are considered:– DVB-S (ETSI Standard 1997).– DVB-T (ETSI Standard 2009a).

1 A program is defined as a collection of ESs with a common time basis, which isintended to have a synchronized presentation (ISO/IEC Standard (2000a)), e.g., a TVchannel.

Page 52: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

30 IPTV Delivery Networks

DVD player

DVB-T

DVB-S

Storage device

IPTV

gateway

IPTV

gateway

Internet

Live

streaming

Time-

shifted

Figure 2.1 Framework for IPTV video streaming.

2. On-the-fly streaming (OFS): As mentioned earlier, in this case,the streaming is performed on the fly. It is typically related to theretransmission of live programmes – for example, sports events.Therefore, in this case, the considered sources are only DVB-S andDVB-T.

Figure 2.1 illustrates the analysed framework. Three possible sourcesare considered (DVB-S, DVB-T and DVD), as well as the two streamingstrategies described earlier (TSS and OFS).

2.2.1 IPTV Description

In this work, we assume that the IPTV standard (ETSI Standard,2009b) is used for delivering multimedia content over IP-basednetworks; this standard has an advantage with respect to otherdistribution protocols of only slightly changing the MPEG2-TSpacket structure used by most digital television standards – forexample, Digital Video Broadcasting (DVB, 1993), Advanced Tele-vision Systems Committee (ATSC, 1982) and Integrated Services

Page 53: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 31

Digital Broadcasting (ISDB) (DIBEG, 1997). Due to the authors’location, only European DVB standard streams are considered inthe experiments performed in this work. We remark, however, thatthe same approach can be applied to any other American ATSC orJapanese ISDB compliant streams, as they are also MPEG2-TS-based.

Furthermore, although both MPEG2-TS and IPTV streams maycontain several programmes, we will focus on the reasonable case(especially if one has in mind bandwidth requirements) where eachIPTV stream contains only one programme. Additionally, as itwas already mentioned, the DVD format is based on MPEG2-PS;consequently, to be streamed by IPTV, DVDs must be converted toMPEG2-TS. This is easily achieved by mapping the PES packets fromthe PS payload to the TS payload, as explained in ISO/IEC Standard(2000a).

Concerning the IPTV packet structure, it is worth noting that IPTVis based on IP, UDP and RTP (Hoffman et al., 1998; Schulzrinneet al., 1996). Therefore, the IPTV packet structure is basically givenby IP, UDP and RTP headers followed by several MPEG2-TS packets,as illustrated in Figure 2.2. In general, an arbitrary integer numberof 188-byte MPEG2-TS packets can be encapsulated within an IPpacket. Nevertheless, due to the maximum transfer unit (MTU) ofany Ethernet-based network, to avoid IP fragmentation, the numberof MPEG2-TS packets per IP packet should be smaller than or equalto 7; indeed, with the aim of maximising channel efficiency, IPTVpackets typically contain exactly seven MPEG2-TS packets.

Seven transport stream packets

RTP packet encapsulated in a UDP/IP packet

TS packet

1

IP

header

UDP

header

RTP

header RTP payload

Timestamp

TS packet

2

TS packet

3

TS packet

4

TS packet

5

TS packet

6

TS packet

7

Figure 2.2 Scheme of IPTV packet structure.

Page 54: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

32 IPTV Delivery Networks

00

1

2

3

4

5

6

7

2 4 6 8 10

Time [s]

IPT

V b

itra

te [

Mb

its/s

]

12 14 16 18 20

Figure 2.3 Example of IPTV piecewise constant-rate of a streamed DVB-Sprogramme.

Finally, it is also relevant for our purposes to mention that thebitrate of one-programme IPTV streams is piecewise constant, thatis, IPTV is based on the use of constant-rate bursts; this propertyis illustrated in Figure 2.3. The length of those bursts is an integernumber of MPEG2-TS packets. To minimise bitrate peaks, IPTVservers try to uniformise their output bitrate; this process requirespacket buffering and modifies the instantaneous bitrate distributionof the considered programme.

2.2.2 IPTV Bitrate Footprint

During the bitrate uniformisation process, the IPTV server takes thevideo bitrate into account to manage the output buffer. If the videois delivered time-shifted, the IPTV server can manage the buffer in abetter way than for on-the-fly delivery. Therefore, the time distribu-tion of IPTV packets after the bitrate uniformisation process might beaffected by the streaming strategy.

Page 55: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 33

A similar approach is followed for source identification. Accordingto ISO/IEC Standard (2000a), the programmes in an MPEG2-TSare statistically multiplexed. Considering that different streamingsources (e.g., DVB-T, DVB-S, DVD) have a characteristic bandwidth(e.g., DVB-S bitrate is about 42 Mbps (ETSI Standard, 1997), and thatDVB-T bitrate is typically not larger than 20 Mbps (ETSI Standard,2009a), and that a different number of programmes are multiplexed,one would expect that the instantaneous rate of programmes comingfrom different sources will follow different statistical distributions. Asmentioned earlier, the piecewise constant-rate of IPTV streams willmodify that distribution, but traces of the source will remain.

This work tries to exploit such time-footprint to detect both thestreaming strategy of the transmission and the source of a streamedcontent. Specifically, the timestamp at the RTP header of each ITPVpacket is exploited; this timestamp reports the IPTV packet dispatchtime by considering a 32-bit counter running at 90 kHz.

This time footprint was already exploited in Masciopinto andComesaña (2012), where it was used for distinguishing betweenDVB-S and DVB-T sources. Here, its application is extended todistinguish between DVD and DVB-S/T sources and to classifybetween TSS and OFS.

2.3 Classification Scheme

As mentioned in the preceding text, the proposed classificationmethod will exploit the instantaneous bitrate distribution, whichwill be computed from the RTP timestamp. Specifically, we willdenote by qn(i) the ith RTP timestamp of the nth programme, wheren = 1,… ,N , with N being the number of streamed programmes,i = 0,… , sqn

− 1 and sqnbeing the number of IP packets corre-

sponding to the nth streamed programme. Therefore, in general, theinstantaneous bitrate for the ith IP packet of the nth programme willbe computed as

rn(i) =(188 ⋅ 7 + 40) ⋅ 8

19⋅104 ⋅ (qn(i + 1) − qn(i))

[bits∕s],

where the numerator stands for the total IP packet size (in bits)and the denominator is the time between consecutive packets. Notethat 9 ⋅ 104 is the RTP timestamp counter frequency in Hz, 188 is

Page 56: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

34 IPTV Delivery Networks

the length in bytes of one MPEG2-TS packet, seven is the numberof MPEG2-TS packets in each IPTV packet and 40 is the lengthof the IPTV packet headers (including IP, UDP and RTP headers)in bytes. Note that, as discussed previously, in IPTV streams, ratechanges happen on an MPEG2-TS packet basis; therefore, a bitratechange could happen during the transmission of an IP packet, and,consequently, that IP packet would be transmitted at two differentrates.

From rn(i), it is possible to compute the following features that tryto capture the characteristics of the IPTV stream bitrate:

• tn(j): Length (in terms of IP packets) of the jth constant-rate burstfor the nth programme;2

• p(j): Instantaneous bitrate of the jth constant-rate burst for the nthprogramme;

• d(j) = |pn(j+1) − pn(j)|: Absolute difference between the instanta-neous bitrates of the (j+1)th and jth constant-rate bursts for thenth programme;

where n = 1,… ,N , j = 0,… , stn− 1 and stn

is the number of ratechanges for the nth programme. Note that stn

= spnand sdn

= spn− 1.

To make a classification decision, the features correspondingto L rate changes will be required. Therefore, the feature vectorscorresponding to the nth programme (i.e., tn, pn and dn) are split intoL-length blocks, yielding

tln(j) = tn(l ⋅ L + j),

pln(j) = pn(l ⋅ L + j),

dln(j) = dn(l ⋅ L + j),

where l = 0, · · · , Ln − 1, j = 0, · · · , L − 1 and Ln =⌊

sdn

L

⌋is the number

of L-length blocks of rate changes. Additionally, rn is also split intosubvectors rl

n, which contain those values of rn corresponding to thepackets in the lth L-length block of rate changes; therefore, the size ofrl

n, denoted by srln, can be written as srl

n=∑L−1

j=0 tn(l ⋅ L + j).

2 Whenever an IP packet is transmitted at two different rates (i.e., when the ratechange happens during the IP packet transmission), the IP packet is not considered forconstant-rate burst length. This approximation only marginally affects the estimatedvalue of the constant-rate burst length as, in general, tn(j) ≫ 1.

Page 57: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 35

Notice that L must be chosen as a trade-off between the total cap-ture time and the availability of enough data for a reliable classifica-tion – that is, a large value of L will improve the correct classificationrates but at the cost of increased capture time. Furthermore, as therate changes depend on several factors (e.g., the variability of the inputstream rate, the buffer state and so on), a general upper bound on thecapture time required for obtaining those L rate changes cannot bederived. This will be further discussed in Section 2.5, where results onthe average and maximum capture time are reported.

From the feature vectors discussed earlier (i.e., rln, tl

n, pln and dl

n),a set of empirical statistics is derived for use in the classificationalgorithm. The target of those statistics is to summarise the IPTVrate variability, which, as discussed in the preceding text, is expectedto depend on both the streaming strategy and the source of thestreamed programme, and, consequently, provide useful classificationinformation. The used statistics are the first- and second-order empir-ical central moments of tl

n, pln and dl

n, as well as the second-orderempirical central moment, Fisher’s measure of skewness and thekurtosis of rl

n. Specifically, the considered features are:

1. tln.= 1

L

∑L−1j=0 tl

n(j); empirical first central moment of tln

2. σ(tln)

.=(

1L−1

∑L−1j=0 [tl

n(j) − tln]2

)1∕2; empirical second central

moment of tln

3. pln.= 1

L

∑L−1j=1 pl

n(j); empirical first central moment of pln

4. σ(pln)

.=(

1L−1

∑L−1j=0 [pl

n(j) − pln]2

)1∕2; empirical second central

moment of pln

5. dln.= 1

L

∑L−1j=0 dl

n(j); empirical first central moment of dln

6. σ(dln)

.=(

1L−1

∑L−1j=0 [dl

n(j) − dln]2

)1∕2; empirical second central

moment of dln

7. σ(rln)

.=(

1srl

n−1

∑srln−1

i=0 [rln(i) − rl

n]2)1∕2

; empirical second central

moment of rln

8. sk(rln)

.=

1srln

∑srln−1

i=0 (rln(i)−rl

n)3

(√1

srln

∑srln−1

i=0 (rln(i)−rl

n)2

)3 ; empirical third central moment of

rln(skewness)

Page 58: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

36 IPTV Delivery Networks

9. sk(rln)

.=

1srln

∑srln−1

i=0 (rln(i)−rl

n)4

(1

srln

∑srln−1

i=0 (rln(i)−rl

n)2

)2 ; empirical fourth central moment of

rln(kurtosis),

where rln.= 1

srln

∑srln−1

i=0 rln(i) stands for the average bitrate. Please note

that each of these empirical statistics is obtained for every L-lengthblock of rate changes; therefore, for the nth programme, nine empir-ical statistics are obtained for each of the Ln blocks. Higher-orderstatistics (e.g., fifth or sixth order) were tried, but finally discarded,as it did not improve classification results. Moreover, the average ofrl

n (i.e., rln) was not considered, as its value does not depend on the

variability of the IPTV bitrate, but only on the streamed video quality(ISO/IEC Standard, 2000b).

2.3.1 SVM Classifier

A support vector machine (SVM) is a supervised learning tool usedfor binary data classification (Abe, 2010; Burges, 1998; Press et al.,2007). An SVM solves a quadratic programming problem in whichthe margin between the separating hyperplane and the training datais maximised.

To quantify the ability of a machine-learning method to classify newdata (meaning data previously unseen by the system) in a real-worldapplication, the available data is split into training and testing sets (seeSection 2.4.3). As in any machine-learning method, the training set isused by the SVM for building a classification model, while the systemperformance is evaluated from the testing set.

In this chapter, the empirical statistics defined in Section 2.3 (i.e.,(1) to (9)) are fed to an SVM; the obtained classification results for theproposed scenarios are reported in Section 2.5.

2.4 Experimental Setup

In this section, the experimental framework used for checkingthe goodness of the classification scheme proposed in Section 2.3is described in detail. First, we summarise how the database isbuilt to mimic real scenarios; in the same vein, it is relevant to

Page 59: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 37

define the mechanism used for building the training/test set parti-tions. Additionally, the terminology related to error and detectionprobabilities is defined.

The construction of the database used for performing the exper-imental tests is described in Section 2.4.1, while the training/testset-partitioning method is defined in Section 2.4.2. Section 2.4.3introduces the classification performance measures that will be usedin Section 2.5 for evaluating the proposed classification method.

2.4.1 Database Construction

The results reported in Section 2.5 were obtained by consideringa database that contains video programmes from three differentsources: DVD, satellite and terrestrial. Specifically, the databasecontains ND = 16 DVD programmes, NS = 146 DVB-S programmesfrom 16 MPEG2-TSs and NT = 37 DVB-T programmes from nineMPEG2-TSs. DVB-S and DVB-T programmes are transmitted byusing both TSS and OFS.3

Because the proposed method exploits the IPTV rate variability,and the video content is a key factor of this variability, the databasewas designed to contain different types of programmes, such as news,movies and sports programmes from DVB-S and DVB-T sources.Therefore, the reported results factor in the variability of the videocontent.

The number of blocks of rate changes for each source are denoted by

KD.=

ND∑n=1

Ln = number of DVD blocks,

KS.=

ND+NS∑n=ND+1

Ln = number of DVB − S blocks,

KT.=

ND+NS+NT∑n=ND+NS+1

Ln = number of DVB − T blocks.

The number of blocks used for testing the SVM from each source aredenoted by KDV

, KSVand KTV

, respectively. As it will be discussed later(see Section 2.4.2), those values will depend on the SVM training/testset-partitioning method, and on the partitioning realisation.

3 DVD programs are TSS by definition (see Section 2.2).

Page 60: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

38 IPTV Delivery Networks

Similarly, we defineKF

.= number of TSS blocks,

KL.= number of OFS blocks,

and the number of test blocks from each class will be denoted by KFV

and KLV, respectively.

To balance the number of blocks from each source, and because thevalues of ND, NS and NT are quite different, the capture time is madesource-dependent. Specifically, the capture time for each programmewas about 300 seconds for DVB-S programmes, 480 seconds forDVB-T programmes and 1800 seconds for DVD programmes. How-ever, in general, KD ≠ KS ≠ KT , as the value of Ln depends on otherfactors, including the frequency of rate changes (which, in turn, isexpected to be a function of the streamed content and the streamingstrategy).

2.4.2 Training/Test Set-Partitioning

With the aim of performing the classification described in Section 2.3,the considered dataset is partitioned into two sets: One for training anSVM and another for testing the classification results. The partitionsare chosen using the stratified K-fold cross-validation technique(Kohavi, 1995; Raudys and Jain, 1991). This technique randomlysplits the dataset into K disjoint subsets (the folds); then, each fold isused to test the system, while the remaining K−1 folds are used fortraining. This procedure yields a total of K training/test partitions. Thestratified characteristic indicates that the folds contain approximatelythe same portion of programmes from each class. Apart from theK-fold cross-validation, J , different partitioning realisations of the Kfolds are considered, with the aim of minimising the influence of thechosen folds (see Section 2.5).

The average number of programmes in each set is determinedby a so-called ‘partitioning parameter’ f = 1 − 1

K; the number of

programmes in the training set will be proportional (up to roundingeffects) to f . Moreover, since the number of test blocks from each classwill depend on the partitioning realisation, we will use KDV

(j), KSV(j),

KTV(j), KFV

(j) and KLV(j) to denote the value of the corresponding

variables for the j-th (j = 1,… , J) K-fold partitioning realisation.As we have mentioned in Section 2.4.1, the considered programmes

are streamed using either TSS or OFS. Consequently, both TSS

Page 61: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 39

and OFS databases contain the same DVB-S and DVB-T streamedprogrammes (NT + NS = 183); the TSS database contains also DVDprogrammes (ND = 16). Two different partitioning methods areproposed for the streaming strategy classification:

Coupled programme-wise partitioning: The statistics of all the blocksof a given programme belong to the same fold. Therefore, the averagenumber of training programmes is NR = f ⋅ (ND + 2 ⋅ (NS + NT )),where 2 ⋅ (NS + NT ) is the total number of DVB programmesin the dataset, while the remaining programmes (i.e., NV =ND + 2 ⋅ (NS + NT ) − NR) are used for testing. The selection ofthose NR and NV programmes is carried out pseudorandomly andindependently for each K-fold partitioning realisation.

Disjoint programme-wise partitioning: Similar to the previous one,with the additional constraint of only considering one version (TSSor OFS) of each DVB programme. The version of each programme ischosen pseudorandomly for each partitioning realisation. In this caseNR = f ⋅ (ND + NS + NT ) and NV = ND + NS + NT − NR. Obviously,the number of available DVB programmes is reduced by half.

Be aware that coupled programme-wise partitioning might overfitthe SVM, as both versions of the same programme (TSS and OFS)could belong to the training set. Indeed, the disjoint programme-wisepartitioning proposal is aimed at preventing overfitting; the price tobe paid is the reduction by half of the number of available DVB pro-grammes. Notice that the number of considered DVD programmesis the same for both methods. Results comparing both partitioningmethods are reported in Section 2.5.1.

Concerning source classification, we remark that it is performedafter the TSS vs. OFS classification (i.e., different databases arebuilt for each streaming strategy choice). Therefore, in this case, thedatabase size is not doubled, as each database is built for each specificchoice of streaming strategy. The following partitioning methods areconsidered:

Programme-wise partitioning: Similar to the streaming strategyclassification, the programmes are assigned to folds in a pseudoran-dom way. In this case, the average number of training programmesis NR = f ⋅ (ND + NS + NT ), while the remaining programmes (i.e.,NV = ND + NS + NT − NR) are used for testing.

Block-wise partitioning: In this case, the set of blocks correspond-ing to each programme is split into two subsets before applyingK-folds. To simulate real scenarios, the split is implemented by

Page 62: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

40 IPTV Delivery Networks

a programme-dependent threshold-based method. Specifically,for each partitioning realisation, an integer value in [0, Ln − 1] ispseudorandomly generated for the nth programme according to

max(0,min(Ln, round(x))),

where x is a realisation of the Gaussian distribution 𝒩 (Ln ⋅ p, Ln ⋅p ⋅ (1 − p)), with p = 0.5.4 K-folding is applied by considering apseudorandom partitioning of the resulting 2(ND + NS + NT ) subsets.Therefore, this method allows some blocks of a given programme tobe assigned to a fold and the remaining blocks of that programme toa different fold.

In other words, the programme-wise partitioning represents a veryrestrictive situation for which if a block from a programme belongs to afold, then the remaining blocks of that programme are also in the samefold (i.e., we preclude the case where a TV channel is used for trainingand a later capture of the same TV channel is used for testing); thisconstraint is weakened by block-wise partitioning.

Although initially programme-wise partitioning might seem tobe more realistic (or block-wise partitioning could be thought torepresent an ideal situation), in practical scenarios, the SVM could betrained by considering programmes from the geographical area wherethe system will work; therefore, blocks from the same programmeat different capture times, might be included in the training and testsets. In fact, this is the idea behind the sequential time partitioning(based on a threshold) that was introduced above for the block-wisepartitioning, that is, blocks from a given programme up to a giveninstant can be in the training set and the remaining ones in the testset (and vice versa); in this way, the instantaneous bitrate contentdependence among blocks in the two sets is substantially reducedwith respect to the scenario where a uniform random partition (i.e.,without the sequential constraint) is used, avoiding overtrainingdue to the bitrate variability of the particular content. Further-more, the choice of splitting random threshold of the block-wisepartitioning provides flexibility in the number of blocks from aprogramme that is assigned to each fold. The results reported inSection 2.5 consider both methods to compare a pessimistic approach

4 Note that the mean and variance of the considered Gaussian distribution are thoseof a binomial distribution with success probability p.

Page 63: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 41

(programme-wise partitioning) with a more realistic case (block-wisepartitioning).

Notice that the block-wise partitioning method does not makesense for the TSS vs. OFS classification, as the same programmesare present in both classes (TSS and OFS), and, consequently, theSVM might be overfitted, providing misleading and over-optimistic(compared with real frameworks) experimental results. Similarly, thedisjoint programme-wise partitioning does not make sense for thesource classification problem.

2.4.3 Classification Performance Measures

To quantify the goodness of the proposed classification scheme, threedifferent matrices are defined: The confusion matrix, the probabilitymatrix and the inter-K-fold accuracy covariance matrix. We will findit useful to define MAB(j) as the number of cases where the streaming isclassified as A, when it was actually streamed according to B, when thej-th K-fold partitioning is considered.

For the TSS vs. OFS classification problem (denoted by thesuperscript F), if we let F stand for TSS, and L for OFS, the confusionmatrix for the j-th (j = 1,… , J) K-fold partitioning realisation isdefined as

MF2 (j)

.=(MFF (j) MLF (j)

MFL(j) MLL(j)

),

from which the probability matrix PF2 (j) is computed as

PF2 (j)

.=

⎛⎜⎜⎜⎜⎝MFF (j)KFV

(j)MLF (j)KFV

(j)MFL(j)KLV

(j)MLL(j)KLV

(j)

⎞⎟⎟⎟⎟⎠=

(PF

a2(j) PL

e2,F(j)

PFe2,L(j) PL

a2(j)

).

Note that the main diagonal contains the accuracy per class (TSSand OFS), while the off-diagonal entries contain the misclassificationprobabilities. We will denote the corresponding average (over the Jconsidered K-fold partitioning realisations) confusion and probabilitymatrices by M

F2 and P

F2 , respectively; similarly, hereafter bars will be

used to denote the components of average matrices. Consequently,

Page 64: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

42 IPTV Delivery Networks

the inter-K-fold accuracy covariance matrix is defined as

CF2

.=

⎛⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎝

1J − 1

J∑j=1[

PFa2(j) − P

Fa2

]2

1J − 1

J∑j=1

[(PF

a2(j) − P

Fa2

)⋅(

PLa2(j) − P

La2

)]1

J − 1

J∑j=1

[(PL

a2(j) − P

La2

)⋅(

PFa2(j) − P

Fa2

)]1

J − 1

J∑j=1[

PLa2(j) − P

La2

]2

⎞⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎠

.

Similarly, for the source classification problem (denoted by thesuperscript S) into DVD, satellite and terrestrial, if we let D, S and Tstand for DVD, satellite and terrestrial, respectively, the confusionmatrix is defined as

MS3(j)

.=⎛⎜⎜⎜⎝

MDD(j) MSD(j) MTD(j)MDS(j)MDT (j)

MSS(j) MTS(j)MST (j) MTT (j)

⎞⎟⎟⎟⎠ ,

while the probability matrix is

PS3(j)

.=

⎛⎜⎜⎜⎜⎜⎜⎜⎝

MDD(j)KDV

(j)MSD(j)KDV

(j)MTD(j)KDV

(j)MDS(j)KSV

(j)MSS(j)KSV

(j)MTS(j)KSV

(j)MDT (j)KTV

(j)MST (j)KTV

(j)MTT (j)KTV

(j)

⎞⎟⎟⎟⎟⎟⎟⎟⎠=⎛⎜⎜⎜⎝

PDa (j) PS

e,D(j) PTe,D(j)

PDe,S(j) PS

a(j) PTe,S(j)

PDe,T (j) PS

e,T (j) PTa (j)

⎞⎟⎟⎟⎠ .

As above, the main diagonal contains the accuracy per sourceand the other entries of the matrix contain the misclassificationprobabilities. Furthermore, M

S3 and P

S3, respectively, denote the

average confusion and probability matrices over the J K-fold realisa-tions; therefore, the inter-K-fold accuracy covariance matrix for this

Page 65: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 43

classification scenario is

CS3.=

⎛⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎝

1J − 1

J∑j=1[

PDa (j) − P

Da

]2

1J − 1

J∑j=1[(

PDa (j) − P

Da

)⋅(

PSa(j) − P

Sa

)]1

J − 1

J∑j=1[(

PDa (j) − P

Da

)⋅(

PTa (j) − P

Ta

)]1

J − 1

J∑j=1[(

PSa(j) − P

Sa

)⋅(

PDa (j) − P

Da

)]1

J − 1

J∑j=1[

PSa(j) − P

Sa

]2

1J − 1

J∑j=1[(

PSa(j) − P

Sa

)⋅(

PTa (j) − P

Ta

)]1

J − 1

J∑j=1[(

PTa (j) − P

Ta

)⋅(

PDa (j) − P

Da

)]1

J − 1

J∑j=1[(

PTa (j) − P

Ta

)⋅(

PSa(j) − P

Sa

)]1

J − 1

J∑j=1[

PTa (j) − P

Ta

]2

⎞⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎠Instead, if we know that the streamed programme source is not a

DVD (e.g., because we already know that it is a live transmission), thesource classification problem may be reduced to a binary one, that is,satellite vs. terrestrial. In this case, the classification results are sum-marised by using matrices

MS2(j)

.=(

MSS(j) MTS(j)MST (j) MTT (j)

),

PS2(j)

.=

⎛⎜⎜⎜⎜⎝MSS(j)KSV

(j)MTS(j)KSV

(j)MST (j)KTV

(j)MTT (j)KTV

(j)

⎞⎟⎟⎟⎟⎠=

(PS

a2(j) PT

e2,S(j)

PSe2,T

(j) PTa2(j)

),

Page 66: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

44 IPTV Delivery Networks

and

CS2.=

⎛⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎝

1J − 1

J∑j=1[

PSa2(j) − P

Sa2

]2

1J − 1

J∑j=1

[(PS

a2(j) − P

Sa2

)⋅(

PTa2(j) − P

Ta2

)]1

J − 1

J∑j=1

[(PT

a2(j) − P

Ta2

)⋅(

PSa2(j) − P

Sa2

)]1

J − 1

J∑j=1[

PTa2(j) − P

Ta2

]2

⎞⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎠where, as it was done earlier, M

S2 and P

S2, respectively, denote the aver-

age confusion and probability matrices for this case.

2.5 Experimental Results

Once the experimental framework is described, experiments areconducted to obtain the performance of the proposed classificationscheme for the proposed scenarios. Thus, results obtained for TSS vs.OFS classification and the subsequent source classification problem(either binary or ternary) are reported. Furthermore, in Section 2.5.5,we analyse the relevance of the different statistics in each scenario,trying to get some insight into the importance of each statistic in theclassification results.

For all the results reported in this section, the block length was setto L = 300, J = 100 partitioning realisations of the K-fold are used perexperiment and K = 10; thus, the number of different training/testset-partitions is K ⋅ J = 1000.

Regarding the SVM setup, a radial basis function (RBF) kernel isused. The regularisation parameter C (soft-margin parameter) andthe RBF kernel parameter σ are found with a grid search for eachtraining/test partition. First, notice that to replicate what would occurin a real situation, once a partition is fixed, the optimal values of C andσ, which we will denote, respectively, by C* and σ*, must be computedsolely from the statistics in the training set. Once C* and σ* are foundas explained next, they are employed while training and testing theSVM; for the latter, the test set from the current K-fold partition isused. Concerning the search for C* and σ*, for a given partition, the

Page 67: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 45

cost at each (C*, σ*) pair is calculated by applying a further eightfoldpartition to the available samples (i.e., the training set); such eightfoldpartition is subsequently used for training and testing the SVM(Chang and Lin, 2011; Chapelle et al., 2002; Golub, Heath and Wahba,1979). The optimal (C*, σ*) is the one that yields the largest accuracywhen averaged over the eight different subpartitions that result fromthis eight-fold procedure.

The numerical classification results are obtained by applyingthe sign-based (SB) criterion (i.e., the decision threshold is set tozero) to the score values from the test set and averaging over thetraining/test partitions. The receiver operating characteristic (ROC)for binary classification systems is built by averaging the ROC curvescorresponding to each training/test partitioning realisation; the SBoperating point (SB-OP) is shown on each curve. To make a faircomparison between different scenarios, the area under the curve(AUC) is also reported. Note that for a perfect classifier, AUC = 1,whereas for totally random decisions, AUC = 0.5.

2.5.1 TSS vs. OFS Classification

The problem of streaming strategy classification (TSS or OFS)is relevant in numerous scenarios. For example, a video contentprovider may have the right to stream videos on-the-fly, but not in atime-shifted way (or vice versa); in fact, the recording and subsequentstorage of copyrighted content to be later streamed could raise newand involved legal issues. A specific example is given in Cherry (2013),where users of the company Aereo stream terrestrial video content,either on-the-fly or previously stored in a digital video recorder(DVR) (TiVo, n.d.), to any location. As mentioned in Courtland(2014), broadcasters are obviously concerned about this new service,so they could be interested in automatically detecting whether Aereo’susers are delivering programmes on-the-fly or after having storedthem, because both cases will have different legal implications.

Therefore, content right owners and/or broadcasters could be inter-ested in automatically detecting the streaming strategy followed by aservice provider. Moreover, the TSS vs. OFS classification can be con-sidered as a previous step to the source classification methods to bediscussed later, to improve their performance.

The results obtained by using the statistics and the SVM classifierdescribed in Sections 2.3 and 2.4.2, respectively, are:

Page 68: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

46 IPTV Delivery Networks

• Coupled programme-wise partitioning– Average number of programmes and blocks:

⚬ Training: 343.8 programmes; 1900.8 blocks.⚬ Test: 38.2 programmes; 211.2 blocks.

– Results averaged over 1000 training/test partitions:⚬ . M

F2 =

(122.1 5.2

4.0 79.9

)⚬ .

PF2 =

(95.8% 4.2%4.8% 95.2%

)⚬ . CF

2 =(

2.45 1.041.04 0.98

)⋅ 10−4

.

• Disjoint programme-wise partitioning– Average number of programmes and blocks:

⚬ Training: 179.1 programmes; 1144 blocks.⚬ Test: 19.9 programmes; 127 blocks.

– Results averaged over 1000 training/test partitions:⚬ . M

F2 =

(80.8 4.62.9 38.7

)⚬ . P

F2 =

(94.5% 5.5%7.0% 93.0%

)⚬ . CF

2 =(

1.54 0.390.39 2.44

)⋅ 10−4

.

The whole database described in Section 2.4.1 was used to obtainthese results. The programmes from DVD and the TSS versions ofDVB-S and DVB-T programmes were labelled as time-shifted, whilethe OFS versions of the DVB-S and DVB-T programmes were labelledas OFS. Concerning the database, it is relevant to mention that theexperimentally measured average capture time necessary for buildingan L-length block of rate changes is 62.8 s, while the maximum time is168 s.

Figure 2.4 shows the ROC and the SB-OP for this binary classifi-cation system for both partitioning methods; the axis probabilitiesare those defined in Section 2.4.3. The reported results show thatthe proposed classification scheme succeeds in distinguishing thenature of a streamed programme with large accuracy for bothpartitioning methods. Slightly better results are provided by thecoupled programme-wise partitioning, showing that it does notoverfit the SVM.

Page 69: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 47

0.1

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0.2 0.3 0.4 0.5 0.6 0.7

Coupled program–wise partitioning

SB–OP for Coupled program–wise

SB–OP for Disjoint program–wise

Disjoint program–wise partitioning

0.8 0.9 100

–P F

e2,L

– P F a

2

Figure 2.4 Averaged ROC curves for TSS vs. OFS classification for bothpartitioning methods. The square and diamond symbols locate the SB-Ops.Coupled programme-wise AUC = 0.98; disjoint programme-wise AUC = 0.97.

2.5.2 TSS Ternary (DVD vs. DVB-S vs. DVB-T) Classification

Besides resolving the problem of TSS vs. OFS classification, theproposed scheme is also able to deal with the source identificationof a streamed video. The interest of this classification problem liesin the fact that the legal implications of an unauthorised distributionof copyrighted content will generally depend on the streamed videosource. For example, if the source were a DVD, then the unauthorisedsummarised distribution would affect the content owners, whereasif the source were a satellite or terrestrial TV stream, the broadcastnetwork would also be involved.

As mentioned in Section 2.2, three sources are considered in theTSS scenario: DVD, DVB-S and DVB-T. Two different classificationmethods are devised. In the first, the different nature of the sources(i.e., DVD vs. DVB) is exploited; consequently, the classificationsystem is built up in two binary steps:

Page 70: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

48 IPTV Delivery Networks

1. DVD/DVB classification.2. In those cases where the input stream is classified as DVB, the sec-

ond stage will classify it as DVB-S or DVB-T.The classification results obtained by applying this two-step SVM

classifier are:• Programme-wise partitioning

– Classifier 1:– Average number of programmes and blocks:

⚬ Training: 179.1 programmes; 1145.7 blocks.⚬ Test: 19.9 programmes; 127.3 blocks.

– Classifier 2:– Average number of programmes and blocks:

⚬ Training: 110 programmes; 758.7 blocks.⚬ Test: 73 programmes; 82.5 blocks.

– Results averaged over 1000 training/test partitions:⚬ .

MS3 =

⎛⎜⎜⎝38.4 2.8 1.82.6 44.0 11.73.5 4.7 17.7

⎞⎟⎟⎠⚬ .

PS3 =

⎛⎜⎜⎝89.9% 6.2% 3.9%4.5% 75.4% 20.1%

13.5% 17.9% 68.6%

⎞⎟⎟⎠⚬ .

CS3 =

⎛⎜⎜⎝3.23 0.27 0.460.27 1.36 0.560.46 0.56 8.55

⎞⎟⎟⎠ ⋅ 10−4.

• Block-wise partitioning– Classifier 1:– Average number of blocks:

⚬ Training: 1145.7 blocks.⚬ Test: 127.3 blocks.

– Classifier 2:– Average number of blocks:

⚬ Training: 758.7 blocks.⚬ Test: 82.9 blocks.

– Results averaged over 1000 training/test partitions:⚬ .

MS3 =

⎛⎜⎜⎝38.7 2.9 1.42.4 46.2 9.83.3 3.6 19.0

⎞⎟⎟⎠

Page 71: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 49

⚬ .P

S3 =

⎛⎜⎜⎝90.2% 6.5% 3.3%4.1% 79.1% 16.8%

12.7% 13.7% 73.6%

⎞⎟⎟⎠⚬ .

CS3 =

⎛⎜⎜⎝2.30 0.37 0.030.37 1.27 0.110.03 0.11 5.13

⎞⎟⎟⎠ ⋅ 10−4.

Alternatively to this two-step SVM classifier, a three-class SVMbased on the one vs. all classification method (Rifkin and Klautau,2004) is proposed. This method builds one SVM per class; each ofthose SVMs is aimed at distinguishing between one class and theremaining ones. The ternary decision is taken by majority voting;in the case of draw, a random decision between the tied classes isperformed (Allwein et al., 2000). The obtained results are:

• Programme-wise partitioning– Average number of programmes and blocks:

⚬ Training: 179.1 programmes; 1145.7 blocks.⚬ Test: 19.9 programmes; 127.3 blocks.

– Results averaged over 1000 training/test partitions:⚬ .

MS3 =

⎛⎜⎜⎝36.3 3.9 2.82.8 42.8 12.83.1 3.5 19.3

⎞⎟⎟⎠⚬ .

PS3 =

⎛⎜⎜⎝84.5% 9.2% 6.3%4.7% 73.3% 22.0%

11.9% 13.5% 74.6%

⎞⎟⎟⎠⚬ .

CS3 =

⎛⎜⎜⎝2.85 −0.11 −0.14−0.11 1.30 −0.36−0.14 −0.36 7.23

⎞⎟⎟⎠ ⋅ 10−4.

• Block-wise partitioning– Average number of blocks:

⚬ Training: 1145.7 blocks.⚬ Test: 127.3 blocks.

– Results averaged over 1000 training/test partitions:⚬ .

MS3 =

⎛⎜⎜⎝38.1 3.0 1.92.4 45.0 11.12.6 2.5 20.8

⎞⎟⎟⎠

Page 72: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

50 IPTV Delivery Networks

⚬ .P

S3 =

⎛⎜⎜⎝88.7% 6.9% 4.3%4.1% 77.0% 18.9%9.8% 9.6% 80.6%

⎞⎟⎟⎠⚬ .

CS3 =

⎛⎜⎜⎝2.73 −0.42 −0.23−0.42 1.00 −0.16−0.23 −0.16 5.32

⎞⎟⎟⎠ ⋅ 10−4.

Both implementations of the three-class SVM classifier system(two-step and one vs. all) report similar results. In view of the maindiagonal of matrices P

S3, the two-step SVM method seems to be

slightly better than the one vs. all classifier; on the other hand, theone vs. all errors are more uniformly shared among classes. Theinter-K-fold accuracy covariance matrices CS

3 have low values thatare similar for both methods. Notice that, in this case, neither theROC curve nor the AUC are reported, because the classification isnot binary.

These results show that the distinguishability between DVD andDVB sources is higher than that for DVB sources (DVB-S vs. DVB-T);these results are somewhat expected because of the absence ofstatistical multiplexing artefacts in the DVD source (see Section2.2.2). As it was discussed in Section 2.4.2, block-wise partitioning isalso expected to perform better than programme-wise partitioning.

For the TSS database, the experimentally measured average capturetime necessary for building an L-length block of rate changes is 61.2 s,while the maximum time is 168 s.

2.5.3 TSS Binary (DVB-S vs. DVB-T) Classification

The multimedia content from DVDs are usually films and documen-taries, while other types of content (e.g., news programmes or TVshows) come very often in satellite or terrestrial broadcasts. In thissituation, broadcasters could be interested in knowing whether thesource is satellite or terrestrial, to learn about the geographical areawhere the unauthorised provider (in this case, the IPTV server) islocated.

For instance, many broadcasters use both DVB-S and DVB-T forbroadcasting their programmes, but covering different areas. It isusually the case that the broadcasters’ home country is covered byDVB-T, while foreign countries are covered by DVB-S. Since different

Page 73: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 51

countries may have different laws regarding video distribution, theautomatic detection of the video source can provide informationabout the possession of the proper rights to stream a certain content.

Therefore, if the programme source is known to be DVB, then abinary SVM classifier will be used for performing the DVB-S/DVB-Tclassification (ND = 0). Note that in this case, the second classifier ofthe two-step SVM classifier described in the previous section is used.

The obtained results are:

• Programme-wise partitioning– Average number of programmes and blocks:

⚬ Training: 164.7 programmes; 758.7 blocks.⚬ Test: 18.3 programmes; 84.3 blocks.

– Results averaged over 1000 training/test partitions:⚬ .

MS2 =

(45.0 13.45.7 20.2

)⚬ .

PS2 =

(77.1% 22.9%22.0% 78.0%

)⚬ .

CS2 =

(1.61 −0.55−0.55 8.18

)⋅ 10−4

.

• Block-wise partitioning– Average number of blocks:

⚬ Training: 758.7 blocks.⚬ Test: 84.3 blocks.

– Results averaged over 1000 training/test partitions:⚬ .

MS2 =

(47.0 11.34.6 21.3

)⚬ .

PS2 =

(80.5% 19.5%17.5% 82.5%

)⚬ .

CS2 =

(1.95 −0.34−0.35 7.28

)⋅ 10−4

.

The ROC curves are shown in Figure 2.5.In this case, as we only consider the DVB-S and the DVB-T pro-

grammes, the experimentally measured average capture time neces-sary for building an L-length block of rate changes is 60.6 s, while themaximum time is 104 s.

Page 74: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

52 IPTV Delivery Networks

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0

Block–wise partitioning

SB–OP for Block–wise

SB–OP for Program–wise

Program–wise partitioning

–P

se2,T

– Ps a

2

Figure 2.5 Averaged ROC curves for DVB-S/T TSS classification for bothpartitioning methods. The square and diamond symbols locate the SB-Ops.Block-wise AUC = 0.89; programme-wise AUC = 0.84.

Defining submatrix

P′S3 =

(P

Sa P

Te,S

PSe,T P

Ta

),

it is possible to compare the reported results with those introducedin the previous section for the ternary classification. Consideringthe two-step SVM classifier results, the differences between P

S2 and

P′S3 are expected to be small, as P

De,S and P

De,T (i.e., the probabilities

of wrongly classifying a programme source as DVD, when it is not)have small values. Non-null probabilities mean that some DVB-S orDVB-T programmes will be wrongly classified as DVD, so they arenot input to the second classifier. Nevertheless, this error propagationdisappears when a priori knowledge on the video source (i.e., rulingout DVD) is exploited, as only the second classifier is used. Similarly, ifthe one vs. all three-class SVM classifier is considered for comparisonpurposes, then matrices P

S2 and P

′S3 will be slightly different, as the

Page 75: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 53

presence of an additional class (DVD) increases the DVB-S andDVB-T misclassification probabilities.

Additionally, to provide a fairer comparison, matrix P′′S3 is defined

as the normalised version of P′S3 , that is,

P′′S3 =

(1∕(P

Sa + P

Te,S) 0

0 1∕(PSe,T + P

Ta )

)⋅ P

′S3 .

The results for the two-step SVM case are as follows:

• Programme-wise partitioning

P′′S3 =

(79.1% 21.0%20.7% 79.3%

)• Block-wise partitioning

P′′S3 =

(82.5% 17.5%15.7% 84.3%

)while the results for the one vs. all 3-class SVM methods are:

• Programme-wise partitioning

P′′S3 =

(76.9% 23.1%15.3% 84.7%

)• Block-wise partitioning

P′′S3 =

(80.3% 19.7%10.6% 89.3%

).

2.5.4 OFS Binary (DVB-S vs. DVB-T) Classification

Concerning OFS, in this scenario, the cases with practical interest arethose where the video source is a DVB stream, and, consequently, wefocus on determining whether it comes from a satellite or terrestrialbroadcast network (DVB-S or DVB-T, respectively). Notice that if avideo programme is streamed on-the-fly, then the source cannot bea DVD.

The OFS DVB-T vs. DVB-S source classification may be relevant inseveral scenarios. An example is the case described in Section 2.5.3,where the programmes are being delivered on-the-fly. Broadcasterscould get an insight into the geographical location of an IPTV serverwhile it delivers a live programme.

Page 76: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

54 IPTV Delivery Networks

The classification will be performed by using a binary SVM and onlyconsidering the OFS version of the DVB-S and DVB-T programmes(ND = 0); the obtained results are:

• Programme-wise partitioning– Average number of programmes and blocks:

⚬ Training: 164.7 programmes; 755.1 blocks.⚬ Test: 18.3 programmes; 83.9 blocks.

– Results averaged over 1000 training/test partitions:⚬ .

MS2 =

(48.6 9.75.4 20.2

)⚬ .

PS2 =

(83.3% 16.7%21.0% 79.0%

)⚬ .

CS2 =

(1.24 −0.26−0.26 10.0

)⋅ 10−4

.

• Block-wise partitioning– Average number of blocks:

⚬ Training: 755.1 blocks in average.⚬ Test: 83.9 blocks in average.

– Results averaged over 1000 training/test partitions:⚬ .

MS2 =

(50.0 8.34.5 21.1

)⚬ .

PS2 =

(85.8% 14.2%17.1% 82.9%

)⚬ .

CS2 =

(1.56 −0.67−0.67 4.90

)⋅ 10−4

.

The ROC curves obtained for the OFS classification scenario areshown in Figure 2.6.

These results are just slightly better than those obtained for TSSbinary DVB-S vs. DVB-T classification (see Section 2.5.3). Weconjecture that this difference is due to the influence of the bitrateuniformisation process, which affects the footprint left by the sourcein a different way when the video is TSS or OFS (see Section 2.2.2).

In this case the experimentally measured average capture timenecessary for building an L-length block of rate changes is 64.4 s,while the maximum time is 146.7 s.

Page 77: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 55

0.1

0.1

0.2

0.2

0.3

0.3

0.4

0.4

0.5

0.5

0.6

0.7

0.8

0.9

1

0.6 0.7

Block–wise partitioning

SB–OP for Block–wise

SB–OP for Program–wise

Program–wise partitioning

0.8 0.9 100

–P

se2,T

– Ps a

2

Figure 2.6 Averaged ROC curves for DVB-S/T OFS classification for bothpartitioning methods. The square and diamond symbols locate the SB-Ops.Block-wise AUC = 0.91; programme-wise AUC = 0.86.

2.5.5 Relevance of the Used Statistics

In Section 2.3, a list of nine empirical statistics, aimed at summarisingthe bit-rate variability of the L-length change rate blocks, was pre-sented. From the results given so far, it is possible to conclude thatthose statistics fairly summarise programme source time footprints. Apertinent question regarding the relevance of each of those statisticsin the classification is whether the computational cost of the proposedalgorithms could be reduced by discarding some features withoutsignificantly worsening performance. To answer the question, arelevance analysis algorithm is proposed for the binary classifiersdescribed earlier. Notice that this type of analysis is very useful whena machine-learning method is employed to solve a classificationproblem, as it provides information about features that are moreinformative for the considered classification problem.

Page 78: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

56 IPTV Delivery Networks

The target function used by the proposed algorithm is the averagemisclassification probability Pe, that is, the arithmetic mean of thetwo involved misclassification probabilities. The algorithm looks forthe least relevant statistics by discarding one at a time and analysingthe resulting classification performance; the least relevant statisticis the one that produces the minimum average misclassificationprobability when it is discarded. This procedure is applied iteratively.

Before providing a detailed description of the algorithm, for the sakeof notational simplicity we find it useful to introduce:

• m: Vector containing the indices of those statistics used forthe classification. The numbering introduced in Section 2.3 isconsidered.

• 𝛚: Version of m sorted by ascending relevance.• Pout

e : Poute (i) is the average misclassification probability obtained by

discarding statistics ω(j) = 1,… , i.

Note that the results presented so far were obtained for sm andm = (1, 2, 3, 4, 5, 6, 7, 8, 9). Moreover, the following functions aredefined:

• w = delete(v, x): Removes element x from vector v.• Pe = run_classifier(scenario, training_method, v): Runs the classifi-

cation system corresponding to scenario by using the statistics in vand the partitioning method defined by training_method. The out-put is the average misclassification probability. Parameter scenariocan take the following values:

• TSS vs. OFS,• TSS DVD vs. DVB,• TSS DVB-S vs. DVB-T,• OFS DVB-S vs. DVB-T,

while parameter training method can be any of the following:

1. Coupled programme-wise partitioning,2. Disjoint programme-wise partitioning,3. Programme-wise partitioning,4. Block-wise partitioning.

Note that if scenario = 1, then training_method = 1, 2; on the otherhand, if scenario = 2, 3, 4, then training_method= 3, 4.

After these definitions, the algorithm used for sorting the featuresaccording to their relevance can be described as

Page 79: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 57

Input: scenario, training_method, m, smOutput: 𝛚, Poutei ← 1mi ← mwhile i < sm dofor j = 1 to smi domi

j ← delete(mi,mi(j))

Pie(j) ← rum classifier(scenario,training method,mi

j)end for{Search for the least relevant statistic}k ← argmin

jPi

e(j){Store the results}ω(i) ← mi(k)Pout

e (i) ← Pie(i)

{Prepare the next iteration}mi+1 ← delete(mi

,mi(k))i ← i + 1{Most relevant statistic}if i = sm thenω(sm) ← mi

end ifend while

In this section, for the sake of computational cost reduction, asingle K-fold partition is used for computing the misclassificationprobabilities Pi

e(j); we have observed that this simplification doesnot significantly affect the results, as the values of the obtainedcovariance matrices are much smaller than the squared elements ofthe probability matrices.

The results obtained using this algorithm in the TSS vs. OFSclassification problem are summarised next:

• Coupled programme-wise partitioning:– 𝛚 = (9, 6, 8, 7, 4, 5, 2, 1, 3),– Pout

e = (3%, 3%, 3%, 3%, 3%, 5%, 6%, 39%).• Disjoint programme-wise partitioning:

– 𝛚 = (8, 9, 5, 7, 4, 6, 2, 3, 1),– Pout

e = (8%, 7%, 7%, 6%, 6%, 7%, 7%, 49%).

These results show that the most relevant statistics for streamingstrategy classification are tl

n and pln. Indeed, a high accuracy for the

Page 80: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

58 IPTV Delivery Networks

TSS vs. OFS classification problem can be achieved even when onlythose two statistics are used.

Concerning the source classification problem, the results obtainedby using the relevance analysis described above are:

• Programme-wise partitioning– TSS DVD vs. DVB:

⚬ 𝛚 = (5, 8, 9, 4, 2, 3, 6, 7, 1),⚬ Pout

e = (8%, 8%, 8%, 8%, 8%, 8%, 11%, 11%).– TSS DVB-S vs. DVB-T:

⚬ 𝛚 = (3, 2, 9, 1, 8, 7, 5, 4, 6),⚬ Pout

e = (21%, 20%, 20%, 20%, 20%, 20%, 24%, 27%).– OFS DVB-S vs. DVB-T:

⚬ 𝛚 = (2, 4, 5, 6, 7, 9, 8, 1, 3),⚬ Pout

e = (17%, 17%, 18%, 16%, 19%, 18%, 18%, 36%).• Block-wise partitioning

– TSS DVD vs. DVB:⚬ 𝛚 = (3, 2, 4, 7, 8, 6, 5, 9, 1),⚬ Pout

e = (6%, 6%, 7%, 8%, 10%, 10%, 10%, 13%).– TSS DVB-S vs. DVB-T:

⚬ 𝛚 = (3, 9, 2, 6, 4, 8, 5, 7, 1),⚬ Pout

e = (18%, 17%, 18%, 18%, 18%, 23%, 26%, 29%).– OFS DVB-S vs. DVB-T:

⚬ 𝛚 = (7, 5, 6, 2, 4, 9, 8, 3, 1),⚬ Pout

e = (13%, 13%, 13%, 11%, 14%, 14%, 17%, 30%).

These results illustrate that for classification purposes some statis-tics do not provide new information with respect to the remainingones, that is, there is redundancy. In fact, for each scenario at leastfour statistics can be discarded without significantly worsening theclassification performance. Although the most relevant statisticsdiffer in both scenarios (i.e., TSS and OFS), statistic 1 is almost in allcases among the most relevant. Moreover, it seems that statistic 2 canbe removed from all scenarios.

Based on the reported results, two subsets with the most relevantstatistics for TSS and OFS scenarios are built. Specifically, we define:

1. M = {1, 2, 3, 4, 5, 6, 7, 8, 9} full set of statistics.2. MT = {1, 5, 6, 7} most relevant statistics for TSS.3. ML = {1, 3} most relevant statistics for OFS.

Page 81: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 59

Table 2.1 Results obtained by using different subsets of statistics in the sourceclassification problem.

Set of statisticsScenarios M MT ML

Programme-wise partitioning

TSS DVD vs. DVB-S vs. DVB-T: PDa ;P

Sa;P

Ta P

Da ;P

Sa;P

Ta P

Da ;P

Sa;P

Ta

Two-step ternary SVM 90%; 75%; 69% 91%; 71%; 60% 87%; 68%; 46%One vs. all ternary SVM 85%; 73%; 75% 86%; 68%; 72% 87%; 45%; 59%

OFS DVB-S vs. DVB-T: PSa2;P

Ta2

PSa2;P

Ta2

PSa2;P

Ta2

Binary SVM 83%; 79% 72%; 65% 76%; 85%Block-wise partitioning

TSS DVD vs. DVB-S vs. DVB-T: PDa ;P

Sa;P

Ta P

Da ;P

Sa;P

Ta P

Da ;P

Sa;P

Ta

Two-step ternary SVM 90%; 79%; 74% 91%; 74%; 61% 88%; 68%; 46%One vs. all ternary SVM 89%; 77%; 81% 90%; 68%; 73% 89%; 46%; 58%

OFS DVB-S vs. DVB-T: PSa2;P

Ta2

PSa2;P

Ta2

PSa2;P

Ta2

Binary SVM 86%; 83% 77%; 77% 77%; 90%

The performance of the source classification scenarios describedabove is recomputed when those subsets of statistics are considered;specifically, Table 2.1 summarises the results achieved by using setsM, MT and ML in the scenarios presented in Sections 2.5.2, 2.5.3 and2.5.4. These results show that it is possible to achieve a good accuracy,even if a reduced set of statistics is exploited. In any case, note that ifthe set of features were chosen depending on the considered scenario(or if the full set of statistics was used), then some accuracy gainwould be achieved.

2.6 Conclusions

The streaming strategy classification and IPTV-stream sourceidentification are relevant problems for content owners who areconcerned about unauthorised streaming of their assets. In a previouswork (Masciopinto and Comesaña, 2012), we have presented anSVM-based source identification scheme that exploits the timefootprints (e.g., length of the constant bitrate bursts, their bitrateand the jump between consecutive constant bitrate bursts) left by

Page 82: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

60 IPTV Delivery Networks

the video source in the IP packet dispatch time distribution. In thischapter, such IPTV source identification algorithm has been extendedto work in several other frameworks. Compared with Masciopintoand Comesaña (2012), some of the novel contributions of this chapterare the following:

• A new source, corresponding to programmes streamed from aDVD, is considered, and a ternary classification system is proposedto address the resulting problem.

• The problem of detecting whether a streamed content wastime-shifted or transmitted on-the-fly is considered for the firsttime in the literature.

• The relevance of the considered statistics on the classification resultis also considered for the first time.

The reported results show that the proposed statistics containenough information for performing the streaming strategy classi-fication and source identification; the corresponding classificationaccuracies are around 94% and 85%, respectively.

Acknowledgement

This work was partially funded by the Spanish Ministry of Economyand Competitiveness and the European Regional Develop-ment Fund (ERDF) under projects TACTICA and COMPASS(TEC2013-47020-C2-1-R), by the Galician Regional Govern-ment and ERDF under projects ‘Consolidation of Research Units’(GRC2013/009), REdTEIC (R2014/037) and AtlantTIC and by the EUunder project NIFTy (HOME/2012/ISEC/AG/INT/4000003892).

References

Abe, S. (2010). Support Vector Machines for Pattern Classification, 2ndedn. London: Springer.

Aereo (2012). Aereo, Inc. Available from: https://www.aereo.com.Allwein, E., Schapire, R., Singer, Y. and Kaelbling, P. (2000). Reducing

multiclass to binary: A unifying approach for margin classifiers.Journal of Machine Learning Research, 1(2), 113–141.

Arantia (2010). Arantia IPTV HE-21 Headend. Available from: http://www.arantia.com/en/product/iptv/compact-headend.

Page 83: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 61

ATSC (1982). The Advanced Television Systems Committee website.Available from: http://www.atsc.org.

Burges, C.J. (1998). A tutorial on support vector machines for patternrecognition. Data Mining and Knowledge Discovery, 2(2), 121–167.

CAIDA (2013). Analyzing UDP Usage in Internet Traffic. Available from:http://www.caida.org/research/traffic-analysis/tcpudpratio/.

Chang, C.-C. and Lin, C.-J. (2011). LIBSVM: A library for support vectormachines. ACM Transactions on Intelligent Systems and Technology,2(3), 27:1–27:27.

Chapelle, O., Vapnik, V., Bousquet, O. and Mukherjee, S. (2002).Choosing multiple parameters for support vector machines. MachineLearning 46(1–3), 131–159.

Cherry, S. (2013). Paying for Free TV. IEEE Spectrum. Available from:http://spectrum.ieee.org/podcast/geek-life/tools-toys/paying-for-free-tv.

Cisco Systems (2011). Cisco IPTV Head-End Solution. Available from:http://www.cisco.com/c/dam/en/us/products/collateral/video/multiplexers/7004373.pdf.

Courtland, R. (2014). Profile: Aereo’s Chet Kanojia is Bringing Live TV tothe Cloud. IEEE Spectrum. Available from: http://spectrum.ieee.org/geek-life/profiles/profile-aereos-chet-kanojia-is-bringing-live-tv-to-the-cloud.

Deering, S. (1989). Host Extensions for IP Multicasting. RFC 1112,Stanford University.

DIBEG (1997). The Digital Broadcasting Experts Group website. Availablefrom: http://www.dibeg.org.

DVB (1993). The Digital Video Broadcasting Project website. Availablefrom: http://www.dvb.org.

Espeland, H., Lunde, C., Henrik, S., Håkon, K., Griwodz, C. andHalvorsen, P. (2007). Transparent Protocol Translation for Streaming.In Proceedings of the 15th International Conference on Multimedia.ACM, New York, USA, pp. 771–774.

ETSI Standard (1997). Digital Video Broadcasting (DVB); FramingStructure, Channel Coding and Modulation for 11/12 GHz SatelliteServices. EN 300 421 v1.1.2.

ETSI Standard (2009a). Digital Video Broadcasting (DVB); FramingStructure, Channel Coding and Modulation for Digital TerrestrialTelevision. EN 300 744 v1.6.1.

ETSI Standard (2009b). Digital Video Broadcasting (DVB); Transport ofMPEG-2 TS based DVB Services over IP Based Networks. TS 102 034v1.4.1.

Page 84: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

62 IPTV Delivery Networks

Golub, G., Heath, M. and Wahba, G. (1979). Generalized cross-validationas a method for choosing a good ridge parameter. Technometrics,21(2), 215–223.

Hoffman, D., Fernando, G., Goyal, V. and Civanlar, M. (1998). RTPPayload Format for MPEG1/MPEG2 Video. RFC 2250.

Information Sciences Institute (1981). Internet Protocol. RFC 791,University of Southern California.

ISO/IEC Standard (2000a). Information Technology – Generic Coding ofMoving Pictures and Associated Audio Information: Systems. 13818-1.

ISO/IEC Standard (2000b). Information Technology – Generic Coding ofMoving Pictures and Associated Audio Information: Video. 13818-2.

Johnson, T. (2013). NFL, Major League Baseball Warn that Aereo CouldTrigger End of Free TV Game Broadcasts. Variety Magazine. Availablefrom: http://variety.com/2013/tv/news/nfl-major-league-baseball-warn-supreme-court-that-aereo-could-trigger-end-to-games-on-free-tv-1200847089/.

Kienzle, C. (2013). Taking Steps to Fight Piracy in Online Video.Streaming Media Magazine. Available from: http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=90584&PageNum=1.

Kohavi, R. (1995). A study of cross-validation and bootstrap for accuracyestimation and model selection. In International Joint Conference onArtificial Intelligence, Vol. 14, pp. 1137–1145.

Little, T. and Venkatesh, D. (1994). Prospects for interactivevideo-on-demand. IEEE Multimedia, 1(3), 14–24.

MacAulay, A., Felts, B. and Fisher, Y. (2005). WHITEPAPER – IPStreaming of MPEG-4: native RTP vs. MPEG-2 Transport Stream.Available from: https://developer.ridgerun.com/wiki/images/5/58/RTP_vs_TS.pdf.

Masciopinto, M. and Comesaña, P. (2012). IPTV streaming sourceclassification. In IEEE International Workshop on InformationForensics and Security. Tenerife (Spain), pp. 157–162.

MPEG (1988). The Moving Picture Experts Group website. Availablefrom: http://mpeg.chiariglione.org.

Netflix (2007). Netflix, Inc. website. Available from: https://www.netflix.com/global. https://www.netflix.com/global.

Press, W.H., Teukolsky, S.A., Vetterling, W.T. and Flannery, B.P. (2007).Numerical Recipes: The Art of Scientific Computing, 3rd edn.Cambridge University Press, Chapter 16.5.

Page 85: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Streaming Classification 63

Raudys, S. and Jain, A. (1991). Small sample size effects in statisticalpattern recognition: recommendations for practitioners. IEEETransactions on Pattern Analysis and Machine Intelligence, 13(3),252–264.

Rifkin, R. and Klautau, A. (2004). In defense of one-vs-all classification.Journal of Machine Learning Research, 5, 101–141.

Schulzrinne, H., Casner, S., Frederick, R. and Jacobson, V. (1996). RTP: ATransport Protocol for Real-Time Applications. RFC 1889, InternetEngineering Task Force.

SoChuang (n.d.). SoChuang Electronics: IPTV Headend Series. Availablefrom: http://www.sochuang.com/News_List.asp?tag=Product&Pid=15.

Sripanidkulchai, K., Maggs, B. and Zhang, H. (2004). An Analysis of LiveStreaming Workloads on the Internet. In Proceedings of the 4th ACMSIGCOMM Conference on Internet Measurement, New York, USA, pp.41–54.

TiVo (n.d.). TiVo Support Center. Available from: https://support.tivo.com.

Unitron (n.d.). Unitron Group: Digital Modular Headend. Available from:http://www.unitrongroup.com/en/products/CAT/DMH/DIP.html.

Van der Merwe, J., Sen, S. and Kalmanek, C. (2002). Streaming VideoTraffic: Characterization and Network Impact. In Proceedings of the7th International Workshop on Web Content Caching and Distribution(WCW), Springer, pp. 63–75.

VideoLAN (2001). The VideoLAN website. Available from: http://www.videolan.org.

WOWZA (2007). Wowza Streaming Engine: RTSP Streaming. Availablefrom: http://www.wowza.com/html/mobile.html.

Wu, D., Hou, Y. T., Zhu, W., Zhang, Y.-Q. and Peha, J. M. (2001).Streaming video over the Internet: approaches and directions. IEEETransactions on Circuits and Systems for Video Technology, 11(3),282–300.

Zhao, J., Lee, B., Lee, T.-W., Kim, C.-G., Shin, J.-K. and Cho, J. (2013).Flexible Dual TCP/UDP Streaming for H.264 HD Video over WLANs.In Proceedings of the 7th International Conference on UbiquitousInformation Management and Communication, ACM, New York,USA, pp. 34:1–34:9.

Page 86: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

65

3

Efficient IPTV Delivery over EPONAliAkbar Nikoukar, I-Shyan Hwang and Andrew Tanny Liem

3.1 Introduction

IPTV is an association of modern technologies in storage, comput-ing and networking to offer high-quality services to users. Severalfactors are responsible for the delivery of the IPTV content from theoriginal source to the end-user. The chain content delivery referencedby International Telecommunication Union (ITU-T; Grgic et al.,2009) contains content provider, service provider, network providerand end-user. The end-user connects to the network provider andthen selects the IPTV service provider (Mikoczy and Podhradsky,2009), and consequently, the end-user will be able to access theservice provider’s contents or contents from other service providers.The ITU-T and European Telecommunications Standards Institute(ETSI)/Telecoms and Internet Converged Services and Protocolsfor Advanced Networks (TISPAN) are the main IPTV deliveryarchitecture that have been approved. The ITU-T mission is todevelop the universal client-server architecture standard for IPTVwith the addition of a service delivery platform according to thedigital right management (DRM), quality of service (QoS)/qualityof experience (QoE) metrics, interoperability and metadata. Themission of ETSI/TISAN is specification development for the nextgeneration wireless and fixed networking infrastructure, definingIPTV as the next generation network (NGN) service and utilisingthe IP multimedia subsystem (IMS) with respect to the QoS, contentsecurity, infrastructure equipment and interoperability testing. The

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 87: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

66 IPTV Delivery Networks

typical IPTV architecture is based on the client-server topology,peer-to-peer (P2P) architecture and mobile IPTV architecture.

The very large IPTV systems are constructed based on theclient-server topology and ITU-T standards to deliver IPTV servicesacross a large expanse of territory. This architecture is a hierarchy offacilities that contains one super head end (SHE) and numerous videohub offices (VHOs), video serving offices (VSOs), local end officesor central offices (COs) (Simpson and Greenfield, 2009) (Doverspikeet al., 2009). SHE is responsible for collecting content from contentsuppliers, digitising and packetising the contents to deliver over theIPTV system and transmitting the content to the VHOs. Each VHOis responsible for distributing content in the metropolitan area. TheVSO serves a geographic region such as a city; it receives the contentfrom the VHO as well as the local source. To deliver the IPTV contentto the end-user, the IPTV network mainly uses existing telephonecompany infrastructure. The digital subscriber line access multiplexer(DSLAM) is in the CO and acts as an Ethernet switch and connectsthe VSO to the subscriber’s premises. Figure 3.1 shows the typicalarchitecture of IPTV systems.

The P2P overlay networks are virtually constructed over physicalnetworks. The P2P IPTV system is not a new idea; many file-sharingsystems have been developed based on the P2P concept. Commonly, afile is divided into pieces, and these pieces are instantaneously down-loaded by the user individually from users who have one or more piecesin the P2P file-sharing system (Tingting and Yunhua, 2011).

Super head end (SHE)

Content

processing

Content

preparation

and storage

VHOVideo hub office

(VHO)

Video-on-demand

server

Localcontent

processing

Internet

protocol

router

Local off-air

antenna Digital subscriberline access multiplexer

Data

Video serving office (VSO)

Local end office or

central office (CO)

CO

CO

User

Residential gateway (RG)

Set-top box

Metro area Access networkLong-distance backboneUser

Figure 3.1 Typical IPTV architecture.

Page 88: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 67

The growth of users’ mobile devices (i.e., mobile phone, tabletsand so on) has increased the mobility of users who need to accessinformation from any location. Broadband wireless technologies(such as WiMAX and 4G) allow users to transfer multimedia trafficover IP-based networks with supporting QoS and QoE, mobility,security and interactivity (Boussen et al., 2014; Park and Jeong, 2009;Joo et al., 2012). Typically, in the mobile IPTV architecture, a wirelessinterface is placed between the access network and the receiver thatenables communication. Currently, different wireless technologiesexist and each one has its own characteristics that should be carefullyconsidered in deploying mobile IPTV. The user is allowed to createIPTV content for other mobile IPTV users. Before the mobile IPTVservices are extensively deployed, it must prevail despite severalchallenges such as wireless link bandwidth limitation, heterogeneity ofend-user terminal and devices, service coverage, QoS/QoE issues andMiddleware and scalable video coding.

3.2 Broadband Access Network Technologies

The exponential growth of bandwidth-intensive applications suchas IPTV continues to fuel the penetration of fibre network into theaccess network segment (Shaddad et al., 2014). Access networks havebeen traditionally referred to as the last/first mile networks as theycomprise the final segment of connection from the COs of serviceproviders to those of the subscribers (Cheng et al., 2014). They areplaced closer to the subscribers and installed in immense capacities.Further, as they are in the last mile of Internet access, they shouldbe enhanced to support bandwidth-intensive applications and theincreasing traffic growth as well. Therefore, recently, many broadbandaccess networks have been existing in different technologies tofind faster, easier and cost-efficient ways of increasing the networkbandwidth under their existing legacy (Ansari and Zhang, 2013).The broadband access networks can be implemented under differentcommunication technologies such as twisted-pairs, coaxial cables,optical fibre or wireless link with the covered range being fromhundreds of metres to 20 kilometres.

The technology that carries the bandwidth over the existingtwisted-pairs of copper telephone line is the asymmetric digitalsubscriber line (ADSL), which is a distance-sensitive technology. The

Page 89: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

68 IPTV Delivery Networks

optical and wireless access networks have emerged to address a fairsharing of the channel with users and provide sufficient bandwidthaccording to the service requirements. The wireless access networktechnologies include worldwide interoperability for microwave access(WiMAX) (Yeh et al., 2008), next generation (NG) wireless fidelity(WiFi) and long-term evolution (LTE or 4G LTE), providing hundredsof megabits bandwidth to end-users. The fifth generation (5G) ofwireless technology initially will deploy in 2020 and is expectedto provide approximately 1000 times higher wireless area capacity(Peng et al., 2015). The optical access networks can deploy as apoint-to-point (P2P) or point-to-multi-point (P2MP) and providehigh bandwidth, cover a large distance but with less ubiquity whilewireless access networks provide a flexible and ubiquitous network.However, the deployment scalability of wireless networks is limitedby spectrum and range. Table 3.1 shows the comparison of the accessnetworks technologies.

Optical access networks are sited in the last/first mile near the sub-scribers’ premises, gathering data from the subscribers and feedingthe metro and core networks. Optical network units (ONUs) are typi-cally connected to the workstation at subscribers’ premises and furtherconnected to the optical line terminal (OLT) at the CO. Figure 3.2 illus-trates the generic structure of a modern telecommunication networkof an optical access network.

Table 3.1 Comparison of the access networks technologies.

TechnologyMax Downstream(Mpbs)

Max Upstream(Mpbs)

Max distance(km)

ADSL 8 1 5.5ADSL2+ 25 1 1.5VDSL2(long reach)

30 30 1.2-1.5

WiMAX 1000 (for fixed user)100 (mobiledevices)

1000 (for fixed user)100 (mobiledevices)

1.5-6

NG WiFi 1300 1300 0.14G LTE 299.6 75.4 12-16TDM PON 40 000 40 000 20

Page 90: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 69

GbE

routerMTU

OLT ONU

ONU

100/10 BT

Ethernet

PON

ATM

channel

bank

DSLAM

Ethernet

SONET

FCWDM

Mesh

Metro/

regional

network

Backbone

(core)

network

Figure 3.2 Modern telecommunication network of an optical access network.

Typically, regardless of implementation, there are three main vari-eties of optical access networking technologies, such as point-to-point(P2P) fibre, active Ethernet network and passive optical network(PON) (Lam, 2007). The implementations of these three typesof technologies are different, ranging from installation throughimplementation, such as devices that are to be used between theCO and ONUs. Figure 3.3 shows the above-mentioned varieties ofoptical access networks. As shown in Figure 3.3(a), the P2P fibrehas a direct connection between the OLT and the optical networkterminal (ONT), which is sited at the premise of the subscriber orcustomer. The second type of optical access technology is activeEthernet network, where active components such as routers, switchesand so on are used between the OLT and subscribers’ premises.Such implementation can provide network operators with completecontrol over their infrastructure, which enables them to provide abetter QoS to the subscribers. Figure 3.3(b) shows the active EPON.A PON is shown in Figure 3.3(c), which is well-known and themost commonly used network in the optical access network. It isknown as one of the best networks in providing bandwidth-intensiveapplications to subscribers with simple, efficient and cost-effectivesolutions (Hwang and Liem, 2013) (Hwang et al., 2013). Instead ofusing active components such as those used by the active Ethernet,

Page 91: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

70 IPTV Delivery Networks

(a)

(b)

(c)

Point-to-point fibre

Active Ethernet network

Passive optical network

Figure 3.3 Varieties ofoptical access network.

PON uses a passive optical combiner/coupler (POC) between theOLT and the ONUs.

PON consists of three major components such as OLT, ONU andoptical distribution network (ODN). According to Ansari and Zhang(2013), PON can be categorised into three or four types, dependingon the multiplexing scheme: (1) the orthogonal frequency-divisionmultiplexing (OFDM), which employs the number of orthogonalsubcarriers for sending the data from/to ONUs, (2) the opticalcode-division multiple (OCDM), which is used as the optical orthog-onal code (OOC) to identify the signal comes from/to ONUs, (3)the wavelength-division multiplexing (WDM), which uses multiplewavelengths to provision bandwidth to each ONU and (4) the cur-rently deployed PON technology that uses time-division multiplexing(TDM) scheme. The TDM-PON is the only multiplexing scheme thathas been standardised up to today by IEEE and ITU.

Figure 3.4 shows the PON architecture and its operation, wherethe OLT is located in the CO and is connected via the passive splitter

Page 92: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 71

PS

C

… .

....

Feeder fibreOLT

ONU

PS

C

… .

....

Feeder fibreOLT

ONU

...

...

...

Figure 3.4 PON architecture and its operation.

combiner/coupler (PSC) to the multiple ONUs or optical networkterminals (ONTs). The PSC is located in the remote node (RN),allowing a single point of feeder fibre to be distributed to numeroussubscribers. In the downstream direction, when the signal is arrivingat the PSC, it splits the signal by power division to each drop distri-bution fibre (DDF) of ONU. In contrast, in the upstream direction,the PSC combines the signal from all ONUs, sending it to the OLTvia the feeder fibre. Moreover, all ONUs must share the commontransmission channel towards the OLT based on TDM, and thus, onlya single ONU may transmit upstream data to avoid data collision inthe feeder fibre.

Because of its passive nature, this network is referred to as PONsince there is no active component between the OLT and ONUs. The

Page 93: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

72 IPTV Delivery Networks

PSC that is sited outside the plant can reduce the power consumptionand maintenance cost outside the plant. Consequently, the PONhas several advantages compared with other optical access networktechnologies (Lam, 2007). First, because it uses the passive componentoutside the plant, it yields a small fibre deployment cost in the localexchange and local loop. Second, PON provides higher bandwidthto subscribers due to its deep fibre penetration. Third, PON is easierto provision video broadcasting, since it has the nature of P2MP inthe downstream direction. Finally, PON eliminates the necessity ofinstalling multiplexers and demultiplexers in the splitting locations,and thus lowers the operational expenditure.

Currently, most of the deployed PON systems are time-divisionmultiplexing (TDM)-PON, which follow either full service accessnetwork (FSAN) or IEEE standard such as ATM-based PON (APONand BPON), gigabit-capable PON (GPON), which utilises the genericframing procedure (GPON), and Ethernet PON (EPON). At first,there were high expectations that the ATM-based PON can becomethe predominant technology in the local area network (LAN), metroarea network (MAN) and wide area network (WAN). However,Ethernet technology has surpassed the ATM, becoming a universallyaccepted standard with over 320 million deployed worldwide. It isalso proved that approximately 95% of enterprise LANs and homenetworks use Ethernet as their choice.

EPON is developed based on Ethernet technologies and thereforehas become one of the most promising optical access technologieschosen by the network operators to provision home and businessusers. According to Kramer et al. (2012), EPON has been rapidlydeployed in Japan, Korea, China and Taiwan since the IEEE ratifiedEPON standards IEEE 802.3ah in 2004 and IEEE 802.3av in 2009. It isprojected that EPON will be the most promising TDM-PON system(Tomkos et al., 2012). In fact, according to Kramer et al. (2012), EPONbandwidth resource is increasing fast enough to cope with the demandfor bandwidth-intensive applications from subscribers. The EPONplatform density is not only being focused on the fibre-to-the-home(FTTH) platform but also has been spanning may other platformsas well such as fibre-to-the-building (FTTB), fibre-to-the-node(FTTN) and fibre-to-the-business (FTTB). As previously stated inthis book/chapter/section, recently, a single state-of-the-art EPONOLT can support approximately 30,000 customers, depending on thenumber of subscribers per single ONU.

Page 94: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 73

EPON layering concept is similar to that of traditional point-to-point(P2P) Ethernet. EPON adopts a point-to-multi-point (P2MP) topol-ogy, which is implemented along with PSC and optical fibre physicalmedia dependent (PMD) sub-layers that support this topology. More-over, because EPON uses P2MP topology, the Multi-Point ControlProtocol (MPCP) is being introduced to control the P2MP topology,in which messages, state machines and timers are used. Generally, theMPCP has two modes of operation, which is bandwidth assignmentmode and autodiscovery mode. The first mode is used for sustainingthe communication between the ONUs and OLT, where the MPCPwill provide a periodic granting to each ONU. The latter mode is usedto discover newly joined ONUs, where the MPCP will initiate thediscovery procedure periodically. The ONU in the system communi-cates to the OLT via an instance of MPCP. The MPCP is mandatoryfor the EPON system, as the EPON system cannot operate withoutMPCP. Further, in the MPCP lies the point-to-point emulation (P2PE)sub-layer, which assigns a unique logical link identification (LLID) atthe beginning of each packet, replacing two octets of the preamble.Therefore, during the registration process, each ONU is given aunique LLID, mapping each message authentication code (MAC) portat the OLT to the LLID of each ONU. Hence, when the OLT wants tosend a frame to the ONUs, this emulation function inserts the LLIDaccording to the MAC port mapping. Afterwards, the frame will bebroadcast to all ONUs, yet only one ONU with the matching LLIDwill accept the frame and forward to the destination.

In EPON system, the downstream traffic is continuously beingbroadcast to the entire ONUs, in which an ONU filters the packetsaddressed to the other ONUs. On the contrary, in the upstream direc-tion, an ONU transmits the packets that are allocated by the OLTbased on the time-division multiplexing (TDM) allocation. Therefore,the dynamic bandwidth allocation (DBA) is introduced at the OLT toallocate bandwidth resources. The upstream data transmission can besummarised as follows:

First, the traffic for the subscribers is queued in the buffer at theONU. The ONU can support up to eight different queues based on theclass-of-service (CoS). Three buffer queues are commonly used at theONU to accommodate different traffic priority such as voice, videoand data. Second, the ONU reports the required bandwidth based onits buffer queues using REPORT message upon its designated timeslots. Third, upon receiving the REPORT messages from all ONUs, the

Page 95: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

74 IPTV Delivery Networks

OLT executes and calculates the upstream bandwidth, sending out theresults of bandwidth assignment to the ONUs using GATE messages.Finally, each ONU transmits the upstream data based on the givenallocation time slots. The IEEE 802.ah and 802.av did not specifythe standard for DBA for EPON, and, therefore, vendors have theautonomy to implement DBAs in the products offered. Generally, thebandwidth scheduling in EPON consists of two scheduling, which isreferred to as inter-scheduling and intra-scheduling. Inter-schedulingcan be defined as the resource allocation for all ONUs by the OLT;intra-scheduling, on the other hand is defined as resource alloca-tion for all queues at the ONU. Figure 3.5 illustrates the inter- andintra-scheduling, respectively.

The objectives of these two types of scheduling are founded on theQoS metrics such as packet delay, queue length, jitter performance,system throughputs, fairness and so on. However, it is challenging todesign one single DBA algorithm to satisfy the multidimensional sys-tem performance requirements, because improving one QoS metriccan affect or even lower the other QoS metrics. In addition, a dedicatedalgorithm can also affect the system complexity, although it supportshigher QoS metrics.

Currently, many studies, regardless of the intra-scheduling band-width allocation, are being carried out (Kim and Kang, 2007) (Choiet al., 2010) (Chan et al., 2011), and most studies are discussed on how

Inter-ONU

scheduling

Intra-ONU

scheduling

ONU ONU ONU

OLT

Figure 3.5 Inter- and intra-scheduling.

Page 96: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 75

to improve the QoS of higher priority traffic without sacrificing thosewith a lower priority. Assigning the queue according to priority at theONU such as strict priority scheduling can increase fairness; how-ever, it creates another issue, which is referred to as light-load penaltyproblem. Moreover, by giving more to the highest priority traffic, itcauses other issues such as starvation, unfairness and so on. Conse-quently, proper QoS metrics need to be considered when designing astate-of-the-art intra-scheduling bandwidth allocation algorithm.

EPON is now evolving; a few years ago, one single OLT can onlyserve in the range of less than a hundred subscribers. However, a sin-gle state-of-the-art EPON OLT does cover up to 30,000 subscribers.This is worsening by the increasing demand of bandwidth-intensiveapplications such as VoD, evolution of P2P streaming, IPTV and so on.The content providers of these types of applications can offer the videofrom standard digital television (SDTV) up to the high-definition tele-vision (HDTV) or even support super HD and 3D formats. The issuesinclude the network operators being required to evolve as well to offerthese killer applications to the subscribers to satisfactory quality.

Although EPON is now evolving to support higher bandwidths,there are still many challenges to support video services in EPON.One of the issues is how network operators can guarantee QoS tosubscribers, while achieving sufficient revenue and profit. Yet, morevideo content will be provided over unicast that has increased thebandwidth dramatically, and moreover, video bandwidth has beenincreasing due to evolution from HDTV formats towards super HDand ultra HD and 3D formats (Hei et al., 2007).

To tackle this challenge, currently, most of the network operatorsuse proxy servers (replica) to cache content, minimising the latency atthe subscribers and reducing the bandwidth and loading at the serverside. Other network operators can also use different approacheswith the same objective, which is trying to localise the traffic toreduce the bandwidth at the server side. However, few studies havebeen considering these issues, which somehow are important, notonly for the network operators to keep competitive services butalso for the subscribers to have a better video-streaming quality.Consequently, in Section 3.3, we examined and designed a new archi-tecture in EPON, which supports traffic localisation by localising thebroadcast/multicast IPTV delivery mechanism over enhanced EPON.

Page 97: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

76 IPTV Delivery Networks

3.3 Live IPTV Delivery over EPON

To deliver successful streaming over IP-based networks, transportprotocols (i.e., Real-time Transport Protocol (RTP), Moving PictureExperts Group (MPEG) transport protocol) and signalling proto-cols (i.e., Real Time Streaming Protocol (RTSP), Session InitiationProtocol (SIP), Internet Group Management Protocol (IGMP) andSession Announcement Protocol (SAP)) are required. The InternetEngineering Task Force (IETF) recommends RTP (Schulzrinne et al.,2003) (Yuste and Melvin, 2012) (Park and Hong, 2013) (Cruz et al.,2011) over UDP or TCP transports with setup and control usingsignalling protocols over TCP for web-based multicast live, unicastVoD streaming, connected TVs, game consoles, set-top boxes andnetwork personal video recorders. In this work, the RTP is the defaulttransport protocol for delivering live IPTV channels; however, anykind of signalling protocols can be used for delivering IPTV to users.

As mentioned in Section 3.2, OLT tags frames with LLID andsends the frames via unicast, multicast and broadcast mechanisms.Figure 3.6 shows the broadcast and multicast filtering where theframes are tagged with broadcast/multicast LLID. If the frame isbroadcast by broadcast LLID, the reconciliation sub-layer (RS) willaccept and forward it to the MAC layer; MAC layer discards frameswith unknown multicast MAC address (Figure 3.6 (a)). If the frameis tagged with multicast LLID, the RS is responsible for filtering theframes (Figure 3.6 (b)). The multicast protocol for both cases is out ofthe EPON standard’s scope.

Address recognition filter

Multicast MAC address

Multicast MAC address

MAC

RS

Address recognition filter

Multicast LLID

Multicast LLID

MAC

RS

Frame with broadcast LLID Frame with broadcast LLID

Multicast

protocol

(out of scope)

(a) MAC filtering (b) RS filtering

Figure 3.6 Broadcast and multicast filtering frame in EPON.

Page 98: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 77

A new multicasting and broadcasting mechanism for live IPTVis discussed throughout this section. The broadcast mechanismis broadcast by the most popular channels as the pre-request. Toexecute the multicasting/broadcasting mechanism, a simple multicastprotocol is designed. The proposed multicast protocol is responsiblefor the communication between OLT and ONUs. If the user usesanother multicast protocol, the OLT and ONU replace it by theproposed protocol inside EPON. The proposed broadcast mechanismuses broadcast LLID and adds the MAC multicast address for eachchannel to the frames. The multicast mechanism tags the framewith P2P emulation mode (mode 0) and assigns a unique LLID toeach IPTV channel. To manage broadcasting/multicasting, tables areconstructed in the OLT and ONUs. These tables are maintained inthe RS to deliver the IPTV traffic. A mechanism is proposed to handleIPTV requests as intra-traffic in the ONU without sending the requestto the OLT. Handling the live IPTV channel as intra-traffic can savebandwidth in the feeder fibre and increase the system throughput.

IGMP is the popular multicasting protocol in the IP-based network.To support forward multicast packets, IGMP runs between multicastrouter and host (user). IGMP is a network protocol in the OSI model(layer 3), by which the router can control the forwarding of the multi-casting frame (configure the port and time to live (TTL)) (Cheng andWang, 2008). The access network technologies such as EPON workup to a data link layer of OSI model (layer 2); therefore, if the con-figuration is not a layer 2 device, the multicast stream will flood. Theaccess networks mainly implement multicasting by IGMP snooping,IGMP proxy and Cisco Group Management Protocol (CGMP). IGMPsnooping extracts the network layer (layer 3) information, builds andmaintains the multicast table to snoop the packet between host androuter by recurring the data link layer (layer 2) group function, and itis implemented in the data link layer (layer 2). The IGMP proxy is sim-ilar to the IGMP snooping but in the IGMP proxy, the proxy stationcan process IGMP by replacing it with another station. To implementIGMP multicasting, the ONU needs a processor to perform IGMPsnooping and the 802.1D entity should be added in the ONU. The OLTshould broadcast/multicast traffic to run IGMP snooping and it alsoneeds software to snoop IGMP and configure 802.1D entity in ONUthrough OAMPDUs.

To carry live IPTV traffic in EPON, several broadcasting/multicastingalgorithms based on the MAC address, the LLID and IGMP snooping

Page 99: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

78 IPTV Delivery Networks

have been proposed (Cheng and Wang, 2008; Sue et al., 2009; Zareand Rahbar, 2012). In the IP broadcasting network over a PON systemproposed in Ikeda et al. (2008), the OLT transmits HDTV usingmulticast identifier (MID). Multicast traffic management is proposedin Kwon et al. (2009), where the OLT uses three queues for sortingmulticast traffic. The channels with high request have the most pri-ority to decrease the packet loss, and minimum priority is assigned tothe multicast traffic (of the channel) with the lowest request. However,previous studies also have not mentioned how to distinguish IPTVtraffic from the others in the real PON-based networks.

To remedy the aforementioned challenges, in this section, wepropose a new pre-request broadcasting and LLID multicastingmechanism, which emulate the broadcasting and multicasting mech-anisms by using the SME. The OLT in the proposed mechanismis liable for broadcasting/multicasting and can prevent sendingmultiple copies of the stream to the feeder fibre. Moreover, the ONUsare responsible for delivering the multicast stream to end-users bygenerating multiple copies of the stream. The proposed broadcastmechanism broadcasts the most popular channels to the ONUsbefore they send the request to the OLT, which is called pre-requestbroadcasting. The ONU joins the rest of the channels by sendinga request to the OLT. To build the system, the OLT and ONUarchitecture should be enhanced and the RS functionality has to bemodified.

3.3.1 Hardware Architecture

To implement the proposed broadcasting/multicasting mechanism,the OLT and ONU architecture need to be enhanced to be able tohandle a live IPTV channel. Figures 3.7 and 3.8 show the OLT andONU architecture, respectively.

Figure 3.7 shows the IPTV engine, multicast emulator, LLID broad-cast manager and CoS & ToS classifier, which are the new componentsin the proposed OLT architecture. The CoS & ToS classifier is usedto classify the incoming/outgoing OLT traffic and the IPTV traffic.The CoS & ToS classifier in the OLT redirects the data stream fromthe VHO to the packet-processing engine (sub-component of IPTVengine) for further processing. Moreover, the requests passed by theONU IPTV controller are forwarded to the IPTV engine by the CoS &ToS classifier for the application of the request with proper operations.

Page 100: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 79

Gigabit

ethernet

MAC

Central processing unitDBA

Security

Random access memory

LLID

bridgeFECMAC

LLID

broadcast

manager

Optics

control

EPON MAC

VLAN

CoS & ToS

classifierVLAN

CoS & ToS

classifier

Queue

QueueMulticast

emulator

IPTV Engine

Firmware

packet

processing

Rate

limiter

Figure 3.7 Proposed OLT architecture.

User

port

Optical distribution

network (ODN)

interface

Microprocessor unit Random access memory

IPTV

Routing table

Queue manager

Buffer manager

Traffic classifier

IPTV controller

Ingress

rule

CoS

classifier

Packet

forward

Figure 3.8 Proposed ONU architecture.

The IPTV engine consists of the firmware and the packet-processingengine sub-components. The packet-processing engine processes thepacket up to the application layer in the OSI model. The firmware con-tains the functions and algorithms to employ the requests and updatethe ONU/OLT tables. The multicast emulator is in cooperation withthe IPTV engine to emulate the multicasting mechanism for the IPTVchannels by assigning an LLID to each channel in the P2P mode. TheLLID broadcast manager is responsible for broadcast channels via theSCB port in cooperation with the IPTV engine.

Figure 3.8 shows the proposed ONU architecture with newtraffic classifier and the IPTV controller components. The traffic

Page 101: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

80 IPTV Delivery Networks

classifier has classified the incoming user traffic with modules anddifferent strategies. The IPTV controller accepts or rejects thebroadcast/multicast stream and delivers the accepted streams tothe end-user as either inter-traffic or intra-traffic (local traffic).Moreover, the IPTV controller includes functions to handle theIPTV request by managing broadcast and multicast tables for desiredbroadcast/multicast channels. The IPTV controller is governed by theOLT, and the IPTV engine updates the IPTV controller.

3.3.2 Multicast Protocol Design

A simple mechanism is designed to emulate multicasting by joiningor leaving the channel between OLT and ONUs. The multicastingprotocol between OLT and VSO can be conventional protocols suchas IGMP as well as the multicast protocol between user and ONU.The IPTV engine and IPTV controller replace the designed multicastmechanism (emulate multicast protocol) instead of using anothermulticasting protocol. Moreover, the IPTV engine sends the requestfor channels to the VSO (router) with its address. The tables areconstructed in the ONUs and OLT to manage the user’s request.Figures 3.9 and 3.10 depict the operations involved in joining andleaving the channel by users.

When the channel is not broadcast, the request will be forwardedby the OLT to the VOS; afterwards, the ONU will update its tableby creating a new multicast group for the requested channel andresponds to the join request by sending a message to the ONU.The ONU will also update its table for future requests. If anotheruser in the ONU requests the same channel, the ONU will respondto the request directly without forwarding to the OLT. Joining themulticast channel when it is not multicast by the OLT is shownin Figure 3.9(a). Figure 3.9(b) shows the procedure of joining thechannel when the channel is multicast by OLT. When the userrequests to leave the channel, the ONU replies and updates itstable; consequently, the ONU sends the update message to the OLT,which is shown in Figure 3.10(a). If another user is joined withthe stream, the OLT does not forward the leave message to theVSO. If there is no request for the channel, the OLT will discardthe channel by sending the leave message to the VSO as shown inFigure 3.10(b).

Page 102: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 81

USERIPTV controller

(ONU)

Live IPTV engine

(OLT)

VSO

(router)

Join

Request Join

Join

Join reply

Response join

Join reply

Create group

UPDATE table

UPDATE table

(a) Join to channel when does not exist in the OLT table

USERIPTV controller

(ONU)

Live IPTV engine

(OLT)

Join

Request Join

Response join

Join reply

UPDATE table

UPDATE table

(b) Join to channel when exist in OLT table

Figure 3.9 Joining the channel.

3.3.3 Pre-request Broadcasting Mechanism

The pre-request scheme uses the broadcasting approach for the mostpopular channels. The IPTV engine cooperates with VSO to retrievethe list of the most popular channels. The IPTV engine starts broad-casting the channel and using the broadcast LLID when it receives thefirst request for the channel. A MAC group is assigned to each mostpopular channel. By broadcasting the channel, each ONU accepts thestream and forwards the stream to the user if any request exists; oth-erwise, at the ONU, the stream will be dropped. To manage the broad-casting channel, a table is constructed in the IPTV engine that con-tains the channel’s name, the MAC group address and ONU’s LLIDfor the requested channel. This table helps the OLT decide whether tostart/stop broadcasting the channel. Also, a table is needed in the ONUto manage the requests that are being received from users connected

Page 103: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

82 IPTV Delivery Networks

USERIPTV controller

(ONU)

Live IPTV Engine

(OLT)

leave

update

leave reply UPDATE table

UPDATE table

(a) Leave channel when other request exist

leave

USERIPTV controller

(ONU)

Live IPTV Engine

(OLT)

VSO

(router)

Join

update

leave reply

Leave reply UPDATE table

UPDATE table

(b) Leave the channel when no longer request exist

Figure 3.10 Leaving the channel.

to the ONU. The ONU table contains the channel’s name, MAG groupaddress, the user’s MAC address and the user’s IP address fields. Thetables in the OLT and ONU are maintained in the RS.

When the user sends a new request to the ONU, the previous user’srecord is replaced by the new request to keep the ONU table updated.Deleting or replacing the record from the table indicates leavingthe channel and adding a new value indicates joining a channel. Inother words, each user can have a record of the ONU table. The joinalgorithm is shown in Figure 3.11. If the requested channel is alreadybroadcast by the OLT, and the name of the channel being broadcastexists in the ONU table, the ONU will start to broadcast the requestedchannel to the user and add the user MAC and the requested channelin the table by using the Add_ONU(user_MAC, ch_name) function. Ifthe request is not in the ONU table, it means that it is not broadcast

Page 104: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 83

Figure 3.11 Joiningthe broadcastchannel.

Request to join channel

IPTV receives packet from traffic classifier

Process the packet

Is channel in ONU’s

table?

Forward request to OLT

Forward request to VSO

Waiting response from VSO

Create MAC group address for channel

Update OLT table

Response join

Update ONU’s table

Join reply to user

Forward request join to OLT

Start broadcasting by SCB

Stop

Yes

No

Page 105: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

84 IPTV Delivery Networks

from the OLT. The request should be sent to the OLT. Consequently,the OLT passes it to the VSO. When the data starts being sent fromthe VSO, the OLT receives these packets, and by examining the sourceaddress of the packets, it sends via the SCB port. When the OLTstarts broadcasting a channel, the function Add_OLT() is executed toadd the channel’s name and assign the MAC’s channel address to theOLT table. After any change is made to the OLT table, it is necessarythat the OLT informs the ONUs to know about current channelsbeing broadcast. The OLT should decide to continue or stop channelbroadcasting. Figure 3.12 shows the algorithms to continue/stop

Request to leave the channel

Other requests for

channel exist in the

ONU?

Remove the user from ONU table

Remove the ONU LLID from OLT table

Other ONU LLID for the

channel exist in

the OLT table?

Stop broadcasting

Stop

NO

Yes

NO

Yes

Figure 3.12 Continue/stop the broadcastingmechanism.

Page 106: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 85

broadcasting. When a user leaves the channel, the correspondingONU removes the user’s MAC address from the ONU’s table with theRemove_ONU(User_MAC, Ch_name) function. Whenever changeshappen to the ONU’s table, the Filter_ONU_Table(Ch_name) func-tion executes to check whether any other record for the channel isin the table or not; if a record no longer exists in the ONU’s table,the ONU requests OLT to remove its LLID from the OLT’s table.Consequently, the Filter_OLT_Table(Ch_name) function executesto help OLT decide on continuing or stopping the channel frombroadcasting.

3.3.4 Performance evaluation

To evaluate the performance of the proposed scheme in terms ofmean system throughput and packet loss for the IPACT (Krameret al., 2002), the system model is set up in the OPNET simulator withone OLT and 32 ONUs. The data rate of upstream and downstreamdirections is 1 Gbps. The ONU buffer size is 10 Mb. The distance fromthe ONU to the OLT is uniform from 10 to 20 km. The self-similarityand long-range dependence (LRD) is chosen as the network trafficmodel for AF and BE (Erramilli et al., 1997). High-priority traffic (i.e.,EF traffic) is modelled using the Poisson distribution with a fixedpacket size (70 bytes). This model generates the high burst AF andBE traffic with a Hurst parameter of 0.8. The packet size is uniformlydistributed between 64 and 1518 bytes. The maximum transmissioncycle time is 1.5 ms. Two significant cases are designed and analysedwith various Expedited Forwarding (EF), Assured Forwarding (AF)and Best Effort (BE) service proportions to show the effectivenessof the high-priority traffic management. Table 3.2 shows the trafficproportions in different cases.

The proposed architecture can handle a portion of IPTV requestsas intra-traffic without forwarding to the OLT. To evaluate the effectsof local (intra) traffic, three scenarios are examined with 20%, 30% and40% of the total number of request handles as intra-traffic for different

Table 3.2 Traffic proportion.

154 (EF, AF, BE) 163 (EF, AF, BE)

Traffic proportion 10%, 50%, 40% 10%, 60%, 30%

Page 107: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

86 IPTV Delivery Networks

traffic cases. For each traffic proportion, four different scenariosare simulated: the original IPACT without local traffic, referredto as IPACT-163 and IPACT-154, 20% of the channel request asintra-traffic, referred to as IPACT-163-20% and IPACT-154-20%, 30%of the channel request as intra-traffic, referred to as IPACT-163-30%and IPACT-154-30% and 40% of the channel request as intra-traffic,referred to as IPACT-163-40% and IPACT-154-40%.

The upstream network system throughput is calculated by thecombined efficiency multiplied by the EPON line rate (i.e., 1 Gbps).The combined efficiency consists of the scheduling overhead and theencapsulation overhead. The upstream encapsulation and schedulingoverheads are 7.42% and 5.76% (i.e., 32 ONUs with 1.5-ms cycletime), respectively. Therefore, the maximum upstream networksystem throughput of EPON is 897.6 Mbps (Nikoukar et al., 2015).The system throughput in the proposed architecture is defined as thesum of the data rates that are delivered to all terminals in a network.Therefore, the system throughput in the proposed architecture isthe sum of the throughput for communication between the ONUsand OLT and local traffic throughput. The local traffic is the traffichandled by the ONUs without referring to the feeder fibre and OLT.In the proposed architecture, the ONU is responsible for generatingmultiple copies of the stream to the end-users and OLT just sendsa single copy of the stream to all the ONUs. Figure 3.13 shows thesystem throughput in different cases and scenarios versus the offered

10%0

500

1000

1500

2000

Syste

m T

hro

ug

hp

ut

(Mb

ps)

2500

20% 30% 40% 50% 60%

Offered Load

IPACT-163

IPACT-163-20%

IPACT-163-30%

IPACT-163-40%

IPACT-154

IPACT-154-20%

IPACT-154-30%

IPACT-154-40%

70% 80% 90% 100%

Figure 3.13 System throughput with different traffic loads and 10 Mbps videotransmission rate.

Page 108: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 87

load. When the number of requests handled increases as intra-trafficincreases, the system throughput is increased. The system throughputof all proposed scenarios at high loads is more than 1 Gbps. Thereason for this is that the ONUs handle part of the traffic locally.Note that the IPACT-136 and IPACT-154 without local traffic haveanalogous system throughputs. Furthermore, the system throughputis increased when the portion of AF traffic is increased.

Cycle time and buffer size are two main metrics triggering packetloss at the ONU. Increasing the buffer size obviously reduces packetloss, but the queuing delay will be increased. In contrast, a larger cycletime reduces packet loss because each ONU has more time-slots tosend its queues; however, a larger cycle time leads to a higher packetdelay. Figure 3.14 compares the average BE to the packet loss prob-ability ratio in different cases and scenarios versus the offered load.The packet loss probability for high-priority traffic such as EF and AFis zero in all cases and scenarios. The packet loss ratio for IPACT-163and IPACT-154 occur for traffic loads that are greater than 80% load,in which case, there is no mechanism to handle part of the requestsas intra-traffic. The packet loss of the proposed mechanism occursin all cases and scenarios when the traffic load is above 90% and thepacket loss ratio is decreased to compare to the original IPACT-163and IPACT-154, because the proposed mechanism handles part ofrequest locally; thus, DBA can assign more bandwidth to the BEtraffic. Moreover, the packet loss of scenarios with a traffic ratio of

0

0.5

1

1.5

2

2.5

3

3.5

Pa

cke

t lo

ss r

atio

(%

)

4

Offered load

IPACT-163

IPACT-163-20%

IPACT-163-30%

IPACT-163-40%

IPACT-154

IPACT-154-20%

IPACT-154-30%

IPACT-154-40%

70% 80% 90% 100%

Figure 3.14 Packet loss with different traffic loads.

Page 109: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

88 IPTV Delivery Networks

163 is less than the packet loss with a ratio of 154 when the numberof requests being handled as intra-traffic is the same.

3.4 Conclusions

Recently, the demands of multimedia applications have increased,and the IPTV market will improve because of its unique features.Moreover, modern high-bandwidth access networks such as opticalnetworks satisfy the IPTV bandwidth requirements. IPTV deliverymechanisms, broadband access network and proposed the broad-cast/multicast delivery mechanisms for live IPTV channels havebeen discussed briefly in this chapter. The IPTV engine and IPTVcontroller are designed in the OLT and ONU architecture to enhanceEPON. By enhancing the EPON architecture, OLT is responsiblefor the broadcasting/multicasting mechanism inside EPON insteadof VSO or outside the router. Two new mechanisms for delivery ofa live IPTV channel are discussed where a pre-request broadcastmechanism is designed to deliver the most popular channel to theuser by broadcasting the channel via SCB. The multicast mechanism isproposed, which assigns a unique LLID to each channel (CLLID). TheOLT adds the CLLID to the Ethernet frame and sends a copy of theframes in the downstream direction. The ONU is redesigned and isresponsible for multicasting the received frames from the OLT to theend-user. Thus, the proposed architecture handles a portion of IPTVtraffic as local traffic. Simulation results have shown that the proposedarchitecture improves system performance in response to requestsas intra-traffic by ONU broadcasting/multicasting mechanisms. Theproposed ONU and OLT architecture and broadcasting/multicastingmechanism can apply to all PON technologies such as TDM-PON,WDM-PON and OFDMA-PON.

References

Ansari, N. and Zhang, J. (2013). Media Access Control and ResourceAllocation. Springer.

Boussen, S., Arnaud, J., Krief, F., Tabbane, N. and Tabbane, S. (2014).IPTV QoS adaptation for multi-homed mobile terminals in a new IMSbased architecture. Telecommunication Systems, 55, 199–210.

Page 110: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 89

Chan, C.A., Attygalle, M. and Nirmalathas, A. (2011).Local-traffic-redirection-based dynamic bandwidth assignmentscheme for EPON with active forwarding remote repeater node.Journal of Optical Communications and Networking, 3, 245–253.

Cheng, C. and Wang, L. (2008). Discuss of multicast mechanism inEPON. Industrial Electronics and Applications, 2008. 3rd IEEEConference on, ICIEA 2008, 3–5 June 2008, 2548–2551.

Cheng, N., Gao, J.H., Xu, C.Z., Gao, B., Liu, D.K., Wang, L., Wu, X.M.,Zhou, X.P., Lin, H.F. and Effenberger, F. (2014). Flexible TWDM PONsystem with pluggable optical transceiver modules. Optics Express, 22,2079–2091.

Choi, J., Yoo, M. and Mukherjee, B. (2010). Efficient video-on-demandstreaming for broadband access networks. Journal of OpticalCommunications and Networking, 2, 38–50.

Cruz, R.A.S., Nunes, M.S., Menezes, L. and Domingues, J. (2011). IPTVarchitecture for an IMS environment with dynamic QoS adaptation.Multimedia Tools and Applications, 53, 557–589.

Doverspike, R., Li, G.Z., Oikonomou, K.N., Ramakrishnan, K.K., Sinha,R.K., Wang, D.M. and Chase, C. (2009). Designing a reliable IPTVnetwork. IEEE Internet Computing, 13, 15–22.

Erramilli, A., Pruthi, P. and Willinger, W. (1997). Fast andphysically-based generation of self-similar network traffic withapplications to ATM performance evaluation. Simulation Conference,Proceedings of the 1997 Winter, 7–10 Dec. 1997. pp. 997–1004.

Grgic, M., Delac, K., Ghanbari, M. and Springerlink (Online Service)(2009). Recent advances in multimedia signal processing andcommunications. Studies in Computational Intelligence. Springer,Berlin, Heidelberg.

Hei, X., Liang, C., Liang, J., Liu, Y. and Ross, K.W. (2007). AMeasurement study of a large-scale P2P IPTV system. IEEETransactions on Multimedia, 9, 16.

Hwang, I.S. and Liem, A.T. (2013). A hybrid scalable peer-to-peerIP-based multimedia services architecture in Ethernet passive opticalnetworks. Journal of Lightwave Technology, 31, 213–222.

Hwang, I.S., Nikoukar, A., Teng, C.H. and Lai, K.R. (2013). Scalablearchitecture for VoD service enhancement based on a cache scheme inan Ethernet passive optical network. Journal of OpticalCommunications and Networking, 5, 271–282.

Page 111: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

90 IPTV Delivery Networks

Ikeda, H., Sugawa, J., Ashi, Y. and Sakamoto, K. (2008). Architecture anddesign of IP broadcasting system using passive optical network. IEICETransactions on Communications, E91b, 2477–2484.

Joo, H., Yoon, C., Um, T.W. and Song, H. (2012). A novel fountaincode-based mobile IPTV multicast system architecture over WiMAXnetwork. Journal of Visual Communication and Image Representation,23, 161–172.

Kim, N.U. and Kang, M.H. (2007). Traffic share-based multicastscheduling for broadcast video delivery in shared-WDM-PONs.Journal of Lightwave Technology, 25, 2814–2827.

Kramer, G., Khermosh, L., Daido, F., Brown, A., Yoon, H., Suzuki, K.I.and Bo, W. (2012). The IEEE 1904.1 standard: SIEPON architectureand model. IEEE Communications Magazine, 50, 98–108.

Kramer, G., Mukherjee, B. and Pesavento, G. (2002). Interleaved pollingwith adaptive cycle time (IPACT): A dynamic bandwidth distributionscheme in an optical access network. Photonic NetworkCommunications, 4, 89–107.

Kwon, Y., Choi, J.K., Choi, S.G., Um, T.W. and Jong, S.G. (2009). Aweighted scheduling mechanism to reduce multicast packet loss inIPTV service over EPON. ETRI Journal, 31, 469–471.

Lam, C.F. (2007). Passive Optical Networks. Academic Press, Elsevier.Mikoczy, E. and Podhradsky, P. (2009). Evolution of IPTV architecture

and services towards NGN. In: Grgic, M., Delac, K. and Ghanbari, M.(eds.) Recent Advances in Multimedia Signal Processing andCommunications. Springer, Berlin, Heidelberg.

Nikoukar, A., Hwang, I.S., Liem, A. and Wang, C.J. (2015). QoS-awareenergy-efficient mechanism for sleeping mode ONUs in enhancedEPON. Photonic Network Communications, 1–12.

Park, S. and Hong, C.S. (2013). RTSP-based adaptive sending control forIPTV service in heterogeneous networks and experimentalimplementation. IEICE Transactions on Communications, E96b,905–909.

Park, S. and Jeong, S.H. (2009). Mobile IPTV approaches, challenges,standards, and QoS support. IEEE Internet Computing, 13, 23–31.

Peng, M.G., Li, Y., Zhao, Z.Y. and Wang, C.G. (2015). System architectureand key technologies for 5G heterogeneous cloud radio accessnetworks. IEEE Network, 29, 6–14.

Schulzrinne, H., Casner, S., Frederick, R. and Jacobson, V. (2003). RFC3530: RTP: A Transport Protocol for Real-Time Applications [Online].Available: http://tools.ietf.org/rfc/rfc3550.txt.

Page 112: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Efficient IPTV Delivery over EPON 91

Shaddad, R.Q., Mohammad, A.B., Al-Gailani, S.A., Al-Hetar, A.M. andElmagzoub, M.A. (2014). A survey on access technologies forbroadband optical and wireless networks. Journal of Network andComputer Applications, 41, 459–472.

Simpson, W. and Greenfield, H. (2009). IPTV and Internet videoexpanding the reach of television broadcasting. NAB ExecutiveTechnology Briefings, 2nd edn. Burlington, MA: Focal Press.

Sue, C.C., Hsu, C.Y., Su, Y.S. and Shieh, Y.Y. (2009). A new IPTV channelzapping scheme for EPON. Ubiquitous and Future Networks, 2009.First International Conference on, ICUFN 2009. 7–9 June 2009. pp.131–136.

Tingting, G. and Yunhua, Z. (2011). Research of incentive mechanisms inP2P-based video on demand system. Networking and DistributedComputing (ICNDC), 2011 Second International Conference on, 21–24Sept. 2011. pp. 340–343.

Tomkos, I., Kazovsky, L. and Kitayama, K.I. (2012). Next-generationoptical access networks: dynamic bandwidth allocation, resource useoptimization, and QoS improvements. IEEE Network, 26, 4–6.

Yeh, S.P., Talwar, S., Lee, S.C. and Kim, H. (2008). WiMAX femtocells: aperspective on network architecture, capacity, and coverage. IEEECommunications Magazine, 46, 58–65.

Yuste, L.B. and Melvin, H. (2012). A protocol review for IPTV andWebTV multimedia delivery systems. Komunikacie, 14, 9.

Zare, S. and Rahbar, A.G. (2012). An FEC scheme combined withweighted scheduling to reduce multicast packet loss in IPTV overPON. Journal of Network and Computer Applications, 35, 459–468.

Page 113: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

93

4

Content Awareness in IPTV Delivery NetworksSuliman Mohamed Fati and Putra Sumari

4.1 Introduction

With the massive development in networking and multimedia, IPTVhas recently become popular as a promising trend in home andbusiness entertainment due to the increasing number of IP-networkusers. Therefore, IPTV, as a promising technology, has been growingrapidly in terms of subscribers and revenue, and is likely to become,in the near future, the standard means of delivering home andbusiness entertainment content (Yarali and Cherry, 2005). Thus,telecommunication companies have entered a fierce competition toincrease their customer base and profit by providing IPTV services(Lee, Muntean and Smeaton, 2009; Li and Wu, 2010; Yarali andCherry, 2005). IPTV is globally considered a dominant technology indistributing high-quality videos and live channels anytime anywherein a challenging environment. This challenging environment tends todeliver a hybrid IPTV service over an IP-based network infrastructureto end-users with different preferences and demands (Aldana Diazand Guh, 2011; Montpetit, Klym and Blain, 2010; Montpetit, Klymand Mirlacher, 2011).

Currently, IPTV service providers consider the IPTV content pop-ularity distribution and/or user preferences to allocate IPTV content(Dukes and Jones, 2004; Sujatha et al., 2008; Lie, Lui and Golubchik,2000; Little and Venkatesh, 1994; Sobe, Elmenreich and Böszörmenyi,2010), balance the network workload (Huang and Fang, 2004; Zhouand Xu, 2002) and/or pre-fetch the desired channels into the set-topbox (Bikfalvi et al., 2011). Moreover, IPTV service providers exploit

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 114: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

94 IPTV Delivery Networks

user preferences and content popularity to recommend some contentsas well as to control the advertisement that should be displayed tothe users.

Although content popularity and user preferences play an importantrole in coping with the increasing demand of IPTV content/channels,these two measures fail to produce efficient IPTV delivery net-works (Fati et al., 2014b). For example, allocating IPTV contentonly according to content popularity may lead to satisfy the user’sdemand or preferences. According to Joe, Yi and Sohn (2011), thepopularity-based replication schemes assume a threshold for decidingwhich content should be replicated. In other words, the contenthaving popularity values larger than this threshold can be replicated.Also, some of these algorithms are proactive wherein the contentscan be replicated as the server allocating these contents becomesoverloaded. While replicating content of large sizes such as IPTVcontent, one must consider the trade-off between the quality of ser-vice (QoS) requirement and exploited storage space. In other words,the replication algorithms should maintain the QoS requirementswithout wasting storage resources. Both the popularity-based andproactive algorithms may replicate redundant content, which leads,in turn, to increase the exploited storage space. On the other hand,the current studies focus on the channel popularity and/or userpreferences only. In the real world, the popularity of a channel or theuser’s behaviour suffers from the rapid fluctuation. Such fluctuation inchannel popularity and/or user’s preferences may lead to prefetchingirrelevant channels, which, in turn, leads to bandwidth saturation anddelay the required channel.

To overcome this challenge, the design process of IPTV deliverynetworks for both video on-demand (VoD) and live services shouldconsider the other characteristics of IPTV content/channels. Besidesthe popularity, these characteristics include the huge size (e.g., HDrequires a huge bandwidth compared with the normal channels),interactivity and the rapidly changing effective period (Joe, Yi andSohn, 2012). In addition, there are other factors that should be con-sidered including multicast factor (e.g., some channels are requestedby many people in the area while other channels are rarely requested,or they are requested only by a few). Population size is another factorthat should be considered (e.g., some service areas are crowded andthen the request rate is higher than in other areas).

Page 115: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 95

According to García et al. (2009), modelling the workload formultimedia streaming services is an essential factor in improvingthe performance, enhancing the QoS and increasing the reliabil-ity of delivery networks. Therefore, the idea of this chapter is tobuild a mathematical model that integrates all these factors in oneconcept called the IPTV content status. Modelling the contentsstatus according to its characteristics is important in designingcontent-aware IPTV delivery networks. Content status modellingrefers to estimating the portion of concurrent requests that targetthe content according to content characteristics. Such modellinghelps a lot in handling both load balancing and resource allocationbased on the anticipated load of the content. However, these contentsare huge in size with non-uniform patterns of both content lifetimeand user request access. For this reason, modelling the status ofcontents is a challenge. Many studies in the literature review focus onthe popularity of content during the approaches to solving the loadimbalance problem. However, content popularity is not everything.Other characteristics such as size and interactivity play a significantrole in modelling the content status. Hence, the aim of this chapter isto model the content status in an IPTV environment. Modelling thecontent status helps delivery network providers build content-awaredelivery networks that overcome the problems of load imbalance andwastage of resources. To the best of our knowledge, there is no studyyet that has formulated the content status for IPTV contents.

The expected load of content or server has a significant role in bal-ancing the load among the servers. Estimating the load of content orserver takes different forms according to the nature of problems. Insome studies, the load can be estimated as the CPU consumption,while in other studies, the load can be estimated as the active con-nections to servers (Cho et al., 2008, Meng, Liu and Yin, 2013; Kanrar,2012). In this chapter, the load is estimated as the number of activeconcurrent requests that access the content/servers. Thus, the IPTVcontent status model that estimates the maximum load for each videoin the service area at the peak busy period is suggested. The video loadis estimated based on its popularity, length and request arrival rate(e.g., normal requests and interactive requests) (Gaber and Sumari,2014; Fati et al., 2014a). The proposed estimation model deals withboth the normal and interactive viewing sessions. Load and workloadwill be used interchangeably throughout this book.

Page 116: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

96 IPTV Delivery Networks

For each video, the workload can be estimated as the number ofconcurrent requests that must be served by that video. The estimatedworkload for a video is a function of the request arrival rate, the num-ber of subscribers within the service area, the video popularity and thevideo length. All this information, which is required in the workloadestimation, should be stored in the request dispatcher that is locatedin front of the clustered video hub office. To estimate the workload inthe IPTV system, we have to imagine the viewing scenario of any sub-scriber as follows: Once connected, the subscriber has two viewingstates; a normal state and an interactive state. The user starts in thenormal state where the requested video is being viewed at the usualspeed. After that, the subscriber issues an interactive VCR commandto stop, pause and jump forward or backward (Cho et al., 2008). Dur-ing the viewing time, the user can transit from one state to anotherinterchangeably until the end of viewing time.

Based on the above viewing scenario, there are two types of requests:Normal requests and interactive requests. Thus, the expected work-load of a video i can be defined as the portion of concurrent requestsof both types that can be served by this content within the peak busyperiod. Therefore, the expected load of content i is estimated as thefraction of simultaneous incoming requests targeting content i.

According to Kanrar (2012) and Wong (2004), the number of con-current requests at a certain time point can be estimated as the sumof the active request lengths within an interval time divided by thatinterval time. Kanrar (2012) has estimated the server’s workload as afunction of the number of households, request arrival rate and videolength during the peak busy period.

Most of the studies focus on channel popularity and/or user prefer-ences only without any consideration for channel characteristics suchas size (e.g., HD requires a huge bandwidth compared with the normalchannels), multicast factor (e.g., some channels are requested by manypeople in the area, while other channels are requested rarely or onlyby some individuals) and the population size (e.g., some service areasare crowded and then the request rate is higher than in other areas).Moreover, depending on the popularity of the channel or user behav-ior, IPTV systems suffer from the rapid fluctuation of user preferencesin the real world. Therefore, such fluctuation in channel popularityand/or user preferences may lead to prefetching irrelevant channels,which, in turn, could lead to bandwidth saturation and delay therequired channel. To control such fluctuation, expecting the channel

Page 117: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 97

status (the expected requests targeting this channel) according tothe channel characteristics and demand is beneficial. This predictioncan control the fluctuation in the channel popularity and/or the userpreferences. Channel status can be modelled as a function of channelbandwidth, channel popularity, multicast factor and region popula-tion. According to historical analysis, we can easily predict the demandof a channel in a particular area, and then, decide the prefetching.

4.2 The Key Challenges in IPTV DeliveryNetworks

As highlighted in Chapter 1, designing a delivery network is not atrivial task and many problems must be solved. Delivery networkcomposition, content distribution and management, resource allo-cation and request redirection are the main type of issues that mustbe considered during building a delivery network. Delivery networkcomposition includes delivery network placement, determining serverspecifications and interaction among servers. Content distributionand management include content selection and distribution basedon cache/replica management. Resource allocation judges the typeand size of resources required for each surrogate server. Requestredirection includes the techniques to distribute requests amongservers in a manner of maintaining the load balance and keepingthe traffic congestion minimal (Xu, 2009; Pathan and Buyya, 2007).Figure 4.1 depicts the taxonomy of the issues related to IPTV deliverynetworks including request distribution, content placement andresources allocation problems.

4.2.1 Request Distribution Algorithms in IPTV DeliveryNetworks

An appropriate request distribution mechanism is required to assigneach request to the right target server. Such a distribution mechanismshould maintain the load balance, increase the system throughput anddecrease the rejection rate for incoming requests. In the literature,the terms load balancing, request distribution and request redirectionare used interchangeably. In fact, request distribution of multimediasystems has long been a research topic, where many algorithms areproposed to tackle the load imbalance problem by assigning the

Page 118: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

98 IPTV Delivery Networks

IPTV delivery network issues

Request distribution

Distribution-

based Dynamic

placement

Disk

striping

Replication Caching

iCloud-

based

Cluster-

based

Content-blended

Replica placement problem

Full replication

Cost function

Cost Reduction

QoS improvement

Evolutionary

Heuristic

Hierarchical

based

Distribution-

based

Proposed solution

Content-aware

Content placement Resources allocation

Partial replication

Figure 4.1 IPTV delivery networks: issues taxonomy.

Request

dispatching

Distribution-

basedCluster-based iCloud-based

Content-

blendedContent-aware

Figure 4.2 Taxonomy of load-balancing algorithms.

incoming request into the target servers using the load balancerhardware. These algorithms can be classified into three categoriesaccording to the used delivery network architecture. Figure 4.2 depictsthe taxonomy of those algorithms.

The first category includes request distribution algorithms indistributed architecture, as in Tay and Pang (2000), Dakshayiniet al. (2007), Moon, Moon and Cho (2010) and Guruprasad andMaheshappa (2008). Guruprasad and Maheshappa (2008) proposedan algorithm that distributes the requests to three kinds of servers:The local server, the proxy server and the central server depending on

Page 119: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 99

the availability of the requested video in one of them. Tay and Pang(2000) utilised the same algorithm that used the agent technology.Even though both the algorithms addressed the load imbalanceproblem, none of them considered the workload estimation orload-balancing mechanism. A new algorithm called global waitingqueue (GWQ) algorithm is proposed by Tay and Pang (2000), whereinevery server in the distributed VoD environment maintains twoqueues: A local queue to serve the locally generated requests and aglobal queue to serve the redirected requests from other servers. Theserver redirects the request to all other servers if it has insufficientbandwidth and waits for their bids to choose the best bid for servingthe redirected requests. Despite that Tay and Pang (2000) proposedrequests redirection mechanism among the servers, their focus wason load sharing rather than on load balancing. Thus, the load imbal-ance problem has not been addressed in this approach. Moreover, thisalgorithm prioritised local requests rather than redirected requests.Certainly, this priority, in turn, negatively affects the response time ofthe redirected requests.

The second category includes request distribution algorithms inthe cluster-based systems. There are two directions in this field:content-blind algorithms (Zhou and Xu, 2007; Huang and Fang,2004) and content-aware algorithms (Cho et al., 2008; Pai et al.,1998; Casalicchio, Cardellini and Colajanni, 2002). The content-blindalgorithms ignore the existence of content during load distributionamong servers. The famous representatives for the content-blindcategory are round robin (RR), least loaded (LL), random serverselection (RSS) and weighted round robin (WRR) algorithms (Casal-icchio, Cardellini and Colajanni, 2002; Teo and Ayani, 2001). Thesealgorithms distribute requests blindly without checking content. This,in turn, leads to an increase in the rejection rate, and, as a result,affects the performance of the distribution process. In the following,we will briefly describe these algorithms.

Round robin (RR) algorithm: This assigns the incoming requests onround robin base, wherein the first request goes to the first server,and the second request, to the second server and so on. As therequests are assigned in sequence among the servers, all serverswill serve the same workload without considering the server’scapacity and/or the content status. In the case of full contentreplication over homogeneous servers, RR can be considered thebest distribution algorithm.

Page 120: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

100 IPTV Delivery Networks

Weighted round robin (WRR) algorithm: In this algorithm, eachserver, from a set of heterogeneous servers, holds a weight. Theseweights indicate the capacity of servers. The incoming requestwill be redirected into the server according to the servers’ weight.Hence, high weight servers can accept a number of requests morethan those assigned to servers with low weight.Least loaded (LL) algorithm: This redirects the incoming requeststo the server with the least load. The load dispatcher in this case hasto count the active connections to each server.Random server selection (RSS) algorithm: The incoming requests areassigned to a uniform randomly selected server among the serverfarm.Dynamic algorithm: The incoming requests are assigned to theserver with the smallest amount of remaining workload. Theremaining workload for each server can be calculated after deduct-ing the sum of expected workload of both the queued request andthe current requests being served.

As mentioned earlier, round robin algorithm, from the content-blended subcategory, can become the best request distribution algo-rithm in case all the contents are fully replicated among homogeneousservers. However, the full replication of huge size content (e.g., IPTVcontent) is not a good option in terms of storage resources saving.Thus, the content-aware request distribution algorithms that checkthe locality of content have been proposed to deal with the partialreplication schemes. Content-aware algorithms check whether thecontent exists on the server or not before redirecting the incomingrequest. In fact, most of the proposed content-aware request dis-tribution algorithms consider content existence rather than contentcharacteristics. Zhou and Xu (2002) proposed a request redirectionalgorithm based on video popularity and backbone bandwidth. Theiralgorithm tries to solve the load imbalance problem among theservers by redirecting the requests from the overloaded servers tothe lightly loaded servers. The load balancing in their algorithm isachieved by replicating the requested content from the heavy loadedserver to lightly loaded server via a backbone connection among theservers. As a result, the requests of this replicated content will beredirected from the original server to the target server. An admissioncontrol algorithm that verifies the server ability to serve the incomingrequest is proposed by Huang and Fang (2004). In this algorithm,

Page 121: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 101

the admission control in the destination server checks the server’sresources including memory, CPU and disk bandwidth. Based on theestimated resources availability, the request can be migrated fromthe original server to the destination server with the aim of balancingthe load among the cluster. Two studies (Zhou and Xu, 2007; Huangand Fang, 2004) tried to solve the problem of request migration amongthe clusters after request dispatching. However, there is no need fora request migration mechanism in case of building an appropriatedispatching mechanism considering the expected and current load.Moreover, taking into consideration the processing, bandwidth andstorage requirements during the dispatching process is valuable, butit causes an overhead on the link between dispatcher and servers.

A locality-aware request distribution algorithm (LARD) is proposedby Pai et al. (1998) for the server cluster. LARD algorithm distributesthe incoming requests among the clusters according to the locality (i.e.,the existence of content) and the load of the server. The LARD algo-rithm uses the replication mechanism to cope with increased requestsby distributing the requests to more than one location. The main lim-itation in this study is that the server workload is not addressed (i.e.,the workload is not estimated). Moreover, the LARD algorithm omitsthe content load and there is no clear restriction on the replicationmechanism. Thus, the LARD algorithm is not valid for the IPTV deliv-ery in the shared environment. Gaber and Sumari (2014) introduced agood survey on content-aware request dispatching mechanisms. Theyargued in their study that the content-aware mechanisms augment thelocality, reduce disk accesses and improve load balancing. Accordingto their study, the content-aware mechanisms focus on two types ofinformation: Client information (including the content size and con-tent location) and server information that represents the server load.

In contrast, the load-balancing algorithm by Cho et al. (2008) is pro-posed to reduce disk I/O operations using buffer sharing. The algo-rithm distributes the requests based on the trade-off between the diskstreams and network streams using ideal state matrix. In spite of usingan accurate workload estimation, Cho et al. (2008) ignored the popu-larity effect on the workload estimation. Furthermore, they assumedthat all contents are fully replicated on all servers. Thus, this is unreal-istic in multimedia systems.

The third category includes load-balancing algorithms in iCloud-based systems. Meng, Liu and Yin (2010) proposed a dispatchingalgorithm for on-demand IPTV services using the utility function.

Page 122: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

102 IPTV Delivery Networks

Their utility function aims at minimising the disk I/O among theservers inside the service group in their proposed iCloud architecture.In their algorithm, the dispatcher will assign the request to the serverthat had served the same content recently. The dispatcher choosesthe server that has the minimum utility function value to assign therequest. If the requested video is not presented in the cluster, thenit will be requested from the central station. This algorithm swiftlyreduces the disk I/O of the servers. However, the real bottlenecksin multimedia systems are the server load and network bandwidthrather than the disk I/O transactions.

Most of the proposed approaches that have been discussed abovedistribute the incoming requests according to the server status (i.e., theserver workload) only. Thus, according to Gaber and Sumari (2014),these algorithms are inapplicable in the shared environments that dealwith hybrid contents that belong to different sources. Moreover, thesealgorithms fail to distribute the load in the server farm or cluster withinteractive contents wherein the user has the option to forward orbackward and so on (Sharifian, Motamedi and Akbari, 2008). Gaberand Sumari (2014) suggested that building a predictive load balancerthat distributes the incoming load based on the anticipated load ofboth contents and servers will give a strong guarantee on balancing theload. The load balance includes the identical load distribution amongthe servers to improve system performance and provide a fair loaddistribution among content. This is to ensure that all content will berequested fairly (i.e., each content must be served according its pop-ularity). Such a load balance ensures quality of service improvementand user satisfaction for all shareholders (Cardellini, Colajanni andPhilip, 2002; Sharifian, Motamedi and Akbari, 2011; Cherkasova andPonnekanti, 2000).

4.2.2 Cost Reduction in IPTV Delivery Networks

Cost reduction is an area of concern to service providers; therefore, itshould be considered during the designing of IPTV delivery networks.In delivery networks, many service providers may share resourcesand compete to deliver high-quality services. Furthermore, IPTVsystems also suffer from the sudden peak workloads. As it happens,allocating a large amount of resources to cope with the suddenworkload leads to low resources utilisation at non-peak hours. Also,not considering the peak workload leads to user dissatisfaction during

Page 123: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 103

the peak hours. Similarly, IPTV content is characterised by the hugesize and rapidly changing effective period (Joe, Yi and Sohn, 2011).These characteristics make content replication a serious problem interms of storage space saving and service availability. Hence, resourceallocation and replica placement problems are important issues thatshould be considered mutually. In other words, resource allocationand replica placement should be integrated (Laoutaris, Zissimopoulosand Stavrakakis, 2005). Such integration can help reduce the wastageof resources by allocating the resources according to the necessitatedreplication scheme. As a result, the total cost can be reduced.

4.2.2.1 Replica Placement Schemes in IPTV Delivery NetworksContent placement is important in delivery networks for multimediastreaming. In large multimedia systems (e.g., IPTV), the effectivecontent placement is highly required to cope with load imbalance,insufficient bandwidth, large delay and packet loss. In the contextof content placement, a considerable number of studies have beenproposed to cope with the growing demand for this content. The earlystudies, employing the central architecture (i.e., single main server),focus on content organisation among an array of disks. These studiesinclude dynamic data placement (Wah, 1984; Wolf, 1989) and diskstriping (Ganger et al., 1993; Bolosky et al., 1996; Wang and Du, 1997;Alemany and Thathachar, 1997; Scheuermann, Weikum and Zabback,1998; Gafsi and Biersack, 2000; Lee and Wong, 2000).

Further, replica placement problem, as a global strategy, is widelyinvestigated in the literature review to improve the overall perfor-mance and/or minimise the allocation cost (Karlsson et al., 2002). Inthe literature, the replica placement problem is formally expressedas a problem definition (cost function) that moves towards anoverall goal (performance improvement or cost reduction). Suchproblems typically require heuristic algorithms to find approximatesolutions within a feasible time, due to that they are nondeterministicpolynomial time (NP)-complete (Du et al., 2011).

In the context of problem definition, the researchers investigatethe content replication problem from two perspectives. The firstperspective is to improve the quality of service (Tang et al., 2001;Wauter et al., 2006; Guo et al. 2008; Zaman and Grosu, 2011). Thesecond perspective is to minimise the delivery cost (Li and Wu, 2010;Neves et al., 2010; Laoutaris, Zissimopoulos and Stavrakakis, 2005;Tang et al., 2001; Wauter et al., 2006; Guo et al., 2008; Zaman and

Page 124: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

104 IPTV Delivery Networks

Grosu, 2011; and Cidon, Kutten and Soffer, 2002). These studies canalso be classified according to the solutions proposed. These solutionscan be classified into heuristic solutions and evolutionary solutions.The heuristic solutions include the approximation algorithms and thegreedy algorithms. In contrast, the evolutionary algorithms includegenetic, ant colony and particle swarm algorithms.

As long as it is NP-complete (Karlsson, Karamanolis andMahalingam, 2002; Tenzakhti, Day and Ould-Khaoua, 2004;Mahmood, 2010), replica placement problem typically requiresmeta-heuristic algorithms to find approximate solutions within afeasible time (Du et al., 2011). However, according to Tenzakhti, Dayand Ould-Khaoua (2004) and Mahmood (2010), the studies that utilisethe heuristic algorithms fail to produce an optimal effective place-ment strategy (Tenzakhti, Day and Ould-Khaoua, 2004; Mahmood,2010). Thus, the need for an effective algorithm to find the optimalsolution still persists. Accordingly, due to the fruitful application ofevolutionary algorithms to solve a variety of optimisation problems,many attempts are recorded in the direction of using these algorithmsin solving the replica placement problem. Khan and Ahmad (2008)compared the heuristic algorithms with evolutionary algorithms(genetic algorithm as an example). They introduced a unified costmodel that captures the minimisation of the total object transfer costin the system and leads, as a result, to effective utilisation of storagespace, replica consistency and fault-tolerance. The study showsthat genetic algorithm outperforms the heuristic algorithms (e.g.,greedy algorithms) in terms of solution quality. Despite producingbetter solutions as close as possible to the optimal solutions, theevolutionary algorithms are still slower than heuristic algorithms inthe running time. These findings are also confirmed by Mahmood(2010) and Loukopoulos and Ahmad (2004). From another angle,most of the discussed replica placement algorithms are based onpopularity. As the term implies, they replicate the content onlyaccording to the popularity value. According to Joe, Yi and Sohn(2012), the popularity-based replication schemes assume a thresholdto judge what content must be replicated. For example, the contentthat has popularity values larger than a predefined threshold canbe replicated rather than those with a popularity value lesser thanthe threshold. Furthermore, some of these algorithms are proactive,wherein the contents can be replicated once the server holding thesecontents becomes overloaded. While replicating content of huge sizes,

Page 125: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 105

such as IPTV content, one should consider the trade-off betweenthe QoS requirement and the utilised storage space. In other words,the replication algorithms should maintain the QoS requirementswithout wasting the storage resources. Both popularity-based andthe proactive algorithms may replicate redundant contents. Suchredundant replication leads, in turn, to increase the storage spaceutilised.

4.2.2.2 Resource Allocation Schemes in IPTV Delivery NetworksResource allocation is another important issue in designing the deliv-ery network. Resource allocation determines the locations and theamount of resources to minimise the cost under certain constraints.As pointed out earlier, in delivery networks, many service providersmay share resources and compete to deliver high-quality services.Therefore, these resources should be shared in an effective manner(Xu, 2009). However, IPTV systems suffer from the sudden peakworkloads. Thus, allocating a large amount of resources to cope withthe sudden workload leads to low resource utilisation at non-peakhours. Furthermore, non-considering the peak workload leads to userdissatisfaction during the peak hours. Therefore, the pay-as-you-goscheme is suggested by some delivery network providers. AmazonCloudFront is a prominent example of this scheme. In this scheme,the service provider has to pay for the used resources only withoutany upfront payment, commitment or service contract.

The aim of the resource allocation problem is to minimise thecost while certain constraints are respected (Thouin and Coates,2007). Thus, the optimisation strategy is a good option to solve suchproblems. In the literature review, the resource allocation problemhas been addressed using heuristic solutions (Belbekkouche, Hasanand Karmouch, 2012). Wauters et al. (2006) address the resource allo-cation problem of determining the equipment required for buildingtransport network for VoD services. They focused on determining thenumber of ports of each server, as well as the number of multiplexersand switch ports at each node. In their study, the decentralised net-work is divided into regional sub-networks with a ring topology. Next,a single server is installed on each regional sub-network. Similarly,Kitjongthawonkul and Ko (2011) examined the resource allocationproblems in a VoD network to find the optimal locations of the videoservers. They considered the users’ demand to select the locationof those servers. Moreover, the authors addressed the allocation

Page 126: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

106 IPTV Delivery Networks

problem using the dynamic programming technique. The objectiveof Kitjongthawonkul and Ko is to minimise the total operating cost,including transmission cost, storage cost and server installation cost.

Allocating the resources to build an overlay network over multiplesubstrate networks is proposed by Houidi et al. (2011) and Pandeyet al. (2011). Houidi proposed a dynamic overlay network creationmodel according to the load and the available resources. The proposedmodel is composed of request-splitting algorithm and -embeddingalgorithm. The request-splitting algorithm aims at helping the over-lay network provider distribute the incoming requests among theavailable substrate network providers. The authors proposed tworequest-splitting algorithms: Max-flow min-cut algorithm and linearprogramming algorithm. Based on the splitting algorithm, embeddingalgorithm is proposed to simultaneously assign virtual nodes andlinks into each substrate network provider. In this work, the authorsformulated the overlay network embedding process to be solved bymeans of the mixed integer programme. The aim of the proposedembedding algorithm is to increase the request acceptance rate anddecrease the leasing cost of infrastructure.

Pandey et al. (2011) focused on determining the optimum networkdeployment strategy for VoD services in a heterogeneous networkingenvironment. The deployment decisions can be made consideringthe following parameters: The required number of VoD servers,the minimum physical distance of server from the community andthe bandwidth capacity requirement. Pandey’s aim is to determinethe minimum capacity requirements that maintain the minimumrequirement of quality of experience (QoE) to be met. Therefore, theyestimated three QoE metrics: The server waiting time, the minimumone-way delay and the access network bandwidth consumption.Such estimation is done based on the analysis of user requirementsand network configurations. Afterwards, they jointly formulated theserver location problem and path selection problem as an integerlinear programming (ILP) problem. The authors solved this problemby means of ILP techniques, as well as, heuristics.

One of the flaws in the most proposed works to solve the resourceallocation and/or replica placement problem is that they considerthe problems of resource allocation or replica placement problemindependently. Solving these two problems independently pro-duces suboptimal solutions, which is due to the direct effect ofreplica locations on the amount of required resources and vice

Page 127: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 107

versa (Laoutaris, Zissimopoulos and Stavrakakis, 2005; Thouin,2007). The main advantage of combining replica placement andresource allocation in one joint problem is that the resources willbe utilised efficiently and as necessary. Once these resources areno longer required, they will be released to be available for otherusers who require it or are able to pay for it. Thus, integrating thereplica placement problem with the resource allocation problem isfirst suggested by Laoutaris, Zissimopoulos and Stavrakakis (2005),who argue that the replica placement problem and the resourceallocation problem should be jointly solved to avoid a suboptimalsolution. They proposed a realistic framework to build an optimalresource/content allocation model for a hierarchical architecture thatminimises the total cost. The cost here is represented by the distancebetween the storage location and the end-user. The framework ofLautaris took into consideration the load balance and request peeringamong servers as constraints. In this framework, genetic algorithmis exploited to solve the resource allocation problem. Nguyen et al.(2005) addressed the problem of overly network provisioning formultimedia contents to build a cost-effective virtual delivery network.Their framework aims to build an overly delivery network over asubstrate network. They formulated the provisioning problem as acombination between content replication and resource allocation.Next, they solved this provisioning problem using a Lagrangianrelaxation heuristic algorithm.

Similarly, Nakaniwa and Ebara (2007) introduced a mathematicalmodel to join content replication with server placement for the hier-archical architecture. Their aim was to maximise the system reliabilityof delivery network. They introduced an integer programming tech-nique to maximise the reliability of the system. This technique findsthe optimal scheme for both content and resource allocation problemsthat maximise the reliability of all the paths from each user to each filelocation. They applied their model on a real delivery network for anInternet service provider in Japan called ‘B Bit-Japan’ subject to delayand storage and/or transmission cost constraints.

On the other side, Aldana Diaz and Huh (2011) argue that allocat-ing the IPTV resources including storage and bandwidth requirescreating a cost function based on content management and distri-bution. They proposed three cost-based policies, particularly, localhosting, external hosting and partial hosting policies for third-partycontent service on a distributed architecture. In their detailed cost

Page 128: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

108 IPTV Delivery Networks

function, they consider the storage and bandwidth requirements thatmaintain the least level of service level agreement (SLA). The resultsshowed that partial hosting of content is the most suitable technique,wherein some of the contents are hosted locally while the others canbe requested upon demand. Such partial hosting may maintain thetrade-off between the storage cost and bandwidth cost. However,this work lacks real constraints on the content that should be hosted,and, the content that should be requested upon demand. Li and Wu(2010) proposed a heuristic algorithm that finds the optimal quantityof popular contents and the optimal number of servers to store thesecontents. Their model ignores the contents’ replication and the loadbalancing.

In the foregoing resource allocation algorithms, resource allocationhas been integrated with replication schemes. However, as mentionedin Section 4.2.2.1, using the content popularity as a measure to decidethe replication degree can definitely lead to storage redundancy. Thisredundancy affects the resource allocation process. Thus, finding aneffective replica strategy and integrating it with resource allocation toavoid the wastage of resources and the high cost of IPTV delivery net-work design process is a definite requirement.

4.3 Content Status Issue in IPTV DeliveryNetworks

IPTV content is characterised by huge size (i.e., in mega bytes orgiga bytes), interactivity and a rapidly changing effective period (Joe,Yi and Sohn, 2012). Such distinct characteristics make the design ofIPTV delivery networks challenging. That means building a deliverynetwork for allocating huge size content to satisfy the demands ofdiverse customers requires careful attention. Accordingly, consider-ing these characteristics is important to achieve load balancing andavoiding the wastage of resources. For this reason, we believe thatignoring the status of diverse contents leads to load imbalance, which,in turn, leads to performance degradation in the IPTV system.

Therefore, modelling content status according to its characteristicsis important for designing content-aware IPTV delivery networks.Content status modelling refers to estimating the portion of concur-rent requests that target the content according to its characteristics.Such modelling helps a lot in handling both the load balancing

Page 129: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 109

and resource allocation based on the anticipated load of content.However, this content is of huge size with non-uniform patternsof both content lifetime and user request access. For this reason,modelling content status is a challenge. Many studies in the literaturereview focus on the popularity of content during their approaches tosolve the load imbalance problem. However, content popularity is noteverything. The other characteristics such as size and interactivityplay a significant role in modelling content status.

4.3.1 Unawareness of Content Status in Replica PlacementSchemes

Storing IPTV content efficiently to make it accessible for end-usershas been a challenge. This is because inadequate content allocationmay lead to the wastage of resources and load imbalance. Suchinadequate allocation may be caused by not considering contentstatus (i.e., the workload of content). For instance, ignoring the statusof popular content leads to replicating these contents lesser thanexpected. Accordingly, the request rejection rate will increase, andthe throughput will decrease, especially during the peak hours. Onthe other hand, replicating unpopular content more than expectedby ignoring content status would lead to a wastage of resources (i.e.,storing redundant objects).

A considerable number of replica placement schemes have been pro-posed over the past several years for web and VoD services. The mainconcern of these studies is to improve the QoS and/or minimisingthe content transmission cost. However, to the best of our knowledge,there is no study that considers the impact of content status on thereplica placement problem. Replicating the content according to sta-tus (i.e., expected load) would avoid the redundancy in the storageresources, which, in turn, reduces the allocation cost and balances theload as well. For this reason, these current algorithms may not workwell in the shared environments that host huge hybrid content belong-ing to different sources.

Therefore, distributing the content based on the anticipated load ofboth content and server will give a strong guarantee on balancing theload, which, in turn, ensures QoS improvement. Moreover, consider-ing the content status helps the delivery network manager with theaccurate handling of storage resources. Handling the storage resourcesis achieved first by differentiating between the frequently requested

Page 130: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

110 IPTV Delivery Networks

content (i.e., popular content) that consumes more resources and thatcontent that is not requested so frequently (i.e., unpopular content).Next, the delivery network manager adjusts the storage resources forcontent based on the expected load. Consequently, a larger portion ofresources will be devoted to popular content to cope with the grow-ing demand. On the other hand, a small portion of storage resourcesis allotted to unpopular content.

4.3.2 Unawareness of Content Status in RequestDistribution Algorithms

Many request distribution algorithms have been proposed to deal withthe load imbalance problem for web and video servers. However, mostof them distribute the incoming requests according to the server’s sta-tus (i.e., the server’s workload). On the other hand, content status hasa significant impact on load balancing. Thus, these request distribu-tion algorithms are inapplicable in the shared delivery networks thatdeal with hybrid content, which belong to different sources. Moreover,these algorithms fail to distributed the load in the server farm or clus-ter with the interactive content, wherein the user has the option tochoose forward or backward (Sharifian, Motamedi and Akbari, 2008).

4.3.3 Unawareness of Content Status in Resource Allocation

Resource allocation is an important issue in designing the shareddelivery network. Resource allocation determines the locationsand the amount of resources to minimise the cost under certainconstraints. As pointed earlier, in delivery networks, many serviceproviders may share resources and compete to deliver good qualityservices, for which, these resources should be shared in a moreeffective manner (Xu, 2009). However, IPTV systems suffer from thesudden peak workloads. Thus, allocating a large amount of resourcesto cope with the sudden workload leads to low resources utilisationat non-peak hours. On the other hand, not considering the peakworkload leads to user dissatisfaction during peak hours. Therefore,the pay-as-you-go scheme is suggested by some delivery networkproviders. Amazon CloudFront is a global example of this scheme. Inthis scheme, the service provider has to pay for the used resourcesonly without any upfront payment, commitment or service contract.

Page 131: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 111

Particularly, the service provider has to control the allocationof resources according to the content status and the user demandto reduce the hosting cost (Niu, 2013) without affecting usersatisfaction. Thus, the replica placement problem and the resourceallocation problem should be integrated for the purpose of buildingcontent-aware IPTV delivery networks. This integration allows theservice provider to adjust the required resources according to thenecessitated replication scheme, against which, Laoutaris, Zissi-mopoulos and Stavrakakis (2005) argue that the replica placementproblem and resource allocation problem should be solved jointlydue to the interdependency between them. Moreover, consideringthe content status during the integration gives the service providersthe possibility of controlling the resources and content distributionaccording to the demand fluctuation and enables the delivery networkto absorb the sudden load fluctuation.

4.4 IPTV Content Status Modelling: A NewDirection

Currently, IPTV service providers consider the popularity distributionof IPTV content and/or user preferences to allocate IPTV content andresources, balance the network workload and/or pre-fetch the desiredchannels into the set-top box. Despite playing an important role incoping with the increasing demand of IPTV contents/channels, thecontent popularity and the user preferences fail in producing efficientIPTV delivery networks. For instance, content popularity and/oruser behaviour suffer/s from the rapid fluctuation. Such fluctuationin content popularity and/or user preferences may lead to replicateirrelevant content. Consequently, such content replication can leadto storage space waste and improper request distribution as well. Toovercome these challenges, the design process of IPTV delivery net-works for both on-demand and live services should consider the othercharacteristics of IPTV contents/channels. Besides the popularity,these characteristics include the huge size (e.g., HD requires more ofa huge bandwidth than the normal channels), interactivity and therapidly changing effective period. In addition, there are other factorsthat should be considered including multicast factors (e.g., somecontent/channels are requested by many people in the area while

Page 132: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

112 IPTV Delivery Networks

other content/channels are rarely requested). The population size isanother factor that should be considered (e.g., some service areas arecrowded and then the request rate is higher than other areas).

4.4.1 IPTV Content Status Modelling

As mentioned earlier, the workload of contents can be estimated byconsidering the content’s characteristic. For example, the contentworkload means the number of active requests targeting that contentat the same time during the peak busy period. In the case of esti-mating the workload for individual content, there is a population ofsubscribers H issuing different requests targeting diverse contents atthe peak busy period. Each subscriber can issue a number of normalrequests λ and interactive request λvcr with holding times ti and tvcrfor normal and interactive requests, respectively. Thus, the workloadfor a video i can be estimated as the portion of concurrent normaland interactive requests originating within the service area by thesubscribers to watch that content during the peak busy period. Thiscan be interpreted mathematically as in Equation 4.1.

Li =pi∗ HTpeak

((λ ∗ ti) + (λvcr ∗ tvcr) ) (4.1)

Where the terms Li, pi and ti denote the expected work load, thepopularity and the length of the particualr movie i in the service area,respectively. The popularity takes a value between 0 and 1. The termH denotes the number of households in the service area, and Tpeakdenotes the peak busy period of IPTV system in minutes. In addi-tion, the terms λ and λvcr denote the request arrival rate and VCRcommands request arrival rate, respectively. Both arrival rates followthe Poisson distribution. In Equation (4.1), the term H((λ ∗ ti) + (λvcr ∗tvcr) ) represents the total sum of all requests issued by the household swithin the peak busy period. By multiplying this term with the contentpopularity value pi, the number of requests targeting this content isobtained. Finally, the concurrent requests per unit time are estimatedby the term p_i* H dividing on the term Tpeak.

After content workload estimation, the expected workload of serverj is estimated by summing up the load of all content that is stored inthis server as shown in Equation (4.2).

Lj =∑i∈j

Li =H

Tpeak

∑i∈j

(pi((λ ∗ ti) + (λvcr ∗ tvcr))) (4.2)

Page 133: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 113

The term Lj denotes the expected workload for a particualr serverj. Assuming that the available servers in the service area are sufficientto handle the total workload, these servers must be accurately allo-cated to cope with the growing load problem. After estimating theexpected load of contents, the replication degree (i.e., the number ofreplicas that are required to handle the expected load) is calculated.The replication degree must be controlled by the video’s popularity.For instance, video i can be allocated on all servers if its popularity isextremely high. This is to ensure that the expected load can be dis-tributed on as large a number of servers as possible to minimise therequest rejection rate. On the other hand, there is no need to replicatethe remarkably low popular videos so that one copy is enough to catchits low expected load. Based on the above explanation, the replicationdegree (i.e., number of copies) for a video i can be formulated as a func-tion of the number of servers and the normalised popularity as shownin Equation (4.3). According to Nafaa, Murphy and Murphy (2008),normalising the popularity distribution improves the overall perfor-mance by building a strong relationship between content popularityand replication degree.

ri = ⌈Sa ∗ pni ⌉ (4.3)

Where the term ri denotes the number of replicas for content i, Sarepresents the number of servers in service area a and finally the termpn

i represents that the normalised value of pi should be within [0,1].The normalised popularity value has been obtained using min-maxnormalisation law. Min-max normalisation performs a linear trans-formation on the original data (Gaber and Suamri, 2014). Min-maxnormalisation maps pi to pn

i value in the range [new_ min, new_ max].In this case, the new_ max value equals one where the highest popular-ity value in the dataset will be scaled to equal the value (1) and the othervalues will be scaled successively. The operator ⌈.⌉ is a ceiling functionoperator to take the largest integer nearest to the calculated term.

After computing the expected number of replicas for a video i,the expected load for each replica can be calculated by dividing theexpected load for that video on its number of replicas as follows:

Lri = Li/

ri (4.4)

Where Lri represents the load of one replica for contenti, Li denotesthe load of video I and ri represents the number of replicas for contenti, which is obtained from Equation (4.3).

Page 134: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

114 IPTV Delivery Networks

According to the proposed content status model, the content of highpopularity value, which has a high expected load, is replicated to han-dle the increasing demands. On the other hand, the content of lowpopularity value can be replicated as less as possible for serving the lowexpected load. Furthermore, allocating the contents and distributingthe incoming requests according to this proposed IPTV content sta-tus model can be useful in maintaining the load as balanced as possiblewithin the service area.

4.4.2 Experimental Results

To investigate the performance of our proposed IPTV content sta-tus model, we have tested the model on an empirical data set that issampled according to the content popularity distribution. The pop-ularity distributions used are Zipf-like distribution (Zipf ). There area set of assumptions that were taken into account during the exper-imental study of the proposed model as follows: The population ofsubscribers H= 1000; each subscriber can issue a number of normalrequests λ= 2 request/user/minutes and interactive request λ_vcr= 2request/user/minutes with holding times t_vcr= 10 seconds for inter-active requests. These values are typical empirical data and widely usedby different studies (Cho et al., 2008). The content size distribution hasbeen generated randomly between 50 and 1000 MB. Figure 4.3 depictsa sample of the content size distribution in MB.

The popularity of contents is computed according to Zipf’s Law (Liand Wu, 2010) as in Equation (4.5), where i, N and θ represent the

0

1 4 710 13

16 19

22

25

28

31 34

37

40

43

46

49

52

55

58

61

64

67

70

73

76

79

82

85

88

91

94

97

100

200

Co

nte

nt

size

(M

B)

Content rank

400

600

800

1000

1200

Figure 4.3 Random content size distribution.

Page 135: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 115

content rank, the total number of contents and the skewness degree,respectively. The content rank refers to the position of content in thesorted content’s list. The content’s list is sorted according to the popu-larity value of content. In this list, the first video is the highest popularvideo and so on.

P(i, θ,N) =1∕iθ∑N

n=1 (1∕nθ)(4.5)

Then, the workload is computed using our proposed IPTV contentstatus model. Note that the expected load of server j can be expressedby summing the load of all content stored in this server. Figure 4.4depicts the expected load for the content, which is obtained from theIPTV content status model.

Figure 4.5 plots the relationship between the expected workload ofcontents and the popularity distribution. What is apparent is the factthat the expected load of contents differs from the popularity distri-bution. This is due to the other factors that contribute to the workloadestimation such as video length and interactivity.

Another experiment is conducted on a delivery network with fourservice areas. Each service area contains four servers. We changed thepopularity skewness at each service area such that each area allocatesdifferent replicas for the content. After that, our request distributionalgorithm was developed by Gaber and Sumari (2014) over theIPTV content status model. Then, this algorithm (CARDA) has beencompared with two other request distribution algorithms, that ofCho et al. (2008) and the RR algorithm. The experiment showed that

Expected load

0

1 6 11 16

21

26

31

36

41

46

51

56

61

66

71

76

81

86

91

96

101

500

1000

1500

2000

2500

3000

3500

4000

Content rank

Lo

ad o

f co

nte

nts

Figure 4.4 The distribution of expected content load.

Page 136: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

116 IPTV Delivery Networks

0

Content rank

Po

pu

lari

ty v

alu

e

Lo

ad (

con

curr

ent

req

ues

ts)

1 8

15

22

29

36

43

50

57

64

71

78

85

92

99

500

Expected load Popularity

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

1000

1500

2000

2500

3000

Figure 4.5 The relation between expected load and popularity.

s11

s12

s13

s14

s21

s22

s23

s24

s31

s32

s33

s34

s41

s42

s43

s44

Server number

0

500

1000

1500

2000

2500

RR

Wo

rklo

ad

ca

pa

city (

nu

mb

er

of

co

ncu

rre

nt

req

ue

sts

)

Cho CARDA

3000

3500

4000

4500

Figure 4.6 The relation between expected load and popularity.

popularity has no effect on the request distribution mechanism thatsupports the argument of Gaber and Sumari (2014) that the requestdistribution process is solely affected by the request arrival rates.Figure 4.6 depicts the distribution of workload among four serviceareas with four servers each. Moreover, it is apparent from the factsthat our model, which exploits the content status, has a balancedworkload distribution among all servers.

Managing IPTV delivery networks that allocate interactive contentof large size (videos and/or channels) characterised by fluctuatingpopularity and non-uniform request patterns is challenging. Ignoringsuch characteristics can lead to load imbalance and affect the system

Page 137: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 117

performance. Therefore, modelling content status according to itscharacteristics is very important in designing IPTV delivery networks.Such modelling helps a lot in handling load balancing by distributingthe incoming requests based on the anticipated load of both contentand servers. However, modelling content status is challenging dueto the nature of IPTV content. Most of the proposed studies focusonly on content popularity, but the influence of other characteristicsshould be investigated. Thus, this chapter suggests that the IPTVcontent status model estimate the maximum workload for each video.The load is estimated to be the number of active concurrent requeststhat access the content. The workload for the content is estimatedin the service area at the peak busy period based on its popularity,length and request arrival rate (e.g., normal requests and interactiverequests). The proposed model deals with both the normal andinteractive viewing sessions.

According to Fati et al. (2014b), modelling the workload for multi-media streaming services is an essential factor in delivery networksto improve performance, enhance the QoS and increase reliability.Therefore, a new direction in IPTV delivery networks has been openedby Gaber and Sumari (2014). The general purpose of this direction isat integrating all the factors, influencing the content, into one conceptcalled IPTV content status. Modelling content status according to itscharacteristics is important in designing content-aware IPTV deliverynetworks. Content status modelling is referred to as estimating theportion of concurrent requests that target the content according toits characteristics. Such modelling helps a lot in handling both theload balancing and resource allocation based on the anticipated loadof contents. Also, modelling the content status helps the deliverynetwork providers build content-aware delivery networks that dealwith contents according to their consumption of resources rather thantheir popularity/preference. Yet again, modelling the content statusaccording to its characteristics helps in controlling the resourcesconsumption by way of overcoming the load imbalance and wastageof resources problems.

Gaber and Putra [32–34] argue that unlike content popularity, whichrepresents the percentage of access to the content over a period in thepast depends on the server log file [89, 90], content status expects thebehaviour of the content in the future to depend on its characteristicsalong with the popularity. Therefore, considering content status in theIPTV delivery networks helps the network manager handle the storage

Page 138: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

118 IPTV Delivery Networks

resources accurately. Handling the storage resource is achieved by allo-cating the large-sized content according to the expectation of contentload and resource consumption. In the context of pricing, the networkmanager can draw his/her own content hosting pricing plan based onthe expected consumption of resources. Pricing plan is determined byunderstanding the content status and expected load.

In the replica placement arena, replicating the content accordingto the status (i.e., expected load) would avoid the storage resourceswaste, and, as a result, reduce the allocation cost and balance the load.For this reason, the current popularity-based algorithms may notwork well in the shared environments that host huge hybrid contentbelonging to different sources. Hence, building a content-awarereplica placement strategy that replicates the contents based on theanticipated load of both contents and servers is highly required.Furthermore, considering content status is important to achieveoptimal resource allocation scheme depending on replica placement.Particularly, the service provider has to control the resources alloca-tion according to the content status and the user demand to reducethe hosting cost [99] without affecting user satisfaction. Thus, thereplica placement problem should be integrated with the resourceallocation problem for the purpose of building content-aware IPTVdelivery networks. This integration allows the service provider toadjust the required resources according to the necessitated replicationscheme. Accordingly, Laoutaris, Zissimopoulos and Stavrakakis. [47]argue that the replica placement problem and resource allocationproblem should be solved jointly due to the dependency betweenthem. Moreover, considering the content status during the integrationgives the service providers the possibility to control the resources andcontent distribution according to the demand fluctuation, as well as,enables the delivery network to absorb the sudden load fluctuation.Therefore, building a content-aware resource allocation model thatconsiders content status to reduce the wastage of resources is anecessity.

4.5 Conclusion

Throughout this chapter, the state-of-the-art research on IPTVdelivery networks has been discussed. Besides, the main research

Page 139: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 119

challenges have been outlined. Request distribution, replica place-ment and resource allocation, the key problems threatening IPTVdelivery networks, have been surveyed. Furthermore, this chapterdiscusses the existing solutions and the open research issues for thethree aforementioned problems in light of content characteristics. Weshowed how content characteristics are more accurate than contentpopularity in judging the replication degree and resources allocation.Accordingly, we pointed out how the recent studies undertakenin modelling the content status based on content characteristicsare a new direction in IPTV delivery network design process. Webelieve that this research area will attract the attention of manyresearchers and that it will push one step further our ability todesign content-aware IPTV delivery networks, which will enable thecompromise between resources utilisation and the popularity/userpreferences for IPTV content.

References

Aldana Diaz, M.E. and Huh, E.N. (2011, February). Cost Analysis onIPTV Hosting Service for Third-Party Providers. In Proceedings of the5th International Conference on Ubiquitous InformationManagement and Communication (p. 114). ACM.

Alemany, J. and Thathachar, J. S. (1997). Random Striping News onDemand Servers. Dept. of Computer Science & Engineering,University of Washington, Technical Report -TR-97-02-02.

Belbekkouche, A., Hasan, M. and Karmouch, A. (2012). Resourcediscovery and allocation in network virtualization. CommunicationsSurveys & Tutorials, IEEE, 14(4), 1114–1128.

Bikfalvi, A., García-Reinoso, J., Vidal, I., Valera, F. and Azcorra, A. (2011).P2P vs. IP multicast: Comparing approaches to IPTV streaming basedon TV channel popularity. Computer Networks, 55(6), 1310–1325.

Bolosky, W.J., Barrera, J.S., Draves, R.P., Fitzgerald, R.P., Gibson, G.A.,Jones, M.B., Levi, S.P., Myhrvold, N.P. and Rashid, R.F. (1996). TheTiger Video Fileserver. Technical Report (MSR-TR-96-09), MicrosoftResearch.

Cardellini, V., Colajanni, M. and Philip, S. Y. (2002). Dynamic loadbalancing on web-server systems. Internet Computing, IEEE, 3(3),28–39.

Page 140: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

120 IPTV Delivery Networks

Casalicchio, E., Cardellini, V. and Colajanni, M. (2002). Content-awaredispatching algorithms for cluster-based web servers. ClusterComputing, 5(1), 65–74.

Cherkasova, L. and Ponnekanti, S.R. (2000). Optimizing a‘content-aware’ load balancing strategy for shared Web hostingservice. In Modeling, Analysis and Simulation of Computer andTelecommunication Systems, 2000. Proceedings. 8th InternationalSymposium on (pp. 492–499). IEEE.

Cho, D.H., Lee, K.Y., Choi, S.L., Chung, Y.D., Kim, M.H. and Lee, Y.J.(2008). A request distribution method for clustered VOD serversconsidering buffer sharing effects. Journal of Systems Architecture,54(1), 335–346.

Cidon, I., Kutten, S. and Soffer, R. (2002). Optimal allocation ofelectronic content. Computer Networks, 40(2), 205–218.

Dakshayini, M., Guruprasad, H.S., Maheshappa, H.D. and Manjunath,A.S. (2007, December). Load Balancing in Distributed VoD usingLocal Proxy Server Group [LPSG]. In Proceeding of InternationalConference on Computational Intelligence and MultimediaApplications 2007 (ICCIMA’ IEEE-07) (Vol. 4, pp. 162–168). IEEE,Sivakasi, Tamilnadu, India.

Du, Z., Hu, J., Chen, Y., Cheng, Z. and Wang, X. (2011). Optimizedqos-aware replica placement heuristics and applications in astronomydata grid. Journal of Systems and Software, 84(7), 1224–1232.

Dukes, J. and Jones, J. (2004). Using dynamic replication to manageservice availability in a multimedia server cluster. In InteractiveMultimedia and Next Generation Networks (pp. 194–205). SpringerBerlin Heidelberg.

Fati, S.M., Budiartu, R. and Sumari, P. (2014a). Fair and Popularitybased content allocation scheme for IPTV Delivery Networks.In International Journal of Computer Applications, 131(5),0975 – 8887.

Fati, S.M., Budiartu, R. and Sumari, P. (2014b, January). ProvisioningVirtual IPTV Delivery Networks Using Hybrid Genetic Algorithm. InProceedings of the 8th International Conference on UbiquitousInformation Management and Communication (p. 106). ACM.

Gaber, S.M.A. and Sumari, P. (2014). Predictive and content-aware loadbalancing algorithm for peer-service area based IPTV networks.Multimedia Tools and Applications, 70(3), 1987–2010.

Gafsi, J. and Biersack, E.W. (2000). Modelling and performancecomparison of reliability strategies for distributed video servers.

Page 141: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 121

Transactions on Parallel and Distributed Systems, IEEE, 11(4),412–430.

Ganger, G.R., Worthington, B.L., Hou, R.Y. and Patt, Y.N. (1993,January). Disk Subsystem Load Balancing: Disk Striping vs.Conventional Data Placement. In Proceeding of the Twenty-SixthHawaii International Conference on System Sciences, 1993, (Vol. 1,pp. 40–49), January 4–8, 1993, IEEE Computer Society, Maui, Hawaii.

García, R., Pañeda, X.G., Melendi, D. and Garcia, V. (2009). Probabilisticanalysis and interdependence discovery in the user interactions of avideo news on demand service. Computer Networks, 53(12),2038–2049.

Guo, J., Wang, Y., Tang, K. S., Chan, S., Wong, E. W., Taylor, P. andZukerman, M. (2008). Evolutionary optimization of file assignment fora large-scale video-on-demand system. Knowledge and DataEngineering, IEEE Transactions on, 20(6), 836–850.

Guruprasad, H.S. and Maheshappa, H.D. (2008). Dynamic load balancingarchitecture for distributed VoD using Agent Technology.International Journal of Computer Science & Security (IJCSS), 2(5),14–20.

Houidi, I., Louati, W., Ben Ameur, W. and Zeghlache, D. (2011). Virtualnetwork provisioning across multiple substrate networks. ComputerNetworks, 55(4), 1011–1023.

Huang, Y.F. and Fang, C.C. (2004). Load balancing for clusters of VODservers. Information Sciences, 164(1), 113–138.

Joe, I., Yi, J.H. and Sohn, K.S. (2012). A Content-Based Caching Algorithmfor Streaming Media Cache Servers in CDN . In Proceeding of:Multimedia, Computer Graphics and Broadcasting –InternationalConference, MulGraB 2011, Held as Part of the Future GenerationInformation Technology Conference, FGIT 2011, in Conjunction withGDC 2011, Jeju Island, Korea, December 8–10, 2011. Proceedings,Part I (pp. 28–36). Springer Berlin Heidelberg.

Joe, I., Yi, J.H. and Sohn, K.S. (2011). A content-based caching algorithmfor streaming media cache servers in cdn. In Multimedia, ComputerGraphics and Broadcasting (pp. 28–36). Springer Berlin Heidelberg.

Kanrar, S. (2012). Analysis and implementation of the large scalevideo-on-demand system. International Journal of AppliedInformation Systems, 1(4), 41–49.

Karlsson, M., Karamanolis, C. and Mahalingam, M. (2002, July). AFramework for Evaluating Replica Placement Algorithms, TechnicalReport HPL-2002, HP Laboratories.

Page 142: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

122 IPTV Delivery Networks

Khan, S.U. and Ahmad, I. (2008). Comparison and analysis of ten staticheuristics-based Internet data replication techniques. Journal ofParallel and Distributed Computing, 68(2), 113–136.

Kitjongthawonkul, S. and Ko, J. (2011, February). Using an EffectiveAlgorithm to Resolve the Video-On-Demand Service NetworkResource Allocation Problem. In Advanced CommunicationTechnology (ICACT), 2011 13th International Conference on(pp. 1031–1036). IEEE.

Laoutaris, N., Zissimopoulos, V. and Stavrakakis, I. (2005). On theoptimization of storage capacity allocation for content distribution.Computer Networks, 47(3), 409–428.

Lee, J.Y.B. and Wong, P.C. (2000) Performance Analysis of a Pull-BasedParallel Video Server, IEEE Transactions on Parallel and DistributedSystems, 11(12), 1217–1231.

Lee, S.B., Muntean, G.M. and Smeaton, A.F. (2009). Performance-awarereplication of distributed pre-recorded IPTV content. Broadcasting,IEEE Transactions on, 55(2), 516–526.

Li, M. and Wu, C.H. (2010). A cost-effective resource allocation andmanagement scheme for content networks supporting IPTV services.Computer Communications, 33(1), 83–91.

Lie, P.W., Lui, J.C. and Golubchik, L. (2000). Threshold-based dynamicreplication in large-scale video-on-demand systems. In ContinuousMedia Databases (pp. 31–58). Springer US.

Little, T.D. and Venkatesh, D. (1994, January). Probabilistic assignment ofmovies to storage devices in a video-on-demand system. In Networkand Operating System Support for Digital Audio and Video(pp. 204–215). Springer Berlin Heidelberg.

Loukopoulos, T. and Ahmad, I. (2004). Static and adaptive distributeddata replication using genetic algorithms. Journal of Parallel andDistributed Computing, 64(11), 1270–1285.

Mahmood, A. (2010). Replicating web contents using a hybrid particleswarm ptimization. Information Processing & Management, 46(2),170–179.

Meng, S., Liu, L. and Yin, J. (2013). A collaborative and scalable platformfor on-demand IPTV services. Services Computing, IEEE Transactionson, 6(3), 358–372.

Meng, S., Liu, L. and Yin, J. (2010, July). Scalable and ReliableIPTV Service through Collaborative Request Dispatching.In Web Services (ICWS), 2010 IEEE International Conferenceon (pp. 179–186). IEEE.

Page 143: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 123

Montpetit, M.J., Klym, N. and Blain, E. (2010). The future of mobile TV:When mobile TV meets the Internet and Social Networking. InMobile TV: Customizing Content and Experience (pp. 305–326).Springer London.

Montpetit, M.J., Klym, N. and Mirlacher, T. (2011). The future of IPTV.Multimedia Tools and Applications, 53(3), 519–532.

Moon, J., Moon, H.J. and Cho, Y. (2010, March). A history-basedscheduler for dynamic load balancing on distributed VOD serverenvironments. In Computational Science and Its Applications, TheInternational Conference (ICCS’10, Fukuoka, Japan, March 23–26,2010. Proceeding Part III (pp. 269–276). (Lecture Notes in ComputerScience; Vol. 6018). Springer Berlin Heidelberg.

Nafaa, A., Murphy, S. and Murphy, L. (2008). Analysis of a large-scaleVOD architecture for broadband operators: a P2P-based solution.Communications Magazine, IEEE, 46(12), 47–55.

Nakaniwa, A. and Ebara, H. (2007, March). Optimal Allocation of CacheServers and Content Files in Content Distribution Networks. InProceedings of IASTED European Conference on Internet andmultimedia systems and applications (IMSA’07) (pp. 15–22). ACTAPress Anaheim, CA, USA.

Neves, T.A., Drummond, L., Ochi, L.S., Albuquerque, C. and Uchoa, E.(2010). Solving replica placement and request distribution in contentdistribution networks. Electronic Notes in Discrete Mathematics, 36,89–96.

Nguyen, T., Safaei, F., Boustead, P. and Tung Chou, C. (2005).Provisioning overlay distribution networks. Computer Networks,49(1), 103–118.

Niu, D. (2013). Demand Forecast, Resource Allocation and Pricing forMultimedia Delivery from the Cloud. Doctoral dissertation. Universityof Toronto. CANADA.

Pai, V.S., Aron, M., Banga, G., Svendsen, M., Druschel, P., Zwaenepoel,W. and Nahum, E. (1998, October). Locality-aware requestdistribution in cluster-based network servers. ACM Sigplan Notices,ACM, 33(11), 205–216.

Pandey, S., Won, Y.J., Hong, J.W. and Strassner, J. (2011). DimensioningInternet Protocol television video on demand services. InternationalJournal of Network Management, 21(6), 455–468.

Pathan, A.M.K. and Buyya, R. (2007). A Taxonomy and Survey ofContent Delivery Networks. Grid Computing and Distributed SystemsLaboratory. Technical Report. University of Melbourne.

Page 144: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

124 IPTV Delivery Networks

Scheuermann, P., Weikum, G. and Zabback, P. (1998) Data partitioningand load balancing in parallel disk systems. VLDB Journal, 7(1):48–66.

Sharifian, S., Motamedi, S.A. and Akbari, M.K. (2008). A content-basedload balancing algorithm with admission control for cluster webservers. Future Generation Computer Systems, 24(8), 775–787.

Sharifian, S., Motamedi, S.A. and Akbari, M.K. (2011). A predictive andprobabilistic load-balancing algorithm for cluster-based web servers.Applied Soft Computing, 11(1), 970–981.

Sobe, A., Elmenreich, W. and Böszörmenyi, L. (2010). October. Towards aSelf-Organizing Replication Model for Non-Sequential Media Access.In Proceedings of the 2010 ACM Workshop on Social, Adaptive andPersonalized Multimedia Interaction and Access (pp. 3–8). ACM.

Sujatha, D.N., Girish, K., Venugopal, K.R. and Patnaik, L.M. (2008). Anefficient storage mechanism to distribute disk load in a VoD server.In Distributed Computing and Networking (pp. 478–483). SpringerBerlin Heidelberg.

Tang, K.S., Ko, K.T., Chan, S. and Wong, E.W. (2001). Optimal fileplacement in VOD system using genetic algorithm. IndustrialElectronics, IEEE Transactions on, 48(5), 891–897.

Tay, Y.C. and Pang, H. (2000). Load sharing in distributedmultimedia-on-demand systems. Transactions on Knowledge andData Engineering, IEEE, 12(3), 410–428.

Tenzakhti, F., Day, K. and Ould-Khaoua, M. (2004). Replicationalgorithms for the world-wide web. Journal of Systems Architecture,50(10), 591–605.

Teo, Y.M. and Ayani, R. (2001). Comparison of load balancing strategieson cluster-based web servers. The International Journal of the Societyfor Modelling and Simulation, 77(5–6), 185–195.

Thouin, F. (2007) Video-on-demand Equipment Allocation, Masterthesis, McGill University Montreal.

Thouin, F. and Coates, M. (2007). Video-on-demand networks: designapproaches and future challenges. Network, IEEE, 21(2), 42–48.

Wah, B. W. (1984). File placement on distributed computer systems.IEEE Computer, 17(1), 23–32.

Wang, Y. and Du, D. (1997) Weighted Striping in Multimedia Servers, theInternational Conference on Multimedia Computing and Systems(ICMCS ’97), IEEE Computer Society, Washington, DC, USA,pp. 102–119.

Page 145: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Content Awareness in IPTV Delivery Networks 125

Wauters, T., Coppens, J., De Turck, F., Dhoedt, B. and Demeester, P.(2006). Replica placement in ring based content delivery networks.Computer Communications, 29(16), 3313–3326.

Wolf, J. (1989). The placement optimization program: a practical solutionto the disk file assignment problem, Performance Evaluation Review,ACM, 17(1), 1–10.

Wong, E.M. (2004). Method for Estimating the Number of ConcurrentUsers, report. Retrieved from:http://wenku.baidu.com/view/68f1853a5802-16fc700afd74.html.

Xu, S. (2009). Replica Placement Algorithms for Efficient InternetContent Delivery. Doctoral dissertation, University of Adelaide.Australia.

Yarali, A. and Cherry, A. (2005, November). Internet Protocol television(IPTV). In TENCON 2005 2005 IEEE Region 10 (pp. 1–6). IEEE.

Zaman, S. and Grosu, D. (2011). A distributed algorithm for the replicaplacement problem. Parallel and Distributed Systems, IEEETransactions on, 22(9), 1455–1468.

Zhou, X. and Xu, C.Z. (2002, April). Request redirection and data layoutfor network traffic balancing in cluster-based video-on-demandservers. In ipdps (p. 0127). IEEE.

Zhou, X. and Xu, C. Z. (2007). Efficient algorithms of video replicationand placement on a cluster of streaming servers. Journal of Networksand Computer Applications, 30(2), 515–540.

Page 146: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

127

Part II

QoS and QoE for IPTV Delivery Networks

Page 147: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

129

5

Zapping Delay Reduction in IPTV SystemsAlireza Abdollahpouri

5.1 Introduction

Most TV viewers surf the channels to find a programme of interest.These surfing events happen more frequently during, for example,commercial advertisements or the half-time break of a soccer game.

IPTV service providers use multicast for transmitting TV channels.Due to the lack of network bandwidth in the last-mile access link, notall the channels can be transmitted at the same time. This limitationleads to a delay between two consecutive channel switches. In addi-tion, the dependency between frames in compressed video streams(using e.g., moving picture experts group (MPEG)-2) prevents the abil-ity of random access and prolongs the switching delay.

On the other hand, to make profit and satisfy subscribers, an IPTVservice provider has to provide at least the same (if not better) qual-ity of experience (QoE) in comparison with the already existing videodelivery schemes (e.g., cable or satellite). The most relevant aspects forQoE are:

• Video and audio quality• Audio to video synchronisation• Channel-switching delay (zapping delay)

The time between pushing the channel change button and the firstvideo frame being displayed on the TV along with the corresponding

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 148: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

130 IPTV Delivery Networks

audio is called zapping delay. Channel zapping delay is a fundamen-tal requirement for the user’s QoE. Although it seems to be a naturalrequirement from a subscriber’s perspective, providing this function-ality can be problematic for network operators.

The problem is essentially more serious in point-to-point (P2P)IPTV systems, because the dynamic nature of P2P networks requireslarger buffers and the exchange of more signalling messages toestablish the overlay structures (Manzato and da Fonseca, 2013).

Zapping time is influenced by various elements on the end-to-endtransmission path, such as:

1. The frequency of I-frames2. Reordering delay3. Size of video buffer in set-top box (STB)4. Programme association table (PAT) and programme map table

(PMT) frequency5. Multicast leave and join times6. The delay of access link7. STB de-jitter buffer8. Conditional access and digital rights management system

(CA/DRM)9. Packet recovery with forward error correction (FEC)/automatic

repeat request (ARQ)10. Processing time in the STB11. Processing time in display device

In general, there is a trade-off to be made between video quality, datarate and zapping time when configuring the first four parameters of theabove-mentioned list. The factors 5–7 (multicast leave and join times,the size of STB jitter buffer and access link delay) depend on the under-lying network. Factor 8 is responsible for providing content protectionand revenue protection (blocking access from unauthorised users) forTV channels. In the case of packet loss, FEC or ARQ techniques canbe deployed to recover lost packets. Both schemes will increase thezapping time. Finally, the processing time of the STB as well as theadditional processing steps in the display device contribute to the over-all zapping time.

MPEG and de-jitter buffering and waiting time to receive the I-frameare the main factors of channel-zapping delay.

Page 149: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 131

5.2 A Review of the Existing Studies

Recently many research efforts have been devoted to reduce thechannel-zapping delay in IPTV systems. In general, the proposedsolutions can be categorised as follows:

5.2.1 Reduce I-Frame Acquisition Delay

As mentioned above, I-frame acquisition delay is the most prominentfactor in channel zapping. To reduce the waiting time for receivingan I-frame, the service providers can use an additional companionstream beside the original stream. Other solutions can be insertingextra I-frames to the main stream or reducing the size of the group ofpictures (GOP).

5.2.1.1 Use Additional StreamIn this method, a dedicated companion stream is used to reduce thechannel change response time. A STB that tunes to a specific chan-nel also receives the companion stream at the same time. As soon asthe first I-frame arrives (either from the additional or original stream),the STB starts decoding the video. The additional stream can be a uni-cast transmitted stream or a stream that is transmitted by means ofmulticast.

Cisco White Paper (2013) proposed a visual quality of experience(VQE) appliance for x digital subscriber line (xDSL)–based IPTVsystems, which uses I-frame caching and unicast bursts to accel-erate channel-switching time. Lin et al. (2009) proposed anotherunicast-based method that distributes an additional media streamstarting with a key frame (to reduce I-frame acquisition delay). How-ever, because of the correlation in channel-switching events (e.g., dur-ing commercial advertisements), unicast-based schemes lead to spikesin the network load. To prevent such an impulsive load, Banodkar et al.(2008) and Sasaki et al. (2008) used multicast-based approaches (usingan additional multicast stream instead of an additional unicast burst).

This additional companion stream can be one of the following cases,as can be seen in Figure 5.1:

a) A stream of only I-frames with lower quality and higher frequency(e.g., Banodkar et al., 2008)

Page 150: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

132 IPTV Delivery Networks

(a) Additional stream of only

I-frames

(b) Time-shifted copy of the

original stream

I-frame B-frame P-frame

Figure 5.1 Companion stream to reduce zapping delay.

b) Time-shifted copy of the original stream (e.g., Tian, Cheng andShen, 2013)

5.2.1.2 Inserting Extra I-Frames and Reduction in the Size of GOPTo increase the frequency of I-frames in the TV stream and hence byreducing the I-frame acquisition delay, extra I-frames can be insertedinto the original stream.

Joo et al. (2008) proposed a method to insert extra I-frames intothe channels based on the user’s channel preference information. Theytried to pursue an effective trade-off between channel-zapping timeand network efficiency. However, this method reduces compressionefficiency.

Uzunalioglu (2009) tried to adjust the GOP duration to decreasechannel change delay. He argued that the delay requirement can be metby choosing a suitable GOP length. More precisely, shorter GOPs notonly reduce the I-frame acquisition delay but also decrease the encod-ing efficiency, resulting in higher bit-rate for the encoded stream. Heevaluated different GOP lengths (i.e., with the sizes of 6, 12, 24 frames)to determine the number of streams that can be transmitted concur-rently via a link without violating the QoS objectives. According to hissimulation results, the number of streams that can be supported bythe link is very similar for GOP lengths of 12 and 24 frames. With theGOP length of 6 frames, the link supports one less video stream.

To summarise, although the techniques described previously canshorten the channel-switching delay, all of them need a higher band-width in the network. Another important drawback is the necessity ofchanges in the encoder and decoder sides.

Page 151: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 133

5.2.2 Prediction-Based Mechanisms

Prejoining or predictive tuning is another technique in which one ormore channels (those which are likely to be selected next) are prejoinedand pre-buffered in addition to the channel being watched to reducechannel-zapping time.

Because the most channel-switching events are sequential (using‘up’ and ‘down’ buttons on the remote control), the simplest predictionmethod is to prejoin the neighbouring channels as shown in Figure 5.2.If the prediction is correct, for the next channel-switching event, thedelay is virtually zero, because the desired channel is already bufferedand ready to be decoded.

Oh, Lim and Bahn (2010) presented various hybrid channelprefetching and reordering schemes and showed that the adjacentchannel-prefetching scheme has better performance than the popularchannel-prefetching scheme no matter what reordering scheme isused. A rating server is proposed in Lee et al. (2007), which gathersinformation about channel-change events from STBs and managesstatistics for each STB (which, of course, could lead to privacyproblems). Based on those statistics, a list of channels is predicted,and therefore, the user experiences low zapping delay when selectingthose channels. A survey of prediction-based methods to reducechannel zapping is presented by Ahmad et al. (2009). In Lee et al.(2010), Kim et al. (2008) and Abdollahpouri and Wolfinger (2012), theauthors try to predict the channels based on the surfing behaviour ofIPTV subscribers.

Khosroshahi, Yousefi and Rahbar (2015) proposed two algorithms(Packet Gateway Control Protocol (PGCP) and P-PGCP) based on

IPTV

head-end

Core and distribution

networks

ISP

IP backbone

Access

network Subscriber

Request for channel 3

Send channels 2, 3, 4

Figure 5.2 Channel prejoining to decrease zapping delay.

Page 152: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

134 IPTV Delivery Networks

the favourite channels whose scores exceed a predefined threshold arepre-fetched in a low-quality format. They take subscribers’ behavioursinto account.

5.2.3 Techniques Based on Scalable Video Coding

Scalable video coding (SVC) schemes are used to adapt bit-streamto the various needs of end-users, varying terminal capabilities ornetwork conditions. Another application scenario of SVC is forrapid channel-switching. Lee et al. (2008) allocated the base layerand enhancement layer of each channel to two separate multicastgroups. For example, assume having four TV channels, each of whichis composed of one base layer Bi and one enhancement layer Ei asshown in Figure 5.3. The base layers of a collection of candidatechannels are stored in the buffer. Channel switching in preview modeoccurs immediately because users access the base layers withoutdelay. In watching mode, both the base and enhancement layers of theselected channel are used to achieve full quality.

A combination of prejoining and SVC to reduce zapping delay isused by Lee, Hong and Lee (2010).

5.2.4 Techniques Based on IGMP Schemes

Some of the researchers try to influence network factors such aslatency in the access network by enhancing Internet Group Manage-ment Protocol (IGMP) features (e.g., reducing the number of IGMPmembership queries, join before leave and snooping). Sarni, Hilt

Watching

mode

E1 E2

E3 E4

B4

B2B1

B3

Preview

mode

Figure 5.3 Scalable video coding(SVC) to decrease zapping delay.

Page 153: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 135

and Lorenz (2009) suggested sending an IGMP-join message for therequested channel before leaving the channel being currently watchedby sending an IGMP-leave message. Lee et al. (2010) proposed anew extended IGMP for mobile WiMAX networks. Their proposedextended IGMP involves classifying multicast packets, updating theIPTV channel table and managing channel control in the networklayer.

Figure 5.4 summarises some of the most important methodsused for reducing channel-switching delay. In the following, wetry to reduce the average switching (zapping) delay by mixing twomechanisms: (1) a combined multicast/unicast transmission of TVchannels and (2) prediction-based prejoining. Taking advantage ofmulticast support of WiMAX and considering the minimum slotrequirement, one or two channels that are likely to be selected nextwill be prejoined. Prejoining is only applied for unicast channels andin the surfing period. The main differences between this study andother prediction-based methods are twofold: We focus on WiMAXnetworks while other studies are for DSL-based access networksand we combine prediction-based prejoining with multicasting mostpopular channels to reduce zapping delay. Note that, in this chapter,prejoining is not in the sense of multicast joining but in the sense ofpre-requesting.

Methods to reduce

channel zapping time

Reduce I-frame

acquisition delay

Adjust GoP

length

Insert extra

I-frames

Use additional

stream

Unicast

stream

Multicast

stream

Using scalable

video coding (SVC)Prediction and

prejoining methods

Using IGMP

schemes

Figure 5.4 Categorisation of zapping delay reduction schemes.

Page 154: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

136 IPTV Delivery Networks

5.3 Prediction-Based Prejoining Methodin WiMAX Networks

Taking advantage of the mobile base station/broadcasting station(MBS) support in WiMAX, the bandwidth requirement for TVchannels reduces from one burst per viewer to one burst per TVchannel. The TV channels that are transmitted by means of MBScan be accessed by all subscribers and the switching delay for thesechannels is much shorter than that for unicast transmitted channels.

A WiMAX cell with seven IPTV users is depicted in Figure 5.5.The numbers beside the stations indicate the TV channel each user isalready watching (at an instant of time). In this example, three usersare watching Channel 1 and two others are watching Channel 2. TVChannels 3 and 4 are watched by only one user. Channels 1 and 2 aretransmitted by means of multicast using multicast bursts. Unicastbursts are used for TV Channels 3 and 4. The number of data bursts(unicast and multicast) is equal to four. Note that because Channel 3is watched by a user who is close to the base station (BS) (with goodsignal condition), the resource requirement (number of OFDMAslots) is lower.

The steps involved in channel switching depend on the networkinginfrastructure and the location of the requested channel. For instance,if the channel is available at the BS, then the delay is shorter than whenthe channel must be requested from the MBS server.

Switching to an MBS channel, involves a shorter delay in compar-ison to switching to a unicast channel. Because, in the former case,

DL-subframe

Ch4FCH

DL

MAP

UL

MAP Unicast bursts

Ch3

Ch2

Ch1

Multicast bursts

MB

S-M

AP

Pre

am

ble

MBS region4

21

2

3

1

1MCID1

MC

ID1

CID

4

CID3

MC

ID2

MCID2

MC

ID1

Figure 5.5 Multicast and unicast in a WiMAX cell.

Page 155: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 137

channel-switching time only consists of the delay to wait for the nextburst on the target MBS stream and buffering it in the MS to avoidunderflow and remove the jitter. In the latter case however, the MSshould at first obtain bandwidth to transmit the channel-changerequest (in the MAC and IP level). This is a random backoff-basedcontention mechanism and happens during the contention period inthe uplink sub-frame. For example, if the user in Figure 5.5, who iswatching Channel 4 wants to switch to Channel 2, as this channel isbeing transmitted in the MBS region, the switching delay is shorterthan in the case when the user wants to switch to Channel 3.

If the channel-change request is accepted by the BS, after schedulingthe requested channel, the BS advertises the position of the unicastbursts via DL-MAP. Thereafter, the MS should decode the MAP andfind the location of the desired burst. Finally, after a buffering delay,the first picture of the new channel is displayed.

Note that the optimisation techniques that have been explored inthe wired IPTV domain (e.g., a separate tune-in stream or predictionprejoining) can also be adapted for WiMAX MBS.

The ITU-T FG IPTV group is recommending that the time taken bythe channel-switching process should not exceed 2.5 s.

Using the Zipf-like distribution of the popularity of TV channels andconsidering what we discussed in Abdollahpouri and Wolfinger (2011)regarding the minimisation of the number of required overhead slots,a combined unicast/multicast transmission can be useful to decreasethe average switching delay.

Before turning to our proposed method, we need some knowledgeabout the workload. Such workloads are usually derived from mon-itoring a real IPTV system (which is of course time-consuming andcostly). To generate the workload, we model the switching behaviourof a typical IPTV user.

5.3.1 Modelling the Behaviour of a Single IPTV User, Duringan ON Session

The behaviour of an IPTV user is different from the users of otherIP-based applications. Figure 5.6 illustrates the typical behaviour ofan IPTV user during an ON period (active session). In this figure,switching events performed by the user during the peak hour (here,9 PM to 10 PM) are depicted. A switching event occurs when a userselects a new TV channel. Several switching events with a certaininter-arrival time (e.g., less than 10 s) show that the user is zapping

Page 156: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

138 IPTV Delivery Networks

20 min

18 min

15

8

5

Sw

itchin

g e

vent num

ber

9:00 9:10 9:20 9:30 9:40 9:50 10:00

Watched channel

Zapped channel

Time

vzvzvz

Figure 5.6 Channel zapping (z) and viewing (v).

TV channels to find something of interest. The number of channelsswitched prior to viewing is called a zapping block. For example, threezapping blocks with the sizes of 4, 2 and 6 can be seen in the figureduring the 1−h time interval. Note that the channels being actuallywatched during a long time period are not included in the zappingblock. The user experiences a sequence of zapping periods followedby viewing periods. The user is in watching state whenever there is noswitching event during a relatively large amount of time. Modellingand analysing this different type of workload can help IPTV serviceproviders in the design process or after the implementation processto evaluate several ‘what-if’ scenarios.

Depending on the next channel chosen, channel switching is consid-ered to be sequential or targeted. In the sequential channel switching,the user chooses the next channel using UP and DOWN buttons on theremote controller. Targeted switching represents the cases in whichthe user chooses the desired channel directly by pressing the channelnumber or using electronic programme guide (EPG).

During a commercial advertisement or, for example, betweenhalf-times of a football match, most users change the channel tofind a more favourite programme. In other words, channel-switchingbehaviour of the viewers may be correlated.

There exist some problems to be considered in the modelling of theuser behaviour. In general, the following three main questions shouldbe answered.

1. How many channels does a user surf on average before viewing (sizeof zapping block)?

Page 157: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 139

2. Which channels are a user watching or surfing (access pattern –channel number)?

3. When do channel-change events happen (channel dwell time inviewing or zapping modes)?

In Abdollahpouri et al. (2011), we introduced our model to coverboth channel popularity and user activity, in an IPTV system for asingle typical IPTV user. The proposed user behaviour automaton(TV-UBA) to model zapping and viewing periods of Figure 5.6 isdepicted in Figure 5.7. According to our model, after turning theSTB on state Si, the subscriber starts zapping channels with theprobability of pz or watches a channel with the probability of 1−pz.In zapping mode, the user may surf one or more channels beforeviewing (zapping block). Each state indicates the number of successivechannel-switching events. For example, state Z3 means surfing threechannels before watching. The user returns to viewing mode aftereach zapping block. In viewing mode, after watching a specificchannel, the viewer may terminate watching with probability pt, viewanother channel or start surfing another set of channels. Interestedreaders can refer to Abdollahpouri et al. (2011) for more detailedinformation about viewing and zapping states.

We used the LoadSpec tool (Kolesnikov, and Heckmüller 2008) toformally describe and thereafter simulate our model. A sample out-put of our model is shown in Figure 5.8. Zapping blocks and view-ing time are clearly distinguishable. In this figure, the user first surfs

Viewing

Zapping

VIEW

1–Pz

1–P

z–P

t

1–P1.21–P2.3

p1.2p2.3

Z2

Z3

Z4

Pz

Z1

Pt

Si

St

Figure 5.7 User behaviour automaton for IPTV user (TV-UBA) (Abdollahpouriet al., 2011).

Page 158: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

140 IPTV Delivery Networks

Figure 5.8 Output of the TV-UBA model in LoadSpec tool (Abdollahpouri et al.,2011).

three channels (zap block with size three) and then starts watchingthe fourth channel. After termination of the corresponding viewingperiod, the user browses five channels and finds the sixth channel ofinterest.

According to Cha et al. (2008), about 60% of channel-changerequests are sequential. In other words, more users prefer to switchchannels using ‘up’ and ‘down’ buttons on the remote control. There-fore, in sequential switching, the next requested channel would be anadjacent channel. The rest of the switching events are called targetedswitching, in which choosing the next channel only depends on thewatching probability of the destination channel.

Based on the preceding information, instead of just prejoiningneighbouring channels, we propose a more intelligent prejoiningmethod (to prejoin one or two channels), which considers thechannel-switching behaviour of a typical IPTV user, as follows (thecurrently requested channel is Ci):

• Prejoin1 (Ci) =⎛⎜⎜⎜⎝Cj; | j- i | ≥ 2; with probability pta ⋅ p(Cj)Ci+1; with probability pseq ⋅ pu + pta ⋅ p(Ci+1)Ci-1; with probability pseq ⋅ (1-pu) + pta ⋅ p(Ci-1)

• Prejoin2 (Ci) = Ci+1

where:

p(Ci): watching probability of TV channel Ci.pta: Probability of targeted switchingpseq: Probability of sequential switching, where pseq=1 − ptapu: Probability of sequential UP switching

Page 159: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 141

pta·p(C1)pta·p(Ci)

pta·p(Ci–2)

pta·p(Ci+2)

pta·p(Cmax)

pseq·(1–pu) + pta·p(Ci–1)

pseq·pu + pta·p(Ci+1)

Ci–2 Ci–1 Ci+1 Ci+2 CmaxCiC1

Figure 5.9 Prejoin1 (Ci) probability state diagram; Cmax = 50.

Here, Prejoin1 is a method that predicts the next channel based onstatistics obtained from the switching behaviour of users in a real IPTVsystem.

The probability state diagram for Prejoin1 is given in Figure 5.9. Inthe figure, Cmax defines the maximum number of offered TV channels.Whenever Ci+1 is larger than Cmax, evidently Ci+1 has to be replacedby C1 (we omit this in the text in favour of better readability). Pre-join2 always predicts the next upper channel for prejoining. Therefore,one or two channels will be prejoined depending on whether the pre-joined channels are the same or not. Also, with probability pta⋅p(Ci),the method Prejoin1 will not recommend any channel to prejoin, inwhich case, only channel Ci+1 will be prejoined (according to methodPrejoin2). Note that prejoining is performed only for unicast channels.

Let us take a simple example to explain the prediction-based pre-joining method. In Figure 5.10, a part of the trace for an IPTV user isshown, which consists of two zapping blocks and one viewing period.The numbers above the arrows indicate requested channels. For thesake of simplicity, assume channels are sorted by the descending orderof popularity (Channel 1 is the most popular channel). If, for example,the five most popular channels are transmitted by means of multicast,the user experiences a shorter switching delay for these channels. Tak-ing this example and assuming the scenario illustrated by Figure 5.9,Table 5.1 indicates the prejoined channels and channel-change delay

Zapping

21

ZappingTime

Viewing

12 22 8 4 9 10 11 31 2

Figure 5.10 Channel-switching events over a period of time.

Page 160: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

142 IPTV Delivery Networks

Table 5.1 An example of zapping delay reduction with prejoining.

21 12 22 8 4 9 10 11 31 2

U U U U M U U U U Mx 22 x 3 x 13 11 16 12 xx 13 x 9 x 10 11 12 32 xT

M/U

RequestedChannel

Prejoin 1Prejoin 2Delay T 0 T t T T 0 T t

in each switching event (‘T’ represents long delay and ‘t’ is used to indi-cate short delay).

If the requested channel is correctly predicted and prejoined, theswitching delay is virtually zero (at the time of switching, the newchannel is already buffered and ready to decode). Note that the firstchannel-switching (if unicast) suffers a long delay because there is noprediction mechanism yet. For the third channel-switching (Channel22), switching delay is zero because this channel is predicted andprejoined previously (by Prejoin1). This is also happening in theeighth switching event when both prejoined formulas predict the nextchannel correctly (in this case only one channel is prejoined, which isChannel 11).

To save valuable bandwidth, the prejoined channels will be releasedin viewing mode (when the channel dwell time is longer than 30 s).Therefore, at the seventh event, although Channel 10 is predicted andprejoined correctly, because of staying in viewing mode in the previouschannel, the switching delay is long.

In this example, the average zapping delay is equal to (6T+2t)/10.

5.4 Performance Evaluation

A trace-driven simulation is conducted to evaluate the performanceof the proposed prejoin method. For this purpose, a dedicated simu-lation programme was implemented by us using C++ programminglanguage.

The simulation scenario depicted in Figure 5.11 is composed of aWiMAX cell and 30, 60 IPTV users. The MBS server has access to allchannels and handles the TV requests of IPTV users on behalf of theIPTV head-end.

Page 161: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 143

ISP Backbone

IPTV

head-end

Video

source

MBS server

ASN-GW

MS

MS

BSSS

Home

gateway

STB

Channel rank

Zipf with parameter

Ω = 0.2222622

Po

pu

larity

Figure 5.11 WiMAX network with MBS server.

Similar to that in the previous chapters, we use Zipf-like distributionwith Equation (5.1) to model the watching probability of TV channels.

p(Ci) =Ωiα, where Ω =

( C∑j=1

1jα

)−1

; 0 < α ≤ 1; (5.1)

With the assumption of shaping parameter α = 1 and having 50 TVchannels (C = 50), the scaling parameter Ω is equal to 0.2222622. Wealso assume pseq = 0.6 and pu = 0.7 (Cha et al., 2008).

We elaborated the effects of overhead slots in WiMAX-based IPTVsystems in Abdollahpouri and Wolfinger (2011) (using both analyticaland simulation methods) and showed that with the right combinationof multicast and unicast TV channels and a proper scheduling pol-icy, the overhead can be significantly reduced. The total number ofrequired slots (data bursts plus overhead slots) for the cases of 30 and60 users is shown in Figure 5.12.

For the case in which 30 IPTV users exist in the cell, multicasting thefour most popular channels can lead to minimum slot requirement.When 50 users are served, the six most popular channels should betransmitted by means of multicast to expend the minimum number ofslots when providing the IPTV service. This value is 10 when 70 usersare inside the WiMAX cell.

As a consequence of the low-resolution quality assumed in thischapter for the display devices, one MBS burst will typically containseveral GOPs, and therefore, there will be more than one I-frame in

Page 162: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

144 IPTV Delivery Networks

1200

1000 30 users

50 users

70 users

800

600

Re

qu

este

d s

lots

pe

r fr

am

e

400

200

01 4 7 10 13 16 19 22 25

No. of multicast channels

28 31 34 37 40 43 46 49

Figure 5.12 Required slots when multicasting N most popular channels andunicast the rest of the requested channels (N = 1, …, 50).

the MBS burst. Hence, for WiMAX MBS, we do not need to accountfor an I-frame acquisition delay.

We perform the simulation for the cases where the first N chan-nels are transmitted by means of MBS (varying N = 1,…, 10). We alsoassume a target-switching delay of 2.5 s for unicast (T = 2.5) and 0.5s for multicast (t = 0.5). For each user, a 10-h trace is obtained froman existing TV-UBA model. Note that, we use the term ‘trace’ in itsgeneral sense, that is, not only referring to measured data but also todata obtained from our TV-UBA model.

Each entry of the trace includes the following information:

• Timestamp• Type of event (i.e., request for channel – start watching – terminate

watching)• Number of the requested channel (when event is request for

channel)

The flowchart of the simulation is depicted in Figure 5.13. The aver-age zapping delay with and without prediction is calculated for eachuser. The results are shown in Figure 5.14.

Page 163: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 145

Count = 0

Zap_time = t

Total_zap = Total_zap+ Zap_time

Count = Count + 1

Zap_time = T

Trace isfinished?

Average_zap =

Total_zap/Count

N

Stop

Zap_time = 0

Y N

N

Y

Read the next requested

channel in the trace (Cn)

Cn is in MBS?Cn is

Prejoined?

Prejoin1 (Cn)

Prejoin2 (Cn)

Start

Figure 5.13 Simulation flowchart.

The improvement in average zapping delay is between 33% and28% for multicasting one to ten most popular channels as shown inFigure 5.14. Considering the minimum overhead and slot require-ment (which means that, here, multicasting the top four channelsis the optimum decision), an improvement of about 30% in averagechannel-zapping delay is obtained.

We repeated the simulation for different user behaviours (differenttraces) and obtained similar results.

Total delay reduction is a combination of the following two factors(see Figure 5.14):

a) Reduction obtained from multicasting N most popular channels(efficiency of multicasting)

b) Reduction obtained from prejoining mechanism (efficiency ofprejoining)

Page 164: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

146 IPTV Delivery Networks

0.00

0.50

1.00

1.50

2.00

2.50

1 2 3 4 5 6 7 8 9 10

Ave

rag

e z

ap

pin

g t

ime

(s)

Number of most popular channels being multicast

Average delay w/o prejoining

Average delay with prejoining(a)

(b)

Figure 5.14 Average zapping delay with and without prejoining (95% confidenceintervals).

As can be seen in Figure 5.14, the efficiency of multicasting increaseswith the increment of the number of multicast channels and thisclearly makes sense (the size of the (a)-arrow increases). But for theefficiency of prejoining, a gradual decrement can be seen. The size ofthe (b)-arrow decreases with the increment of the number of channelsbeing multicast.

To calculate the percentage of successful prejoins, we analysedthe switching behaviour of a typical user and the predicted channelsobtained by Prejoin1 and Prejoin2. The results are as follows:

• Total number of switching events (in a 10-h trace): 372• Number of prejoining channels (both Prejoin1 and Prejoin2) = 137• Number of successful prejoins: 62

Therefore, the percentage of successful predictions is about 45%. Werepeated the analyses for some other user behaviour patterns and thisvalue is almost the same.

5.5 Future Directions for Research

Although many research efforts have been devoted to reducechannel-switching delay, there still exist many directions that can

Page 165: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 147

be investigated in the future. For instance, more intelligent methodsusing machine-learning techniques can be used to discover thebehaviour of users. In addition, using real datasets of IPTV users canlead to more realistic results.

Moreover, because IPTV is a technology driven by service providers,it may be desirable (or required) to implement the channel-changeprocedure strictly at the network infrastructure with the aid of ded-icated servers. Therefore, it is also necessary to investigate scalableserver-driven solutions to achieve that objective.

Another issue to be considered is the treatment with heavy zappers.An organised group of heavy zappers can significantly degrade theperformance of or ‘kill’ an IPTV system. Because frequent leave/joinoperations will lead to frequent changes of multicast trees and imposeextra load on the network. Sequential switching (during zapping) iseven much more dangerous than targeted switching. Heavy zapperscould result in denial-of-service (DoS) attacks for IPTV systems, andtherefore, should be punished in some way.

5.6 Conclusion

In this chapter, we analysed the factors that affect the channel-switching delay in IPTV systems and investigated different pro-posals and methods to reduce this delay. Thereafter, based on ourprevious studies on modelling switching behaviour of IPTV usersand slot requirement for different multicast/unicast combinations,we proposed a prediction-based prejoin mechanism to shortenchannel-zapping delay during surfing periods. Taking advantage ofthe Zipf-like distribution of the watching probability of TV channelsand the multicast support in WiMAX networks, two mechanismswere successfully used to reduce channel-zapping delay: Combinedmulticast/unicast transmission of TV channels and prediction-basedprejoining. Simulation results confirm that with the consideration ofminimum slot requirement, quite a significant improvement of about30% zapping time can be obtained.

References

Abdollahpouri, A. and Wolfinger, B.E. (2011, October). Overheadanalysis in WiMAX-based IPTV systems. In Ultra Modern

Page 166: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

148 IPTV Delivery Networks

Telecommunications and Control Systems and Workshops (ICUMT),2011 3rd International Congress on (pp. 1-8). IEEE.

Abdollahpouri, A., Wolfinger, B.E., Lai, J. and Vinti, C. (2011).Elaboration and formal description of IPTV user models and theirapplication to IPTV system analysis. MMBnet.

Abdollahpouri, A. and Wolfinger, B.E. (2012, March). Reducing channelzapping delay in WiMAX-Based IPTV systems. In InternationalGI/ITG Conference on Measurement, Modeling, and Evaluation ofComputing Systems and Dependability and Fault Tolerance(pp. 182–196). Springer Berlin Heidelberg.

Ahmad, M.Z., Qadir, J., Rehman, N.U., Baig, A. and Majeed, H. (2009,October). Prediction-based channel zapping latency reductiontechniques for IPTV systems – A survey. In Emerging Technologies,2009. ICET 2009. International Conference on (pp. 466–470). IEEE.

Banodkar, D., Ramakrishnan, K.K., Kalyanaraman, S., Gerber, A. andSpatscheck, O.(2008, January). Multicast instant channel change inIPTV systems. In Communication Systems Software and Middlewareand Workshops, 2008. COMSWARE 2008. 3rd InternationalConference on (pp. 370–379). IEEE.

Cha, M., Rodriguez, P., Crowcroft, J., Moon, S. and Amatriain, X. (2008,October). Watching television over an IP network. In Proceedings ofthe 8th ACM SIGCOMM conference on Internet measurement(pp. 71–84). ACM.

Cisco White Paper. (2013). Delivering Video Quality in Your IPTVDeployment.

Joo, H., Song, H., Lee, D.B. and Lee, I. (2008). An effective IPTV channelcontrol algorithm considering channel zapping time and networkutilization. IEEE Transactions on Broadcasting, 54(2), 208–216.

Khosroshahi, A.A., Yousefi, S. and Rahbar, A.G. (2015). IPTV channelswitching delay reduction through predicting subscribers’ behaviorsand preferences. Multimedia Tools and Applications, pp. 1–20.

Kim, Y., Park, J.K., Choi, H.J., Lee, S., Park, H., Kim, J., Lee, Z. and Ko, K.(2008, March). Reducing IPTV channel zapping time based onviewer’s surfing behavior and preference. In 2008 IEEE InternationalSymposium on Broadband Multimedia Systems and Broadcasting(pp. 1–6). IEEE.

Kolesnikov, A. and Heckmüller, S. (2008). LoadSpec-ein E-LearningWerkzeug zur Lastspezifikation im Bereich der Telematik. E-LearningBaltics, eLBa.

Page 167: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Zapping Delay Reduction in IPTV Systems 149

Lee, C.Y., Hong, C.K. and Lee, K.Y. (2010). Reducing channel zappingtime in IPTV based on user’s channel selection behaviors. IEEETransactions on Broadcasting, 56(3), 321–330.

Lee, E., Park, S., Lee, J. and Lau, P.Y. (2010, June). An Extended IGMPProtocol for Mobile IPTV Services in Mobile WiMAX. InInternational Conference on Mobile Wireless Middleware, OperatingSystems, and Applications (pp. 413–426). Springer Berlin Heidelberg.

Lee, J., Lee, G., Seok, S. and Chung, B. (2007). October. Advancedscheme to reduce IPTV channel zapping time. In Asia-Pacific NetworkOperations and Management Symposium (pp. 235–243). SpringerBerlin Heidelberg.

Lee, Y., Lee, J., Kim, I. and Shin, H. (2008). Reducing IPTV channelswitching time using H. 264 scalable video coding. IEEE Transactionson Consumer Electronics, 54(2), 912–919.

Lin, J., Lei, W., Bai, S. and Li, L. (2009, October). The Implementation ofFast Channel Switching in IPTV. In Intelligent ComputationTechnology and Automation, 2009. ICICTA’09. Second InternationalConference on (Vol. 4, pp. 684–688). IEEE.

Manzato, D.A. and da Fonseca, N.L. (2013). A survey of channelswitching schemes for IPTV. IEEE Communications Magazine, 51(8),120–127.

Oh, U., Lim, S. and Bahn, H. (2010). Channel reordering and prefetchingschemes for efficient IPTV channel navigation. IEEE Transactions onConsumer Electronics, 56(2), 483–487.

Sarni, M., Hilt, B. and Lorenz, P. (2009, April). A Novel ChannelSwitching Scenario in Multicast IPTV Networks. In Networking andServices, 2009. ICNS’09. Fifth International Conference on(pp. 396–401). IEEE.

Sasaki, C., Tagami, A., Hasegawa, T. and Ano, S. (2008 May). RapidChannel Zapping for IPTV Broadcasting with Additional MulticastStream. In 2008 IEEE International Conference on Communications(pp. 1760–1766). IEEE.

Tian, X., Cheng, Y. and Shen, X. (2013). Fast channel zapping withdestination-oriented multicast for IP video delivery. IEEETransactions on Parallel and Distributed Systems, 24(2), 327–341.

Uzunalioglu, H. (2009 January). Channel change delay in IPTV systems.In 2009 6th IEEE Consumer Communications and NetworkingConference (pp. 1–6). IEEE.

Page 168: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

151

6

Channel-Zapping Time in IPTV: Challenges andSolutionsSajjad Zare, Seyyed Mohammad Hosseini Verki and AkbarGhaffarpour Rahbar

6.1 Introduction

Channel-zapping time is one of the most important factors for thequality of experience (QoE) metric in IPTV services. Channel-changelatency is determined as the time difference between pressing somebuttons on a remote control and the moment of displaying the firstframe of the ordered channel on the TV screen. In other words, thetime it takes to play a new TV programme from requesting a channelchange is called zapping time, which is a critical QoE metric for IPTVsystems (Tian, Cheng and Shen, 2013).

Unlike analogue TVs, channel-zapping latency rises because of therequirement of audio/video data buffering, decoding at set-top box(STB) and other additional signalling information in IPTV. To guar-antee interactivity and acceptable QoE, the channel-zapping latencymust be under 2 s. In this chapter, we study the different methods pro-posed to reduce channel-zapping time in IPTV.

6.1.1 IPTV Network Infrastructure

The IPTV system structure includes four domains (Zeadally, Moustafaand Siddiqui, 2011):

• Customer domain: To present services to end-users• Network provider domain: To provide a connection between the

customer’s domain and the service provider’s domain

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 169: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

152 IPTV Delivery Networks

• Service provider domain: To provide services to customers• Content provider domain: To produce content

In the following, we discuss the architecture of the basic IPTV sys-tem, IP multicasting and peer-to-peer (P2P) communication (i.e., anetwork of computers configured to allow certain files and folders tobe shared with everyone or with selected users).

6.1.1.1 Basic IPTV SystemThe basic architecture of the IPTV system is illustrated in Figure 6.1.The main elements of a typical IPTV system are:

• Acquisition servers: They encode video and add digital rights man-agement (DRM) metadata, where DRM denotes various access con-trol technologies that are used to restrict the usage of proprietaryhardware and copyrighted works.

• Distribution servers: They provide caching and QoS control• Video on demand (VoD) creators and servers: They keep a library

of encoded VoD contents to provide VoD services.• IP routers: They route IP packets and provide fast rerouting in case

of routing failures.• STBs: A STB is a device the customer uses that interfaces with the

user terminal (e.g., TV, PC, laptop and others) and the network.

VoD servers Distribution

servers

Set-top box

Acquisition servers

Router

/Dslam

Router

/DslamRouter

Figure 6.1 Basic architecture of the IPTV system.

Page 170: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 153

SHOVHO

VHO: Router

Customer’s home

STBSTBSTBSTBSTBSTBSTBSTBSTBSTB

RG RG RG RG RG RG RG RG

DSLAMDSLAMDSLAMDSLAM

CO CO

IOIO

Figure 6.2 Architecture of an IP multicast IPTV system.

6.1.1.2 IP Multicast in IPTV ArchitectureIP multicasting is a method of sending IP packets to a group of inter-ested users. This method uses network architecture efficiently to senda packet to many users to ensure the packet is sent only once. Figure 6.2shows that a TV programme is encoded at the super hub office (SHO),and then delivered via multicasting through video hub offices (VHOs),intermediate offices (IOs), central offices (COs), digital subscriberline access multiplexers (DSLAM) and residential gateway (RG), tothe TV STB of users. SHO is used for the acquisition of national liveTV programmes. Live TV programmes can be received via satelliteand processed for delivery to multiple VHOs, where VHOs are thevideo distribution points. IOs and COs are located at each metropoli-tan area network and connected to access networks (Liu et al., 2013).

6.1.1.3 P2P IPTV ArchitectureFor a P2P IPTV distribution, there is a source and a group of peerswatching the video. This method refers to the source and the groupof peers as a torrent. The source encodes video and distributes thevideo packets into the P2P torrent. Each peer receives packets fromthe source or/and from other peers as shown in Figure 6.3 (Luo et al.,2006).

Page 171: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

154 IPTV Delivery Networks

Peer

server

Figure 6.3 Architecture of a peer-to-peer IPTV system.

6.1.2 Business Models

The IPTV service presents powerful multimedia services throughoutIP networks and it is usually supposed to be the next killer applicationover the Internet. It can provide many benefits, particularly for ser-vice providers who want to expand successful business models thatwill safeguard their existence in the market. To achieve a successfulbusiness model, a service provider should provide the right IPTV con-tents and services to the right subscribers at the right time and in away that is most comfortable and attractive to the subscribers (Punchi-hewa, Silva and Diao, 2010).

Some of the suggested services for IPTV are pay per view (PPV),interactive TV (iTV), games, presence service, communication mes-saging and many more (O’Driscoll, 1999). In the following sections, weexplain some of the services.

6.1.2.1 Free to Air (FTA)One way for a service provider to earn income from the FTA service isto charge customers a fee to host their video contents for easily sharingamong friends and family members. Another way is to sell advertisingspace on the video web portal or to push advertisements to viewersbefore the video is played. The other common method is to suggestpreviewing a video content that needs to be purchased (Punchihewa,Silva and Diao, 2010).

Page 172: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 155

6.1.2.2 PPVThe PPV service is usually used for high-value data such as movies.In this service, a customer buys the right to view an exact part of thecontent over a particular time period. The customer is permitted topause, fast forward and rewind the movie. However, when the particu-lar time period for which the user has subscribed expires, the user can-not access or view the content (Punchihewa, Silva and Diao, 2010). Forexample, TiVO uses this service in New Zealand (O’Driscoll, 1999).

6.1.2.3 SubscriptionThe subscription service is one of the most public techniques used forfinancing IPTV systems. In this service, customers sign up for a clusterof video channels and pay a flat monthly charge. Customers are thenpermitted to watch as much of any of the channels involved in theirsubscription clusters. Two business methods are being operated undersubscription.• Live video access, where customers pay a monthly charge in trade

for the rights to view live streaming video.• Video library access, where customers pay a monthly charge to

have permission to view a collection of contents: Mysky HDi is anexample of this service model (Punchihewa, Silva and Diao, 2010).

6.1.2.4 A La CarteThis service is similar to the conception of subscription, except thateach customer is permitted to select only the channels he/she wantsto view. Therefore, he/she does not pay for unwanted channels. ForIPTV suppliers, there are two benefits in following this method:• It is professionally less difficult to transport only a particular group

of channels to each customer.• IPTV suppliers may capitalise on subscribers’ wishes to pay only

for those channels they want to watch (Punchihewa, Silva andDiao, 2010). A comparison of various business models is shown inTable 6.1.

6.2 Challenges in Channel-Zapping Time

Channel-zapping time is one of the main factors for QoE in IPTV ser-vices. Because the number of IPTV channels is high, finding a desiredchannel among many channels is difficult.

Page 173: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

156 IPTV Delivery Networks

Table 6.1 Comparison table for various business models.

Method

FactorFree to air(FTA)

Pay perview (PPV) Subscription A la carte

Example Telstraclear TiVO Mysky HDi iiNETHow toearnmoney

Advertisingbefore avideo isplayed

A customerbuys the rightto view anexact part of acontent over aparticular timeperiod

Customers sign upfor a cluster of videochannels andcustomers are thenpermitted to watchas much of any ofthe channelsinvolved in theirsubscriptionclusters

A customerbuys whateverchannels andcontentshe/she wantsand pays a feefor each

6.2.1 Jitter

Jitter in IP networks is the variation in the latency on a packet flowbetween two systems so that some packets take a longer time totransmit from one system to another. Jitter is a problem since thereceiver must decode the frame at a constant bit rate, and any lateframes can produce the problem in the reconstructed video. To solvethis problem, a buffer is used at the receiver’s end to compensate thejitter, but the buffer may introduce an additional delay (Punchihewa,Silva and Diao, 2010).

6.2.2 Limited Bandwidth

The backbone of IP networks should be typically based on opticalnetworks; therefore, the probability of congestion in the backbone islow. However, we have bandwidth limitations at the access networks.Because of this bandwidth limitation, we cannot send all TV channelsto each user; therefore, when the user requests a channel, he/she willexperience some delay in receiving the channel he/she is interested in(Punchihewa, Silva and Diao, 2010).

6.2.3 Elements of Zapping Delay

When a user changes a channel, the system configuration is changedby his/her STB to allow the delivery of the new channel stream.

Page 174: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 157

Commercial IPTV

Channel

switching

request

JoinIP multicast

Application layer

multicast

Network delay

Synchronisation GOP

Synchronisation delay

Leave

Leave

Join

Buffered

DE

CO

DE

R

Buffering delay

P2P IPTV

Figure 6.4 Delay factors in channel-zapping time.

This operation consists of changing the membership of the currentmulticast group to the multicast group of the requested channel. Inthis situation, the user starts receiving packets from the stream of thenew group and stops receiving packets from the stream of the previousmulticast group. First, a join message is sent to the new multicastgroup and a leave message to the current group. In commercial IPTVsystems, a common protocol is the Internet Group ManagementProtocol (IGMP), and a single pair of join/leave messages (Manzatoand Nelson, 2013).

There are three types of delays during the channel-changing scenario(see Figure 6.4) (Manzato and Nelson, 2013):

• Network delay (ND): Includes both the network latency for theexchange of signalling messages and the processing time of eachnode.

• Synchronisation delay (SD): Includes the time between receiving areference frame by the STB and the start of the decoding process.

• Buffering delay (BD): Includes the time to buffer video frames afterthe arrival of the first I-frame. This buffering is to overcome theproblem caused by the unavailability of content due to network jitterand packet reordering.

Page 175: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

158 IPTV Delivery Networks

6.3 Proposed Methods for ReducingChannel-Zapping Time

Considering channel-zapping time has been one of the significantproblems in IPTV, many efforts and researches have been carriedout to reduce the latency and to help provide QoS. We shall groupthese methods in five categories and study them in the followingsubsections.

6.3.1 Client-Based Methods

These methods usually emphasise user preferences to reduce thechannel-zapping latency. In these methods, those channels that have atop rank in viewing are pre-fetched in the background before channelswitching happens.

We study two groups of researches in this context. The first groupis popularity-based methods that operate based on the popularity ofchannels. In these methods, when a user selects a channel, a limitednumber of channels that the user has spent most of time watchingthem are pre-joined (Lee et al., 2009). There are two problems in thesemethods: Channels that are pre-joined and in which order they shouldbe placed in the list (Cho et al., 2004).

The second group is based on adjacent channel pre-fetching (Chaet al., 2008), where the adjacent channels of the current channels thathave been watched by a user are pre-joined as they are good candi-dates for selection. If one of these pre-joined channels is requestedby the user, the channel-switching time is much shorter than that forrequesting other channels.

In IPTV, when a user requests a channel by pressing a button on hisremote control, this request is sent to the network and the requestedchannel is delivered to the user. The idea of all the methods studied inthis section is that an additional set of channels pre-join together withthe requested channel. However, the main issue is not knowing whichchannels are pre-joined and in which order. The pre-joined channelsare synchronised and buffered with the requested one at the same time.Hence, if the user decides to watch another channel in the pre-joinedlist, the zapping time will be very low (Cha et al., 2008).

6.3.1.1 Pre-Joining Neighbouring ChannelsThe first scheme uses adjacent channels of the requested channel topre-join. There are two problems for pre-joining adjacent channels.

Page 176: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 159

First, selecting and sending adjacent channels concurrently to the STBis very rapid. However, this is not efficient as it increases bandwidthutilisation. To solve this problem, this scheme maintains the adjacentchannels in the STB during a small period between 10 s and 2 min.The second problem is the number of adjacent channels that shouldbe sent concurrently to the STB. Conventional STBs usually receiveone or two channels together. However, recent STBs are capable ofreceiving more channels in parallel. These STBs are low cost and theirprocessing and memory capabilities can be improved. Therefore, thistype of STB is capable of concurrently processing more channels.Anyway, due to the limitations of STB processing and bandwidth, thisscheme proposes a limited number of concurrent channels between2 and 10 (Cha et al., 2008).

6.3.1.2 Tracking User BehaviourInstead of creating a long list of channels for a user to keep switching,making a small list of channels according to user interests can easilyprevent useless channel switching (Manjunath and Mastani, 2013).These channels can be selected based on user behaviour in changingthe channels. A channel with more viewing counts is called a popularchannel and has a higher probability of being requested again byusers. These methods identify the popular channels and try to reducechannel-zapping time by paying more attention to them.

Reducing Channel-Zapping Time in IPTV by Predictive Pre-Joining of TVChannels The method detailed in Section 6.3.1.1, in which adjacentchannels are pre-joined, can provide good performance results,but user behaviour in tracking TV channels is an important factor.Ramos et al. (2011) have proposed that user actions can be trackedto build a personal prediction model. To obtain this model, thismethod maintains two types of information in the STB for a user: Theprobability of user zapping with up and down buttons (i.e., adjacentchannel selection) and probability of switching to each of differentchannels (i.e., trying to obtain the user’s favourite channels). In thismethod, two tables in the memory are updated by each user action:

1. A channel popularity table: This table preserves a counter for everyspecific channel. Each time the subscriber shifts to a channel, itscounter is added by one. The preferred channel of a specific sub-scriber will be the one related to the maximum count of the table.

Page 177: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

160 IPTV Delivery Networks

2. A ‘jump distance’ popularity table: This table preserves a counterfor every specific ‘jump distance’. Each time a user jumps fromchannel number i to channel number j, this distance is computedas ji and the counter for this specific distance is added in thetable by 1.

An Efficient Hot Channel Identification Scheme for IPTV Channel NavigationThe method in Lee, Ku and Bahn (2014) provides two lists. The firstlist is for hot channels, that is, those channels likely to be watchedsoon enough by the user. The second list is for cold channels, that is,the channels that have less popularity. This information is obtainedby the user’s history of channel selection. Therefore, this methodconsiders the user’s behaviour in terms of watching frequency andnovelty. On the other hand, this method always observes the channel’sstate, which implies that those channels that are hot may becomecold, and vice versa. During the channel-surfing period, the hot listis searched first and then the cold list. If the target channel was notfound in the hot list, then the cold list is searched. This is becausethe requested channel is much more likely to be in the hot list, andtherefore, the seek distance (i.e., the number of channels that haveto be bypassed on the way to the requested channel) is usually short.The hot channel can be sent in small and low resolution to support apreview mode. This operation usually reduces channel-zapping timeeven if the network bandwidth is limited.

IFCS: Intelligent and Fast Channel Switching in IPTV Over PON Based on HumanBehaviour Prediction The method in Beyragh and Rahbar (2014) oper-ates on passive optical networks (PON). In Beyragh and Rahbar (2014),there are two types of user behaviour information. The first type ofinformation is dedicated to each user. This information indicates thetime and channel watched by the user. This type of information is keptin the STB. The second type of information is about all user behaviourin selecting the channel such as the list of most popular programmes,their channel IDs and their playing times that are public and storedin the optical line terminal (OLT). This method uses this informationto predict the channels that the user will select. The public informa-tion should be updated daily. The OLT also should reserve some ofits bandwidth for the most popular channels. When a user requests achannel, if the channel exists in the OLT, the OLT forwards the channelto the user and forwards a join message to the IPTV server. But if the

Page 178: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 161

requested channel is not in the OLT, the OLT requests the interestedchannel in base-mode quality by forwarding the STB’s pre-join mes-sage to the IPTV server. Now, assume that an important programmesuch as an important football match will start soon. This type of infor-mation is public and is stored in the OLT. A few minutes before thestart of the programme, the OLT will reserve some of its bandwidthfor that programme. Then, the OLT will check the playing list. If thetraffic of the match exists in the playing list, the OLT will keep its con-nection alive. In this situation, when a user switches the channel towatch the match, the OLT will send his/her leave message to the IPTVserver, update its playing list and send a join message for the matchprogramme to receive the match in base-mode quality.

However, if the traffic of the match does not exist in the playing list,the OLT will send a join message to the IPTV server to receive thematch programme in base-mode quality. When the user decides towatch the interested programme, he/she receives the relevant contentrapidly in base-mode quality, and after a while, he/she can watch ahigh-quality video based on the OLT’s request from the IPTV server.

6.3.1.3 Ordering Pre-Join Channels in the ListAs mentioned, a challenge with respect to pre-join channels is theuser not knowing how to order pre-join channels in the list. In thenon-weighted circular ordering (NWCO) technique, IPTV channelsare visited in a numerical order. In this way, a popular channel maybe located in a random place in the list; therefore, the channel surfingperiod will be increased. This means that a user must do many chan-nel changes to select his/her popular channel of interest (Azgin andAltunbasak, 2013).

To solve this problem, the work in Manjunath and Mastani (2013)has proposed a solution called the frequency circular ordering (FCO)technique that orders the channels based on their frequencies. Here,all hot channels are placed to the right and all cold channels are placedto the left of the circle shown in Figure 6.5(b). This method has a betterperformance than the NWCO technique. However, it has a problemtoo. Based on the FCO technique, accessing some cold channels areeasier than some hot channels according to Figure 6.5(b). For example,according to Figure 6.5(b), we need three channel switches to reachChannel 10 from Channel 4. To reach Channel 17 from Channel 4, weneed two channel switches.

Page 179: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

162 IPTV Delivery Networks

(c) Frequency interleaved ordering

Hot channels

Cold channels

CH13 CH4

CH7

CH10

CH12

CH5

CH1

CH15

CH8CH16

CH6

CH14

CH3

CH9

CH2

CH16

1416 15

12

10

8

6

4

5

31

2

7

9

11

13

(a) Numerical ordering

CH10

CH9 CH8

CH6

CH5

CH4

CH3

CH2

CH1CH16

CH15

CH14

CH13

CH12

CH11

CH7

4

9 14

2

17

8

1

13

7105

12

15

3

8

(b) Frequency circular ordering

Cold to hot Hot to cold

11

CH1

CH9 CH5

CH12

CH16

CH10

CH13

CH7

CH4CH6

CH14

CH8

CH3

CH15

CH11

CH2

7

8 9

10

11

12

13

14

15161

2

3

4

5

6

Figure 6.5 Channel sequences of (a) NWCO, (b) FCO and (c) FIO.

To solve this problem (i.e., accessing some cold channels is easierthan some hot channels), the frequency interleaved ordering (FIO)technique has been proposed in Lee et al. (2009). Based on this tech-nique, the channels are distributed in the list based on their accessfrequencies as shown in Figure 6.5(c). The frequency (or weight) of achannel for a given user is obtained based on the number of channelsaccessed by the user. When the user selects a channel, the frequencyof that channel for the user is increased.

Figures 6.5(a)–(c) illustrate the channel sequences of NWCO,FCO and FIO, respectively. The number in each cell represents the

Page 180: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 163

frequency priority and the numbers outside the cell are channelnumbers. Number 1 represents the least popular channel and 17represents the most popular channel.

For example, if a user’s channel selection behaviour is: Channel 4▸ Channel 13 ▸ Channel 16, then the number of channel switchingsunder numerical ordering, frequency circular ordering and frequencyinterleaved ordering are 12, 4 and 2, respectively. For example, assumea user watches Channel 4. To select Channel 13 in numerical ordering,he/she first switches to Channel 5, then 6, next 7, … , until Channel13 (see Figure 6.5(a)). Then, to select Channel 16, he/she needs threechannel changes (i.e., Channel 14, Channel 15, Channel 16) to selectChannel 16.

However, in frequency circular ordering, for selecting Channel 13,he/she needs only two channel switches as Channel 7 and Channel 13as shown in Figure 6.5(b). Then, to select Channel 16, he/she needstwo channel changes (i.e., Channel 10 and Channel 16) to selectChannel 16.

6.3.2 Content-Based Methods

These methods use content factors (such as I-frames and video com-paction effects) to reduce channel-zapping time. We describe severalmethods in this section. All methods studied in this section use scal-able video coding (SVC) to reduce channel-switching delay.

In SVC, there are several layers with different encoding rates fromlow to high bit rate, where layers with a low bit rate have lower videoquality and layers with a high bit rate have higher video quality (calledenhancement layers). An SVC scalable video stream contains layers,where each layer serves as a prediction for the next upper layer. There-fore, the SVC uses information of previously decoded frames andlower layers simultaneously. In SVC, the low layers (i.e., those layersthat have a low bit rate and then low video quality) and enhancementlayers (i.e., those layers that have a high bit rate and then a highvideo quality) are coded for rapid channel switching (Wallendaelet al., 2012). SVC develops H.264/AVC with temporal, resolution andquality scalability. SVC standardises the encoding of a high-qualityvideo bitstream that may contain one or more subset bitstreams.These bitstreams are from the SVC layers mentioned before.

The lowest layer of the SVC is called the base layer. The base layerof SVC is a standard H.264/AVC video stream. This H.264/AVC base

Page 181: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

164 IPTV Delivery Networks

layer can be improved by using enhancement layers that have moreframe rate, resolution or quality. As many attributes of SVC can beobtained from H.264/AVC, fast channel switching with H.264/AVCwill be mentioned first.

In IPTV systems, moving pictures experts group (MPEG) methodsare used to compact the media content and reduce the bandwidthutilisation of the TV channel. This type of coding is constructed on thespatial and temporal redundancy of the frames. As a result, efficientmedia coding schemes have been developed, such as MPEG-2 orMPEG-4/H.264, for efficient utilisation of the available bandwidth.In these schemes, a video stream is divided into segments called agroup of pictures (GOP) that contains a short video stream betweenhalf a second to a few seconds. Each one of GOFs begins with anI-frame that includes the whole picture and it is trailed by a seriesof P/B-frames that offer only incremental changes relevant to theprevious frames in the same GOF.

P-frames or Predicted (P) frames are encoded from a ‘predicted’ pic-ture based on the closest preceding I- or P-frame. P-frames are alsoknown as reference frames because neighbouring B- and P-frames canrefer to them. P-frames are typically much smaller than I-frames (Zareand Rahbar, 2014).

B-frames or Bi-directional (B) frames are encoded based on aninterpolation from I- and P-frames that come before and after them.B-frames require very little space, but it may take a long time fordecompression because they are dependent on the frames that maybe dependent on other frames (Zare and Rahbar, 2014).

Since an I-frame offers information about the whole picture, its sizeis extremely bigger than that of a P/B frame. It is noted that if theduration of a GOP is long, then the number of I-frames per secondis reduced. Therefore, the required bandwidth for encoding the mediastream is decreased. It is necessary to mention that the STB can onlystart playing a received media stream at the beginning of a GOP.

We discuss some proposed methods in the following:

• The first method uses scalable video coding (SVC) configuration toreduce channel-zapping time. To obtain a rapid channel-switchingperiod based on the video content, we need to have random accessto the video stream. There are several methods in H.264/AVC toenable random access to the video stream. The simplest methodto achieve random access is to use instantaneous decoding refresh

Page 182: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 165

Open GOP

(IBBP, IS Frames)

Closed GOP

(IBBP, IS Frames)

P

03 04 05 06 07 08

PB B B B PB B PB B PB B IB BI

09 10 11 12 13 14 15 16 17 18 19 20 21

I

04 05 06 07 08

PB B B B PB B PB B B PP

09 10 11 12 13 14 15 16 17 18

Figure 6.6 Open GOP and closed GOP.

(IDR) frames (Wallendael et al., 2012). An IDR frame is a specialtype of I-frame in H.264. An IDR frame specifies that no frame afterthe IDR frame can refer to any frame before it. This makes seekingthe H.264 file easier and more responsive in the player (Richard-son, 2003). When an encoder sends an IDR frame that is made upof I- or SI-slices to the decoder, the decoder clears the content ofthe reference picture buffer and marks all pictures in the referencebuffer as ‘unused for reference’; therefore, the next transmitted slicescan be decoded without reference to any frame that was decodedbefore the IDR frame. The first picture in a coded video sequence isalways an IDR frame (Richardson, 2003). Therefore, before decod-ing these intra frames, the decoder clears the decoded picture buffer(DPB) for permitting random access to these frames. Open-GOPintra frames are very similar to the concept of IDR frames but theopen-GOP intra frames are less limiting than IDR frames and allowhigher compression efficiency. As it is shown in Figure 6.6, unlike

closed GOP, an open GOP allows the B-frames from one GOP torefer to an I- or P-frame in an adjacent GOP. To increase the numberof IDRs without affecting the bandwidth, a companion stream witha lower quality and increased IDR frequency is produced, where

Page 183: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

166 IPTV Delivery Networks

the companion stream is a stream with low bit rate and low qualityor spatial resolution. Because we want to increase the number ofIDRs without affecting the bandwidth, we use a stream (i.e., com-panion stream) with a low bit rate to compensate for the increasein bandwidth that resulted from the increase in IDRs; therefore, thebandwidth remains constant. It is noted that a channel-switchingoperation is called simulcast in this method as both video streamsare independently encoded and independently transmitted onto thenetwork. This action is unlike SVC, where both video streams aredependent on each other (Wallendael et al., 2012). When a userselects a channel, the STB probably decodes from the companionstream first because of the high frequency of IDR frames. Therefore,because of the low bit rate of the companion stream, a low resolution,small frame rate or low-quality video is displayed to the user. But,he/she experiences a rapid channel change. In the following, when anIDR frame of the main video stream is decoded, the user experiencesthe video with full quality. The time between decoding the companionstream and the start of decoding the main video stream is calledtransition period (Wallendael et al., 2012). As mentioned earlier, thecompanion stream is similar to the main video stream, except in theframe rate, resolution, quality or IDR frequency. SVC is basicallyproduced to efficiently compress these two similar streams to severallayers that depend on each other (Wallendael et al., 2012).• Another method in Boyce and Tourapis (2005) claims that last

mile networks have rigid bandwidth constraints; therefore, onlyrequested media streams are forwarded to each viewer. Boyce andTourapis (2005) have proposed a new encoding scheme that insertsa lower resolution stream into a regular resolution stream for everyseparated channel. They use this concept that channel switchingis completed when an I-frame of the requested channel arrivesat the STB of the user. However, as I-frames have high volume, alow bit rate stream with a higher number of I-frames is created.The number of I-frames in a lower resolution stream is more thanthose of a regular resolution stream. The lower resolution streamhas a low bit rate, but the number of its I-frames is high. On theother hand, a regular resolution stream has a normal bit rate andlower number of I-frames, but it has a better quality and resolution.When a user requests a channel, the lower resolution stream isforwarded to the user at first, and when enough data for the regularresolution stream is gathered and buffered in the jitter buffer of the

Page 184: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 167

decoder, the regular stream is forwarded to the user. This methodexpends extra bandwidth on the subscriber’s dedicated line (Boyceand Tourapis, 2005).

• The method in Lee et al. (2008) uses the SVC pattern to solve thechannel-switching delay problem. It is proposed that the base layerand enhancement layer of each channel are allocated to two sepa-rate multicast groups. This method claims that the users are in twomodes: Preview mode and watch mode. A user only surfs the chan-nels in the preview mode to select his/her desired channel. Whena channel is selected by the user, he/she is switched to the watchmode. In the preview mode, users access the base layers of differ-ent channels stored in the buffer of the STB; therefore, they canswitch between channels rapidly. The users use both the base andenhancement layers of the selected channel in watching mode toreceive full quality (Lee et al., 2008). On the other hand, in the pre-view mode, switching to a channel occurs rapidly as the data ofthe newly selected channel is already in the buffer. When the userdecides to watch the current channel for a while, the enhancementlayers are transmitted instead of the base layers of multiple chan-nels, and therefore, the user has a full quality video. It is noted that aswitch from the watching mode to the preview mode takes less timethan a change of channel at full quality. Figure 6.7 shows dataflowof conventional IPTV during channel switching and dataflow of theproposed method (Lee et al., 2008). The current channel is repre-sented as a blue rectangle, and black rectangles denote the switch-ing time during which the user cannot watch any programmes. Thedotted rectangles show related channels being transmitted. As it isshown in Figure 6.7(a), when a channel change occurs in regular dig-ital video, a notable amount of time is required for channel switch-ing. But as it is illustrated in Figure 6.7(b), when a channel changeoccurs in the proposed system, the requested channel is switchedrapidly. This is because in the preview mode, there is almost nozapping time in channel switching as all the base layers of channelsare in the STB buffer.

6.3.3 Network-Based Methods

These methods use network components (such as servers and routers)to reduce channel zapping.

Page 185: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

168 IPTV Delivery Networks

Arrow shows channel switching

Display

Time

Zap time

Arrow shows channel switching

(a)

(b)

Display

Watching mode Zap Preview mode Watching mode

Enhanced layer

Base layer

Zap time Transmit

CH1

CH2

CH3

CH4

CH5

Time

CH1

CH2

CH3

CH4

CH5

Figure 6.7 Dataflow in (a) a conventional system and (b) the system proposed inLee et al. (2008).

Page 186: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 169

6.3.3.1 Improving Zap Response Time for IPTVThere are two main factors that affect channel-zapping time. The firstone is the signalling delay (SD) for sending a join message and joiningthe multicast group of a requested channel. The second is the firstI-frame delay (FID) that is the time it takes for a STB to receive suf-ficient data for a channel to start playing the channel on the user TV.On the other hand, FID is the time it takes to receive and decode thefirst I-frame by the STB. Therefore, FID is dependent on the GOP size(Bejerano and Koppol, 2009).

The method in Bejerano and Koppol (2009) reduces the zappingtime by decreasing the FID. This method uses a zapping accelerator(ZA) server to generate several time-shifted replicas of the channel(called sub-channels) so that each one is identified by a uniquemulticast group. One of the sub-channels is considered as the mainTV channel. The ZA broadcasts a meta-channel to all STBs, where themeta-channel specifies the sub-channel that has the earliest replicaof an I-frame for each channel. Note that a meta-channel consumesa slight amount of bandwidth even when the ZA supports hundredsof TV channels. When a user switches the TV channel, the STBalready knows which sub-channel of the requested channel has theearliest I-frame and it joins this sub-channel. It is noted that eachsub-channel can be used by multiple users simultaneously, but theZA generates a sub-channel only for registered users. This methodmigrates users from sub-channels to main channels and stops thetraffic on unused sub-channels, thus improving network bandwidth.Finally, this method does not impose any modification in the videocontent, and therefore, a user receives a high-quality video with fastchannel switching.

6.3.3.2 A Novel Channel Switching Scenario in Multicast IPTVNetworksSarni, Hilt and Lorenz (2009) claim that in a normal channel-zappingscenario, the current channel is left first and then a join message issent for the requested channel. Therefore, the network delay (ND) iscalculated as:

NDStandard Approach = CSDIPTVdevice + JLRequested channel (6.1)

where NDStandardApproach is the network delay of the standard approach,CSDIPTVdevice is the channel switch delay (CSD) of standard IPTVdevice and JLRequested channel is the join latency (JL) of the requested

Page 187: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

170 IPTV Delivery Networks

channel. The JL depends on several parameters such as the processingability of the equipment in the network used by the service provider,the number and bit rate of the channels and finally the values of theIGMP parameters (such as response time). To solve this problem,Sarni, Hilt and Lorenz (2009) have proposed that when channelswitching is initiated by a user, he/she joins the requested channel atfirst and then he/she leaves the currently watched channel. Therefore,the ND will be reduced to the JL of the requested channel and theother factor in Equation (6.1) is eliminated. Hence, Equation (6.1) isconverted to

NDProposed Approach = JLRequested channel (6.2)

This method (Sarni, Hilt and Lorenz, 2009) increases the QoE in IPTV.When a user requests a channel, a black screen appears in the TVscreen during zapping time. This is because of the decoding processdelay and a delay between the last packet of the currently watchedchannel and the first packet of the requested one. However, Sarni, Hiltand Lorenz (2009) introduce a channel overlapping, which reduces theblack screen duration in the TV screen.

6.3.3.3 IGMP for IPTV Services in Passive Optical NetworksAs stated in Section 6.3.3.2, the network delay is the time interval thatthe first video frame of the requested channel arrives at STB afterthe IGMP leave/join process. Therefore, the IGMP leave/join processdelay mainly affects the network delay. A method called extendedIGMP (EIGMP) has been proposed in Lee and Park (2010) that canremove the usual IGMP leave/join process time in the PON-basedshared network such as GEPON architecture. GEPON is a point tomultipoint (P2MP) network with many optical network units (ONUs)connected to one optical line termination (OLT) with a passiveoptical splitter (Kramer, Mukherjee and Pesavento, 2002). Figure 6.8illustrates the architecture of the IPTV service and its components inGEPON.

When a channel is requested by a user, the EIGMP method permitsthe user to receive the requested channel instantly when the requestedchannel is already being broadcast for other users in the same fibre bythe request from another user at the network. Therefore, the EIGMPconsiderably decreases the zapping time by eliminating the IGMPleave/join process time.

Page 188: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 171

6.3.3.4 Implementation of EIGMP for Fast IPTV Channel Changein GEPONThe method discussed in Section 6.3.3.3 has a problem. It does not tellhow to implement EIGMP in the architecture of GEPON for IPTV orother similar broadcasting services. As it is shown in Figure 6.8, in apractical IPTV system using GEPON, the requested channels arrivedat each ONU and Ethernet frames of unwanted channels are filteredby the logical link identifier (LLID) in the media access control (MAC)layer of each ONU. Therefore, ONUs should extract Ethernet frames ofencapsulating IP packets for the EIGMP in the MAC layer, otherwise,they may be discarded in the MAC layer of each ONU.

By altering two layers (i.e., the MAC layer and the IP layer), anew method has been proposed in Yoon, Park and Choe (2011) toimplement EIGMP in GEPON. With this method, each ONU classifiesEthernet frames of encapsulated IP packets for the EIGMP by LLIDaccording to the channel-mapping table (CMT). The IP packets thatare obtained from the classified Ethernet frames can be used in theIP layer according to the EIGMP. This method operates on GigabitEthernet Passive Optical Network (GEPON). In this method, if a userrequests a channel that is being broadcast for other users in the samefibre, Ethernet frames that have the LLID of the selected channel canbe extracted by the IPTV host (see Figure 6.8) instantly by checkingthe CMT. As a result, the IP packets of the selected channel for

FHR: First hop router (edge router)LHR: Last hop router (edge router)OLT: Optical line terminationONT: Optical network unitPS: Passive splitter

Fibre

IPTV hosts

IPTV server

FHR LHROLT

PSPS

PS

IP network

IPTV channels

ONUs

Figure 6.8 Architecture of the IPTV service and its components in GEPON.

Page 189: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

172 IPTV Delivery Networks

EIGMP can be produced from the Ethernet frames without the IGMPnetwork delay.

6.3.3.5 Advanced Scheme to Reduce IPTV Channel-Zapping TimeThe method in Lee et al. (2007) uses the home gateway (HG) as IGMPproxy to reduce channel-zapping time. The HG can receive bothcurrent channel and the adjacent channels. Therefore, when a userchanges the current channel to an adjacent channel, the HG does notneed to process another IGMP join operation; therefore, the channel ischanged without delay. The method in Lee et al. (2007) has two prob-lems. The first one is that if the user selects a random channel, therewill still be a long channel-zapping time gap. The second problem isthat this method needs an additional device (i.e., HG) as IGMP proxy.

To solve these problems, Lee et al. (2007) have proposed a method toreduce channel-zapping time not only for adjacent channel selectionbut also for random channel selection by using a rating server. Therating server gathers channel change events from STB and managesstatistics for each STB. This method does not use HG. It uses STBinstead of HG to manage adjacent channel multicast group lists andchecks IGMP join/leave operation for adjacent channels. To reducechannel-zapping time for random channels, the rating server gathersthe information on channel-switching events from STB and managesstatistics for each STB. If the rating server receives a query messagefrom an STB, it obtains expected channel list from managed statisticsand responds with the list to the STB.

6.3.4 Hybrid Methods

These methods combine two or more of the methods mentioned inSections 6.3.1–6.3.3 to reduce the channel-zapping time.

6.3.4.1 An Effective IPTV Channel Control Algorithm ConsideringChannel-Zapping Time and Network UtilisationNew recent research believes that both the network delay and videodecoding delay must be considered as they have important roles inthe zapping time (Joo et al., 2008). This method proposes to insertadditional I-frames to normal video frames to economically reducevideo decoding. One of the main features of this method is that bothbroadcasting channel distribution state and video encoding shouldbe considered. This method reduces the network delay by locating

Page 190: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 173

IP network

FHRLHR

Edge router

Edge router

Aggregation

switch/Router

Aggregation

switch/Router

Home gateway (HG)

STB

STB HG

STB HG

STB HG

ADSL

ADSLIPTV headend

VDSL

VDSL

Figure 6.9 IPTV service architecture.

channels based on their popularity and reducing video decodingdelay by adding additional I-frames to the video stream. A STB startsdecoding the channel content when it receives the first I-frame of thatchannel. Therefore, by adding extra I-frames to the video content, thetime between two adjacent I-frames becomes small, and therefore,the STB waits for a small time.

Figure 6.9 shows a typical IPTV service structure. As it is shown inthis figure, the users are connected to the broadcasting system withSTB and the STB is connected to the HG. The HG is an IGMP proxylocated between access network and home network that controlsincoming IPTV channels. Head-end receives all the broadcastingchannels from external sources and multicasts them to users toimprove the network utilisation. Last hop router (LHR) is the closestedge router from home network and first hop router (FHR) is theclosest edge router from head-end.

To reduce the network delay, the channels are categorised into twogroups: Static channels and dynamic channels. The static channels areplaced at LHR, therefore, the static channels require a relatively smallnetwork delay because these channels are close to users, but when noone is watching these channels, the network bandwidth is wasted. Onthe other hand, the dynamic channels are placed at FHR, and therefore,their network delay is relatively high, but less bandwidth is wasted. Itis noted that video decoding delay is related to the GOP size. Note thatGOP is a group of successive pictures within a coded video stream. Themaximum video decoding delay is the length of a GOP. To reduce thevideo decoding delay to be less than a GOP, this method (Joo et al.,2008) inserts additional I-frames to the video stream to enable fastchannel changing. However, in this situation, the channel bandwidth is

Page 191: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

174 IPTV Delivery Networks

Dserver Dserver

Access network

Central

office

DSLAM

2Mbps30Mbps

1 Gbps

10-100 Gbps

~100 s OF Mbps

I/O B/W

RG

S S

RG

S S

RouterVideo hub officeSHO

Dserver

Figure 6.10 IPTV network architecture and components.

increased. This is because an I-frame offers whole picture information;therefore, its size is extremely bigger than a P/B frame (see Section 3.2).

6.3.4.2 Multicast Instant Channel Change (ICC) in IPTV SystemsThe method in Banodkar et al. (2008) uses two types of channelstreams and two groups. One type of channel is of high quality withhigh resolution, but it needs high bandwidth. The second type denotesthe channel streams that have low quality/resolution and require lowbandwidth. There are two multicast groups in this method: A primarymulticast group that includes main channels with high quality and asecondary multicast group that consists of secondary channels withlow quality and low bandwidth. Note that the channels of the primaryand secondary multicast groups are the same, but with differentquality and bandwidth requirements.

Video content is received from SHO either live or from storagedevices (for VoD). The content is buffered at D-Servers in the VHO asshown in Figure 6.10.

Each secondary channel stream placed on a multicast group trans-mits only I-frames for each channel. When a user requests a channel, ajoin message is sent to both secondary and primary multicast groups.The D-server transmits both secondary channel stream and primarymulticast channel. Therefore, the first frame of the secondary chan-nel stream is displayed for the user without buffering along with the

Page 192: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 175

TV client

1: Join

2(a): I-frame stream flow 2(b): Primary multicast stream flow

3: The first frame from the I-frame stream is displayed on the screen

4: Buffer from the primary multicast stream upto HTE playout point of the buffer

5: Issue a leave to the I-frame stream and start playing out the buffer

1

3

4

5

2.A

2.B

Multicast

replicator

Figure 6.11 Steps of the multicast ICC method.

audio so that the user experiences low delay in channel change evenwith low quality. When the user is receiving the secondary channelstream, the primary stream of that channel is buffered in the STB.When the buffer is full, the STB starts playing the buffered high-qualitychannel. This mechanism is shown in Figure 6.11. The tradeoff in thismethod is between low-quality video and rapid channel-zapping time.The low-quality video will be displayed in the user TV until filling theSTB buffer with high-quality video that takes around 2–3 s.

6.3.4.3 IPTV Channel Switching Delay Reduction ThroughPredicting Subscribers’ Behaviours and PreferencesIn Khosroshahi, Yousefi and Rahbar (2016), user behaviour in channelselection is used to reduce channel-zapping delay in IPTV overWiMAX networks. First, user preferences are extracted accordingto watching behaviour and a list of favourite channels is earned foreach user. Then, each channel is assigned a score. Two algorithms,background channel pre-fetching (BGCP) and popularity-basedbackground channel pre-fetching (P-BGCP), have been proposed.These algorithms operate because the favourite channels and theirscores that exceed a predefined threshold are pre-joined with alow-quality format. Then, when a full-quality video is received fromthe IPTV server, it is sent to the user. These methods use backgroundchannel transmission as the key factor in reducing channel-switching

Page 193: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

176 IPTV Delivery Networks

delay. In other words, these methods use pre-join mechanism with lowquality in the content of the video. In PGCP, a dedicated bandwidthis given to the channel with the highest score at the top of eachuser’s preference list. However, in P-PGCP, the popularity of channelsamong all users is considered and it means that the channels arehighly popular among all users who are assigned high priority forpre-fetching. Simulation results show that the BGCP method has abetter performance than the P-BGCP method.

6.3.5 Programme-Based Methods

It is noted that the number of channel-switching times mainly affectsthe channel-surfing period. Almost all methods that try to reducechannel-zapping time are channel-driven. This means that thesemethods attempt to select the pre-join channels based on the pop-ularity of channels. Recently, to reduce the channel-surfing period,some methods have been proposed based on programmes, that is,a programme-driven method. This means that users do not selectchannels; instead they select programmes (Zare and Rahbar, 2016).

Zare and Rahbar (2014) claim that popularity-based methods havesome problems:

• In IPTV, with hundreds of channels, the number of channels withhigh popularity becomes high, and therefore, the number of channelzappings becomes high, and, as a result, the channel-zapping timeincreases.

• If a channel with less popularity is requested, the number of channelzappings becomes high, thus increasing the channel-zapping time.

• If a channel with less popularity broadcasts an exciting programme,users may miss it.

To solve these problems, it is proposed that the selection of chan-nels should be programme-driven (Zare and Rahbar, 2016). In thismethod, TV programmes are categorised in different groups suchas news, movies, health, cocking, sport, cartoons and so on. Thesecategories could be inserted as some buttons on a TV remote controlor as a list in a TV menu. When a user decides to watch a specialtype of programme, he/she presses the associated buttons on the TVremote control or selects the associated category in the menu. Then,those channels that play the interested programme are joined to a listfrom which the user can switch to them rapidly. It is noted that when

Page 194: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 177

1

3

2

Number description:

1: Programme selection

2: Channels that play the programme are prejoined

3: Channel request

4: Channel with higher popularity

4

Figure 6.12 Channel selection scenario in the programme-driven method.

the channels are categorised, the range of the search will be smalland the channels in which the user is interested can be found rapidly.Therefore, in the programme-driven method, the number of channelswitches becomes lesser. Figure 6.12 shows the channel selectionscenario in the programme-driven method.

6.4 Discussion

As mentioned earlier, there are some factors that impact channel-zapping delay, where each method proposed for reducing channel-zapping latency tries to reduce these factors. In this chapter, we haveexplained some existing methods to decrease the channel-zappinglatency based on the client’s side, content-based methods,network-assisted types, hybrid and programme-based methods.We evaluate these methods in the following. A comparison of the fivegroups of methods is shown in Table 6.2.

The client-based methods try to reduce network delay. These meth-ods use user behaviour to reduce channel-zapping time, and therefore,this makes it a complexity on the client’s side. These methods usu-ally use MPEG/H.264 for video coding. However, these methods havesome problems as:• If the adjacent channels of the requested channel are pre-joined,

then when a user requests a random channel, the channel-zappingtime is increased.

Page 195: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

178 IPTV Delivery Networks

• If popularity channels are pre-joined, then:

1. When the user selects a channel with less popularity, thechannel-zapping time is increased.

2. In IPTV with hundreds of channels, the number of popularity chan-nels is high, and therefore, requesting a popular channel may needa long zapping time.

• We need extra bandwidth for pre-joining channels.• Placing pre-joined channels in the list is a challenge.

The content-based methods have some features. These meth-ods usually use a secondary stream that has less quality forchannel-zapping time during filling the buffer of STB with pri-mary stream of high quality. Therefore, these methods usually useSVC (H.264/AVC) in video coding. They have a trade-off betweenrapid channel change and high-quality video stream. Because thesemethods use secondary streams with low quality, the requiredadditional bandwidth for these methods is small. These methodstry to reduce synchronisation delay and buffering delay. In thesemethods, there is a complexity in the service provider to producevideo streams.

The network-based methods operate on the network property toreduce channel-zapping time. These methods try to reduce networkdelay by changing the IPTV system architecture such as using cacheserver and so on. Therefore, there is a complexity in the network pro-vided. These methods usually use MPEG/H.264 for video coding.

The hybrid methods try to reduce some factors that impactchannel-zapping time. For this purpose, these methods operate indifferent sections in the network such as routers, servers, STBs,content and so on. In other words, these methods use a hybrid ofclient-based, network-based or content-based scenarios to reducechannel-zapping time.

The programme-based method uses a different overview to reducechannel-zapping time. Instead of requesting a channel, a user requestshis/her desired programme. The goal of this method is to reduce thenumber of channel switchings. If this approach is used along withother methods such as client-based methods, good results can beobtained. Simulation results show that the programme-based methodprovides better performance than client-based methods. In all thestudied methods, if the number of IPTV channels becomes high, the

Page 196: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Table 6.2 Comparison table for the five groups of proposed methods.

MethodFactor Client-based Content-based Network-based Hybrid methods Programme-based

Operation Based on theactivity of clients

Using contentfactors (such asI-frames and videocompaction effects)

Using networkcomponents (suchas servers androuters)

Combining two ormore methods

Programme-driven

Goal Reducing networkdelay

Reducingsynchronisationdelay and bufferingdelay

Reducing networkdelay

Reducing networkdelay,synchronisationdelay and/orbuffering delay

Reducing thenumber of channelswitching

Strategies forpredictionof next channels

Adjacent/popular/userbehaviour

— — — Programmeselection

Streams withminimum quality

No Yes No — No

Video coding MPEG/H.264 SVC (H.264/AVC) MPEG/H.264 MPEG/H.264 MPEG/H.264Complexity At client side At service provider

sideAt networkprovider side

— At service providerand client side

Page 197: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

180 IPTV Delivery Networks

channel-zapping time increases. However, this issue has less effect onthe programme-based method as it operates on programmes insteadof channels. There is a complexity at the service provider’s and at theclient’s side in this method. This method uses MPEG/H.264 for videocoding.

6.5 Summary

Audio/video multi-channel streaming has generally been presentall over the Internet. However, the channel-zapping latency is still asignificant factor. In this chapter, we have explained some existingmethods to decrease the channel-zapping latency based on theclient’s side, content-based, network-assisted types, hybrid andprogramme-based methods. These methods are helpful in decreasingthe channel-zapping latency, but they need extra bandwidth from thenetwork. Decreasing the channel-zapping latency with the minimumextra network supply is significant for the future of multi-channelstreaming.

References

Azgin, A. and Altunbasak, Y. (2013). Dynamic channel reordering toreduce latency during surfing periods in IPTV networks. IEEETransactions on Broadcasting, 59(3), 471–483.

Banodkar, D., Ramakrishnan, K.K., Kalyanaraman, S., Gerber, A. andSpatscheck, O. (2008, January). Multicast Instant Channel Change inIPTV Systems, Communication Systems Software and Middlewareand Workshops, 3rd International Conference on, Bangalore,pp. 370–379.

Bejerano, Y. and Koppol, P.V. (2009). Improving Zap Response Time forIPTV. IEEE INFOCOM, Rio de Janeiro, pp. 1971–1979.

Beyragh, A.A. and Rahbar, A.G. (2014). IFCS: An intelligent fast channelswitching in IPTV over PON based on human behavior prediction.Multimedia Tools and Applications, 74, 1049–1071.

Boyce, J. and Tourapis, A. (2005, November). Patent (WO/2005/112465):Method and Apparatus Enabling Fast Channel Change for DSL System(Assignee: Thomson).

Page 198: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 181

Cha, M., Rodriguez, P., Crowcroft, J., Moon, S. and Amatriain, X. (2008).Watching Television over an IP Network. In Proceedings of the 8thACM SIGCOMM Conference on Internet Measurement, ACM, pp.71–84.

Cho, C., Han, I., Jun, Y. and Lee, H. (2004). Improvement of ChannelZapping Time in IPTV Services Using the Adjacent Groups Join-LeaveMethod. Proceedings of the 6th International Conference on AdvancedCommunication Technology, vol. 2, pp. 971–975.

Joo, H., Song, H., Lee, D. and Lee, I. (2008). An effective IPTV channelcontrol algorithm considering channel zapping time and networkutilization. IEEE Transactions on Broadcasting, 54(2), 208–216.

Khosroshahi, A.A., Yousefi, S. and Rahbar, A.G. (2016). IPTV channelswitching delay reduction through predicting subscribers’ behaviorsand preferences. Multimedia Tools and Applications, doi10.1007/s11042-015-2572-y.

Kramer, G., Mukherjee, B. and Pesavento, G. (2002, February). IPACT: Adynamic protocol for an Ethernet PON (EPON). IEEECommunication Magazine, 40(2), 74–80.

Lee, E. and Park, S. (2010, February). Internet Group ManagementProtocol for IPTV services in passive optical network. IEICETransaction on Communications, E93-B(2), 293–296.

Lee, E., Ku, J.Y. and Bahn, H. (2014). An efficient hot channelidentification scheme for IPTV channel navigation. IEEE Transactionson Consumer Electronics, 60(1), 124–129.

Lee, E., Whang, J., Oh, U., Koh, K. and Bahn, H. (2009). A popularchannel concentration scheme for efficient channel navigation inIPTV. IEEE Transactions on Consumer Electronics, 55(4), 1945–1949.

Lee, J., Lee, G., Seok, S. and Chung, B. (2007). Advanced Scheme toReduce IPTV Channel Zapping Time. Proc. Managing NextGeneration Networks and Services, Lecture Notes Computer Science,vol. 4773. Springer, Berlin, pp. 235–243.

Lee, Y., Lee, J., Kim, I. and Shin, H. (2008, May). Reducing IPTV channelswitching time using H.264 scalable video coding. IEEE Transactionson Consumer Electronics, 54(2), 483–487.

Liu, Y., Liu, Z., Wu, X., Wang, J. and Yang, C. (2011). IPTV system design:An ISP’s perspective. International Conference on Cyber-EnabledDistributed Computing and Knowledge Discovery, 234–240.

Luo, J., Yun, T., Zhang, M., Zhao, L. and Yang, S. (2006). Design andDeployment of a Peer-to-Peer Based IPTV System over Global

Page 199: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

182 IPTV Delivery Networks

Internet. First International Conference on Communications andNetworking, China.

Manjunath, L. and Mastani, S.A. (2013, May–June). A novel approach forincreasing channel navigation in IPTV based on user’s channelselection interests. International Journal of Engineering Research andApplications (IJERA), 3(3), 1331–1336.

Manzato, D.A.G. and Nelson, L.S. da Fonseca (2013, August). A Surveyof Channel Switching Schemes for IPTV. IEEE CommunicationsMagazine, pp. 120–127.

O’Driscoll, G. (1999). The Essential Guide to Digital Set-top Boxes andInteractive TV . Prentice Hall PTR Upper Saddle River, NJ, USA.

Punchihewa, A., Silva, A.M.D., and Diao, Y. (2010). Internet ProtocolTelevision (IPTV), Multi-media Research Group, School ofEngineering and Advanced Technology, Massey University, NewZealand.

Ramos, F.M.V., Crowcroft, J., Gibbens, R.J., Rodriguez, P. and White, I.H.(2011). Reducing channel change delay in IPTV by predictivepre-joining of TV channels. Signal Processing: Image Communication,26, 400–412.

Richardson, I.E. (2003). H.264 and MPEG-4 Video Compression: VideoCoding for Next-generation Multimedia. New York: John Wiley andSons.

Sarni, M., Hilt, B. and Lorenz, P. (2009). A Novel Channel SwitchingScenario in Multicast IPTV Networks. IEEE Fifth InternationalConference on Networking and Services, Valencia, pp. 396–401.

Tian, X., Cheng, Y. and Shen, X. (2013). Fast channel zapping withdestination-oriented multicast for IP video delivery. IEEETransactions on Parallel and Distributed Systems, 24(2), 327–341.

Wallendael, G.V., Lancker, W.V., Cock, J.D., Lambert, P., Macq, J.-F. andde Walle, R.V. (2012). Fast channel switching based on SVC in IPTVenvironments. IEEE Transactions on Broadcasting, 58(1), 57–65.

Yoon, J., Park, S. and Choe, S. (2011, May). Implementation of EIGMPfor fast IPTV channel change in GEPON. IEEE Transactions onConsumer Electronics, 57(2), 484–491.

Zare, S. and Rahbar, A.G. (2014). Congestion control in IPTV over PONusing Digital Fountain forward error correction. Journal of Networkand Computer Applications, 37, 240–252.

Page 200: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Channel-Zapping Time in IPTV: Challenges and Solutions 183

Zare, S. and Rahbar, A.G. (2016). Program-driven approach to reducelatency during surfing periods in IPTV networks. Multimedia Toolsand Applications, 75(23), Springer, pp:16059–16071.

Zeadally, S., Moustafa, H. and Siddiqui, F. (2011). Internet ProtocolTelevision (IPTV): Architecture, trends, and challenges. IEEE SystemsJournal, 5(4), 518–527.

Page 201: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

185

7

Delivering High-Definition IPTV Services overIP-Based NetworksSeongik Hong

7.1 Introduction

IPTV is considered one of the most profound inventions since itscreation in the 1960s. At first, it served as a backbone for the intercon-nection of regional academic and military networks until the 1980s.In the 1990s, commercial use of the Internet became available bythe dispersion of the World Wide Web (WWW). In the early 2000s,voice-over IP service was growing rapidly, which was the beginningof the multimedia transport over IP.

IPTV (Cisco, 2013; Nokia 2006; Huawei, 2010; O’Driscoll, 2008)delivers television services over the Internet instead of traditionalTV networks such as terrestrial, satellite signal-based, and cable TV.IPTV services have become popular because of features such as videoon demand (VoD) and time-shifted television, which replay TV showsthat have been broadcast earlier. It means unlike the unidirectionaltraditional broadcasting television services, IPTV offers the ability ofbidirectional services. Users can request specific multimedia contentand the content provider can supply them. As a result, IPTV serviceshave become very popular. The global IPTV market was valued at$24.94 billion in 2013 and is expected to reach $79.38 billion by 2020,growing at a compound annual growth rate (CAGR) of 18.1% from2014 to 2020.

In addition, as the Internet technology has been evolving, thedemand for IPTV services also has been growing because videotransmission with higher resolutions can be provided seamlessly.

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 202: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

186 IPTV Delivery Networks

Past Present

GPRS 56Kbps

Analog 56Kbps

1Mbps

10Mbps

100Mbps

1Gbps

ADSL 256Kbps

ADSL 1.2Mbps

ADSL2 12Mbps

ADSL2 + 24Mbps

VDSL2>200Mbps

PON 1∼10Gbps

WCDMA 384Kbps

HSPA 14Mbps

HSPA + 21Mbps

HSPA + 42Mbps

LTE>150Mbps

LTE Adv

1Gbps

Future

Figure 7.1 Evolution of Internet technology.

As shown in Figure 7.1 (Karthikeyan, 2011), along with the network-ing technology advancements, the available bandwidth has increasedtremendously.

Due to the rapid dispersion of high-speed Internet, users can accesshigh-quality contents easily. As Figure 7.2 shows, the portion of

Per

100 inhabitants

0

2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015*

10.8

14.5

43.4

47.2

96.8Mobile-cellular telephone subscriptions

Global ICT developments, 2001–2015

Individuals using the Internet

Fixed-telephone subscriptions

Active mobile-broadband subscriptions

Note: * Estimate

Source: ITU World Telecommunication/ICT Indicators database

Fixed (wired)-broadband subscriptions

10

20

30

40

50

60

70

80

90

100

Figure 7.2 Global ICT developments (ITU-T, 2015).

Page 203: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Delivering High-Definition IPTV Services over IP-Based Networks 187

individuals using the Internet has been increasing gradually from theearly 2000s. Recently, the number of active subscription of mobilebroadband services has risen dramatically. As display devices withhigh resolution such as large screen monitors, TVs and smartphonesare also easily available, the demand for HD IPTV should increase.

HD television (HDTV) in the USA was introduced in 1998 andhas become dominant in the television market (High, 2016). HDTVmay be transmitted in various formats such as 1080p (1920× 1080per frame), 1080i (1920× 1080 per frame) and 720p (1280× 720p,per frame) where the letter ‘p’ and ‘i’ stand for progressive and inter-laced scan, respectively. Progressive scanning is a way of displaying,storing or transmitting moving images in which all the lines of eachframe are drawn in a sequence. This is in contrast to the interlacedvideo where the odd and even numbered lines of frames are drawnalternately. Ultra-high-definition (UHD) television includes 4K UHD(3840× 2160 pixels) and 8K UHD, which are two digital video formatsapproved by the International Telecommunication Union (ITU). 4KUHD has 4 times as many pixels as the full HD. Now high-qualityvideo contents are widely available through IPTV and online stream-ing providers. In addition, broadcast service providers announced a4K video content sources. The world’s first UHD IPTV broadcastingservice was launched in 2014 (Son, 2015).

However, there are several problems in delivering HD video contentover the Internet. With IP, a packet in the network layer is deliveredfrom a source to a destination using the destination IP address. It is dis-tinct from the traditional radio (audio) and television (video) servicesfrom the viewpoint of delivery units. In the traditional broadcast ser-vices, the transmission media type is analogue such as electromagneticwaves. To provide those services with IP-based networks, we need todigitise the content, fill up the packets and send them. This differencecauses some problems especially in providing HD services. First, weneed a large bandwidth to transmit as many packets to ensure the HDquality of services (QoS). Second, we need to control the transmissionof packets to support the required QoS. When the Internet was firstintroduced, it was not expected to deliver multimedia, and thereforemaintaining the QoS was not a concern at all. Among many factors ofQoS, it is said that packet loss and delay are the most critical factors.Finally, network responsiveness/instant channel change is defined asthe time for a user to wait to actually watch the new channel when theuser changes the channel. It is often called finger-to-eye time.

Page 204: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

188 IPTV Delivery Networks

In the following sections, we describe the challenges mentionedabove and propose the solutions to those problems.

7.2 HD Video Compression

Multimedia compression techniques also play an important role in thedispersion of IPTV services. Compression is a must for multimediatransmission as it tremendously reduces the amount of required band-width. It is known that the lossless video compression rate is up to5-12, and typical moving pictures experts group (MPEG)-4 lossy videocompression rates are between 20 and 200. In this section, we brieflydescribe the basic concepts and techniques for video compression thatare commonly used in delivering HD IPTV services.

It is typically defined that HD videos have a vertical resolutionof 720p or higher. For the compression of HD videos, H.264 orMPEG-4 Part 10, and advanced video coding (MPEG-4 AVC) are themost commonly used ones. H.264 is said to be more complex thanMPEG-2, which is also one of the mainstream HD video compressionstandards. However, the data compression rate of H.264 is about 2times better than that of the MPEG-2. More IPTV providers useH.264 video compression techniques for HD videos. If the HDTVstreaming data is compressed by H.264, the bandwidth required for1080i resolution is 6–8 Mbps, and 1080p video streaming requires12–16 Mbps (ITU-T, 2012). High efficiency video coding (HEVC,H.265 [ITU-T, 2013]) was newly developed by the joint collaborativeteam on video coding (JCT-VC). It was aimed that HEVC will at leastdouble the compression efficiency of H.264 AVC.

7.2.1 Issues for HD Video Transmission

In this section, we describe the challenges that HD video deliverybrings to the networks. HD video delivery requires (1) a largebandwidth, (2) a low packet loss/corruption rate and (3) minimalchannel-change latency.

7.2.1.1 Issue 1: Large Bandwidth RequirementsAs described in Section 7.2.1, we need at least several Mbps bandwidthto deliver the HD video. For the UHD services, it requires 24–32 Mbpseven with the advanced encoding technologies such as H.265 HEVC.

Page 205: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Delivering High-Definition IPTV Services over IP-Based Networks 189

8K UHD is the current highest resolution in digital television with totalimage dimensions of 7680× 4320 pixels. It will require four times asmuch bandwidth as 4K UHD, or 16 times as much as full HD.

7.2.1.2 Issue 2: QoSIPTV service has very stringent QoS requirements on packet loss anddelay (Li et al., 2009). Packet loss is one of the principal threats toquality of experience (QoE) for IPTV systems. It may result in mosaiceffects in display. It is said that a delay longer than 1 s does not satisfythe user’s QoE.

The European Telecommunications Standards Institute (ETSI) digi-tal video broadcasting (DVB) standards recommend no more than oneerror per hour of video. Applying this to the MPEG-4 video, the result-ing packet loss rate (PLR) should be no greater than 7.8 x 10E−7. Mostcontent providers allow xDSL bit error rates (BERs) around 10E−6.

Figure 7.3 shows how the DSL-Forum TR-126 specification definesthe packet loss rate (PLR) requirements for different video coding for-mats. To support a higher transport stream, we require a smaller PLR.HD video requires the PLR to be less than 10E−07.

7.2.1.3 Issue 3: Network Responsiveness/Instant Channel ChangeAnalogue TVs do not compress any contents, and videos are displayedas soon as the signals are received without any decoding process. If auser changes the channel, it displays instantly. IPTV must maintain thelatency of channel change within a reasonable limit. Both MPEG-2 andH.264 use the group of pictures (GoP) concepts. The GoP comprises

Transport stream bit rate (Mbps)0

1,0E-08

1,0E-07

Table 12

(MPEG-2 SDTV)

Table 15

(MPEG-2 AVC HDTV)

Table 13

(MPEG-4 AVC SDTV)

Table 14

(MPEG-2 HDTV)

1,0E-06

PLR

1,0E-05

2 4 6 8 10 12

1 Hour between loss events

2 Hours between loss events

4 Hours between loss events

14 16 18

Figure 7.3 Packet loss rate for isolated loss events (DSL Forum, 2006).

Page 206: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

190 IPTV Delivery Networks

a single intra-coded frame (I-frame) and multiple bidirectional andpredicted frames (B- and P-frames). I-frames are base frames contain-ing complete image information. The I-frame is the least compress-ible frame and contains the largest amount of data traffic in the sameGOPs. A P-frame holds only the changes in the image from the previ-ous frame. For example, in a scene where an object moves in a station-ary background, only the object’s movements need to be encoded. Theencoder does not store the unchanged background image. P-framesare also known as delta frames. P-frames are more compressible thanI-frames. When producing B-frames, the encoder looks at both for-wards and backwards frames to remove redundant image information.This makes B-frames the most efficient frame among the three typesof frames.

MPEG transport stream (MPEG-TS) is a standard container formatfor the transmission of audio and video. If IPTV data is contained inthis format, the programme-specific information (PSI) tables are usedto include the programme association table (PAT) and programmemap table (PMT) information. The PAT and PMT contain informationabout programmes.

Instant channel-change delay is influenced by many factors such asInternet Group Management Protocol (IGMP) processing, data planeprotocol processing and MPEG decoder delay. Among all these causes,the largest part is the MPEG decoder delay. For the receiver to decodethe compressed video streams, it should wait for at least one I-frameas it is an independent image frame. The delay is dependent on thecompression rate and the number of B- and P-frames between twosuccessive I-frames. If we increase compression rates, we need to usea large-size GOP, which indicates increased number of B-frames andthat we need more time to encode and decode. In addition, the receivercannot start decoding until it receives the PAT or PMT information.

7.2.2 Solutions

7.2.2.1 Solution 1: Solving Large Bandwidth RequirementsIPTV videos consume large bandwidths. But most of the bandwidthsare consumed by redundant traffic from the unicast communicationbetween user clients and video servers. We describe a couple ofmethods that have been widely used to eliminate the redundancy andreduce the consumed bandwidths.

First, the multicast technology: When the streaming server sends thesame data to multiple receivers, it just sends one copy and duplicates

Page 207: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Delivering High-Definition IPTV Services over IP-Based Networks 191

where paths diverge (i.e., at the multicast points) rather than sendingmultiple copies all the way from the sender to all the receivers. In thisway, the consumed bandwidths can be decreased. Multicast can bebuilt at different layers of a network, for example, network-layer mul-ticast (or IP multicast) and application-layer multicast. IP multicastpackets are sent to a group, and only members of the group receivethe packets. The group is identified by a single IP multicast address.To support the IP multicast, network equipment should support thosefunctionalities. In application-layer multicasts, data packets are repli-cated to end-users in an overlay network. Due to the limited deploy-ment of IP multicast, this alternate approach called overlay multicastutilising only end-systems have been widely spread. In this approach,end-user peers organise themselves into an overlay multicast tree, dothe grouping and transmit data.

In IPTV multicasts, Protocol-Independent Multicast Source Spe-cific Multicast (PIM SSM) at the network layer has been generallyused. SSM extends the concept of any source multicast (ASM) inwhich any host can act a source in a multicast group to identify a setof multicast hosts by the group’s address and also by source. An SSMgroup is identified as (S, G) where S is the source address and G isthe group address. In this mode, the edge router should identify theIP address of the multicast source. The router will launch a PIM joinrequest to the corresponding source.

Another method is to utilise content delivery networks (CDNs).CDNs can reduce the content delivery traffic by providing cached con-tents at geographically dispersed edge servers to content requestors.Users’ requests can be forwarded to the nearby surrogate CDNservers by using domain name system (DNS) redirection or uniformresource locator (URL) rewriting techniques. There are several typesof CDN providers as follows (Netmanias, 2013; Hong et al., 2015).

A. Pure play CDN: The CDN service providers operate surrogateservers around the world and provide CDN services to customerswho want to distribute their content faster to user locations.In this type of CDN, DNS redirection techniques are used andservices are provided by the CDN servers scattered geographi-cally. HD video-streaming services from Netflix and Hulu haveleveraged pure play CDN providers such as Akamai, Level 3Communications and Limelight Networks.

B. Telco CDN: Tele-communication companies (Telco) own the lastmile networks and can deliver the contents closer to end-users.

Page 208: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

192 IPTV Delivery Networks

In addition, as the network operators want to extend their servicesbeyond the communication and networking area, they began toprovide the CDN services utilising their existing network infras-tructures. The topology and operations of this type of CDN is simi-lar to the pure play CDN except that it is operated by IPTV carriers.For example, AT&T, BT, Orange, Telefonica and Verizon operatethis type of networks.

C. Wholesale CDN: In a wholesale CDN model, the network oper-ators offer their CDN facilities to content providers seeking todeliver their online content. The topology and operations are thesame as those of the pure play CDN. For example, the BritishBroadcasting Corporation (BBC) has participated in the wholesaleCDN technology trials to deliver content over the IP networksprovided by British Telecom in the UK.

D. Transparent caching: With transparent caching, content is storedand served from the edge node of the operator’s network. The nodedoes the deep packet inspection and helps save the transit networkbandwidths by answering the content requests of subscribers. Inthe operator transparent caching, there is no functionality of redi-rection to the content servers. If a request packet happens to passby the specific edge node equipped with this type of cache, therequest can be answered by that node. ARA Networks, Huawei,Juniper and PeerApp are players for transparent caching platforms(Rayburn, 2012).

7.2.2.2 Solution 2-1: QoS: Protocols and NetworksDelivering HD IPTV services over the Internet is complex as theunderlying IP networks do not guarantee any kind of QoS support.QoS is particularly important for the transport of IPTV traffic asIPTV services are mostly real-time, which means we do not playthem after we download first. Various mechanisms to guarantee QoSare increasingly available. In this section, we describe the efforts toprovide QoS from the viewpoints of the protocols and networks.

The most common protocols used for IPTV services are streamingtechnologies. Streaming is a technique for a provider to transmitmultimedia constantly to an end-user. By streaming, end-users do notneed to download the entire content first. The client media player canbegin to play the content before the entire file has been transmitted.

Page 209: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Delivering High-Definition IPTV Services over IP-Based Networks 193

In addition, streaming protocols provide controls on the multimediasessions such as start, stop and pause of packet transmissions anddetection of out-of-order packets so that IPTV services can beprovided smoothly, satisfying the QoS requirements.

Streaming services are provided by multiple transport protocolssuch as Real-time Streaming Protocol (RTSP) (Schulzrinne, Rao andLanphier, 1998), Real-time Transport Protocol (RTP) (Schulzrinneet al., 2003) and Real-time Control Protocol (RTCP) (Huitema, 2003).The RTSP is a protocol to control streaming media sources. It is usedfor establishing and controlling media sessions between the serverand client. Clients issue RTSP OPTION, DESCRIBE, SETUP, PLAY,RECORD and PAUSE commands to facilitate real-time control of themedia streaming. The servers transmit streaming data to the receiversaccording to the control messages. However, the data transmissionitself is not conducted by the RTSP. Most RTSP servers use theRTP with the RTCP. The RTP is designed for the transmission ofreal-time streaming data. The protocol provides mechanisms for jittercompensation mechanism and out-of-sequence packet detection. Inthis way, these streaming protocols satisfy the QoS requirements forIPTV services. In addition, RTP supports IP multicast that enablesdata transfer to multiple destinations. The RTCP works with theRTP but its primary function is to gather QoS statistics and providefeedback to the client streaming players in the session. Stream ControlTransmission Protocol (SCTP) and Adobe’s Real-time MessagingProtocol (RTMP) (Parmar and Thornburgh, 2012) are the popularstreaming protocols that work with transmission protocols such asRTSP, RTP and RTCP.

Hypertext Transfer Protocol (HTTP) is also widely used in deliv-ering streaming contents. Dynamic adaptive streaming over HTTP(DASH) (ISO/IEC, 2012), which is also known as MPEG-DASH isan adaptive bitrate streaming technique that enables high-qualitystreaming of IPTV contents. DASH breaks the IPTV content into aseries of small HTTP segments. The content source data can be madeinto different bit rates. While the client plays the content, the clientcan choose the next segment with other bit rates based on currentnetwork conditions. For example, the client can choose the segmentwith the highest bit rate possible at first, but it can change the bit rateand reduce the size of the HTTP segments if the network condition

Page 210: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

194 IPTV Delivery Networks

is not good. Thus, the IPTV services based on MPEG-DASH canseamlessly adapt to changing network conditions and satisfy QoSrequirements under any network conditions.

Multiprotocol label switching (MPLS) (Rosen, Viswanathan andCallon, 2001) is a mechanism to direct packets on the shortest pathusing 20 bit ‘labels’ rather than the longer IP-based network addresses.The labels describe virtual paths between two endpoints and byavoiding complex routing table lookups enable high-performancetransmission of packets. The label switching is faster than the IProuting table lookup as it is done within the switching fabric and notin the CPU. In IP networks, the shortest path between two end nodesis chosen regardless of the path conditions. However, with the MPLSfunctionalities, the bandwidth of the links in each candidate paths canbe considered, such that the shortest path with appropriate bandwidthconditions will be chosen. MPLS traffic engineering (TE) relies uponthe use of TE extensions to open shortest path first (OSPF) or otherrouting protocols. In addition to the bandwidth constraints, users canalso specify their own constraints using certain link attributes. In thisway, MPLS networks help IPTV services satisfy QoS requirements.

In this section, we describe how the various protocols and theMPLS network can compensate for the lack of QoS guarantee in IPnetworks. However, in high-quality video streaming, special care isneeded to reduce the packet loss because errors potentially propagateacross many frames in the compressed videos, and the decoded videoquality becomes too poor to view. In the following section, we willshow how to reduce the packet loss.

7.2.2.3 Solution 2-2: QoS: Reducing Packet LossPacket losses and corruptions are critical factors to the quality ofvideos. With traditional TV services that are delivered over traditionalmedia such as hybrid fibre coaxial (HFC) networks, the quality isguaranteed as there is no congestion; therefore we do not needto worry about packet loss or image corruption. However, IPTVservices are affected by various end-to-end path conditions such asbackbone Internet congestion and last mile wireless transmissionerrors. Figure 7.4 shows the impact of packet loss in the video stream.Only the 0.5% loss of incoming packets can degrade the streamingquality tremendously.

To reduce the packet loss/corruption rate, most IPTV equipmentvendors provide a combination of multicast forward error correction

Page 211: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Delivering High-Definition IPTV Services over IP-Based Networks 195

Figure 7.4 Video degradation bypacket loss.

(a) Original

(b) 0.5% packet loss

(c) 5% packet loss

(FEC) and unicast automatic retransmission request mechanism(Cisco, 2013; Nokia, 2006; Huawei, 2010). If we use the FEC, anFEC stream is multicast from the source to the users. Researchershave proposed mechanisms to selectively retransmit only the mostimportant data in the bitstream (Feamster and Balakrishnan, 2002).However, there is also an argument that retransmission-based errorresilience is not efficient because it takes at least one additionalround-trip time to retransmit the lost data (Bolot and Turletti, 1998).To provide scalable on-demand media streaming, many other mech-anisms such as periodic broadcast protocols (Hu, 2001), patching(Hua, Cai and Sheu, 1998) and bandwidth skimming (Eager, Vernonand Zahorjan, 2000) have been proposed. Among these, we describethe details of an approach that combines the FEC and retransmissionmechanism (Huawei, 2010).

In this approach, we assume multicast capabilities are available andeach user set-top box (STB) may be joined with one of the multiplemulticast sessions. Each multicast group shares a primary video

Page 212: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

196 IPTV Delivery Networks

Video caching point

Video

streaming

server

IP Router

Regional broadband

network

Regional access network

Customer

premises

network

STBOLT

Eth ACG

BNG

Access network

Figure 7.5 Network architecture for Ethernet-based Gigabit passive opticalnetworks (GPON) aggregation.

stream and the corresponding FEC stream(s). If an error occurs inthe video stream: (1) the STB attempts to recover the missing packetsusing the FEC packets. (2) If this fails, it requests the server to retrans-mit the packet. The following procedure shows the retransmissionprocess.

1. The networking equipment lying between the server and thereceiver STB may contain cache storing the video streams for acouple of seconds. Those can be optical line termination (OLT),aggregation ethernet switch (Eth AGG) or broadband networkgateway (BG) in the access network area as shown in Figure 7.5.

2. The receiver checks for any missing packets by checking the order ofthe RTP sequence numbers for the packets. The sequence numberis incremented by 1 when the sender transmits each packet. Thereceiver uses the number to detect packet loss (if there are missingnumbers) and to restore packet sequence (if the numbers are not inorder).

3. The receiver plays the role of the RTP Control Protocol (RTCP)receiver that tells the sender or the multicast group some param-eters such as loss rate and jitter. In this case, if packets are miss-ing, the receiver sends a RTCP request to the upstream networkingequipment.

4. One of the networking equipment in the upstream networks for-wards the lost packets to the receiver.

5. Upon receiving the retransmitted packet, the receiver recovers andplays the corresponding video stream.

Page 213: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Delivering High-Definition IPTV Services over IP-Based Networks 197

The network architecture in Figure 7.5 shows the access networktopology and video caching points. As mentioned above, the retrans-mission mechanism uses the sequence number in the RTP header todetect whether a packet loss occurs or not.

In this mechanism, retransmission has occurred between nearbyequipment. If a packet loss occurs between the two equipment,the equipment closer to the user can play the role of requestingretransmission and the equipment closer to the content providerreplies with the lost packets.

7.2.2.4 Solution 3: Solving Instant Channel Change IssueIn this section, we will analyse the issue of reducing instant channelchange and show the solutions. In the broadcasting environment, allthe channels are broadcast simultaneously. So even if we change thechannel, we should be able to see the new channel without any delay.However, in the IPTV environment where the compressed packets foronly one specific channel are received, we cannot decode the receivedframes until we receive the first I-frame packet containing the PSIinformation for the new channel after we change the channel. Thus,the channel change time in IPTV services is mostly the I-frame andPSI latency. PSI comes in the video stream at an interval between 100and 500 ms. For the I-frame, the time between successive appearancescan be up to a few seconds.

To reduce the waiting time for the PSI information and I-frames, oneeasy approach may be to send the PSI and I-frames frequently. How-ever, it reduces the compression rate. Instead, we can cache some PSIinformation and I-frame packets in the intermediate network equip-ment and send them to the user when it is needed. The following pro-cedure describes how this works (Huawei, 2010).1. When the content provider transmits the video packets, the net-

work equipment in the middle cache the video packets for a while.The cached video should contain a few GoPs and PSI information.

2. If a channel change occurs, an IGMP leave message is sent to tell thesender to stop sending the video multicast packets. Instead, a uni-cast RTCP channel change request is sent to the upstream networkequipment by the corresponding STB.

3. If a network equipment receives the channel change request, itsends the cached PSI information and I-frames of the currentchannel to the receiver. This can reduce the PSI waiting time. Thenthe network equipment sends the unicast video stream packets forthis channel to the STB.

Page 214: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

198 IPTV Delivery Networks

4. If the networking equipment decides that the unicast streams sentat a faster rate are in the same pace with the multicast streams, itsends a message to stop forwarding the unicast stream. Then thereceiver joins the multicast group for the changed channel.

5. The network equipment stops sending unicast video packets.

The mechanism mentioned above has been implemented in mostIPTV equipment vendors with retransmission technology (Cisco,2013; Huawei, 2010).

7.3 Future Trends

Until now, we have described the current technologies to manage theissues in providing HD IPTV services. In this section, we show thefuture of HD IPTV services.

In the near future, UHD services with a better resolution thanHD will become popular. UHD television includes 4K and 8K UHDthat have been defined by ITU in BT.2020-2 (10/2015). The standarddefines two UHDTV profiles: UHD-1 (3840× 2160) and UHD-2(7680x4320). The 4K UHD channels have become available in IPTVbut it is not so popular yet. The main burden is that even the 4K UHDservices require less than 20 Mbps bandwidth but it is still muchhigher than the 1080p HD stream (typically 6 Mbps). It is a big burdenfor most home and cellular broadband connections.

5G (5th generation mobile networks) (Next Generation Mobile Net-works (NGMN), 2015) describes the next mobile telecommunicationsstandards after the current 4G long term evolution (LTE) standards.The NGMN Alliance defines the requirements for 5G networks asat least 50 Mbps (up to 1 Gbps in some specific cases) and ultra-lowlatency. With this bandwidth, 4K or 8K UHD streaming has becomeplausible. Also, ultra-low latency requirement will help improve theQoS. NGMN also assumes beyond 2020, the video transmission withmuch higher resolution will be spread for use, for example, ‘opticalhead-mounted displays’, ‘collaboration in 3D cyber-real offices’ and‘customers’ support by hologram services’.

Cloud computing will also play an important role by placing HDcontent more closely to the users than CDN servers. Cloud computingmeans sharing computing resources rather than having local serversto handle applications. It enables ubiquitous and on-demand access

Page 215: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Delivering High-Definition IPTV Services over IP-Based Networks 199

to the computing resources and storage. NGMN alliance also assumesthat personal devices will have more capabilities such as personalhigh-quality video content production and its sharing, cloud gamingand mobile TV.

Virtualisation refers to creating virtual machines including virtualresources such as computing resources, storages and networks. Virtualmachines act like real computers and software. IPTV service providerscan utilise the cloud infrastructure by intelligently shifting the load tothe newly launched virtual resources so that they can meet the strictdeadlines for each service. By leveraging virtualised cloud infrastruc-ture, it will be possible to reduce the instant channel change time andimprove video streaming efficiency (Aggarwal et al., 2013).

7.4 Conclusion

In this work, we described the issues on how to provide HD IPTV ser-vices over the current Internet. It is not an easy task as (1) HD contentsources require a large bandwidth, (2) underlying IP networks do notprovide QoS guarantee and (3) there are other intrinsic issues in IPTVssuch as instant channel-change delay. We analysed the root cause ofthese issues and have shown how current technology has overcomethose issues. We have also shown future networking technology trendsand how we can leverage them to provide HD IPTV services.

References

Aggarwal, V., Gopalakrishnan, V., Jana, R., Ramakrishnan, K.K. andVaishampayan, V.A. (2013). Optimizing cloud resources for deliveringIPTV services through virtualization. IEEE Transactions onMultimedia, 15(4), 789–801.

Bolot, J.C and Turletti, T. (1998). Experience with control mechanismsfor packet video in the Internet. SIGCOMM ComputerCommunication Review, 28(1).

Cisco (2013). IPTV Solutions for Wireline Carriers [online]. Available at:http://www.cisco.com/c/en/us/solutions/service-provider/iptv-solutions-wireline-carriers/index.html [Accessed 5 August 2016].

DSL Forum, 2006. Technical Report TR-126, Triple-play Services Qualityof Experience (QoE) Requirements.

Page 216: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

200 IPTV Delivery Networks

Eager, D.L., Vernon, M.K. and Zahorjan, J. (2000). Bandwidth Skimming:A Technique for Cost-Effective Video-on-Demand. Proceedings ofMMCN ’00. San Jose, CA, US.

Feamster, N. and Balakrishnan, H. (2002). Packet Loss Recovery forStreaming Video. The 12th International Packet Video Workshop.Pittsburgh, PA, US.

High Definition Television in the United States, 2016 [online]. Availableat: https://en.wikipedia.org/wiki/High-definition_television_in_the_United_States [Accessed 5 August 2016].

Hong, S., Lee, B.-J., Yoo, C.-M., Do, M.-S., and Son, J.W. (2015).Comparative Study of Content-Centric vs. Content DeliveryNetworks: Quantitative Viewpoints. In Proceedings of the 10thInternational Conference on Future Internet (CFI).

Hu, A. (2001). Video-on-Demand Broadcasting Protocols: AComprehensive Study. Proceedings of IEEE INFOCOM, Anchorage,AK.

Hua, K.A., Cai, Y. and Sheu, S. (1998). Patching: A Multicast Techniquefor True Video-On-Demand Services, Proceedings of ACM Multimedia’98, Bristol, U.K.

Huawei Technology, 2010. Technical White Paper for HDTV BearerNetworks [pdf ]. Available at: http://www.huawei.com/es/static/HW-076764.pdf [Accessed 5 August 2016].

Huitema, C. (2003). RFC 3605. Real Time Control Protocol (RTCP)attribute in Session Description Protocol (SDP). IETF.

ISO/IEC (2012). DIS 23009-1.2, Dynamic Adaptive Streaming overHTTP (DASH).

ITU (2015). Global ICT Developments. In 2015, 3.2 Billion People areUsing the Internet of Which 2 billion are from Developing Countries.ITU [online]. Available at: http://www.itu.int/en/ITU-D/Statistics/Pages/stat/default.aspx [Accessed 5 August 2016].

ITU-T (2012). Recommendation H.264 and ISO/IEC 14496-10(MPEG4-AVC), Advanced Video Coding for Generic AudiovisualServices.

ITU-T (2013). Recommendation H.265 (04/13), Series H: Audiovisualand Multimedia Systems, Infrastructure of AudiovisualServices-Coding of Moving Video, High Efficiency Video Coding.

Karthikeyan (2011). Internet and Its Evolution in Technologies [online].Available at: http://www.tothetech.com/technology/internet-and-its-evolution-in-technologies.html [Accessed 5 August 2016].

Page 217: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Delivering High-Definition IPTV Services over IP-Based Networks 201

Li, Z., Zhu, X., Begen, A.C. and Girod, B. (2009). Peer-Assisted PacketLoss Repair for IPTV Video Multicast. The 17th ACM InternationalConference on Multimedia, Beijing, China.

Netmanias Consulting Group (2013). Content Networking Trends – OTT,Global CDN and Operator CDN [online]. Available at: http://www.netmanias.com/en/?m=view&id=reports&no=6015 [Accessed 5August 2016].

NGMN (2015). 5G Initiative Team, 2015. NGMN 5G Initiative WhitePaper by NGMN Alliance, v1.0. [pdf ]. Available at: https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf [Accessed 5August 2016].

Nokia Siemens Networks (2006). High-Quality and Resilient IPTVMulticast Architecture. Technical White Paper [pdf]. Available at:http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.5063&rep=rep1&type=pdf [Accessed 5 August 2016].

O’Driscoll, G. (2008). Next Generation IPTV Services and Technologies.New York: John Wiley & Sons, Inc.

Parmar, H. Ed. and Thornburgh, M. Ed. (2012). Adobe’s Real TimeMessaging Protocol. Adobe Developer Connection.

Rayburn, D. (2012). List of Vendors in the Content Delivery andTransparent Caching Markets [online]. Available at: http://blog.streamingmedia.com/2012/08/updated-list-of-vendors-in-the-content-delivery-and-transparent-caching-markets.html [Accessed 5August 2016].

Rosen, E., Viswanathan, A. and Callon, R. (2001). RFC 3031,Multiprotocol Label Switching Architecture. IETF.

Schulzrinne, H., Rao, A. and Lanphier, R. (1998). RFC 2326, Real TimeStreaming Protocol (RTSP). IETF.

Schulzrinne, H., Casner, S., Frederick, R. and Jacobson, V. (2003). RFC3550, H. RTP: A Transport Protocol for Real-Time Applications. IETF.

Son, H.J. (2015). Korea Telecom IPTV (4K UHD) Service [online].Available at: http://www.netmanias.com/en/post/blog/7537/4k-iptv-kt-korea-uhd/kt-iptv-4k-uhd-service-1-live-tv [Accessed 5 August2016].

Page 218: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

203

8

IPTV Network Security: Threats andCountermeasuresM. S. A. Noman Ranak, Saiful Azad, B. M. F. Kamal Ruhee,N. Nourin Nisa, Nazrul Kabir, Mohammed Mostafizur Rahman andKamal Z. Zamli

8.1 Introduction

As it has been offering a diversity of services such as high-qualitymultimedia contents, interactivity, reliability, quality of service (QoS),quality of experience (QoE) and so forth, IPTV has been attractingmany consumers (Motoi and Ken’ichi, 2017; Alsaffar, Shin and Huh,2015). In IPTV, television contents are distributed across IP-basednetworks that permit a customised and interactive user experience(Fati et al., 2017).

With the increasing popularity of these services, the attacks andthreats to IPTV have also been increasing, and that remains animportant concern. Security problems may arise at various pointsof IPTV networks – for instance, home networks, delivery andmanagement networks, content source and so forth (Vasanthi andChidambaram, 2014). An attacker may take control of the entire homenetwork by spreading worms, viruses and Trojans, and afterwardscan disrupt the service, steal the contents and so on. In delivery andmanagement networks, authentication thefts, middleware-relatedproblems, streaming/encoding server problems, denial-of-service(DoS) attacks, etc., may arise. Therefore, service providers have beenincorporating several secure techniques in their IPTV networks. Toensure a desired level of security to protect the content and end-users’home networks, it is necessary to implement multiple layers ofsecurity. A complete end-to-end security analysis of IPTV networks

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 219: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

204 IPTV Delivery Networks

is a huge task. Therefore, in this chapter, only the overview of thenetwork security of an IPTV system is discussed.

According to the International Telecommunications Union-Telecom(ITU-T) focus group on IPTV, the end-to-end IPTV security consistsof multiple network subsystems along a distribution chain fromproducer to distributor to consumer of multimedia content. At eachstep of this chain, each network contains several security issues (FocusGroup on IPTV, 2006). This group is further divided security require-ments into five categories, namely, terminal security, content security,network security, service security and subscriber security, which arerelated to five assets1, namely, content assets, service assets, networkassets, terminal assets and subscriber assets (Choi et al., 2009; Jungand Oh, 2009). Descriptions of these assets are out of the scope of thischapter, but the readers can find the details in Focus Group on IPTV(2006). The protection mechanisms for content security would enablesubscribers to use the content they have acquired in accordancewith the rights they have been granted. The protection mechanismsfor service security would ensure that subscribers are only able toobtain the services that they are entitled to access. The protectionmechanisms for network security would guard the IPTV servicenetwork from abuse such as DoS attacks and so on (US-CERT, 2013).The protection mechanism for terminal security would guard againstattempts to abuse a box by hacking, DoS attacks, virus infections andso on. Finally, the mechanisms for subscriber security would protectpersonally identifiable information from unauthorised access and use.Among all these security-related issues, this book is focused on IPTVdelivery network, and therefore, our discussion only concentrates onnetwork security. For other related topics in detail, the user can readthe literature mentioned in the references (Focus Group on IPTV,2006; Ramirez, 2008).

8.2 Threats on IPTV Delivery Networks

In IPTV, before delivering content to a set-top box (STB), contenttravels through one or multiple networks. Consequently, it inheritsall the security vulnerabilities that exist in the network. Hence,

1 An asset could be defined as the data or a service resource in the distribution chain(Focus Group on IPTV, 2006).

Page 220: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 205

the basic security measures that are required to protect any TCP/IPnetwork are equally applicable to the IPTV infrastructure. In addition,several constraints of IPTV-related data also need to be assessed. Forinstance, multimedia contents (e.g., video and audio) are sensitive todelays and can sustain a certain level of packet loss. Any resiliencetechnique that fails to ensure those constraints will certainly affectthe consumer experience, and hence, it is undesirable. Therefore, onlythose security mechanisms that control the networking vulnerabilitiesand ensure the proper functionality of the IPTV service should beapplied. Similar to IPTV-data, IPTV assets also have distinctivevulnerabilities, which are discussed in Section 8.3.

Before discussing the vulnerabilities of IPTV networks, let us discussthe nature of the attackers. According to the ITU-T Focus Group onIPTV (Focus Group on IPTV, 2006), they could be classified into fourgroups:

• Crackers: This group is skilled and has a considerably huge oppor-tunity to threaten the network. Generally, they are motivated byrevenge, ideological predilections or the need for personal fame.

• Professionals: They are unlawful resellers of assets. They aremotivated by criminal and financial benefits.

• Insiders: Although the chapter is on information security, we mostlyfocus on protecting resources from attacks perpetrated by peopleoutside an organisation. However, insiders are the biggest securitythreat (Durbin, 2016). Their motivations come from revenge, organ-ised crime, personal fame, ideological predilection and/or so on.

• Consumers: Sometimes consumers also threaten resources to gainbenefits. Their motivation comes from free service access or theunauthorised use of content.

These aforementioned attackers can launch a number of attacksand can directly threaten IPTV networks or utilise IPTV networks toaccomplish other threats in many different ways (Ramirez, 2008) suchas:

- Theft or abuse of network assets- Theft of service- Theft of IPTV-related data- Disruption of service- Privacy breaches- Compromise of platform integrity.

Page 221: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

206 IPTV Delivery Networks

Threats to

IPTV

Theft of Abuse of

IPTV AssetsTheft of service

Disruption of

service

Theft of IPTV

-related dataPrivacy breach

Compromise of

platform integrity

Figure 8.1 Main threats to IPTV and IPTV networks.

Figure 8.1 represents the main security threats to IPTV and IPTVdelivery networks. All these threats are detailed as follows:

8.2.1 Theft or Abuse of Network Assets

Generally, network assets include network bandwidth, intermediatesystems such as routers or firewalls, network messages and endsystems that are vital for a service such as servers and directories andso on. These assets could be stolen or modified by third parties, whichwould affect the IPTV service provider. These assets also could bemanipulated for purposes that are outside the planned functions ofthe elements.

Some notable examples are bandwidth DDoS (BW-DDoS) (Geva,Herzberg and Gev, 2014), unauthorised modification of networkmessages, replay attack (Gao et al., 2007), unauthorised use of networkassets and so forth. In BW-DDoS attacks, network infrastructureoperation is disrupted by causing congestion, which is carried outby increasing the total amount of traffic in the network. Due to this,IPTV networks would experience a huge number of packet losses, andthus, connection and quality degrade severely. The other attacks alsoaffect the network performance, which are summarised in Table 8.1.

8.2.2 Theft of Service

Any activity that leads to receiving IPTV services without the properlevel of subscription could be considered as theft of service. It is notdirectly involved with the network; however, sometimes networksplay a passive role in accomplishing these kind of things. For instance,when virtual local area network (VLANs) and access controls are notproperly deployed, subscribers can add channels to their subscriptionwithout paying for them (Ramirez, 2008).

Page 222: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 207

Table 8.1 List of assets, attacks, severity levels, person involved and likelihood ofIPTV networks according to the ITU-T Focus Group on IPTV (2006).

Asset Attack Severity Likelihood Person involved

Network bandwidth DoS attack Medium High CrackerMedium ProfessionalLow InsiderLow Consumer

Unauthorisedaccess or use

High Medium CrackerHigh ProfessionalLow InsiderLow Consumer

Network messages Unauthorisedaccess

High High CrackerMedium ProfessionalLow InsiderLow Consumer

Unauthorisedmodification

High High CrackerMedium ProfessionalHigh InsiderLow Consumer

Replay High High CrackerMedium ProfessionalLow InsiderLow Consumer

Routers,intermediatesystems, accessservers and systemhosts

DoS attack High High CrackerMedium ProfessionalLow InsiderLow Consumer

Unauthoriseduse

High High CrackerMedium ProfessionalLow InsiderLow Consumer

Page 223: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

208 IPTV Delivery Networks

8.2.3 Theft of IPTV-Related Data

The proper functioning of IPTV involves protecting a considerableamount of data that are related to digital assets, infrastructure,subscribers’ information, other service-related information and so on.Generally, most of these data are kept in the components of the headend and aggregation network. Attackers can gather this informationin unauthorised ways by accessing through networks and can utilise itto damage the reputation of the brand, which, in turn, would have anadverse effect on the existing customers and on the enrolment of thefuture customers. Therefore, all this information must be protectedwith more attention to avoiding any such negative consequences.

8.2.4 Disruption of Service

This is considered one of the main threats to IPTV delivery networksas it is directly involved with QoS and QoE. As IPTV subscriberspay for the QoS and QoE, they demand an always-on-stream servicewith consistent quality levels, similar to what they had previouslyreceived from satellite, terrestrial and cable TV services. They do notaccept frequent interruptions or bad quality images, and would lookfor other available services if such things occur. Attackers can launcha DoS attack or can change the configuration of the digital subscriberline access multiplexer (DSLAM), switches or multicast rules to causea disruption of services. Some examples of such threats (Ramirez,2008) are mentioned as follows:

• Packet flooding: Attackers can launch a DoS attack in the IPTVnetworks by sending many valid packets, which causes thedisruption of service by abusing the available bandwidth and othercomponents of the networks. Due to this circumstance, subscriberswould fail to attain consistent quality levels and experience frequentinterruptions and poor quality pictures.

• Malformed packets and messages: Attackers can cause the disrup-tion of service by disabling endpoints (such as STB, video server) bysending numerous invalid messages that could cause those devicesto crash, reboot or exhaust all resources. Again, the continuousinjection of malformed packets in the network would cause a bufferoverflow and/or degrade the performance of the devices.

• Spoofed messages: To capture IPTV streams, attackers may changeIP and MAC addresses to spoof other users IP and MAC addresses.

Page 224: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 209

This way, traffic would be sent to the wrong destination. They alsocould spoof-control messages to cause the IPTV session to end pre-maturely, inject malicious control traffic into the network, whichmay cause applications or video servers to malfunction and so on.

8.2.5 Privacy Breach

Intruders can acquire private data generally in two ways, for example,they can have unauthorised access to the database servers of IPTVnetworks that store those data or by capturing packets while trans-porting in the networks and decoding them with appropriate yet illegalmechanisms. In whatever ways they capture data, it could be utilisedagainst the service provider, subscribers and so on. Consequently,some technique must be employed to avoid disclosing personalinformation including the encryption and hashing techniques.

8.2.6 Compromise of Platform Integrity

To avoid escalating the security-related incidents, it is necessaryto ensure the integrity of the platform that is delivering the IPTVservices. Otherwise, intruders can compromise the integrity and maybe able to escalate various attacks and also may take over a large areaof the service. Appropriate mechanisms must be installed to ensureconsistent platform integrity and timely detection of intrusions. Someexamples of such threats related to IPTV networks are unauthorisednetwork scans and probes, IPTV session hijacking and servicemasquerading, unauthorised management and so on.

8.3 Security Issues of IPTV Delivery Networks

There are several protocols involved in IPTV delivery networks, whichare out of the scope of this chapter as it covers only the security issues.Readers can use the reference list (Harte, 2007; Veracode, 2017) formore information. Before discussing the specific vulnerabilities ofthese protocols, let us discuss the vulnerabilities in general terms thatare possible on those protocols in brief.

• Man-in-the-middle (MITM) attack: In this type of attack, anattacker illegitimately interrupts a conversation between two

Page 225: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

210 IPTV Delivery Networks

parties, impersonates both parties and gains access to informationthat they are exchanging (Veracode, 2017). In other words, it allowsan attacker unauthorised access to intercept, send and receive data.For more details, consider the following example:Suppose Alice wants to communicate with Bob. Meantime, Devil

occasionally wants to intercept the conversation and to deliver afalse message to Bob. Let us assume that Alice starts the conver-sation by asking for Bob’s public key while Devil is interceptingtheir conversation. Bob sends his public key to Alice, but Devilintercepts it and an MITM attack starts. Devil sends a forgedmessage to Alice including his public key masquerading as Bob.After receiving the public key, Alice encrypts her message andsends the encrypted message to Bob. Devil again intercepts themessage and decrypts it using his own private key. If necessary,he alters the message and re-encrypts it using Bob’s public keyand sends it to Bob masquerading as Alice. When Bob receivesthe encrypted message and decrypts it with his private key, hebelieves that it is from Alice. The whole scenario is depicted inFigure 8.2. In IPTV delivery networks, an attacker can placehim/herself in between the STB and the server to execute thistype of attack.

• Snooping and spoofing attacks: In snooping attacks, an attackerlistens to the traffic that is being exchanged between two machineson a network. If traffic includes unencrypted text, unencryptedpasswords and so on, the attacker can grab those data and canemploy later to initiate other attacks, such as MITM or replay

Normal flow Man-in-the-middle flow

Client

Server

Client

Server

MITM

Figure 8.2 An example ofan MITM attack.

Page 226: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 211

attack or so on. On the other hand, a spoofing attack occurs whenan attacker or an attacking device impersonates another user or adevice on a network to launch attacks against network hosts, stealdata, spread malware or bypass access controls.

• Replay attack: This is an attack that replays messages from adifferent context into the intended (or original and expected)context, thereby fooling the real and honest participant(s) (Malladi,Alves-Foss and Heckendorn, 2002). An attacker can carry outthis type of attack by intercepting the data and retransmitting it,possibly as part of a masquerade attack by IP packet substitution.For more details, let us consider the following example:Suppose Alice sends her password as the proof of identity to

Bob, before which she scrambles the password using sometechniques – let us consider that it is performed using a hashfunction or so on. Meantime, Devil has been eavesdroppingon all the conversations between Alice and Bob and has storedimportant information such as passwords. After the conversa-tion is over, Devil (posing as Alice) connects to Bob. When Bobasks for a proof of identity, he sends Alice’s password (or hash)that is read from the previous session. Thus, Devil may grantaccess from Bob. This scenario is depicted in Figure 8.3.

• DoS attack: In this attack, an attacker employs some techniques tomake one or multiple network resources unavailable temporarily orindefinitely from its intended users by disrupting services. Gener-ally, the DoS is accomplished by flooding the targeted network inan attempt to overload it, and it thus prevents some or all legitimaterequests that are from the valid users from being fulfilled (Veracode,2017).This kind of attack is a crucial threat to IPTV, as DoS introduces

frequent interruptions and causes bad quality pictures; whereasit is expected to be an always-on-stream service. It directly

Original connection

Replay

traffic

Sniff

BobAlice

Devil

Figure 8.3 An example of a replay attack.

Page 227: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

212 IPTV Delivery Networks

affects the availability of the service, which is one of the funda-mental elements of information security among the three. Theother two security elements, that is, confidentiality and integrity,could be ensured by using encryption and hashing techniques.However, there is no such mechanism that can deal with theDoS. Consequently, it is considered as one of the biggest threatsto the IPTV market.

• Distributed denial-of-service (DDoS) attack: This kind of attackoccurs when multiple systems collectively flood the bandwidth orresources of a targeted network or system as shown in Figure 8.4(Zargar, Joshi and Tipper, 2013). Most of the systems that areinvolved in this kind of attack are not aware of their involvement.It is accomplished by compromising those systems to form anetwork, which is often known as Botnet (Heron, 2007), which can

Attacker

Machine

Compromised Compromised Compromised Compromised

Handler Handler Handler

Targeted

server(s)

Internet

Handler Handler

Compromised

Figure 8.4 An example of a DDoS attack.

Page 228: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 213

receive and execute commands without the owners’ knowledge(Sargent et al., 2017). This attack is more severe than a DoS attackas multiple systems can generate more traffic. Again, these systemsare distributed in several places; therefore, it is harder to track allof them and shut them down. There are several reported caseswhere attackers have demanded money to refrain from launchingDDoS attacks against these systems (Ramirez, 2008). Therefore,when defining the architecture of IPTV networks, it is essential toconsider the impact and prevention of DDoS attacks.

• Smurf attack: It is a variant of the DDoS attack where numerousInternet Control Message Protocol (ICMP) packets are broadcastto the intended victim’s network using an IP broadcast addressas the destination address and spoofing victim’s source IP as thesource address. When all machines within the subnet receive thismessage, they reply to the spoofed address. This situation worsenswhen the number of machines on the network is very large and thevictim’s machine is flooded with a huge amount of traffic. This mayslow down the victim’s machine, and, at a certain point, it may stopworking.

• UDP flood: It is another variant of the DoS attack that employs UserDatagram Protocol (UDP) packets. It can be initiated by transmit-ting a considerably large number of packets to random ports ona remote host, eventually making it unavailable for and unreach-able by other clients. Generally, the attackers spoof the IP addressin the UDP packets. They also anonymise their network location(s)to ensure that the excessive packets do not return to them.

• Synchronise (SYN) flood: It is also another form of the DoS attack,where the attack is initiated by sending many SYN requests toa target system attempting to consume enough server resourcesmaking it unresponsive to legitimate traffic. Normally, to establisha TCP connection to a server, the client and the server exchange aseries of messages as the following:– The client first sends a SYN message to the server requesting to

establish a connection between them.– If the server is available, it sends back an acknowledgement

message called SYN-ACK.– To complete this handshake procedure, the client responds back

with an ACK message, and the connection is established betweenthem.

Page 229: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

214 IPTV Delivery Networks

Server(s)

SYN

SYN

SYN ACK

User

(Waiting for SYN ACK)

User

Attacker

Server(s)

(Waiting for ACK)

Server(s)

(No ports available)

Figure 8.5 An example of SYN flood attack.

This procedure is known as the three-way handshake procedure,and it is the foundation of every connection established using theTCP protocol. In a SYN flood attack, an attacker sends a huge numberof SYN messages to block various or all ports of the target computeras shown in Figure 8.5 and never sends the expected ACK. This tacticblocks these ports of the victim computer from being utilised for acertain period of time. They may also spoof the source IP addressin the SYN message, which causes the target computer to reply theSYN-ACK message to a falsified IP address, which never responds tothis message as it knows that it did not send any SYN message.

8.3.1 Protocols Vulnerabilities

There are several protocols involved in IPTV delivery networks,namely, Internet Group Management Protocol (IGMP), ProtocolIndependent Multicast (PIM), Multicast Border Gateway Protocol(MBGP), Multicast Source Discovery Protocol (MSDP), Managed FileTransfer Protocol (MFTP), Real-time Transport Protocol (RTP) andso on. Each of them is vulnerable to various threats and other security

Page 230: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 215

problems (Schulzrinne et al., 2003). In the subsequent discussions,the security issues of these protocols are addressed briefly.

8.3.1.1 IGMPIn an IPTV network, the IP multicasting technique is employed todeliver the television channels that are traditionally broadcast. In thisprocess, IGMP plays an important role as it is the mechanism usedto control the delivery of multicast traffic to authorised and interestedusers. IGMP commands tell the upstream equipment to begin sending(‘join’) a channel and to stop sending (‘leave’) a channel.

However, it suffers from several vulnerabilities, for example, asfollows:

• Using IGMP snooping attack, an attacker can listen to the IGMPconversation between hosts and routers. This knowledge could belater utilised for other attacks, such as MITM attacks, replay attacksand so on.

• Using a replay attack, an attacker can participate in a multicast flow.• DoS or DDoS attacks are possible through flooding IGMP messages.

Due to such flooding, it significantly slows down the system andeventually prevents legitimate traffic from being transmitted acrossthe target network.

• Some operating systems (Oss) are prone to the remote buffer-overflow vulnerability due to a lack of validation of user-supplieddata when storing the state of IGMPv3 requests, which areprocessed by TCP/IP. Attackers can exploit this issue to executean arbitrary code and can likely result in a bug check and DoSconditions.

• Infinite loop attack is another vulnerability that is reported inSargent et al. (2017) where two involving systems may sendrequests back and forth to each other and thus create an infiniteloop.

• By malforming or forging IGMP packets, an attacker can participatein a multicast group, suppress or deflect packet flows, cause bufferoverflow or hang/crash the system and many more.

8.3.1.2 PIMIt is a family of multicast routing protocols for TCP/IP networks thatprovides one-to-many and many-to-many connections to distributedata over various communication media. It is termed so because it

Page 231: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

216 IPTV Delivery Networks

does not include its own topology discovery mechanism, insteaddepends on other routing protocols for such information. Again, itis not dependent on a specific unicast routing protocol for routinginformation.

In Request for Comments (RFC 5294) (Savola and Lingard, 2008),several vulnerabilities of PIM are mentioned. Among them, the onlyprominent vulnerabilities are noted as the following:• A malicious system can send PIM register messages to get around

rate limits or to interfere with foreign rendezvous points (RPs), asdescribed in RFC 4609 (Savola, Lehtonen and Meyer, 2006). Thesource IP address can be spoofed to create arbitrary states at theRPs.

• A malicious node can become a PIM neighbour by sending PIMHello messages. Afterwards, it would be able to send other PIMmessages to the router and may use those messages to attack therouter.

• In PIM sparse mode (PIM-SM), an illegitimate PIM neighbour maybe elected as the PIM designated router (DR), designated forwarder(DF) or asserted forwarder (AF) on a LAN. A DR is responsible forregistering encapsulated data from new sources and for generatingPIM join/prune messages on behalf of the group members on theLAN. On the other hand, a DF is responsible for forwarding datadownstream and upstream onto the link. Again, an AF is in chargeof forwarding all traffic for a particular (S,G) or (*,G) onto the LAN(Savola and Lingard, 2008). An illegitimately designated node caninitiate other kinds of attacks such as DoS, DDoS and so on.

• The easiest way to accomplish a DoS attack using PIM is to denythe multicast service on the link, that is, not forward all or parts ofmulticast traffic from upstream onto the link, or not registering orforwarding upstream the multicast transmissions originated on thelink. One of the typical ways of doing this is to become the DR (howan illegitimate node can become DR has been mentioned earlier).There are also other ways to launch DoS attacks, which could befound in Savola and Lingard (2008).

• When any illegitimate node becomes a DR, it can violate theintegrity of any data streams by modifying the packets sent by thesources before register-encapsulating them.

8.3.1.3 MBGPIn IPTV, it is recommended to enable multicast BGP (MBGP)between different IPTV service providers to advertise multicast

Page 232: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 217

source routes for interoperability. It is used for advertising multicastsource routes for reverse path forwarding (RPF) check. It adds featuresfrom underlying BGP protocol to enable multicast routing betweenBGP autonomous systems. Consequently, any vulnerability in MBGPis mainly from the susceptibility of its underlying protocol. RFC 4272(Murphy, 2006) has noted some vulnerabilities of BGP, which arebriefly discussed as follows:

• An attacker can create a huge number of malformed MBGP packetsand send them to MBGP routers to cause a DoS attack. For instance,advertising large numbers of more specific routes (i.e., longer pre-fixes) can cause BGP traffic and an increase in the router table size,and, at a certain point, it even explodes (Murphy, 2006).

• As routing data between BGP routers are transmitted in plaintext, eavesdropping is a possible attack against routing dataconfidentiality.

• Again, BGP does not provide any mechanism to protect replayattacks in its messages.

• BGP does not provide any mechanism to protect insertion ofmessages. However, because it uses TCP as a transport layer proto-col, message insertion by an outsider requires knowing the accuratesequence number. Session-stealing attacks are also possible in BGP.

• Message deletion and modification are also possible in BGP asit does not provide protection against these functions. However,message deletion is a difficult task against a mature TCP implemen-tation. On the other hand, any modification that was syntacticallycorrect and no change in the length of the TCP payload would ingeneral be difficult to detect.

• There is no protection given in BGP against MITM attacks as it doesnot perform peer-entity authentication.

8.3.1.4 MSDPThis protocol is used in IPTV to connect multiple PIM-SM domains. Itworks as a source announcement protocol and propagates informationabout currently active sources. It allows multicast sources of a groupto be known to all RPs in different domains.

It is vulnerable to the following attacks or threats:

• Most MSDP-based DoS attacks attempt to flood the IPTVnetwork with bogus source active (SA) messages to incapacitatethat network. The matter of concern is that any host on an

Page 233: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

218 IPTV Delivery Networks

MSDP-enabled network can start an infrastructure-wide attackwith minimal effort, becausei) each time a source sends an IP packet, an MSDP peer in the

domain sends a corresponding SA message to all its peers; andii) each received SA is again broadcast by every MSDP peer to every

other connected MSDP peer(Rajvaidya, Ramachandran and Almeroth, 2004). Consequently,when an attacker generates a huge amount of bogus SAs and injectsthem in the network, the MSDP peers propagate them across theentire infrastructure, and hence, these messages are flooded in thenetwork.

• Again, SAs can easily be forged or modified and sent to form a bogusmulticast group. The motivation behind such activity is to createillegitimate content from legitimate content.

• Forged or modified MSDP packets could cause the content manage-ment group, video cache server(s), or gaming server(s) to join a fakegroup, which may result in the suppression or deflection of traffic(Ramirez, 2008).

8.3.1.5 RTP and RTP Control Protocol (RTCP)The RTP is a network protocol for delivering multimedia contentssuch as audio and video over IP networks. It has been extensively usedin communication and entertainment systems, for example, it involvesvideo teleconference applications, telephony applications, televisionservices, web-based push-to-talk features and so on. In the contextof IPTV, UDP is useful for sending IP video content to multiple usersand is the most popular transport level protocol employed by IPTVservice providers; therefore, RTP typically eclipses it. The is used inconjunction with the RTP. While RTP carries audio and video datastream, RTCP is used to monitor statistics of the transmission, QoSand to aid synchronisation of multiple streams.

These protocols are also vulnerable to several attacks or threats,which are mentioned as follows:• To launch a DoS attack, an attacker can send a flood of RTP packets

to a target server to incapacitate that server or to crash it. A trafficflood would consume all or a considerable portion of the bandwidthon the network and thus block legitimate subscribers from gettingtheir required service.

Page 234: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 219

• RTP packets could be captured while travelling using any publiclyavailable packet sniffer or through a MITM attack. Afterwards, theycan be played back for personal use or distribution.

• Forged RTP packets could be injected within an RTP stream, whichwould result in the loss of fidelity of the video stream or in degrad-ing QoS, and, hence, it may create dissatisfaction among the sub-scribers.

8.4 Countering the Threats

Ensuring protection against all security-related vulnerabilities of anIPTV environment would bring a high level of complexity into thesystem and sometimes create obstacles in providing the desired levelof service. Hence, security professionals must take a trade-off betweenthe risks and countermeasures into account while designing such asystem. In other words, they must balance between the benefits interms of risk reduction and the expected costs of the countermea-sures. For IPTV network security, the aforementioned points are alsotrue. In many cases, if proper security mechanisms are applied tothe upper layer, there is no need to apply them in the transport layer.Otherwise, it may introduce redundancy. For example, if encryptionand integrity protection mechanisms are applied at the upper layer,there is no point in repeating the same procedure in the lower layer.

Although there exist various types of networks in IPTV environ-ments, namely, core, access and home network, the basic securitymechanism of these networks is similar. These basic securitymechanisms are discussed as follows (Focus Group on IPTV, 2006):

• Firewall: It is a network security system that monitors and controlsall incoming and outgoing network traffic based on certainpredetermined security rules (Noureddine, 2010). Generally,between a trusted internal network and other outside networks andfilters all incoming and outgoing traffic is established. Based on theIPTV requirements, host-based firewalls and/or network-basedfirewalls could be deployed.

• Access controls: In information security, access control mechanismsensure selective restriction of access to a place or other resources.In IPTV, they are essential for network devices, multicast streams

Page 235: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

220 IPTV Delivery Networks

and media files. In network devices such as routers, intermediatesystems and servers, authentication-based access control mecha-nisms can be applied. A strong password that combines lowercaseand uppercase letters as well as numerals and symbols is neededat a minimum to authorise. A two-factor authentication thatcombines passwords and tokens can also play an important role incontrolling the accessibility to security-critical devices. Multicastauthentication can prevent illegitimate nodes from joining a mul-ticast group. Thus, they can be prevented from being designatedas DR, DF and/or AF. Last but not least, file access control can beused as a pre-requisite to decrypting or receiving a file (Wang andWang, 2016).

• Intrusion detection and prevention: To prevent intrusion in IPTVnetworks, intrusion detection and prevention mechanisms can beapplied. Intrusion detection systems (IDSs) and intrusion preven-tion systems (IPSs) are devices or software applications that monitora network against malicious activities. They typically report either toan administrator or to a control centre when any activity is detected.Sometimes, especially, IPSs can take defensive actions when suchviolations occur.

• Virtual private network (VPN): A VPN logically extends a privatenetwork across a public network and enables a user to send andreceive data across the public networks as if his/her device isdirectly connected to the private network. In other words, VPNcreates a secure connection, which is generally referred to as atunnel, between a computer and a server where one of them is in apublic network. However, due to the overhead of VPNs, sometimes,it is not possible to provide the desired level of IPTV services.Several IPTV-friendly VPNs are currently available in operations(Roswell, 2017).

• Integrity-checking: In network security, integrity-checking detectsany changes in a message that has been travelling from a sender toa receiver. Again, it is also utilised to compare the current state ofstored data to a previously recorded state to detect any changes.In IPTV, several records and other relevant information that arecritical to network management, configuration and operation needto be integrity-protected.

• Documented and auditable security procedures: The securitypersonnel who manage the security of the network system must

Page 236: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 221

Table 8.2 Suggested network security mechanisms by ITU-T Focus Groupon IPTV (Focus Group on IPTV, 2006).

Asset Risk Security Mechanism

Network bandwidth DoS FirewallUnauthorised use

Network messages Unauthorisedaccess

FirewallAccess controls

Unauthorisedmodification

VPNAccess controls

Replay VPNRouters andintermediatesystems

DoS FirewallUnauthorised use Access controls

Intrusion protectionDocumented and auditablesecurity procedures

Network serviceinformation

Unauthoriseddisclosure

Access controlsIntegrity protection

Unauthorisedmodification

Documented and auditablesecurity procedures

follow the documented security guidelines for any wrong attemptto be identified and resolved accordingly.

Table 8.2 shows the suggested security mechanisms by ITU-T FocusGroup on IPTV with respect to various assets and risks (Focus Groupon IPTV, 2006).

8.5 Open Research Issues

As mentioned earlier in this chapter, ensuring protection against allsecurity-related vulnerabilities of an IPTV environment is a complexjob. There are several issues that remain open problems. Some of theseare mentioned next:

• Because protection against all security threats bring a high level ofcomplexity into the IPTV system and create obstacles in providingthe desired level of service, it is essential for a security professional

Page 237: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

222 IPTV Delivery Networks

to find a trade-off between the risks and countermeasures. Thereis no essential guideline to find this trade-off, which could be aninteresting research topic to investigate.

• VPN is considered a promising solution for many applications;however, due to the overhead of VPNs, it is considered inconsistentwith the performance demands of IPTV applications. Therefore,designing VPNs, especially for an IPTV environment, remains anopen problem.

• Among all the fundamental elements of information security, it ispossible to achieve confidentiality and integrity through applyingencryption and integrity-protection techniques, respectively.However, availability remains a big challenge due to attacks such asDoS, DDoS or similar kind of attacks. Therefore, the techniques toprevent a network from those attacks remain open research issues.

8.6 Conclusions

In this chapter, we discussed the security issues of IPTV deliverynetworks. At first, we mentioned the six existing threats to IPTV andIPTV networks in detail: They are theft or abuse of network assets,theft of IPTV-related data, theft of service, disruption of service,privacy breaches and compromise of platform integrity. Afterwards,we discussed most of the prominent attacks of the IPTV deliverynetworks with appropriate examples. Then, the vulnerabilities of mostof the prominent IPTV networks were noted in brief. Subsequently,the technique of countering these vulnerabilities has been discussed,which is suggested by the ITU-T Focus Group on IPTV. For newresearchers, we have presented some open research issues that wouldhelp them in kick-starting their research and avoid the pitfalls offinding a new research topic.

References

Alsaffar, A.A., Shin, Y.-R. and Huh, E.-N. (2015). IPTV ServiceFramework Based on Secure Authentication and Lightweight ContentEncryption for Screen-Migration in Cloud Computing. Advances inMultimedia, Hindawi Publishing Corporation.DOI: 10.1155/2015/147320.

Page 238: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

IPTV Network Security: Threats and Countermeasures 223

Choi, J.-D., Jung, S.-H. Kim, Y.-H. and Yoo, M.-S. (2009), A fast andefficient handover authentication achieving conditional privacy in V2Inetworks. In Smart Spaces and Next Generation Wired/WirelessNetworking, vol. 5764 of Lecture Notes in Computer Science,pp. 291–300, Springer, Berlin, Germany.

Durbin, S. (2016). Insiders are Today’s Biggest Security Threat: The MostFundamental Element of Threat is Deeply Human. Available: https://www.recode.net/2016/5/24/11756584/cyber-attack-data-breach-insider-threat-steve-durbin.

Fati, S. M., Sumari, P., Yuhaniz, S. S., and Sjarif, N. N. B. A. (2017).Modelling contents status for IPTV delivery networks, in Proceedingsof the 6th International Conference of Computing & Informatics(eds J. Zulikha and N. H. Zakaria), Sintok: School of Computing,pp. 282–290.

Focus Group on IPTV (2006). End-to-End IPTV Security: Assets, Risks,and Threats, 2nd FG IPTV meeting, Busan.

Gao, H., Bodei, C., Degano, P. and Nielson, H. R. (2007). A FormalAnalysis for Capturing Replay Attacks in Cryptographic Protocols.Advances in Computer Science – ASIAN 2007: Computer and NetworkSecurity. Lecture Notes in Computer Science book series, Vol. 4846,pp. 150–165.

Geva, M., Herzberg, A. and Gev, Y. (2014). Bandwidth distributed denialof service: Attacks and defenses. IEEE Security & Privacy, 12(1),54–61.

Harte, L. (2007). Iptv Basics, Technology, Operation and Services. AlthosPublishing, USA.

Heron, S. (2007). Botnet command and control techniques. NetworkSecurity, 4, 13–16. DOI: 10.1016/S1353-4858(07)70045-4.

Jung, Y.-H. and Oh, S.-H. (2009), Design and implementation of efficientDRM system for content streaming based on H.264. Journal of theKorea institute of Information Security and Cryptology, 19(2),155–162.

Malladi, S., Alves-Foss, J. and Heckendorn, R.B. (2002). On PreventingReplay Attacks on Security Protocols. In Proceedings of the 7thInternational Conference on Security and Management, pp. 77–83.

Motoi, M. and Ken’ichi, K. (2017). Public Broadcasting and Digitizationof Television: Survey of IPTV Subscribers. Available: https://www.nhk.or.jp/bunken/english/reports/pdf/06-07_no5_09.pdf.

Murphy, S. (2006). BGP Security Vulnerabilities Analysis. RFC 4272,Internet Society. Available: https://www.ietf.org/rfc/rfc4272.txt.

Page 239: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

224 IPTV Delivery Networks

Noureddine, B. (2010). Security of Mobile Communications. CRC Press,Boca Raton, ISBN 0849379423.

Rajvaidya, P., Ramachandran, K.N. and Almeroth, K.C. (2004). Managingand securing the global multicast infrastructure. Journal of Networkand Systems Management, 12(3), 297–326.

Ramirez, D. (2008). IPTV Security: Protecting High Value DigitalContent. John Wiley & Sons, London, UK.

Roswell, C. (2017). Best VPN for IPTV – 2017 In-Depth Review.Available: https://thevpn.guru/best-iptv-vpn-review.

Sargent, M., Kristoff, J., Paxson, V. and Allman, M. (2017). On thepotential abuse of IGMP. ACM SIGCOMM ComputerCommunication Review, 47(1).

Savola, P. and Lingard, J. (2008). Host Threats to Protocol IndependentMulticast (PIM). RFC 5294, IETF Trust. Available: https://tools.ietf.org/html/rfc5294.

Savola, P., Lehtonen, R. and Meyer, D. (2006). Protocol IndependentMulticast – Sparse Mode (PIM-SM): Multicast Routing Security Issuesand Enhancements. RFC 4609, Internet Society. Available: https://datatracker.ietf.org/doc/rfc4609/?include_text=1.

Schulzrinne, H., Casner, S., Frederick, R. and Jacobson, V. (2003). RTP:A Transport Protocol for Real-Time Applications. RFC 3550, InternetSociety. Available: https://www.rfc-editor.org/rfc/rfc3550.pdf.

US-CERT (2013). Understanding Denial-of-Service Attacks. Available:https://www.us-cert.gov/ncas/tips/ST04-015.

Vasanthi, V. and Chidambaram, M. (2014). Internet Protocol Television(IPTV) and its Security threats – An overview. International Journalof Computer Science Trends and Technology (IJCST), 2(4), 172–175.

Veracode (2017). Man-in-the-Middle Tutorial: Learn AboutMan-in-the-Middle Attacks, Vulnerabilities and How to PreventMITM Attacks. Available: https://www.veracode.com/security/man-middle-attack.

Wang, D. and Wang, P. (2016). Two birds with one stone: Two-factorauthentication with security beyond conventional bound. IEEETransactions on Dependable and Secure Computing. DOI:10.1109/TDSC.2016.2605087. Available: http://ieeexplore.ieee.org/document/7558124/.

Zargar, S. T., Joshi, J. and Tipper, D. (2013). A survey of defensemechanisms against distributed denial of service (DDoS) floodingattacks. IEEE Communications Surveys & Tutorials, 15(4), 2046–2069.

Page 240: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

225

9

Anomaly Detection and Big Data in IPTV NetworksMohiuddin Ahmed and Md. Niaz-Ul Haque

9.1 Introduction

To meet the increasing demand of video content, Internet Protocol(IP) facilitated the retrieval of video content from the web. The ser-vices provided by telecommunication companies (telcos) are treatedas IPTV. IPTV provides access to digital television using IP. IPTV sys-tem includes a television, set-top box (STB) for accessing channels andvideo on demand (VoD) services, for example, Netflix along with anInternet connection. Figure 9.1 shows a simplified IPTV system.

An IPTV system with these key elements (Figure 9.1) providesnumerous advantages over a standard cable delivery system. Wediscuss the advantages of IPTV systems as follows:

• Efficiency: First, all content is digital, which automatically improvesthe viewer’s experience. Also, an IPTV system provides the abilityto offer much more content via the switched broadcast capability.Using cable infrastructures, the service providers assign every chan-nel on the wire simultaneously; the user chooses the channel andtunes into that channel. Based on this infrastructure, a standardcable delivery system is constrained by the available bandwidth. Theswitched broadcast capability of an IPTV system enhances the userexperience and with significant efficiency. This characteristic allowsthe IPTV service provider to offer an unlimited number of channelsand the constraints of the available bandwidth is solved (Winkleret al., 2008).

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 241: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

VoD

application

Subscriber Database Set-Top Box

Entitlement

system

Head-end

control

Asset

management

VoD Server

VoD Resource

manager

Video pump

Encoding and

compressing

Encryption resource

manager

Encryption engine

Conditional

access client

EPG client

Broadcast

application

Video

decryption

Video

decoderScrambler

Electric

programme

guide

Session

manager

Content

delivery

platform

IPTV Application

server

Figure 9.1 IPTV system (O’Driscoll, 2008).

Page 242: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 227

• Economy: Another advantage of an IPTV system is that it is econom-ically more efficient. The tools of an IPTV system are significantlyless expensive due to the ever-decreasing cost of IP-related tech-nology, allowing the users to get more content for less. For example,the cost of delivering content with IP is inherently less than the cur-rent cable-delivery costs. Also, the IP STBs are cheaper than cableSTBs, and IP networking costs are lowering faster than traditionalnetworking expenses (Simpson and Greenfield, 2007).

• Heterogeneous services: Taking advantage of the middleware thataccompanies the IPTV system, providers have the flexibility to pro-vide branded services such as VoD, time-shifted television, the ‘startover’ feature and converged services such as on-screen caller ID(Gallagher, 2013).

Moreover, the IPTV networks operational data are complex andpose a unique set of challenges in detecting abnormal events. Thesedata are hierarchical in nature and volatile, for example, sourcedfor a data arrival rate that varies extensively over time. Additionally,these data contain critical information for the user such as failureinformation for a service, which often reaches the user after the eventoccurs to the user’s service network. In a nutshell, the operationaldata have three major identifying characteristics such as: (1) sparsity,(2) volatility and (3) seasonality. Thereby, the data in IPTV networkspose many challenges for anomaly detection.

Although IPTV is an increasingly popular service, the future ofIPTV lies in the research efforts in handling the challenges raisedfrom big data and several other zero-day activities. This chapter canbe used as a useful source of knowledge for the researchers in thisdomain and text content for undergraduate/postgraduate students.

9.1.1 Chapter Roadmap

The rest of the chapter is organised as follows: In Section 9.2, datacharacteristics in IPTV networks are highlighted. Section 9.3 containsdiscussion on anomaly in the context of IPTV networks followedby a case study in Section 9.4. Section 9.5 contains a discussionon big data in IPTV networks and the chapter is concluded inSection 9.6.

Page 243: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

228 IPTV Delivery Networks

9.2 Complex Data in IPTV Networks

Network traffic can be considered as complex data where the straight-forward data mining applications may not be effective (Ahmed,Mahmood and Maher, 2015). Data come from more than one process.Each entry in the dataset is usually not only the outcome of a singlecharacteristic but also the combination of different processes. A com-puter network or data network is a telecommunications network thatallows computers to exchange data. In computer networks, networkedcomputing devices pass data to each other along data connections.The connections (network links) between nodes are established usingeither cable media or wireless media. The best-known computernetwork is the Internet. Network computer devices that originate,route and terminate data are called network nodes. Nodes can includehosts such as personal computers, phones, servers and networkinghardware. Two such devices are said to be networked together whenone device exchanges information with the other device, whether orno they have a direct connection with each other. Computer networkssupport applications such as access to the World Wide Web, shareduse of application and storage servers, printers and fax machines aswell as the use of email and instant-messaging applications. Com-puter networks differ in the physical media used to transmit theirsignals, the communications protocols to organise network traffic, thenetwork’s size, topology and organisational intent. So, the networktraffic data are supposed to be complex data based on these facts.Additionally, data have multiple causes. The relationship among theattributes and between each attribute is subtle and some attributesare predictive only for some records.

Although IPTV system is a networked infrastructure, the data cor-responding to this system are different than the regular computer net-work traffic. Specially, the landscape of Internet service provider (ISP)management has become much broader. IPTV service providers col-lect an increasingly rich variety of data including network trouble tick-ets, customer care cases, equipment system logs and repair logs thatare termed as operational data (Chi-Yao Hong et al., 2012). Accordingto Chi-Yao Hong et al. (2012), several characteristics of IPTV networktraffic make them highly useful for network-monitoring as follows:

• Operational data are often stored with semantics. Customer carepersonnel annotate call logs with detailed characteristics on theend-user’s experience, as well as information on the time andlocation of the event.

Page 244: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 229

• Repair logs store information about the underlying cause of theevent and how the problem was solved. This provides more detailedinformation on the meaning and the type of event.

• More importantly, operational data are often showcased in adescriptive hierarchical format.

Operational data are sparse according to Chi-Yao Hong et al.(2012). As they comprise data spread over a large hierarchical space(Figure 9.1), operational data are also characterised as volatile, beingsourced from a data arrival rate that changes rapidly over time, whichmakes it difficult to detect statistical variations. Additionally, forthe phenomenon that user calls arrive on the order of minutes fora particular network incident (as opposed to the sub-millisecondreporting in traditional network traffic-monitoring systems) reflectsthat the ISP may need to make a decision on when to react after a fewcalls (seasonality). Moreover, the operational data represent urgentconcerns as follows:

• Operational data possess critical failure information, often identi-fied after the problem has reached the customer.

• Operational data such as call logs reflect problems crucial enoughto motivate the customer to contact the call centre. Additionally,the call logs that affect multiple customers reflect largescale outagesthat need immediate attention. However, the complexity of opera-tional data requires substantial processing requirements, making itcomplicated for traditional anomaly detection approaches that haveoffline processing.

According to the previous discussion on the characteristics of thedata used in the IPTV networks, we can conclude that this system pos-sesses complex data. Operational data serve as rich sources of infor-mation to help ISPs manage network performance. However, there isstill a lack of effective measures to help ISP operation teams in usingthese data sources to identify network anomalies in the scope of IPTVsystems. Therefore, in the next section, we discuss anomaly detectionin IPTV networks.

9.3 Anomaly in the Context of IPTV Networks

Anomaly detection is an important data-analysis task. It is usedin many domains to identify interesting and emerging patterns,trends and anomalies from data. Anomaly detection is used to detect

Page 245: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

230 IPTV Delivery Networks

anomalies in many different domains including computer networkintrusion, gene-expression analysis and disease-onset identificationincluding cancer detection, financial fraud detection and humanbehavioural analysis. Among the four primary tasks of data mining,anomaly detection is the closest to the motivation of data mining asdiscovering interesting patterns and modelling relationships are themain aims of data-mining research.

In this section, we discuss the anomaly detection in IPTV networksas the importance of anomaly detection has been described in the pre-vious sections. The theoretical frameworks are presented in Chi-YaoHong et al. (2012). We first describe the operational data format andthen we define hierarchical heavy hitter (HHH) that is used to iden-tify anomalous events. To detect if the event related to these heavyhitters is anomalous, we define time series-based anomaly detection.The following definitions are adapted from the research proposed byChi-Yao Hong et al.

An input stream S = s0, s1,… is a sequence of operational networkdata si. Each data si = (ki; ti) consists of two contents:

• Category ki provides classification information about the data;• Time ti denotes the recorded date and time of si.

The data can be classified into ‘time units’ based on its time informa-tion ti. The data category is drawn from a hierarchical structure such asthe tree where each node n in the tree is associated with a weight valueAn[k; t] for time unit t. For leaf nodes, the weight An[k; t] is defined bythe number of data items in S whose category is k and occur in timeunit t. For non-leaf nodes (i.e., interior nodes), the weight An[k; t] is thesummation of the weights of its children. Next, we describe the HHHas follows.

9.3.1 HHH

Consider a hierarchical tree where each node n is weighted by An[k; t]for time unit t. Then the set of HHH for time unit t can be defined byHHH[α; t] = {n | An[k; t] ≥ α} for a threshold α. These heavy hittersthat are also seen as high-volume aggregates are suspicious locationswhere anomalies could happen (Chi-Yao Hong et al., 2012).

In this definition, the count of appearances of any leaf node willconsider all its ancestors. According to Chi-Yao Hong et al. (2012),if anomaly detection is performed without taking the hierarchy into

Page 246: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 231

account, an anomaly in a leaf node may be detected multiple times ateach of its ancestors. To address this, one could reduce the redundancyby removing a heavy hitter node n if its weight can be inferred fromthat of heavy hitter node nd, which is a descendant of n. To arrive at thismore ‘compact’ representation, we consider a more strict definition ofHHHs to find nodes whose weight is no less than α, after discountingthe weights from descendants that are themselves HHHs.

9.3.2 Succinct Hierarchical Heavy Hitter (SHHH)

To define SHHH, a hierarchical tree where each node n is associatedwith a modified weight value Wn[k; t] for time unit t is considered.For leaf nodes, the modified weight Wn[k; t] is equal to the orig-inal weight An[k; t]. For non-leaf (internal) nodes, the modifiedweight Wn[k; t] is the summation of weights of its children that arethemselves not a heavy hitter. Given the set of SHHHs, denoted bySHHH[α; t], the modified weight for non-leaf nodes can be derived bythe following equation and the SHHH set is defined by SHHH[α; t] ={n|Wn [k; t] ≥ α}.

Wn[k, t] =∑

mWm[k, t] ∶ m ∈ child(n) ∩ m ∉ SHHH[α, t]

9.3.3 Time Series

To detect anomalous events, a forecasting model is required forheavy hitter nodes to detect anomalous events. Heavy hitter nodescould change over time instances also described by concept drift(Gama et al., 2014). Therefore, to construct the time series only fornodes that are heavy hitters in the most recent time unit is extremelyimportant (Chi-Yao Hong et al., 2012). For each time unit t, considera hierarchical tree where each node n is weighted by An[k; t]. Giventhe heavy hitter set in the last time unit (t = 1), i.e., SHHH[α; 1], thetime series of any heavy hitter node n ε SHHH[α; 1] is denoted byT[n; t] = An[k; t] -

∑m

Am[k, t]∶ m ∈ child(n) ∩ m ∈ SHHH[α, 1]for 1 ≤ t ≤ l, where l is the length of the time series.

9.3.4 Definition of Anomaly

According to Chi-Yao Hong et al. (2012), the anomaly in the IPTVnetworks can be defined as follows: Given a time series T[n; t] of

Page 247: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

232 IPTV Delivery Networks

any node n, 1 ≤ t ≤ l, the forecast traffic of the latest time periodT[n; 1] is given by F[n; 1], derived by some forecasting model. Then,there is a presence of an anomalous event at node n in the latest timeperiod iff T[n; 1]/F[n; 1] > RT and T[n; 1] - F[n; 1] > DT, where RTand DT are sensitivity thresholds, which are chosen via a sensitivitytest.

9.4 A Case Study of Anomaly DetectionTechnique in IPTV Networks

Using the concept of HHH and anomaly in IPTV networks, a robustanomaly detection technique (Tiresias) is proposed by Chi-YaoHong et al. (2012). In this section, we highlight the main steps ofthe technique.

In the first step of the proposed algorithm, a sliding time window(Pripužic, Žarko and Aberer, 2015) is maintained to group the inputstream into ‘time units’ based on its time information ti. Particularly, atime window consists of l unit with individual size p. When new datalists arrive, the time window is shifted to keep track of the newly avail-able data. For each time window, detecting anomalous events in thelast time unit is a priority, while the data in other time units is used asthe history for predicting the future models.

In the second step, based on the category information ki on the data,a classification tree is constructed, where each category ki can be bijec-tively mapping to a leaf node in the tree. Nodes associated with higheraggregated data counts in the last time unit are suspicious places whereanomaly could happen. At first the heavy hitter set in the classifica-tion tree is detected. Then, the time series for these heavy hitters isdetected.

In the third step, the data seasonality analysis is performedto automatically choose seasonal factors. More specifically, fastFourier transform and wavelet transform (Rao, Kim and Hwang,2010) is applied to identify significant seasonal factors. The results areused as the parameters for anomaly detection in the next step.

In the fourth step, when the time series and its seasonalities infor-mation is at hand, a time series-based anomaly detection is appliedon heavy hitter nodes. The Holt-Winters’ seasonal forecasting model(Bermúdez, Corberán-Vallet and Vercher, 2009) is used to detectanomalies.

Page 248: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 233

Finally, the anomalous events are filed in a database. A Web-basedfront-end system is exploited in JavaScript to allow SQL queries froma text database.

An adaptive scheme (ADA) that reduces the computation time andsimultaneously achieves high accuracy is proposed. ADA maintains atree and only the heavy hitter nodes in the tree that are associated witha time series. However, the main constraint is heavy hitters evolve overtime. Therefore, an efficient operation is required to derive the timeseries for heavy hitter nodes in the current time instance. Time series isconstructed by adapting the time series generated in the previous timeinstance. For example, consider a tree with only three nodes: A rootnode and its two children. The root node is a heavy hitter only in thecurrent time instance and the other two children are heavy hitters inthe previous time instance; in this case, the root node’s time series canbe derived by merging the time series from its two children. The adap-tation process seems very intuitive in the aforementioned example;however, the problem becomes more complicated as the tree heightincreases.

It is observed that the periodicities of operational datasets have beenfairly stable across time. Therefore, data seasonality analysis can beperformed in an offline fashion, for example, only in the first-timeinstance. To detect anomalous behaviour, normal behaviour is firstcharacterised by using a forecasting model on a time series. Due to theevolving nature of data, simple forecasting models such as exponen-tial weighted moving average (EWMA) (Holt, 2004) may be ineffective.An alternative of this approach is to adopt the additive Holt-Winters’seasonal forecasting model (Bernacki and Kołaczek, 2015). The use ofHolt-Winters’ seasonal model is better than the EWMA approach asit does not compromise the update cost and because of its linearity asthere is no requirement to recalculate the forecasted value.

Lemma 9.1 (Holt-Winter Linearity). Given k Holt-Winter forecastsG1[t],G2[t],Gk[t], where Gi[t] = L[t-1] + B[t-1]+S[t-v]. Consider a timeseries T*[t] =

∑k

i=1Ti[t] and its Holt-Winter forecast G*[t] = L*[t-1] +

B*[t-1]+S*[t-v]. Then G∗[t] =∑k

i=1Gi[t].

9.4.1 Limitations of Anomaly Detection in IPTV Networks

In this section, we discuss some of the limitations of the proposedanomaly detection technique. The performance of Tiresias is limited

Page 249: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

234 IPTV Delivery Networks

by the operational data at hand. The authors used a customer carecall dataset to illustrate some of the fundamental limitations. Someof them are discussed as follows:

• Tiresias can only detect network anomalies that directly or indi-rectly affect customers. For example, Tiresias cannot detect upticksin memory utilisation on aggregate routers if it has no sensibleimpact to customers (Chi-Yao Hong et al., 2012). Therefore, itwill require a more powerful detector that has access to runtimememory usage.

• It is important to verify whether the customer call cases have beenmiscategorised. For example, it is impossible for Tiresias to correctlylocate an anomaly if most customers provide incorrect informationabout their geographical location. To minimise the human error,well-trained service representatives will classify the problem basedon predefined categories.

• Tiresias can only analyse input data that is drawn from an additivehierarchy. The authors limited their focus on hierarchical domainsas it reflects the nature of the operational datasets in practice. Themore general data representation (e.g., directed acyclic graph) is outof the scope of this chapter and is left for future work.

• Tiresias cannot detect anomalies where the data rate changes fre-quently, for example, link outages in network traffic data. There wasno such consideration of anomalies because of detecting spikes, thatis, an unexpected increase is much more interesting in operationaldata such as customer care calls.

9.4.2 Experimental Data

The data used to validate the proposed Tiresias approach was obtainedfrom a major broadband provider of bundled Internet, TV and Voiceover Internet Protocol (VoIP) services in the USA (Chi-Yao Honget al., 2012). The results based on the datasets were collected in theMay–September 2010 time frame. Two distinct operational datasetswere used, which we now describe.

• Customer care call dataset (CCD): It comprises the data extractedfrom calls to the broadband service customer care centre for which arecord is populated. The customer care personnel assign a categoryto the call, choosing from amongst a set of predetermined hierar-chical classes based on the conversation with the customer.

Page 250: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 235

• STB crash dataset (SCD): Similar to other services of electronicdevices, the STB is vulnerable to crashing and then rebooting. TheTiresias developers used logs of STB crash events from the samebroadband network, which are produced by the STB.

9.4.3 Experimental Analysis

In this section, the STA and ADA approaches are compared using fourdifferent criteria as follows.

• Computational time: It is observed that ADA with 15-min (1-h)time units reduces the overall running time by a factor of 14:2 (5:4)as compared with Strawman proposal STA.

• Memory requirement: The memory cost of ADA is almost 36% ofthat of STA.

• Time series accuracy: The usage of the reference time series signifi-cantly reduces the error rate.

• Anomaly detection accuracy: The heavy hitter set detected by theADA method is the same as the real heavy hitter set across time.The STA is used as the ground truth because it reconstructs accuratetime series for each time instance. Considering the overall perfor-mance, ADA can detect anomalies with an accuracy of 99.7% againstSTA.

9.5 Future Research Directions: Big Data

Big data concerns large-volume, complex, growing datasets with mul-tiple, autonomous sources. ‘Big data’ is a term for datasets that areso large or complex that traditional data-processing applications areinadequate. Big data is often characterised by three Vs: volume, veloc-ity and variety. Figure 9.2 shows the three Vs of big data.

9.5.1 Three Vs of Big Data

The term ‘volume’ is related to the amount of data and its dimen-sionality. ‘Velocity’ is the processing speed of the data, and ‘variety’refers to the mix of different types of data. Due to the emergence ofbig data, most of the Internet-based applications are streaming innature. Therefore, data stream processing is an emerging domain of

Page 251: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

236 IPTV Delivery Networks

Volume(Terabyte,

petabyte,

zettabyte)

Velocity(Data streams)

Variety(Social networks,

sensors, blogs, mobile

applications,

and so on)

Figure 9.2 The three Vs of big data.

applications where data cannot be stored or revisited. Examples ofsuch applications include network traffic monitoring such as IPTVnetworks, financial applications, telecommunications data manage-ment, sensor networks, mobile applications and so on. Data streamspresent many unique challenges because of the processing constraintsassociated with the large volumes of continuously arriving data.Typically, data-streaming algorithms operate under the followingconstraints:

• One pass constraint: Because volumes of the data are generatedcontinuously and rapidly, it is assumed that the data can be accessedonly once. Data are almost never assumed to be archived for futureprocessing, which has significant consequences for algorithmicdevelopment in streaming applications. Many data-mining algo-rithms are inherently iterative and require multiple passes over thedata.

• Load-shedding: Data stream is usually generated by an external pro-cess on which the user has little control. Thus, the user has no con-trol over the arrival rate of data stream. When the arrival rate varieswith time, in peak hours, it is challenging to execute continuous pro-cessing. Then, it is necessary to drop data instances that cannot beprocessed in a timely fashion. This phenomenon is referred to as‘load-shedding’.

• Massive domain: In some cases, where attribute values are discrete,they may have a large number of distinct values.

• Concept drift: Data evolve over time. With various statisti-cal properties such as a correlation between attributes and classlabels, cluster distribution may change over time.

Page 252: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 237

9.5.2 Big Data in the IPTV Industry

Owing to the Internet, today’s consumers are way too sophisticatedthan ever before. They look around a lot before they buy, talk to theirentire social network about their purchases, demand to be treated asunique and want to be sincerely thanked for buying products. Big dataallows to profile these increasingly vocal and fickle little ‘tyrants’ ina far-reaching manner so that the service provider can engage in analmost one-on-one, real-time conversation with them. This is not actu-ally a luxury. If the consumers are not treated as per their wish, theywill leave the service in the blink of an eye.

For example, when any customer enters a bank, big data tools allowthe clerk to check his/her profile in real-time and learn which rele-vant products or services (s)he might advise. Big data will also have akey role to play in uniting the digital and physical shopping spheres: Aretailer could suggest an offer on a mobile carrier because a consumerindicated a certain need on social media.

The insights that one can gain from analysing the market and its con-sumers with big data are not just valuable. In fact, one can sell them asnon-personalised trend data to large industry players operating in thesame segment and create a whole new revenue stream. Telcos have alot of data about their subscribers’ activities that the operators need tomanage with proper analysis. Processing this data using big data tech-niques allows the telco to analyse and improve their service and cre-ate new services from information generated from this data. Telecomoperators that provide IPTV services are very sensitive to the quality ofexperience (QoE) of their subscribers. There are several ways to mon-itor QoE; however, the most accurate info is received when measuringthe performance at the subscriber’s end-point (such as STB, long-termevolution (LTE) and customer premises equipment (CPE)).

Big data analytical tools help in the analysis of the enormous amountof data received from the subscriber’s end-point and provide a bet-ter view on the subscribers QoE. Friendly QoE monitoring of data,VoIP and IPTV services are examples of big data tools that monitorend-points and provide accurate QoE for IPTV and 4G LTE broad-band services. Big data availability in telecom operators can help inincreasing customer satisfaction and loyalty.

Data from IPTV STBs can help provide a distinct user experience.Basket analysis can be used to generate a channel affinity map that linkschannels most likely to be viewed together. Analysing the data can

Page 253: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

238 IPTV Delivery Networks

result in appealing bundles based on viewing patterns. These analyticshave even a greater power when combined with voice and data usage.

Big data has swept its way into the living rooms around the globevia the humble TV screen. Increasingly, video analytics are beingembraced by the broadcast industry as the magical keys to retainingand growing fragmented audiences.

In summary, big data for IPTV can provide value in at least two areas,which are related to user experience and QoE. First, it can improveIPTV user experience by understanding subscriber preferences andproactively recommending content, creating a ‘positive surprise’ expe-rience that will ultimately lead to increased loyalty and revenues. Sec-ond, it can use big data to simplify cross-domain network planning,system performance monitoring and root cause analysis, to offer therequired QoE.

Additionally, the IPTV recommendation engines also take advan-tage of big data and massive parallel processing technologies to createintelligence from a mixture of data sources. It is important to create‘relevance and commonality’ relationships, by gathering data, whichmay not be directly relevant to the target content. For example, theelectronic programme guide can be used to create metadata common-alities to VoD content. Remote-control click-stream analysis is also apivotal data source that may be used in batch and real-time analysis.External data sources should also be used to enrich content metadata.

Finally, IPTV and cable providers can even utilise some additionaldata sources such as smartphones or tablets close to hand while theywatch live or on-demand content. These personal devices are used bysubscribers to search for information, send messages and post likes totheir friends and share information about what they are watching atany instant.

It is important to note that all benefits of improving user experiencewith an intelligent recommendation engine, as per the precedingdiscussion, are in vain if the IPTV platform or the underlying net-work is not delivering the required QoE. To avoid these, operatorstypically over-provision their platforms and networks to cope withunforeseen demands and faults. However, such overprovisioningis financially inefficient and high-priced content makes the returnon investment on IPTV deployments a challenge. Fundamentally,network management platforms offer the tools required to minimisenetwork costs and predict problems. However, legacy technologiesconstrain current solutions in technology silos, requiring multiple

Page 254: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 239

platforms to monitor and manage the entire network. Further-more, different systems are used to manage fault, performance,quality of service (QoS) and customer service-level agreements(Spyros, 2013).

9.5.3 The Challenges Associated with Big Data in IPTV

We have been awash in a flood of data. In a broad range of applicationareas, data are being collected at an unprecedented scale. Decisionsthat previously were based on guesswork, or on painstakingly con-structed models of reality, can now be made based on the data itself.Such big data analyses now drives nearly every aspect of modern soci-ety including mobile services, retail, manufacturing, financial services,life sciences and physical sciences.

While IPTV and VoD have differing characteristics and employsomewhat different technologies, the rapid pace of technologi-cal change, consumer options and preferences has been creatinghuge market opportunities. Whether content is consumed live ortime-shifted and in the customer’s living room (IPTV) or streamedto PCs or other mobile devices via the Internet (VoD), some industryexperts have proclaimed that consumer expectations have alreadybeen exceeding the ability of the industry to meet those expectations.Major telecommunications firms, cable operators and other contentproviders are exploring options to successfully monetise content andbuild successful business models. Advanced smartphones, tablets anddigital video recorders have dramatically changed the way in whichusers consume content. The ability to access content anywhere and atany time seems to be the consumer expectation trajectory.

As with most high-growth markets characterised by rapid tech-nology change, there are both significant opportunities as well asdaunting business and technology challenges. A successful busi-ness model requires meeting or exceeding customer expectationsacross multiple content delivery modes. As previously noted, thosecustomer expectations are already high. Consumers have come toexpect high-quality video and audio based on their experience withtraditional broadcast models. While they are quite forgiving with freecontent delivered over the web, the same does not hold true for apaid service. Industry statistics from CDN World indicate that 75%of customers who receive poor-quality IPTV service will either notreturn or will seek out a different provider. These figures do not bode

Page 255: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

240 IPTV Delivery Networks

well for providers who cannot consistently meet consumer qualityexpectations and meet them on multiple devices.

Big data for IPTV can provide value to communication serviceproviders (CSPs) in at least two areas, which are related to userexperience and QoE. First, CSPs can improve IPTV user experienceby understanding subscriber preferences and proactively recom-mending content, creating a ‘positive surprise’ experience that willultimately lead to increased loyalty and revenues. CSPs can use bigdata to simplify cross-domain network planning, system performancemonitoring and root-cause analysis, to offer the required QoE whileminimising capex/opex.

We are all familiar with Amazon’s recommendation engine that isbased on item-similarity algorithms and rich metadata. IPTV recom-mendation engines are not the same as such typical Web content rec-ommendation engines, although they have certain similarities. But, incases such as VoD, metadata and user data are sparse and typically notenough for a content recommendation experience that would ‘pleas-antly surprise’ users.

Finally, IPTV and cable providers are in a position to utilise evensome additional data sources that are either not available or hard tocorrelate for over-the-top (OTT) providers. One of them is based onthe fact that users keep their smartphones or tablets close to handwhile they watch live or on-demand content.

Big data technologies offer the foundation layer for a network oper-ation centre (NOC) platform that consolidates all events coming fromall network elements and all relevant systems. Big data NOC can calcu-late in real-time key performance indicators (KPIs) for every individ-ual subscriber, network element and platform, predicting performancebottlenecks based on cross-domain analysis, while at the same timeexecuting rules that proactively prevent such faults from happening.

Another challenge at the customer premises is that consumers arelooking for content portability. Content service delivery platforms(CDSPs) must be able to distribute IPTV streams to all TV sets (orany type of viewing device the future may bring) in the home. Theyalso must be able to deliver IP-based services to multiple devicessuch as PCs, portable MP3 players, video recorders and so on. All thefeatures and functionality offered by IPTV should be available on anyTV or device in the home. Service providers can expect end-users toconnect a growing number of devices to their home networks includ-ing cameras, network storage devices, printers, wireless networks and

Page 256: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 241

portable music players. They also can expect in-home networks toincreasingly become a network of networks.

When deploying IPTV networks, telcos use expertise gained fromdelivering digital services over their infrastructure from the past yearsto address several gating technical challenges. First, their currentbroadband access networks may not support the extreme demandsand dynamic nature of next-generation video services. Upgrades toasymmetric digital subscriber line service (ADSL2+) or fibre to thenode/premises (FTTN/FTTP) will likely be required. Once accessnetwork issues are resolved, in-home wiring at the customer premisescan introduce a new bottleneck to high-bandwidth, IP-based services.

9.5.4 Contributions of IPTV Service Providers in the Realmof Big Data

Today’s digital infotainment and mobile TV solutions will eventuallybecome the foundation of an integrated, multi-screen entertainmentexperience. IPTV is the first step most IPTV providers take towardsa full suite of multi-screen services. But the available IPTV platformshave made it difficult for small network providers by introducing IPTVin their markets. The capex and complexity level of those solutionshave been higher than what these providers required.

One of the strong steps that IPTV providers have taken for the pro-liferation and widespread adoption of advanced end-user devices thatcan support Internet-based video streaming has created an insatiableappetite among end-users for video-based infotainment and person-alised interactive content on any device, at any time with a high QoE.The latest reports from the USA, for example, show that high-speedInternet has enabled a better online TV experience in 63.5% of UShouseholds. Almost a quarter of households have smartphones thatallow them to watch videos wherever they are. And the year-over-yeargrowth of mobile online video viewing has reached 51.2%.

End-users in the USA are not the only ones accessing online digitalTV and entertainment. In the UK, for example, all major broadcastersare now offering some type of on-demand online video service. Andthe BBC claims there were 120 million requests for TV and radio pro-grammes on BBC iPlayer across all platforms in January 2010 (bothonline platforms and devices and BBC iPlayer on Virgin Media TVcombined) and over 23.8 million requests for programmes during thefirst week alone.

Page 257: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

242 IPTV Delivery Networks

These providers are now looking to leverage these initial investmentsand market successes. But while large network providers are reaping allthe rewards, smaller network providers in smaller markets have, so far,been left out in the cold by hardware vendors and solution providerswho are delivering the platforms that enable digital TV and entertain-ment. Complete, end-to-end solutions have been focused on largerapplications, leaving smaller network providers partial solutions thatdo not completely address the need for a viable IPTV delivery platformfor markets under 100,000 STBs.

IPTV solutions are optimised to deliver video entertainment (mul-ticast live or time-shifted broadcast programming and unicast VoDprogramming) over IP-based, packet-switched infrastructures. Theyare designed for subscriber-based telecommunications networks thatsupport high-speed access from end-user premises via STBs and otherend-user devices. These solutions offer network providers a way toleverage their broadband networks and evolve their broadband ser-vice offerings into multi-screen services that will increase end-user‘stickiness’, reduce churn and generate new revenue from enhancedmultimedia services that end-users can access from any device, any-where, anytime.

Another focus point from IPTV providers is monetising serviceintelligence and connectivity options. With service intelligence atthe IP edge, IPTV service providers can control OTT traffic so itdoes not overwhelm their networks or their finances. With morecontrol over application behaviour in the network, service providerscan offer subscribers the freedom to make bandwidth trade-offs thatbest meet their needs and they can turn OTT video vendors intopartners by offering higher levels of QoS that are beyond their scopeof achievement.

9.6 Conclusions

In this chapter, we have discussed the importance of anomaly detec-tion in IPTV networks. At first, we established the fact that IPTVnetwork data are different from regular network traffic. Then, wediscussed the current definition of anomaly in the context of HHH.Based on the definitions, we examined a robust anomaly detectiontechnique in IPTV networks along with their limitations and experi-mental analysis. Then, we discussed the future research directions in

Page 258: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Anomaly Detection and Big Data in IPTV Networks 243

light of big data as it is being considered one of the crucial factors ininformation technology advancement. This chapter will be helpful forresearchers who are actively involved in the anomaly detection andbig data domains and would like to explore the IPTV network as anapplication field for anomaly detection.

References

Ahmed, M., Mahmood, A.N. and Maher, M.J. (2015). An efficienttechnique for network traffic summarization using multiviewclustering and statistical sampling. ICST Transactions on ScalableInformation Systems, 2(5), doi:10.4108/sis.2.5.e4.

Bermúdez, José D., Corberán-Vallet, Ana and Vercher, Enriqueta (2009).Multivariate exponential smoothing. Mathematics and Computers inSimulation, 79(5, January), 1761–1769.

Bernacki, Jarosław and Kołaczek, Grzegorz (2015). Anomaly detection innetwork traffic using selected methods of time series analysis.International Journal of Computer Network and Information Security,7(9), 10–18.

Chi-Yao Hong, Caesar, M., Duffield, N. and Wang, Jia (2012). Tiresias:Online anomaly detection for hierarchical operational network data,Distributed Computing Systems (ICDCS), 2012 IEEE 32ndInternational Conference, Macau, pp. 173–182.

Gallagher, B. (2013). The Components and Advantages of IPTV .Available: http://leightronix.com/blog/the-components-and-advantages-of-iptv/ (last accessed 14th March 2016).

Gama, João, Žliobaite, Indre, Bifet, Albert, Pechenizkiy, Mykola andBouchachia, Abdelhamid (2014). A survey on concept drift adaptation.ACM Computing Surveys, 46, 4.

Holt, Charles C. (2004). Forecasting seasonals and trends byexponentially weighted moving averages. International Journal ofForecasting, 20(1), 5–10.

O’Driscoll, Gerard (2008). Next Generation IPTV Services andTechnologies. Wiley-Interscience, New York, NY, USA.

Pripužic, Krešimir, Žarko, Ivana Podnar and Aberer, Karl (2015). Time-and space-efficient sliding window Top-k query processing. ACMTransactions on Database Systems, 40, 1.

Page 259: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

244 IPTV Delivery Networks

Rao, K.R., Kim, D.N. and Hwang, J.-J. (2010). Fast FourierTransform – Algorithms and Applications, 1st edn, SpringerPublishing Company, Incorporated.

Simpson, W. and Greenfield, H.A. (2007). IPTV and Internet Video: NewMarkets in Television Broadcasting. Focal Press, London, pp. P1–240.

Spyros, S. (2013). IPTV Meets Big Data – Predicting User Behaviour toCreate Attractive Offerings. Available: http://www.iptv-news.com/2013/03/iptv-meets-big-data-predicting-user-behaviour-to-create-attractive-offerings/ (last accessed 14th March 2016).

Winkler, F., Abbadessa, D., Silva, J.D., Girao, J. and Schmidt, M. (2008).Enriching IPTV services and infrastructure with identitymanagement. GLOBECOM, IEEE, 5564–5568.

Page 260: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

245

Part III

Mobility and Next-Generation Delivery Networks

Page 261: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

247

10

Taxonomy of Intra-Domain Mobility ManagementSchemes in Wireless Mesh Network forImplementing Mobile IPTVAbhishek Majumder, Subhrajyoti Deb and Sudipta Roy

10.1 Introduction

Internet Protocol television (IPTV) is the system of broadcastingand transferring TV programmes over the Internet using InternetProtocol (IP). IPTV connection process is fully digitised, and itworks on an Internet connection. IPTV can be transmitted throughboth wired and wireless media. Transmission of IPTV over wirelessmedia reduces the deployment cost and makes the implementationeasier. In the case of wireless media, clients may be static or mobile.An IPTV network of mobile users is known as mobile IPTV. Inmobile IPTV, there are mainly two types of architectures (Zeadally,Moustafa and Siddiqui, 2011): Stationary sender–mobile receiverarchitecture and mobile sender–mobile receiver architecture. Instationary sender–mobile receiver architecture, the IPTV content andprogrammes are transmitted by the stationary servers. The receiversare handheld mobile devices. This type of architecture is very popularand for the implementation of this architecture, continuous Internetconnectivity to the mobile user is crucial. On the other hand, inmobile sender–mobile receiver architecture, both the senders and thereceivers are mobile. In this architecture, the users can create IPTVcontent and provide IPTV services to other clients. If both the senderand the receiver belong to the same network, this type of architecturewill create intranet traffic. The selection of wireless communicationnetwork technology for the deployment of mobile IPTV is a challenge.For the implementation of mobile IPTV, the wireless mesh network(WMN) is a promising technology (Shihab et al., 2008; Rong and

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 262: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

248 IPTV Delivery Networks

Hafid, 2010). Birlik, Gürbüz and Ercetin (2009) explained the imple-mentation of IPTV home networking through 802.11 (WMN) andhave shown that the quality of service (QoS) of both multimedia anddata users improve. But in the implementation of mobile IPTV, themobility of the mobile users poses an enormous challenge (Zeadally,Moustafa and Siddiqui, 2011). The requirement to maintain seamlessnetwork connectivity to the mobile IPTV users makes the problemmore challenging (Heikkinen et al., 2008; Zeadally, Moustafa andSiddiqui, 2011). Therefore, mobility management schemes for WMNare promising solutions for providing high-quality mobile IPTVservices to the mobile users.

WMN (Akyildiz and Wang, 2005; Akyildiz, Wang and Wang, 2005;Zhang, Luo and Hu, 2006) is a leading solution for modern wirelesscommunications. In WMN, nodes can be classified as mesh client(MC), mesh router (MR) and gateway (GW). The mobile users areknown as MCs. Here MRs are the wireless routers to route the Inter-net as well as Intranet packets. In the mesh network, MR with a wiredinterface to the Internet is known as GW. When the MC moves fromthe vicinity of a MR and enters another, the MC gets disconnectedfrom the old MR and is connected to a new MR. This process isknown as handoff. During handoff, if the user has been accessingIPTV, the service may be disrupted. For ensuring uninterrupted IPTVin the mobile device, seamless mobility management of the MCs isnecessary. To provide seamless connectivity to the MCs, many mobil-ity management schemes have been developed. There are two typesof mobility management schemes: Inter-domain and intra-domain.Inter-domain mobility management schemes are concerned withthe management of movement when the MC is moving from onenetwork domain to another. On the other hand, intra-domain mobilitymanagement scheme is concerned with managing the movementof the MC when it is moving within the same domain. This chapterfocuses on intra-domain mobility management schemes.

Figure 10.1 shows the implementation of mobile IPTV in WMN. Italso demonstrates an instance of intra-domain mobility of the MCsin WMN while they are using the IPTV services. In this example, anInternet GW is present that connects the WMN to the Internet. Inter-net GW enables the mobile nodes (MNs) to access IPTV programmesfrom the servers behind it. The MRs route the IPTV programmes tothe consumers of IPTV. Here all the MRs are in the same domain.MCs are the users of the IPTV, who access the IPTV programmes.

Page 263: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 249

Mesh

client 1

Mesh

client 1

Mesh

router 3

Mesh

router 4

Mesh

client 2

Mesh

router 2

Mesh

router

Mesh

client 2

Mesh

router 1

Internet

Mesh

router

Internet

gateway

Mesh

router

Mesh

router

Wired connection

Wireless connection

between MRs

Wireless connection

between MR and MC

Node movement

Mesh

router

Figure 10.1 Scenario for intra-domain mobility of MCs accessing IPTV services.

In this example, there are two MCs: MC1 and MC2, which move fromone MR to another. Both MC1 and MC2 access the services of IPTVthrough the Internet GW. This creates Internet traffic between the GWand the MC via intermediate MRs. Let MC1 produce some contentof IPTV and MC2 access that content. This initiates intranet trafficbetween MC1 and MC2. Both MC1 and MC2 move from the vicinityof one MR to another. But, to ensure uninterrupted IPTV services, it isessential to maintain continuous connectivity to both the MCs. There-fore, intra-domain mobility management of the MC1 and MC2 is animportant issue for the provisioning of seamless mobile IPTV servicesto the MCs.

The organisation of the chapter is as follows: Section 10.2 discussesthe classification of mobility management schemes. Advantages

Page 264: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

250 IPTV Delivery Networks

and disadvantages of the schemes are presented in Section 10.3.Section 10.4 presents the open research problems. Finally, the chapteris concluded in Section 10.5.

10.2 Classification

Intra-domain mobility management schemes can be classified intothree categories: Tunnel-based, routing-based and multicast-based.Figure 10.2 shows the taxonomy of mobility management schemesin WMN.

Mobility management falls into three categories:

i. Tunnelling-based schemes: In tunnel-based schemes, GW main-tains a location database for every user. Downstream Internet

Intra-domain

mobility

management

Tunneling

based

ANT

M3

Static anchor scheme

Dynamic anchor

SMR based scheme

Routing

based

iMesh

OLSR Fastsync

MEMO

Mobile party

WMM

LMMesh

FPBR

Multicasting

based

iMesh

Figure 10.2 Taxonomy of mobility management scheme.

Page 265: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 251

packets or IPTV packets are sent from the GW to the destinationMC through the tunnel. Upstream Internet packets are sentwithout tunnelling. Intranet packets or IPTV packets served byother mobile nodes within the network are tunnelled from thesource MC to the destination MC. Some of the intra-domainmobility management schemes are ANT (Wang et al., 2007), meshmobility management (M3) (Huang, Zhang and Fang, 2007), staticanchor scheme (Li and Chen, 2011), dynamic anchor scheme(Li and Chen, 2011) and session-to-mobility ratio (SMR)–basedscheme (Majumder and Roy, 2013).

ii. Routing-based schemes: In routing-based schemes, mobilitymanagement is embedded in the routing process. MC’s locationinformation is maintained in the routing table or proxy table.Some of the routing-based schemes are: Infrastructure mesh(iMesh; Navda, Kashyap and Das, 2005), optimised link statefastsync (OLSR Fastsync; Speicher, 2006), MEsh networks withMObility management (MEMO; Maoshen et al., 2007), mobileparty (Sabeur et al., 2007), wireless mesh mobility management(WMM; Huang, Lin and Gan, 2008), LMMesh (Li and Chen,2012) and forward-pointer-based routing (FPBR; Majumder andRoy, 2014).

iii. Multicasting-based schemes: In multicasting schemes, multiplecopies of the same data packet are transmitted to the destinationMC through different MRs. An example of multicasting-basedmobility management scheme is SMesh (Amir et al., 2006; 2010).

10.2.1 Tunnelling-Based Schemes

In this section, the tunnel-based schemes are discussed.

10.2.1.1 ANTWang et al. (2007) proposed a tunnel-based local mobility manage-ment scheme known as ANT. The objective of the ANT scheme is tomanage the mobility of MCs efficiently. The network consists of threetypes of nodes: Routing access point (RAP), Gateway RAP (GRAP) andmobile node. MNs are the users of the network. The RAP works in twoways: It acts as wireless access points (APs) that provide access ser-vice to MN and works as wireless mesh backbone to route the packetsof MH. In the network domain, there is minimum one gateway RAP(GRAP) connecting to the Internet. Figure 10.3 shows an example of

Page 266: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

252 IPTV Delivery Networks

RAP

Internet

CN

GRAP

MN CN

RAP

RAP

Wireless connection

Intranet traffic

Internet traffic

RAP: Routing access point

CN: Corresponding node

GRAP: Gateway routing access point

MN: Mobile node

Figure 10.3 ANT mechanism.

the ANT mechanism. When MN joins the mesh network, it performsthe media access control (MAC) layer association with RAP.

The scheme has the following steps:

i. Mobile host joining network: A location server maintains a loca-tion database to keep track of all MN location information. Thedatabase entry is a triple mapping of {MN-ID, MN-IP, MN-RAP}.The MN-ID is the MAC address of the MN’s network interface. TheMN-IP is the IP address of MN. MN-RAP is the IP address of theRAP to which MN is currently attached with. When a MN joinsRAP, it sends a location update message consisting of MN-ID tothe location server. When the location server has no entry for theMN-ID in its database, it requests the Dynamic Host Configura-tion Protocol (DHCP) server to allocate a new IP address to MN.The MN-IP is sent to the MN through the DHCP message usingstandard DHCP. If there exists an entry of the MN in the locationdatabase, the location server updates the database and sends backa location update acknowledgement message to the MN.

ii. Communication initialisation: When a MN wants to communicatewith a corresponding node (CN), it issues Address Resolution Pro-tocol (ARP) request message to the RAP it is attached with to getthe MAC address of the CN. After receiving the message, the RAP

Page 267: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 253

of the MN queries the location server to get the connecting routerof the CN. The location server sends back the RAP IP of the CNto the MN’s RAP. Then, a bidirectional tunnel will be establishedbetween MN-RAP and CN-RAP.

iii. Fast handover: Each RAP maintains a list of neighbour RAPs.When RAP detects a MAC-layer de-association event of a MN, itsends a handoff notification to all its neighbouring RAPs. Whenthe new RAP detects MAC layer association or re-associationevent of the MN, it verifies whether it has received handoff notifi-cation for the MN. If the message is received, the new RAP sendshandoff confirmation and location update message to the old RAPand the location database. When old RAP receives the handoffconfirmation message, it stops buffering the packets for MN andsets up a bidirectional tunnel to the new RAP for forwarding thepackets. The old RAP informs CN-RAPs that MN has changed itspoint of attachment. It also informs new RAP about the addressesof CN-RAP. After that, the route is established between the newRAP and CN-RAP for communication between MN and CN.

10.2.1.2 Mesh Mobility Management (M3)Huang, Zhang and Fang (2007) proposed a mobility managementscheme for WMNs known as mesh mobility management (M3). InM3, WMN consists of many MCs, one GW and multiple MRs withAPs functionality. The GW is used in M3 only for assigning a uniqueIP address in its domain to a MC. This unique IP address of the MCcan be the care-of address (CoA) when mobile IP is used for theinter-domain roaming. GW contains both the foreign agent (FA) andthe home agent (HA).

Figure 10.4 shows an example scenario of M3. In Figure 10.4, threeAPs connected to the GW have admirable status concerning theirdownstream nodes. They need to gather the location information ofthe MCs in the cells of the subordinate APs. These APs are superiorrouters (SRs). The rest of the APs have the same status. In the case ofa large mesh network, SRs can share the traffic towards the GW. InWMN small structure, if the GW is not the bottleneck, these SRs canbe removed, which yields only a two-level hierarchical structure.

A WMN can be built up in a tree-like structure. The routing of thisscheme strictly adopts a tree structure even if there exists a shorter

Page 268: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

254 IPTV Delivery Networks

Downstream and upstream Internet

traffic between new AP and client

Downstream and upstream Internet

traffic between old AP and client

Client movement

direction

Downstream Internet

traffic

Forward pointer from old

AP to new AP

Upstream Internet trafficClientClient

AP2AP1

AP

AP

SR

SR

SR

Gateway

Internet

AP

AP

Wireless connection

Figure 10.4 Mesh mobility management.

path. In WMN, the M3 scheme performs the communication alongthis route. Routing in the backbone is shown in Figure 10.4. The back-bone nodes of WMNs are considered stationary.

When the MC moves from the vicinity of an AP to another AP,a forward pointer is added from old AP to new AP. This processcontinues until a location update message is sent to the SR or GW.When the location update message is sent to the SR or GW, theforward chain length is reset to 0 and the host AP is set as serving APof the MC in the location database of the SR or GW. The AP sendslocation update message of all the MCs under its vicinity to the SRafter every Tlu time interval. The SR sends a location update messageto the GW after every Thu time unit. In this scheme, downstreamInternet or IPTV packets are tunnelled by the GW to the servingAP of the MC. If the MC is present in its vicinity, the packets willbe delivered to the MC. Else the packets are delivered through theforward chain of APs. In the case of upstream Internet packets orIPTV served by the mobile sender, the packets are directly sent fromthe current AP of the MC to the GW without tunnelling. The intranetor IPTV traffic is sent to the GW by the source MC. The GW thensends the packet to the AP using a tunnel.

Page 269: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 255

10.2.1.3 Static Anchor SchemeLi et al. proposed two mobility management schemes for WMNs,namely, the static anchor scheme and dynamic anchor scheme (Li andChen, 2011). These two schemes are based on pointer forwarding,that is, a chain of forwarding pointer method is used to track thecurrent location of a MC.

When an MC moves from the vicinity of a MR to another, itde-associates from its old MR and re-associates with the new MR,and thus, triggering a location handoff. A forward pointer will beadded between the old MR and new MR. For every MC, the lengthof its forward chain should be less than a certain threshold K. Ifthe length of the MC’s forwarding chain is larger than the thresholdvalue K, a location handoff process will be triggered. In the locationupdate process, a location update message is sent to the GW as wellas all CNs of the MC. After the completion of location update, theforwarding chain is reset and the new MR turns into the anchor meshrouter (AMR) of the MC. The location handoff process is shownFigure 10.5.

In Figure 10.5, let the MC1 have the threshold K = 2. When the MC1moves from AMR to MR1, a forward pointer is added from AMR toMR1. Again, when it moves from MR1 to MR2, the same process is fol-lowed. But when the MC1 moves from MR2 to MR3, it sends location

Node movement

direction

Wireless

connection

Forward

pointer

Location update

message

Internet

Internet

corresponding

node

Gateway and

location server

MR MR

MC 2MR MR

AMR

MR

MRAMR

K = 1 K = 2

MR 1 MR 2 MR 3

(New AMR)

MC 1 MC 1

Figure 10.5 Static anchor scheme.

Page 270: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

256 IPTV Delivery Networks

update message to the GW and the CNs. In this case, the CN is MC2.After location database, update MR3 becomes the new AMR of MC1.

GW maintains location information of all the MCs of the network.When it receives downstream Internet packets or IPTV packets fromthe external server to the MC, it sends the packet to the AMR of theMC, which, in turn, forwards it to the MC by using forwarding chain.The upstream Internet packets or IPTV packets from the mobilesender are directly sent by the current MR of the MC to the GW.

In the case of a new Internet session, MR of the MC sends locationquery message to the GW. Because the location database is in the GW,it finds the location of the CN. Then it returns the address of the AMRof CN. Now, the AMR of the MC can directly send data to the AMRof CN. The AMR of CN then forwards the data packets to the CN.

10.2.1.4 Dynamic Anchor SchemeDynamic anchor scheme (Li and Chen, 2011) is similar to static anchorscheme, but in the dynamic scheme, the forwarding chain of a MC isalso reset with the arrival of new Internet or Intranet sessions. When anew Internet session arrives at GW, the GW initiates a location updateprocedure. The GW sends location query message to the AMR of thedestination MC. The AMR then forwards the location query messageto the current MR of the MC. The current MR sends back route updatemessage to the GW. The GW updates the location information of theMC in its database and sets the current MR of the MC as its AMR. TheGW then routes the packet to the AMR of the destination MC.

When a new Intranet session is initiated to the MC by another MC,the source MC sends a location query message to the GW. The GW ini-tiates a location search procedure to find the AMR of the destinationMC. After the completion of the location search procedure, the GWsends a location update of the destination MC to the current MR of thesource MC. Then packets can be routed between the current MR of thesource MC and the AMR of the destination MC. Figure 10.6 illustratesthe location search method for Intranet sessions. Let MC1 and MC2represent the source and destination MC, respectively. An Intranetsession is initiated towards MC2 from MC1 through the present serv-ing MR of MC1. MR1 sends a location request message to the GW. TheGW queries the location database and routes the location request mes-sage to the AMR of MC2. AMR sends the location request message tothe present MR of MC2. After receiving the location request message,MR of MC2 sends a location reply message to the GW. On receipt of

Page 271: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 257

MC 1

Internet

Location request

message

Wireless

connection

Location request

message through

forward pointer

Location reply

message

Gateway and

location server

Internet

corresponding

node

MRMR

MR

MRMR

MRMC 2

MRAMR

MR MRMR

Figure 10.6 Dynamic anchor scheme.

the location reply message, the GW updates the location informationof MC2 in its location database. GW then sends the location informa-tion of the MC2 to MC1’s MR. Thus, the location update process forthe intranet session will be completed.

10.2.1.5 SMR-Based SchemeMajumder and Roy (2013) proposed a SMR-based dynamic mobil-ity management scheme for WMN. In this scheme, GW maintainsa database of serving MRs of all the MCs roaming inside the WMN.When the MC joins a WMN, it first gets associated with a nearby MR.Then, the MC calculates its SMR. If the SMR value is higher than adynamically changing threshold value, it sends a location update mes-sage to the GW. Else, a forward pointer is added from the old MR tonew MR. The scheme has the following steps:

i. SMR calculation: A session is a stream of the consecutive packet atthe IP layer (Majumder and Roy, 2013). Each MC has an active statetimer with length TA. If time duration between the receiving of twoconsecutive packets is greater than TA, the current packet is con-sidered as the first packet of a new session. Otherwise, the packetbelongs to the ongoing session. Mobility rate is the MR crossingrate of the MC. This method considers both session arrival rate tothe MC and session departure rate from the MC. Therefore, SMR

Page 272: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

258 IPTV Delivery Networks

is the ratio of the summation of session arrival and departure rateand mobility rate.

ii. Calculation of optimal threshold SMR: SMRoth is computed foreach user through Bat Algorithm (BA). When the MC enters thevicinity of the new MR, it calculates SMRoth. SMRoth is calculatedwith an objective to reduce total communication cost of the MC.

iii. Mobility management: In this scheme, when the MC moves intothe vicinity of a new MR, it calculates its SMRMC and compares itwith SMRoth. If SMRMC is less than the SMRoth, the MC notifies thenew MR about its handoff from the old MR and it also sends theaddresses of the corresponding MCs. After receiving the message,the new MR informs the old MR about the handoff and queriesabout the serving MR of the corresponding MCs. The old MRreplies by sending addresses of serving MRs of the correspondingMCs. A forward pointer is also added from the old MR to the newMR of MC. Thus, the forward chain length of the MC increasesby 1.On the other hand, if the SMRMC is larger or equal to SMRoth,the new MR sends a location update message to the GW and thecorresponding MCs. Thus, the forward chain length is reset.

iv. Routing: For routing of downstream Internet packets or IPTVpackets from the external server, GW tunnels the packets toserving MR of the MC. The serving MR then sends the packetsto the current MR of the MC through the forward chain. Theupstream Internet packets or IPTV packets from the mobilesender are directly sent to the GW by the current MR of MCwithout tunnelling. In the case of intranet traffic or IPTV servicefrom a mobile sender, the packets are directly tunnelled to theserving MR of MC. The serving MR then forwards the packet tothe current MR of destination MC or IPTV receiver.

10.2.2 Routing-Based Schemes

In this section, routing-based schemes have been presented.

10.2.2.1 Infrastructure Mesh (iMesh)iMesh (Navda, Kashyap and Das, 2005) is an infrastructure-modemobility management scheme for WMN based on IEEE 802.11. Thescheme is a routing-based one. When the MC moves away from thevicinity of the MR, a link layer handoff is triggered. After completion

Page 273: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 259

of the link-layer handoff, the Optimised Link State Routing (OLSR)protocol is used to broadcast an host and network association (HNA)message in the entire network declaring the new route to the MC.There are mainly two parts in the iMesh mobility managementscheme:

i. Link layer handoff : When the station moves out of the vicinity ofan AP, it triggers a link layer handoff, to find the new AP. The clientcontinuously measures the signal strength of the APs from the bea-con. If the signal strength of the AP falls below a certain thresh-old and another AP has sufficiently high signal strength, the clienttriggers a handoff. The client broadcasts a probe request message.On receiving the probe request message, the APs send a proberesponse message. The client waits for probe-wait time to gatherprobe responses from APs. The client gets the associated AP withthe best signal-to-noise ratio (SINR).

ii. Network layer handoff : In the iMesh scheme, the OLSR protocolruns on all wireless distribution system (WDS) interfaces for everyAP. OLSR does not run on the client-side interface of the AP. Theclient is unaware of routing. AP considers its link with the clientas an external route. When the client moves from the vicinity ofan AP to another, the client uses the new AP as default GW. Themapping of the IP address and MAC address of the client is storedin the new AP. The new AP broadcasts a HNA message in the entirenetwork using the OLSR routing protocol. On receiving the HNAmessage, all APs of the WMN delete the pre-existing entries of theclient and store the new route.

10.2.2.2 OLSR-FastSyncThe OLSR-FastSync (Speicher, 2006) scheme is a proactive routingprotocol. It has been proposed to reduce the uplink and downlinkpath setup delays. The principal objectives are (a) to enable mobilenodes explore, select and declare multipoint relays (MPRs) in thehandoff-target WMN quickly and (b) to allow MNs to obtain a copyof the entire topology and GW information from one of the selectedMPRs directly after the handoff. This protocol can be categorised intothree parts such as fast neighbour detection, fast downlink setup andfast uplink setup.

i. Fast neighbour discovery: For finding out the neighbours, MNbroadcasts a FastSync HELLO-request message (FS-HELLO-REQ).

Page 274: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

260 IPTV Delivery Networks

When points of attachment (PoAs) receive the HELLO requestmessage, it adds MN as an asymmetric neighbour and repliesthrough the broadcast of the HELLO message. After sendingthe FS-HELLO-REQ, MN initiates a timer and waits for HELLOmessages from PoAs. When the timer reaches tndis_max and if noHELLOs are received, another FS-HELLO-REQ is sent. Afterthat, the timer is increased. On the other hand, when the HELLOmessages from the PoAs are received, MN adds the PoAs as thesymmetric neighbours and proceeds to step (ii).

ii. Fast downlink setup: In this phase, the MN selects MPRs fromthe discovered symmetric neighbours. MN sends a hello messageto declare its selected mesh point relays (MPRs) and symmetricneighbours. On receiving the hello message PoAs, which are listedin the symmetric neighbour list, consider MN as the symmetricneighbour. Moreover, PoAs that were selected as MPRs by MN,broadcast a topology control (TC) message to declare that MNcan be reached through them. After the broadcast of the TCmessage, all the nodes in WMN can obtain the route to the MN.This process is used to establish the downlink.

iii. Fast uplink setup: MN sends a FastSync synchronisationrequest (FS-SYNC-REQ) to its MPR and starts a timer. WhenMPR receives the FS-SYNC-REQ message, it multicasts it toselected MPR. MPR sends back FastSync synchronisation reply(FS-SYNC-REP) to the MN. The FS-SYNC-REP contains theentire topology of the MPR. Thus, the MN gets a route to everyother node of the WMN. Figure 10.7 shows the OLSR FastSyncprocess and the flow of synchronization messages.

10.2.2.3 Ad Hoc on-Demand Distance Vector and Mesh and MEshNetworks with MObility Management (AODV-MEMO)Ad hoc AODV-MEMO (Maoshen et al., 2007) is an intra-domainmobility management scheme proposed for WMN. It associatesrouting with mobility management. In the MEMO scheme, mobilenodes carry their IP addresses unchanged while moving acrossdifferent MRs within a WMN.

MEMO system design can be categorised into various parts: (a)IP addressing and self-configuration; (b) location registration; (c)routing; (d) mobility management and seamless user roaming; (e) GWfunction.

Page 275: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 261

1

2

Mobile nodeAdjacent

PoA1

Adjacent

PoA1

Adjacent

PoA1

FS-HELLO-REQ (broadcast)

HELLO (broadcast)

HELLO (broadcast)

TC (broadcast)

HELLO (broadcast)

TC (broadcast)

FS-SYNC-REQ

3

Figure 10.7 OLSR Fastsync.

GW

MN

MRMR MR

MRMR MR MR

MR MR

Wireless connection

GW: Gateway

MR: Mesh Router

MN: Mobile Node

Figure 10.8 MEMO architecture.

i. IP addressing and self-configuration: In the MEMO scheme, asshown in Figure 10.8, two hierarchy structures of IP addresses areused. One is used for the backbone interface and the other for theclient access interface of the MR. There are DHCP servers presentin the MRs, which compute IP addresses of its clients from theirMAC addresses. When a MN joins a MR, it will be allocated an IPaddress where the first 8 bits will be fixed and the rest of the 24bits are the last 24 bits of the MN’s MAC address.

Page 276: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

262 IPTV Delivery Networks

ii. Location registration: In the MEMO scheme, when a MN joinsthe WMN or a new MR, it sends a IEEE 802.11 association orre-association frame to the AP-mode interface of MR. MR storesthe MAC address and IP address of MN in its local MNs table(LMT).

iii. Routing: The MNs can be connected to each other, and further,they can be connected to the Internet or IPTV programme serversvia GW. The MN can handle three types of traffic: Traffic betweentwo MNs within the same MR, traffic between two MNs under dif-ferent MRs in the WMN and traffic between the MN and the GW.

In the case of traffic between two MCs within the same MR, thesource MN sends packets to the host MR, which relays them to thedestination MC. In the event of traffic between two MNs under dif-ferent MRs, source MN sends ARP request to its host MR. The sourceMR sends back ARP response on behalf of destination MN. Then thesource MN sends all packets to its host MR. If the host MR does nothave a route to the destination MN, it floods route request packet tofind the destination MN. The host MR of destination MC sends backroute reply message. Thus, a route will be established between thesource MN and destination MN. In the case of traffic between the MNand the GW, the MN sends Internet or IPTV packets its host MR. Allthe MR in WMN has a route to the GW because the GW periodi-cally broadcasts GW advertisement packet. On receiving the Internetor IPTV packets, the MR sends a proactive route reply message to theGW. This route reply sets up a path from GW to MR. Thus, a route willbe established between GW and MN, and the Internet or IPTV packetcan be transferred through this route.

i. MAC-layer triggered mobility management: When the MN movesfrom one MR to another, it has to rebuild all the routes. First, theMN sends a disassociation message to the old MR that broadcastsroute error message in the entire network. After that, the MNsends authentication and association message to the new MRthat broadcasts a route request message to all correspondingMNs with whom the MN wants to continue communication.The corresponding MNs send back a route reply message. If thecorresponding MN wants to continue communication with theMN, it performs the same route discovery process.

ii. GW function: Gateway mesh routers provide Internet service tothe MNs. It also connects MNs to the external IPTV programme

Page 277: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 263

servers. When a MN roams to a new MR, it updates its locationin the GW routing table by sending a proactive route reply to theGW.

10.2.2.4 Mobile PartyMobile party (Sabeur et al., 2007) is another intra-domain seamlessmobility management solution. This scheme incorporates a newaddress allocation mechanism, which is established through theaddress tree. Each node of MR and MC has a unique address identifierand a dynamically changing unique address that changes as the nodemoves. The root of the address tree is GW, with the address 000.The next level nodes, which are the children of the GW, are assignedaddresses within the range 100–900. The nodes that are the childrenof node 100 are assigned addresses from 110 to 190. This processcontinues until the address tree is formed. The neighbourhoodinformation is stored in the neighbour table of a node. On receiving apacket, an intermediate node forwards it to another node that sharesthe longest prefix with the destination address.

When a node joins the network, a rendezvous agent (RA) is deter-mined. The RA stores the mapping information (node ID, current tem-porary address). To determine an RA of the node, a hash function isused over the node ID. The m bits obtained after hashing is convertedinto a temporary address Rr using a certain function. Then a registra-tion request is sent to Rr. The request message is forwarded until itreaches a node with an address that has the longest prefix match withRr. For sending an intranet or IPTV packet to the destination, sourcenode applies the globally known hash function on the destination nodeID to obtain the address Rr of the destination’s RA. Then a mappingrequest is sent to the Rr. If any intermediate node has a recent routewith the required mapping information, it sends a mapping reply. Else,the request is forwarded to the node with the longer matching addressprefix with Rr. This process continues until the request reaches a nodewith the longest matching address prefix with Rr. On receiving themapping request, the node sends back the mapping reply. Once thesender receives the mapping information of the destination node, itsends the intranet or IPTV packet to the destination.

The GW periodically broadcasts its mobile party address through aGW broadcast. So, each of the backbone nodes has the route to theGW. When any RA with the longest prefix match receives a mappingrequest but does not have the entry of the destination in its cache, it

Page 278: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

264 IPTV Delivery Networks

sends the mobile party address of the GW through the mapping replyto the source node. The source node then sends the Internet or IPTVpackets to the GW.

10.2.2.5 Wireless Mesh Mobility Management (WMM)Huang, Lin and Gan (2008) proposed a mobility management schemenamed WMM. In the WMM mechanism, MNs and mesh access points(MAPs) are assigned a fixed IP. IP addresses are allocated to mobilestations (MSs) manually or by DHCP. MN maintains two cache tablessuch as routing table and proxy table. The routing table is used to main-tain the routing paths between the MN and other MNs. The proxytable manages the location information of the MS. In the IP headerof the data packets, location information of source and destination isstored. Four new subfields are created in the options field: Serving timestamp (SST) field (for storing sender’s SST), ISS field (for storing IPaddress of sender’s serving MAP; SMAP), the receiver’s serving time(RST) field (for storing the RST stamp) and IP address of the receiver’sSMAP (IRS) field (for storing the IRS).

When an MS moves into the vicinity of an MAP from its old SMAP,it sends a registration request to the new MAP. The new MAP updatesits proxy table by creating or updating the entry of MS and becomesSMAP of the MS. The new MAP sends an update request to the oldMAP. The old MAP updates its proxy table and sends back updatereply message to new MAP. Thus, the registration process of MS inthe new MAP is complete.

MS sends Internet or IPTV packets to the SMAP. The packets arethen forwarded to the mesh backhaul node, which is connected to theInternet or external IPTV programme servers. In the case of down-stream Internet or IPTV packets, the packets are received by the meshbackhaul node. If the entry of the MS is present in its proxy table, thepacket will be forwarded to the MS through its SMAP. Else, the meshbackhaul node broadcasts a route request message in the entire WMNto find the destination MN. The SMAP of the destination MN sendsback the route response message to the backhaul node. The backhaulnode sends the downstream Internet or IPTV packets through thatroute. In the case of intranet or IPTV traffic, the source MS sends thepackets to its host SMAP. If the host SMAP does not have the loca-tion information of the destination MS in its proxy table, it forwardsthe packet to the next hop MN towards the backhaul node. When theintermediate MN receives the data packet, it first updates the proxy

Page 279: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 265

table entry corresponding to the source MS. If it has information aboutthe destination MS in its proxy table, the MN forwards the packet tothe destination. Thus, proxy table update and routing of data packetsare done simultaneously.

10.2.2.6 LMMeshLi and Chen (2012) proposed a new routing-based mobility man-agement scheme known as LMMesh. LMMesh combines bothrouting-based location update and pointer forwarding. The datapackets of both the Internet and intranet or IPTV contain the locationinformation of the originator MC in the option field of its IP header.After receiving the data packet, a GW or CN of the MC extracts thelocation information from the data packet. GW updates its locationdatabase from the location information of the source MC. CN usesthis information to route data packets to the MC.

Because GW periodically advertises the GW advertisement in theentire network, all MRs have a route to the GW. When the MC ini-tiates Internet traffic, the uplink Internet packets are sent to the GW.On receiving the uplink Internet data packet from the MC, the GWupdates its location database. The GW uses the location informationto route the downstream Internet packets to the MC. When a newInternet session is initiated towards the MC, the GW sends a locationrequest message to the AMR of the destination MC. The AMR for-wards this information to the serving MR of the MC. The serving MRof the MC sends back location update message to the GW. The GWsets the serving MR of MC as its AMR and sends the downstreampackets to the AMR of the MC. In the case of the intranet packet,the serving MR of the source MC sends a location request messageto the GW. The GW forwards this message to the AMR, and AMRagain sends it to the serving MR of MC. The serving MR sends backthe location update message to the GW, and the GW forwards this tothe MR of the source MC. The source MC can now send packets to thecurrent AMR of the MC.

When the MC moves from one MR to another, a forward pointer isadded from the old MR to the new MR. The forward pointer is resetuntil a new session is initiated to or from the MC, or the chain lengthbecomes equal to the threshold forward chain length (k). If the forwardchain length of the MC is equal to k, the serving MR sends a locationupdate message to the GW and becomes the AMR.

Page 280: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

266 IPTV Delivery Networks

10.2.2.7 Forward Pointer-Based Routing (FPBR)FPBR (Majumder and Roy, 2014) scheme is a tree-based protocol. GWinitiates the process to form the tree. A tree structure of the MCs isused for mobility management of MCs. The scheme has three parts:

i. Tree formation: In the FPBR scheme, the GW periodically broad-casts GW advertisement in the entire network. The advertisementconsists of the level of information. Initially, the level is set to 0 bythe GW. After receiving the GW advertisement, MR incrementsthe value of the level by 1 and stores the level information.Then it rebroadcasts this message to its neighbouring MRs. Thisrebroadcasting process continues until a minimum distanced pathis formed from every MR to the GW. The MRs propagate theirlevel information to neighbouring MRs through a periodical hellomessage. Thus, a tree structure of MRs is formed where GW actsas the root of the tree. Each MR has three types of relationshipwith its neighbours: Child, parent and sibling. This information ismaintained in the neighbour table of the MRs.

ii. Mobility management: After the completion of the link layer hand-off process, the network layer handoff starts. In the FPBR model,when the MC moves from one MR to another, the MC sends aroute update message to the new MR. After receiving the routeupdate message, the new MR checks its relationship with the oldMR. Based on the relationship, it performs one of the followingprocesses:• If the new MR is the child of the old MR, the new MR sends the

route update message to the old MR. The old MR updates theentry to the corresponding MC in its routing table.

• If the new MR is the sibling of the old MR, the new MR broad-casts the route update message through a OLSR in the entirenetwork. On receiving the route update message, the GW andall the MRs refresh the routing table entry to the correspondingMCs. Thus, the forward pointer of the MC is reset.

• If the new MR is the parent of the old MR, the new MR firstsends the route update message to its sibling MRs. If theentry of the MC is present in the routing table of its siblingMR, it sends an ACK message to the new MR. A forwardpointer is added from the old MR to the new MR. Otherwise,a negative-acknowledgement (NACK) signal message will besent to the new MR. If the new MR receives NACK from all its

Page 281: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 267

siblings, the new MR initiates a location update process similarto that of the sibling to sibling movement.

iii. Routing: The FPBR scheme uses a proactive routing method. GWand MRs of the WMN maintain a route to every MC. In thisscheme, when the GW receives a downstream Internet packet orIPTV packets from external servers. GW checks the destinationpart in the received packet. Then, it forwards the packet to thenext hop MR towards the destination. The intermediate MRs alsofollow the same process. This process continues until the packetreaches a MR within whose vicinity the destination MC is present.The upstream Internet or IPTV packets are routed from MC’scurrent MR to the GW. Intranet or IPTV packets are also routedfrom the current MR of the source MC to the serving MR of thedestination MC. The serving MR then forwards the packet to thecurrent MR of the destination MC.

10.2.3 Multicasting-Based Scheme

This section presents a multicast-based scheme named ‘SMesh’.

10.2.3.1 SMeshAmir et al. (2006, 2010) proposed the architecture and proto-cols of SMesh under 802.11 WMN. It supports fast handoff. TheSMesh scheme offers a seamless, fast handoff method for real-timeapplications.

In the architecture of SMesh, it uses the Spines messaging system tobuild the communication between the MNs. Here, Spines maintain themulticast IP address of class D and anycast IP address of class E func-tionalities. Clients are associated with two groups: Client data groupand client control group. A MN, which can serve a mobile client (MC)the best, joins the data group of that MC. On the other hand, a MNwithin the vicinity of a MC joins its control group when it receives aheartbeat from the MC. In this scheme, Internet GWs form a multicastgroup known as the Internet gateway multicast group (IGWMG).

In this scheme, when the GW receives a packet destined to the MCfrom the Internet or external IPTV programme servers, it performs areverse network address translation (NAT) and forwards the packet tothe client data group. On receiving the packet, each of the MNs in thedata group forwards it to the MC. On the other hand, a packet fromMC to the Internet or another IPTV user is sent to the client’s AP. The

Page 282: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

268 IPTV Delivery Networks

AP forwards the packet to the GW by sending it to the anycast groupof GWs. GW performs the NAT and sends the packets to the Internetor an external IPTV user.

In this scheme, the MNs of the client’s control group keeps track oflink quality of the MCs with its neighbours and the AP, which can servethe MC best. Nodes in the client data group receive packets destinedto the MC and forward them to the MC. If a MC has multiple MNs inits data group, it will receive multiple copies of the same data packet.

10.3 Advantages and Disadvantages

In this section, pros and cons of the mobility management schemeshave been discussed. The effect of usage of the mobility managementschemes on highly mobile MCs has also been presented.

i. Tunnel-based scheme:

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

1. ANT(Wang et al.,2007)

1. ANT is amobilitymanagementprotocol thatsupportsintra-domainmobility withina WMN.2. ANTmobilitymanagementproposed forinfrastruc-ture WMNs.3. Addressmanagement(how to identifyeach MT whenroaming) – noaddress changeinside domain.

1. Theadvantage ofthis scheme isthat, before anylink failure,RAP sends ahandoffnotificationmessage to allits neighboursto reduce thehandoff delay.Thus, theneighbouringRAP gets analert of MN’shandoff inadvance.

1. The locationserver getsoverloadedbecause locationupdate messagemust be sent tothe locationserver every timea MN moves to anew RAP.2. The locationserver becomesthe bottleneckbecause locationa query messageis sent to thelocation serverevery time a MNwants tocommunicatewithanother MN.

If the MNs arehighly mobile,the frequencyof handoffincreases.Therefore, thenumber ofhandoffnotificationmessages senttoneighbouringRAPsincreases.Moreover, thenumber oflocation updatemessages sentto the GW alsoincreases.

Page 283: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 269

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

4. ANT mobilitymanagementprovidesclient-sidetransparency.Here, no softwareupgradation isnecessary formobile hosts.5. ANT mobilitymanagement hasbeen proposedfor decreasingthe handofflatency.

3. The signallingcost for alocation updateis consider-ably high.

2. M3

(Huang,Zhang andFang, 2007)

1. M3 is amobilitymanagementprotocol thatsupportsintra-domain andinter-domainmobilityin WMN.2. The designconcept of M3 ispointer-forwardingbased.3. Addressmanagement(how to identifyeach MC whenroaming): Theaddress remainsunchanged whenthe client movesfrom one AP toanother withinthe same WMN.

1. M3 has littlesignalling costfor handoff asthe locationupdate messageis onlyperiodicallysent to the GWor SR.2. Intranet orIPTV packetsare routedthrough theGW or SR.Therefore, theGW or SRbecomesoverloaded.

1. M3 is not a peruser-basedmobilitymanagementscheme.Therefore,optimalperformance ofevery MC cannotbe ensured.2. Periodiclocation updateof the MC makesthe system verystatic, which isnot good in anenvironmentwhere differentMCs havedifferentmobilitybehaviour.

If the mobilityrate of the MCis high, theinterval for theperiodiclocation updateneeds to be lessto reduceforward chainlength.

Page 284: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

270 IPTV Delivery Networks

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

4. Periodically, alocation updatemessage is sent tothe GW orsuperior router(SR) by all themesh clients(MCs).5. In M3 scheme,the gateway (GW)keeps track ofserving a MR foreach MC.6. Here, a locationupdate message issent periodicallyto the GW bythe MC.

3. Staticanchorscheme (Liand Chen,2011)

1. Static anchorscheme is amobilitymanagementprotocol thatsupportsintra-domain andinter-domainmobilityin WMN.2. The locationserver ismaintained atthe GW.3. The MCexplicitly registersor updates itslocation incentralisedlocation servers.

1. Theforwardingchain length kof a MC isdetermineddependingupon itsmobility andsessioncharacteristics.It ensuresbetterperformance ofthe scheme.2. The value ofk for every MCis user-based,whichenhances theperformance ofthe scheme.

1. Forcalculating theoptimal value ofk, periodicallyMCs have toperformcomputation,which is notdesirable for abatterypowered MC.2. Here, all thelocation querymessages for aMC are sent tothe GW, whichincreases theload on the GW.

When themobility rateof the MC ishigh,session-to-mobility ratio(SMR)decreases. Itreduces thefrequency ofsendinglocationupdatemessages tothe GW.

Page 285: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 271

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

4. Here themaximumforward chainlength is K.5. A forwardchain is usedfrom old MR tonew MR.6. The value ofK is decideddynamicallybased onsession-to-mobility ratio(SMR).

4. Dynamicanchorscheme (Liand Chen,2011)

1. Dynamicanchor schemesupportsintra-domainandinter-domainmobility ina WMN.2. It is similarto the staticanchor scheme,but in additionto that, theforward pointeris reset due tothe arrival of anew intranet orInternetsession.3. The locationserver ismaintained atthe GW.

1. Because ofthe resetting ofthe forwardchain upon thearrival of a newsession, theforward chainlength remainssmall if thesession arrivalrate is high.Thus, thepacket deliverycost is reduced.

1. Locationquery messagesare sent to theGW for everynew session to aMC. The GWthen initiateslocation searchprocess for MC.It increases theload on the GWand thesignalling cost.

If the MNs arehighly mobile,the forwardchain lengthincreases,which willreduce thefrequency ofsendinglocationupdatemessages tothe GW.

Page 286: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

272 IPTV Delivery Networks

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

5.SMR-basedscheme(Majumderand Roy,2013)

1. It is auser-basedscheme.2. The GWmaintains acentral locationdatabase tokeep track ofserving MRs ofall the MCsroaming insidethe WMN.3. SMRoth iscomputed foreach user.

1. Assession-to-mobility ratio(SMR) is usedto decide whena locationupdatemessage willbe sent to theGW and thecorrespondingMC, theforward chainlength getssmaller whenthe sessionarrival rate ishigh. On theother hand,the forwardchain lengthgets larger toreduce thepropagation ofthe locationupdatemessage whenthe mobilityrate of MCis high.2. Each MCperiodicallycomputes theoptimal valueof thresholdSMR tominimise totalcommunica-tioncost/second.

1. As each ofthe MCcalculatesoptimalthreshold SMRvalue, thisincreases theload on thebattery-powered MCs.

If the mobilestation ishighly mobile,the schemeadjusts theoptimalthresholdSMR value toreduce thetotal commu-nicationcost.

Page 287: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 273

ii. Routing-based scheme:

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

1. iMesh(Navda,Kashyapand Das,2005)

1. iMesh is amobilitymanagementprotocol thatsupports intraand inter-domainmobilityin WMN.2. OLSRrouting-protocolruns on wirelessdistributionsystem interfacesof every AP.3. When the MCmoves from oneMR to anotherhost networkassociation(HNA), amessage isbroadcast in theentire network.4. APs maintainIP addresses ofall the mobilestations (MSs) inits routing table.

1. The use ofOLSR fortransmittingHNA messagereduces thepropagation ofcontrolmessages.2. In thisscheme, there isno necessity ofextra IP headerfor routing ofdata packets todestina-tion MCs.3. The use oflink staterouting protocolmakes thederivation ofloop-freedom easy.4. Complexrouting policiesand metrics areeasy to usebecause a linkstate database ismaintained.

1. HNAmessage isbroadcast afterevery handoff.2. All the APsin WMNmaintain ahost-specificroute to MSs.So, the routingtable becomeslarge whenthere are manymobile stationsin WMN.

When themobility rateof the mobilestation ishigh, manyHNAmessages arebroadcast inthe network.

2. OLSR-FastSync(Speicher,2006)

1. It supportsintra-domain andinter-domainmobilityin WMN.2. Each MNstores a copy ofthe entiretopology andGW information.

1. The use ofMPR forbroadcasting aTC messagereduces routingoverhead of thenetwork.

1. Because ofthe periodictransmission ofa HNAmessage, thecontrolmessageoverhead of thenetworkbecomes large.

If the mobilityrate of a MCis very high,many TCmessages willbe broadcast.This results ina large controloverhead.

Page 288: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

274 IPTV Delivery Networks

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

3. GWperiodicallybroadcasts a hostnetworkassociation(HNA) messagefor providingroutinginformation tothe externalroute.4. Topologycontrol (TC)messages areused to maintainroutes to allother nodes ofthe networkproactively.5. Mesh pointrelays (MPRs)are used forbroadcasting TCmessage.

2. As each of thenodes maintainstopologyinformation aboutthe entire network,route setup latencywill be very less.

2. The controloverheadfurtherincreases by thebroadcast ofTC messages inthe networkduring everyhandoff.

3. MEMO(Maoshenet al., 2007)

1. It supportsintra-domainmobility withina WMN.2.AODV-MEMOrouting protocolis used for therouting ofpackets.3. During everyhandoff, old MRbroadcasts routeerror messagesin the entirenetwork.

1. The routingprocess is simpleandstraightforward.2. For maintainingcontinuousInternet or IPTVprogramme serverconnectivity, thenew MR of themobile nodeproactively sends aroute replymessage tothe GW.

1. Excessivepropagation ofcontrolmessages in theentire networkduring everyhandoff of themobile node.

In the case ofa highlymobile MN,the number ofcontrolmessagespropagated ina time unitwill be veryhigh. Thisincreases theroutingoverhead ofthe network.

Page 289: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 275

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

4. A routerequestmessage isbroadcast forcommunicatingwith thecorrespondingmobile nodes.

3. The mobilenode does notneed anymodificationfor usingAODV-MEMO.4. The mobilityof mobilenodes ismanaged in adistributedmanner, andno centralisedserver isrequired.5. A cross-layerinteractionbetween MAClayer andnetwork layerreduces thehandofflatency.

4. Mobileparty(Sabeuret al., 2007)

1. A mobileparty supportsintra-domainmobility withina WMN.2. Each of theMCs and themesh routers(MRs) have aunique addressidentifier and adynamicallychangingunique address.

1. When theMC movesfrom one MRto another, itsends aregistrationrequest only tothe rendezvous(RA) node ofthat MC. Thislimits thepropagation oflocationupdatemessages in theentire network.

1. Thetemporaryaddressallocated toeach nodecreates ascalabilityproblembecause a nodecan have amaximum ofnine children.

In the case ofa highlymobile MC,registrationrequests willfrequently besent, whichincreasescontroloverhead ofthe network.

Page 290: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

276 IPTV Delivery Networks

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

3. Each node hasa rendezvous(RA) node, whichkeeps track of themappingbetween thenode ID and atemporary nodeaddress.4. To determineRA, a hashfunction is usedover the node ID.

2. To initiateintranetcommunication,a mappingrequest is sentonly to the RAnode. Therefore,it does notrequire tobroadcast aquery messageto find a route tothe destination.

5. WMM(Huang,Lin andGan, 2008)

1. The datapackets carrylocationinformation ofthe originatormobile station(MS).2. Every mobilenode (MN) inWMN maintainsa proxy table tostore locationinformation ofthe MC.3. The schemeuses a forwardpointer.

1. Duringhandoff, nolocation updatemessage is sentexplicitly, whichreduces thecontroloverhead of thenetwork.

1. Each datapacket carriesfour subfieldsin the optionsfield of the IPheader: forstoring the IPaddress ofreceiver’sserving (IRS)mesh accesspoint, forstoringreceiver’sserving timestamp (RST),for storing theIP address ofthe sender’sSMAP (ISS)and for storingthe sender’sserving timestamp (SST).This increasesthe size of theIP header ofeach packet.

If the MSs arehighly mobile,the forwardchain lengthforforwardingthe packetsfrom theserving meshaccess pointto the currentmesh accesspointincreases.

Page 291: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 277

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

6. LMMesh(Li andChen,2012)

1. It is a locationmanagementscheme, which isa combination ofbothrouting-basedscheme andpointerforwardingfacility.2. Each datapacket carries thelocationinformation ofthe source MC.3. The GWmaintains alocation databasethat stores thelocationinformation ofthe MCsin WMN.4. If the forwardchain length of aMC is equal tosome thresholdchain length, theserving MRsends a locationupdate messageto the GW andbecomes thenew AMR.5. The forwardchain length ofthe MC is reset atthe initialisationof a new sessionto and fromthe MC.

1. The optimalthresholdforward chainlength of a MCis adjustedbased on peruser tominimise totalcommunica-tion cost.2. The forwardchain lengthremains smallbecause it getsreset when anew session isinitiated to orfrom the MC.3. A broadcastof the locationquery messageis not required.4. The locationupdate messageis only sent tothe GW. It is notbroadcast.

1. The GWmaintains alocationdatabase of theMC andperforms alocation searchprocess. Thisincreases theload onthe GW.2. Each of thedata packetscarries locationinformation ofthe originatorMC, whichincreases thesize of everydata packet.

In the case ofa highlymobile MC,numerouslocationupdatemessages aresent to theGW as theforward chainlengthfrequentlycrosses thethresholdforward chainlength.

Page 292: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

278 IPTV Delivery Networks

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

7. FPBR(Majumderand Roy,2014)

1. A tree structureof MRs is used tomanage themobility of MCs.2. The relationbetween two MRsmay be parent,child or sibling.3. Location updatemessage isbroadcast in theentire networkwhen a MC movesfrom one MR toits sibling MR, orthe new MRreceives onlyNACK from all itssiblings.4. OLSR routingprotocol is usedfor broadcastingthe locationupdate message.

1. A broadcastof the locationupdate messageonly in certainconditionsreduces theroutingoverhead of thenetwork.2. The use ofOLSR fortransmitting alocation updatemessage furtherreduces theroutingoverhead.

1. Because ofthe proactiveroutemaintenancefor all the MCs,routingoverhead willbe high.

In the case ofa highlymobile MC,the routingoverhead ofthe networkwill be highbecause offrequenthandoffs.

iii. Multicasting-based scheme:

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

1. SMesh(Amiret al., 2006,2010)

1. It supportsbothintra-domain andinter-domainmobilityin WMN.

1. Becausemultiple packetsare transmittedthrough differentpaths, thepossibility of dataloss is very less.

1. Ambiguousdata packetstransmitted tothe MCincreases theload on thenetwork.

In the case ofa highlymobile MC,the MNs inthe datagroup andcontrol group

Page 293: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 279

Sl. no. Properties Advantage Disadvantage

Effects ofhighly mobileclients

2. Each mobileclient (MC) isassociated withtwo groups:Control groupand data group.3. Multiple copiesof packets can beforwarded to theMC through twodifferent paths.

will frequentlychange. Thiswill increasethe controloverhead ofthe network.

10.4 Open Research Issues

Though intra-domain mobility management schemes in WMN can beused to ensure uninterrupted IPTV services to the MC, they also cre-ate the following research issues:

i. Security: Mobile IPTV suffers from the threat of session hijacking,unauthorised user access and illegal content distribution. There-fore, when the client of mobile IPTV is moving from the vicinityof a MR to another, the client needs to be authenticated.

ii. Resource reservation: As the mobile user moves from the vicinityof a MR to another, the new MR should provide enough resourcesso that IPTV services being accessed by the clients do not get inter-rupted. This introduces the challenge of resource reservation dur-ing mobility management of MCs.

iii. Load on the single GW : In most of the mobility managementschemes discussed in this chapter, there is a single InternetGW or a single location server. Mobile IPTV services requiretransmission of a large amount of multimedia data. Therefore, thenetwork near the GW and the location server gets congested. Theproblem can be solved by using multiple Internet GWs and anefficient GW load-balancing algorithm.

iv. Route management packet propagation: The routing-based schemesuffers from the propagation of many route management packets.

Page 294: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

280 IPTV Delivery Networks

Therefore, the reduction in the route management packet propa-gation during handoff is a challenge.

v. Tunnelling overhead: Tunnel-based schemes suffer from huge tun-nelling overhead. Therefore, a reduction of tunnelling cost is alsoa challenge.

10.5 Conclusion

The number of users for mobile IPTV will increase rapidly in thefuture. To support the QoS requirements of such large numberof users, WMN is a key technology. If WMN is used, it needs tohandle the mobility of the MCs. In this chapter, a taxonomy ofintra-domain mobility management schemes has been presented.The mobility management schemes have been classified into threetypes: Tunnel-based, routing-based and multicasting-based. All thethree types of schemes have been discussed with examples. Finally,a comparative study of different mobility management schemes hasbeen performed concerning their advantages and disadvantages.

Acknowledgement

This study was funded by the Department of Electronics and Infor-mation Technology (DeitY), Ministry of Communications andInformation Technology, Government of India, New Delhi, Vide no.14(8)/2014-CC&BT, dated: 03.09.2015.

References

Akyildiz, I.F. and Wang, X. (2005). A survey on wireless mesh networks.IEEE Communication Magazine, 43(9), S23–S30.

Akyildiz, I.F., Wang, X. and Wang, W. (2005). Wireless mesh networks: Asurvey. Computer Networks, 47(4), 445–487.

Amir, Y., Danilov, C., Musualoiu-Elefteri, R. and Rivera, N. (2006). Fasthandoff for seamless Wireless mesh networks. 4th InternationalConference on Mobile Systems, Applications and Services, pp. 83–95.

Amir, Y., Danilov, C., Musualoiu-Elefteri, R. and Rivera, N. (2010). TheSMesh wireless mesh network. ACM Transactions on ComputerSystems (TOCS), 28(3), 6.

Page 295: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Taxonomy of Intra-Domain Mobility Management Schemes in Wireless Mesh Network 281

Birlik, F., Gürbüz, Ö. and Ercetin, O. (2009). IPTV home networking via802.11 wireless mesh networks: an implementation experience. IEEETransactions on Consumer Electronics, 55(3), 1192–1199.

Heikkinen, A., Laulajianinen, J.P., Korva, J. and Peltoal, J. (2008). WirelessIPTV development platform. VVT Technical Research Center ofFinland. [online] Available at: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.649&rep=rep1&type=pdf (accessed on 7March, 2015).

Huang, D.W., Lin, P. and Gan, C. H. (2008). Design and performancestudy for a mobility management mechanism (WMM) using locationcache for wireless mesh networks. IEEE Transactions on MobileComputing, 7(5), 546–556.

Huang, R., Zhang, C. and Fang, Y. (2007). A mobility managementscheme for wireless mesh networks. IEEE Global TelecommunicationsConference, pp. 5092–5096.

Li, Y. and Chen, I.R. (2011). Design and performance analysis of mobilitymanagement schemes based on pointer forwarding for wireless meshnetworks. IEEE Transactions on Mobile Computing, 10(3), 349–361.

Li, Y. and Chen, I.R. (2012). Mobility management in wireless meshnetworks utilizing location routing and pointer forwarding. IEEETransactions on Network and Service Management, 9(3), 226–239.

Majumder, A. and Roy, S. (2013). Design and analysis of a dynamicmobility management scheme for wireless mesh network. TheScientific World Journal, 2013(656259), 16 pages.

Majumder, A. and Roy, S. (2014). A tree based mobility managementscheme for wireless mesh network. 2nd International Conference onEmerging Technology Trends in Electronics, Communication andNetworking, pp. 1–8.

Maoshen, R., Chao, L., Huizhou, Z., Tong, Z. and Wei, Y. (2007). MEMO:An applied wireless mesh network with client support and mobilitymanagement. IEEE Global Telecommunications Conference, pp.5075–5079.

Navda, V., Kashyap, A. and Das, S.R. (2005). Design and evaluation ofiMesh: An infrastructure-mode wireless mesh network. IEEEInternational Symposium on a World of Wireless Mobile andMultimedia Networks, pp. 164–170.

Rong, B. and Hafid, A. (2010). Cooperative multicast for mobile IPTVover wireless mesh networks: the relay selection strategy. IEEEtransactions on Vehicular Technology, 59(5), 2207–2218.

Page 296: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

282 IPTV Delivery Networks

Sabeur, M., Al Sukkar, G., Jouaber, B., Zeghlache, D. and Afidi, H. (2007).Mobile party: A mobility management solution for wireless meshnetwork. 3rd IEEE International Conference on Wireless and MobileComputing, Networking, and Communication, p. 45.

Shihab, E., Chi, L., Wan, F. and Gulliver, A. (2008). Wireless meshnetworks for in-home IPTV distribution. IEEE Network, 22(1), 52–57.

Speicher, S. (2006). OLSR-FastSync: Fast post-handoff route discovery inwireless mesh networks. IEEE 64th Vehicular Technology Conference,pp. 1–5.

Wang, H., Huang, Q., Xia, Y., Wu, Y. and Yuan, Y. (2007). Anetwork-based local mobility management scheme for wireless meshnetworks. IEEE Wireless Communications and Networking Conference,pp. 3792–3797.

Zeadally, S., Moustafa, H. and Siddiqui, F. (2011). Internet ProtocolTelevision (IPTV): Architectures, trends and challenges. IEEE SystemsJournal, 5(4), 518–527.

Zhang, Y., Luo, J. and Hu, H. (2006). Wireless Mesh NetworkingArchitectures, Protocols and Standards. CRC Press, United States.

Page 297: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

283

11

Towards Multi-Operator IPTV Services Over5G NetworksGergely Biczók, Manos Dramitinos, Håkon Lønsethagen, Luis M.Contreras, George D. Stamoulis and Laszlo Toka

11.1 Introduction

Television service has been continuously evolving in terms of differentperspectives, evolving from analogue signal transmission to digitalvideo processing, being distributed by the air-broadcast stations tofibre-based infrastructure, or, more recently, adapting to the needfor content delivery on large plasma screens as well as small tabletdisplays. The fundamental TV service provisioning model has, formany decades, been a one-to-many communication model. Contentis shared to multiple users, each of whom actively decides what towatch. TV has also evolved from being the principal entertainmentservice to yet another service among multiple entertainment sourcessuch as gaming, video on demand (VoD) and Web browsing, due tothe proliferation of the latter.

Telecom operators have realised this and have created servicebundles by aggregating content offerings, including TV programmes.Such aggregations of services are provided more efficiently over acommon service delivery framework enabled by Internet Protocol(IP); multimedia standards for both file transport and stream deliveryrely on IP. This way, the IPTV service has emerged. Simultaneously,there is a shift towards a TV service based on the Web-based deliveryof video content by means of the ubiquitous Hypertext TransferProtocol (HTTP). This is partly because of the new capabilities offeredby the proliferation of video-capable user devices (smartphones,connected TVs, tablets, Xbox, Mediabox and so on), and due to the

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 298: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

284 IPTV Delivery Networks

new commercial offers of the over-the-top (OTT) providers, servicesknown as live TV OTT or live OTT.

The impact of IPTV on the network is a dramatic increase on theconsumed bandwidth. To avoid congestion of the network whilemeeting increasing customer demand, it is necessary for networkoperators to implement mechanisms capable of efficiently managingand meeting user demand while minimising the capacity needs ina cost-efficient way. An additional evolution is related to the users’location. New mobile wireless technologies provide broadbandaccess outside the home, presenting additional delivery options forIPTV, the so-called mobile IPTV. Finally, the multiplicity of actorsin the value chain and the diversity of their requirements call for thecapabilities brought by network virtualisation and programmabilityfor the effective provision of TV services by different providers overthe same infrastructure.

The emergence of 5G, software-defined networking (SDN) andnetwork function virtualisation (NFV) greatly contribute to thisevolution. As explained in the remainder of this chapter, new serviceorchestration, technical and quality of experience (QoE)–relatedchallenges arise, along with wholesale business, service tradingand ‘long-tail’ market opportunities. In this chapter, we presentimportant challenges, opportunities and operational, business- andcustomer-centric aspects of single- and multi-operator IPTV servicesin 5G networks. We focus on the key features that are crucial for IPTV(and for similar services) in 5G networks: Quality assurance, businessand service coordination, user-service-level awareness, elastic andagile service orchestration and trading of virtualised resources andservices among the providers in the value chain. We present the 5GExchange (5GEx) wholesale business and service trading frameworkas a potential solution to the challenges identified for IPTV in 5G(5GEx, 2015). We also discuss related use cases and the respectivenew wholesale business and service trading opportunities, and relatedbusiness models, and how these are to be served under 5GEx.

11.2 Single-Provider IPTV Services

A nation-wide commercial video service can feature several millioncustomers as of today, with a choice of hundreds of videos to be con-sumed. Hence, the amount of bandwidth required when transmitting

Page 299: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 285

such VoD through the network is challenging. Two different TV andvideo services are typically implemented on the provider’s networksfor managed video services:

• VoD, serving available on-demand streaming in unicast trafficfashion.

• Live TV, for real-time streaming using multicast mechanisms forcontent distribution.

These services are usually based on different platforms or solutions.An additional source of video traffic is the one delivered by OTT

providers, through the Internet connection. Such content is alsodelivered in an on-demand fashion via the best-effort interconnectionpoints enabling global Internet connectivity.

11.2.1 Customer-Centric Challenges and Technical Issues

In this subsection, we overview the most prominent technical issuesand challenges; the resulting solutions are presented in Section 11.2.3.Due to the nature of the IPTV service, challenging technical issues arerelated to end-user QoE and service-level awareness.

The more traditional IPTV services delivered by targeted solutionsare based on longer-term contracts, stable and known demand andcorrespondingly agreed service-level agreements (SLAs) and qualityrequirements. In this context, the solutions are designed accordingto the given requirements and resources are dimensioned accordingto rather static load. In this traditional context, a good or excellentQoE can be achieved, with resilience mechanisms ensuring a highservice availability even under failure conditions. When looking intonew innovative opportunities in the IPTV content delivery area, itis also important to analyse the new challenges that arise. QoE andservice-level awareness are both key customer-centric aspects thatwill need special attention and new capabilities in terms of technicalfeatures and operational follow-up.

It is valuable for the end-user to know the IPTV application perfor-mance to be expected from a particular network at a particular pointin time. This is already pertinent in the best-effort Internet and thenumerous top video-streaming applications. It is expressed in typicalend-user questions, such as: What is the performance of the networkor the streaming video application I would like to use right now? Whileriding the train or bus: Should I click on this video news clip on my

Page 300: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

286 IPTV Delivery Networks

Assured qualitymode

Situation BSituation A

Live event service <X>

XL XL

L L

M M

S S

Live event service <X>

Basic qualitymode

Service levelunavailable orunlikely

Figure 11.1 Examples and illustrations of IPTV service-level indicators.

smartphone, or will I just get annoyed of the poor experience? If I usemy tablet, will I get a good experience with the larger screen? Or, whenat home watching an interesting video on my PC, can I get an excellentexperience if I move onto my 55” HD TV?

Figure 11.1 illustrates ideas around service-level indicators enablingend-user-service-level awareness. By providing service-level indica-tors in real-time, suitably located in the screen of the user device, theuser can be well informed and make educated choices according tothe urgency and importance of the service at the particular setting andcontext. Figure 11.1 depicts that in situation A, for example, while ona bus, the service delivery at a small (smartphone) screen will worksatisfactory in the basic quality delivery mode; while for satisfactorydelivery at the medium screen size of a tablet, the user must select theassured quality mode. In situation B, for instance while at a hotel, thetablet screen size should work fine even for the basic quality delivery;while for delivery at a large or extra-large flat screen TV, the end-usermust select the assured quality delivery mode.

These examples are some indications of future needs for moreclever interaction with the end-user. Such future end-user interac-tions should also give the user a possibility to communicate intentor a flexible and efficient way of ‘signalling’ service requests. Thisconstitutes a whole new area that has received little attention untilrecently, because of the shortcomings of the current Internet wayof working. Hence, next we also envisage to augment the currentInternet where an open multi-service Internetworking (an evolvedand enhanced open Internet approach) will indeed support managed

Page 301: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 287

quality traffic exchange and a new plethora of retail and end-customerfacing services where the application service is demanding a highand predictable network performance. IPTV content delivery is anexcellent use case or vertical (media vertical) that can be enabled bythis approach to Internetworking, as also discussed in detail in theNetWorld2020 Whitepaper (Networld2020, 2016).

Taking a closer look at QoE, we should be reminded that QoE is aconcern about ‘the overall acceptability of an application or service,as perceived subjectively by the end-user’. It includes the completeend-to-end system effects (client, terminal, network, services infras-tructure and so on) and may as well be influenced by user expectationsand context (ITU-T, 2008). Typically, the subjective and end-userfeedback measurements are designed as an off-line process. Whereassuch off-line experiments do give a fairly good representation, weanticipate that in mobile and more diverse settings, the context ofthe individual user will have a greater impact on the QoE. That is, intraditional static settings, the relationship between the objectivelymeasured QoS parameters can be mapped to resulting QoE withquite high certainty. Such QoS to QoE mapping, to be considered atdesign and engineering time as well as for individual user context andfor dynamically changing conditions, becomes a challenging task inthe foreseen 5G IPTV cases.

Mobile operators deploy advanced data analytics tools for observingthe network performance at various network locations and settings.These tools and analytics are important also for the current best-effortInternet access services and provide insight into various types ofapplication services (video streaming, OTT voice, web-browsing).The improved insight into QoE is an important driver for these tools.

Mobile video streaming is increasingly important for the mobilenetwork operators as video consumption increases and the overalltraffic volumes for video streaming dominate the need for networkcapacity. Luckily, advancements in HTTP adaptive streaming (HAS)are employed by numerous video services, which allows efficient videostreaming by adapting the transfer bit rate according to the networkperformance as observed in real-time by the end-user equipment(Seufert et al., 2015). In this way, a reasonable although still somewhatunpredictable QoE can be achieved by proper investments in networkcapacity.

To enable premium offerings with predictable QoE, there is a needto advance these data network analytics solutions and increase their

Page 302: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

288 IPTV Delivery Networks

accuracy in knowing the precise per-customer QoE, while the net-work conditions are still changing as are also the specific conditionsfor the end-user. Deeper knowledge into QoE and QoS to QoE map-ping is needed for successful offerings of such streaming and IPTVservices. This must be accompanied with more advanced performanceobjective setting, monitoring and prediction mechanisms and capabil-ities (ITU-T, 2006) to match customer expectations. In Section 11.4,we look more into the challenges and solution approaches addressingmulti-actor services and contexts.

Finally, the customer centric perspectives and needs of the con-tent provider should be carefully considered as well. The contentprovider buying advanced content delivery services is the valuedwholesale customer of the network service provider (NSP) and willappreciate to have the best-of-breed web-based and customisedtools and dashboard solutions enabling efficient self-service setupand configuration as well as operations support and guiding. Thedashboard view should give the content provider status and statisticsin real-time such as information regarding content usage per regionand customer segments as well as content delivery performance andQoE at per customer granularity. While the big content providers, toa large extent, can handle such information using their own solutions,these tools can be of great importance to small and medium contentproviders.

11.2.2 Business Issues and Challenges

The IPTV service not only empowers customers by offering them agreat choice of content and flexible control on the content comparedwith linear TV, but it also brings challenges to the operator’s busi-ness. As the possibility of customer segmentation increases by shift-ing from mass broadcast to select multicast (channel packages andpay-per-view) and further to exclusive unicast (VoD), higher emphasisis required when designing offerings both in terms of content, controland pricing. In this section, we show how adding value to the TV ser-vice poses more challenges for the operator in addition to the technicalissues.

IPTV gives telecom operators the possibility of boosting theiraverage revenue per user; the challenge is to find the most profitableextent of customisation that it inherently offers. A large part ofthe convergence in the telecom scene in the past decade is due to

Page 303: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 289

the phenomenon that telecom providers expanded their traditionalconnectivity service with media distribution on their infrastructure.Bundling IPTV with the Internet and phone service transformedoperators from mere connectivity providers into media companies.The benefit of this convergence for the customer is twofold: Notonly do they get TV services along with voice and data subscriptionfrom the same provider, but this TV service is also feature-richerand altogether might be even cheaper than a separate traditionalcable plan.

To make a successful transition into an integrated telecommunica-tion service provider by adding IPTV into their portfolio, the operatorsneed to make sufficient investments in infrastructure developmentso that their services brought to the customers do not suffer fromquality issues. As viewer interactivity grows from simple electronicprogramme guides to viewer-interactive television programming,the underlying technology is increasingly resource-hungry, and thuscostlier. Therefore, an important business challenge with IPTV isto cover the increasing investment costs of adding more and moreservice features.

In most parts of the world, the shift from analogue to digital TVhas already taken place. Digital terrestrial television systems, forexample, DVB-T (Digital Video Broadcast – Terrestrial (DVB-T)in Europe, ATSC (Advanced Television Systems Committee(ATSC)in North America, ISDB-T (Integrated Services Digital Broadcast-ing – Terrestrial (ISDBT) in South America and Japan, and DTMB(Digital Terrestrial Multimedia Broadcast(DTMB) in China offer TVbroadcast for a low price, or even essentially for free. For instance,most homes in European countries can get their digital televisionservice with a DVB-T-capable TV (or set-top box: STB) from free TVbroadcast with relatively rich features. Another free TV broadcasttechnology, but of smaller penetration scale, is via satellite (DVB-S).

The three important business aspects in which these alternatives dif-fer from IPTV are cost, content and control. IPTV may offer premiumcontent, rich control but typically for a higher price. The challenge is tofind the sweet spot in these three aspects: What kind of quality andheterogeneity of content are needed to reach the level of personal-isation that generates the highest possible income from the solventdemand in the TV market and what control features are effectivelyused for the customised viewer experience, such as benefiting fromthe on-demand capabilities of the (mobile) IPTV solutions.

Page 304: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

290 IPTV Delivery Networks

11.2.3 Operators’ Solutions and Architecture

The VoD service is either managed (provider’s own service) orunmanaged (offered by OTTs), with unicast delivery of video streamsusually supported by content delivery networks (CDNs). A CDN isformed by entry points and end points. The entry points are the pointswhere content providers feed the video traffic. The origin servers areplaced closer and/or connected to the entry points to store multiplecopies of the produced content. Such duplicated copies are the seedsfor distribution. Finally, the end points are the delivery elements ofthe CDN. Any service that the CDN provides is given to consumersfrom endpoints.

VoD content enters the CDN by the entry points and is stored at theorigin points. Content is replicated at multiple internal parts of theCDN to the end points for delivery to the network. The entire con-tent is stored in one or two points (origin service) and then replicatedinternally in the CDN to the end points for the users demanding it.The main advantages of handling the VoD traffic in this way is that itminimises traffic on the network as the video distribution is practicallynegligible between the video source and the end point, saving networkresources. CDN offers to operators a way of optimising video trans-port over their network, thus reducing capital expenditure (capex) andoperational expenditure (opex) by bringing the content closer to theaggregation.

It is also frequent to have specific servers dedicated to storing videocontent across the network. This is for instance the case of videoservers devoted to ‘catch-up video’ that allows the user to watchIPTV content within the following X hours after the programme hasbeen broadcast. From the distribution point of view, the topologicaldeployment is similar to that of the CDN end point.

In contrast to this, Live TV streaming to customers is commonlyimplemented by means of multicast flows from the video sources.IP multicast allows the efficient support of group communicationservices (one-to-many or many-to-many) over existing IP networks.IPTV takes advantage of this extension of IP that facilitates thedelivery of a single copy of a data stream to multiple listeners orreceivers interested in receiving the same content simultaneously.Multicast-enabled routers are in charge of replicating the data packetsto reach the receivers, usually spread around the whole network,creating a multicast distribution tree over the network. IP multicast

Page 305: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 291

saves resources in terms of both data source processing (allowing thesource to deliver just one copy of data independently of the numberof listeners) and network bandwidth (the network duplicates trafficonly when it is necessary to reach receivers).

Conceptually, IP multicast represents a receiver-centric archi-tecture. Receivers, located anywhere in the network, subscribe toa content in the form of a multicast session group. The content isdistributed by means of a particular data stream creating a multicastflow. A single copy of such data stream is carried on every link inthe network along the multicast path dynamically created to reachthe interested receivers. The data stream is replicated on the routerswhere the multicast path topologically diverges.

The multicast source injecting the data stream to the network doesnot maintain any subscription list of interested receivers. The sourcesimply sends the data stream to an arbitrary group of hosts repre-sented by an IP multicast address. The receivers indicate their intereston receiving certain content by explicitly joining the multicast group.The multicast listener discovery (MLD) protocol for IPv6 defines thecontrol messages for managing the group membership process (IETF,2004). Multicast protocols distinguish between multicast receiver(or host part) and multicast router (or network part) functionalities.Basically, the host part is devoted to the group subscription manage-ment, while the router part is focused on building and maintainingthe multicast tree.

A multicast-enabled router in the receiver’s sub-network will cap-ture the control messages for joining or leaving the multicast group.The router will periodically check if there are receivers interestedin a previously subscribed group in the sub-network by sending outqueries asking for some intended receiver for that group. The routerwill stop the data forwarding of a certain group when it receives anexplicit indication of the last receiver interested in such a group,or as a result of not receiving any confirmation of interest from theperiodical queries.

In some cases, the router can act as a proxy (IETF, 2006) for thegroup membership indications of the receivers connected to it,instead of the multicast router role described earlier. This typicallyoccurs in aggregation networks, where the first-hop router con-centrates the traffic of a huge number of receivers. The proxy willperform the router portion of the group membership protocol on eachdownstream interface, while it will play the host role on the upstream

Page 306: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

292 IPTV Delivery Networks

attached upstream router

MLD proxy router

MLD proxy

upstream interface

MLD downstream interfaceMLD downstream interface

MLD downstream

interface

PC

PC

PC

Figure 11.2 MLD proxy, upstream and downstream interfaces.

interface towards the next multicast-enabled backbone router. Theproxy is in charge of summarising the subscription demand of thereceivers, acting as a unique host towards the upstream multicastrouter, as depicted in Figure 11.2.

On the network side, the routers use different protocols to dynami-cally build and maintain the multicast distribution tree from the multi-cast source to the final set of receivers. Protocol independent multicast(PIM) is the most commonly deployed protocol in commercial net-works. PIM uses the unicast routing information (independently of theconventional routing protocol used to obtain it, that is, Open Short-est Path First (OSPF), Border Gateway Protocol (BGP), IntermediateSystem-to-Intermediate System (IS-IS) and so on) to build a loop-freemulticast distribution tree. In the same way as CDN, multicast distri-bution of video content offers economic advantages in terms of opexand capex to network providers as the number of video replicas circu-lating in the network is limited.

Current metropolitan networks present a hierarchical structure tocollect the traffic generated by the residential customer in an efficientway from the network resources perspective. Several aggregation lev-els provide the necessary capillarity to cover the customer span. Thepurpose of these aggregation networks is to save transport resourcesthrough statistical multiplexing gains as the traffic goes higher in thehierarchy. As the traffic contributions are aggregated on higher lev-els in the hierarchy, summing up thousands or tens of thousands of

Page 307: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 293

subscribers, the aggregation links have a smoothed load due to thestatistical multiplexing shaping the aggregate traffic profile.

Usually, telecom operators statically provision network capacity onbusy hour traffic forecasts. This common static provision results oncapacity overprovisioning, as a consequence of the high variability ofthe traffic, and as a way of guaranteeing the expected quality of ser-vice (QoS). Current implementations in metropolitan aggregation net-works are based on carrier-Ethernet technology. The typical capacitydimensioning of the aggregation network is based on one or multi-ple 10 Gb-links between aggregation and access, and 1 Gb or 10 Gblinks among access and aggregators as a function of the number of net-work nodes connected to final aggregators. The aggregators connectto the access nodes (Digital subscriber line access multiplexer (Digi-tal subscriber line access multiplexer (DSLAM), Optical line terminal(OLT)), which finally provide connectivity to the residential users.

11.3 IPX Multi-Service Internetworking

In the networking world, the IP exchange (IPX; GSMA, 2007) is anon-Internet telecommunications interconnection model for theexchange of IP-based traffic between customers of different operators(mobile and fixed) and NSPs; essentially, a multi-actor privatelymanaged IP backbone. IPX supports QoS interconnection with therespective SLAs or multiple classes of service, even as they crossseveral hubs. To this end, cascading payments between operatorsare supported, so that the chain of operators involved in the servicedelivery are properly compensated according to their effort andthe resulting QoS. As also depicted in Figure 11.3, IPX consists ofcompeting IPX providers that are all interconnected with each othervia many exchange/peering points.

However, IPX has high complexity and limited fitness to the cloud(as opposed to the TDM) delivery model and the new business modelprevents IPX from becoming a truly global solution (Geddes, 2016).Moreover, IPX service negotiation is based on the usage of SIP (allthe domains must be aware of the application details) and, therefore,assumes the vertical integration of the ISPs. Due to the usage of SIP,this solution is not flexible enough to deal with the evolution requiredby society in the provisioning of new services. Considering the widevariety of application protocols, such a design, could lead to complex

Page 308: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

294 IPTV Delivery Networks

Fixed

operator

e.g., NGN

Fixed and

mobile

operator

Other service

provider,

e.g., ISP

Other mobile

operator,

e.g., CDMA2000

3GSM mobile

operator

IPXLow and predictable latency

Hub/proxy Hub/proxy

Hub/proxy Hub/proxy

DNS & ENUM

IPX 4

IPX 2IPX 1

IPX 3

FW

FW

FW

FW

FW

Figure 11.3 The IPX network model.

systems where several gateways should be integrated to interwork withthe user applications. Also, in 5G and future Internet, the users will notonly be the service consumers but also service providers/creators, andtherefore, a wide variety of non-IMS applications are expected to coex-ist. These issues render IPX inadequate for emerging business modelsand services, as opposed to voice service for which it has clear mer-its. However, there are IPX aspects that can be evolved and appliedfor IPTV, and Internet/5G services in general, in the context of anopen multi-service Internetworking approach, which we elaborate onin Section 11.4.

11.4 Multi-Operator IPTV Services in 5GNetworks

In less than 5 years from now, telecom and IT will be integrated ina common very-high-capacity 5G ubiquitous infrastructure (Csaszaret al., 2013), with converging capabilities for both fixed and mobileaccess and with service invocation capabilities for multiple layerson top of the network and cloud infrastructure services layer. 5Gby design integrates networking with cloud, Internet of Things andmachine-to-machine communication, enriching the customer-facingservices such as IPTV. In this context, the service value chain

Page 309: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 295

inevitably involves multiple stakeholders, across the infrastructureand end-user service provisioning layers. This inevitably calls formulti-operator business and service coordination jointly over thenetwork, computation and storage domains.

Therefore, collaboration among various types of providers willplay a key role in 5G IPTV services by harmonising the opera-tion of all involved stakeholders. To this end, a new generationof hubs/exchanges envisaged by the 5GEx project (5GEx, 2015) isexpected to play a key role. It can be seen as the 5G evolution of theIPX ‘coopetitive’ (partly collaborative, partly competing) networkingand wholesale service trading model presented in Section 11.3.5GEx also incorporates software-defined networking and virtualnetwork functions to enable a holistic approach to 5G resource andservice trading at the wholesale level and to support the cost-efficientorchestration and management of high-value services such as IPTV.

For the efficient provisioning and monetisation of IPTV in 5G, thefollowing aspects/views and associated challenges need to be explicitlyaddressed in a multi-domain/actor context:(a) Customer-centric view: Service-level awareness, QoS and QoS to

QoE mapping challenges.(b) Operational view: Dynamic resource and network as a service and

traffic engineering challenges.(c) Business view: Business models, roles, value-chain structure,

charging and revenue sharing, ecosystem evolution challenges.

11.4.1 Technical Issues and Challenges

11.4.1.1 SDN and NFV ExploitationSDN and NFV allow architects to build systems with a greater degreeof freedom and abstractions, thus network flexibility: Networking canbe broken down into building blocks to be chained together to suit theservices to be supported. This service-aware slicing concept has thepotential to enable the highly coveted flexibility in service provisioningand delivery, which is crucial for IPTV. SDN is also a key enabler froma multi-operator collaboration perspective, as it allows for the directexpression of flexible policies potentially tailored to different applica-tions and service-quality requirements (a potential stepping stone foran improved SLA framework).

Wide deployment of computing facilities across operator’s net-works creates new opportunities for instantiating video processing

Page 310: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

296 IPTV Delivery Networks

and delivery end points dynamically in a distinct administrativedomain. Then, by using virtualisation, programmability and slicingcapabilities, it becomes possible to deploy delivery nodes across visitednetworks for facilitating the local delivery of content. Such video deliv-ery nodes can come in the form of virtual network functions (VNFs)instantiated on top of computing elements (commonly x86 serversconstituted in the form of network function virtualisation infrastruc-ture points of presence; NFVI-PoPs). With virtualisation layer (hyper-visors, software containers), the service provider can execute the deliv-ery function over the traditional specialised equipment. The smoothintegration and transition to these new capabilities from the existingoperations and service models of the operators constitutes a technicalchallenge.

11.4.1.2 Lack of QoS Assurance – SLAsMulti-provider services have been implicitly supported over theInternet for pure connectivity services by means of interconnectionagreements between the operators. Networks rely on the BorderGateway Protocol (BGP) to build the Internet connectivity graph,solely exchanging BGP announcements and data. Existing peering andtransit interconnection agreements specify whether and how eachnetwork should accept and terminate or forward the traffic comingfrom a neighbour network, without any type of service-aware routingand management or QoS assurance. They pertain to interdomaintraffic aggregates of multiple services, both elastic and inelastic, thusmultiplexing the IPTV QoS-sensitive flows in bulk aggregates withoutany care for IPTV service needs. Furthermore, BGP has inherentweaknesses such as lengthy routes and the fact that only a singleroute is returned as the path for interconnecting two Internet pointsA and B; this may be acceptable for certain services, for example,background traffic, but it may be inadequate for others such as IPTV,for example, due to delay and jitter.

Therefore, in a multi-operator setting, the efficient provisioning ofIPTV services, especially over parts of the network such as intercon-nection links that are typically saturated, is extremely challenging. Infact, this is why solutions such as IPX (presented in Section 3) havebeen introduced. As Alex Sinclaire of GSMA put it: ‘The open Inter-net is a wonderful thing, but when it comes to providing a guaranteedQoS, particularly for time-critical services, there is still a long way togo’ (Wiki, 2016).

Page 311: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 297

11.4.1.3 Lack of Monitoring and SLA-Based RewardsCurrent interconnection SLAs do not provide economic incentives forpartners to collaborate on exploiting positive network externalities:NSP effort is not verifiable, due to the lack of interdomain monitoringrendering each domain a ‘black box’, nor rewarded, due to currentSLAs (Constantiou and Courcoubetis, 2001). Quality assurance forthe interdomain IPTV flows should be coupled with monitoring capa-bilities and reward penalty schemes for SLA conformance violation.New incentive-compatible SLAs and business models for value-addedconnectivity services (VACSs) suitable for IPTV could serve asthe basis for providing QoS assurance end-to-end. This constitutesfurther motivation for new technical solutions and business modelssuch as exchanges of trusted actors (5GEx, 2015).

A critical element to the QoS and SLA monitoring approach is theinsight into how this can be handled in a QoE and service-level awareway across domains. While ITU-T standardisation in IPTV QoE andperformance measurements and monitoring provide important stan-dardisation of critical solutions elements (ITU-T, 2007), there is lit-tle or no multi-domain operational solutions available and experienceis lacking. The additional complexities introduced by NFV and thegreater dynamics enabled by SDN add to these challenges. We antici-pate that it will be important to suggest a roadmap to enable the intro-duction of the less complex solutions for the simpler scenarios firstand then more advanced solutions can be introduced according to theadvancements of the services and offerings.

11.4.1.4 Wholesale and Retail Market CoordinationEnhanced Internet and 5G services, as depicted in Figure 11.4, per-tain to two different layers and corresponding markets with differentstakeholders and business relationships:• The core assured service quality (ASQ) interconnection services

(ASQ paths, ASQ traffic exchange) are set up and traded amongnetwork service providers, over multi-operator backbone networkscarrying the traffic of 5G and Internet services. These are the coreinfrastructure services that pertain to aggregate data flows, possiblycrossing multiple administrative and technological domains. Asexplained later, the sending party network pays (SPNP) is thecharging principle that applies to these interconnections.

• The VACSs that are the customer-facing connectivity servicesthat involve communication and infotainment services such as

Page 312: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Live event

studio production

Backbone Element

of VACS

Transit PoP

ASQ Traffic Exchange (AQX) Service Edge PoP

Live event source

content production

Access and

Aggregation network

with VACS awareness

Multi-NSP backbone network with aggregate

traffic engineering ASQ paths and AQX

(N3)

(N4)

(N5)

(N7)

(N6)

(N2)

(N1)

Edge Element of VACS

(Value Added

Connectivity Service)

Service Edge PoP

(Expanded view)

With Service Edge NE

and NFVI

Access Edge PoP

E.g. with Mobile Edge Computing

Figure 11.4 Core and value-added communication services.

Page 313: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 299

IPTV where the network performance is either assured (absoluteperformance objectives) or improved (relative performance objec-tives). These services involve the end-user and QoS must be takencare of, even at per-flow level, as opposed to the core serviceswhere because of scalability and cost efficiency only large trafficaggregates are managed.

The general solution anticipated should prepare for the settingwhere the on-demand and real-time end-to-end quality managementof the end-user ASQ connectivity (VACS) can be satisfactorilyhandled, by coordinating the policy control and enforcement at theservice nodes of the edge NSPs that serve the end-points that takepart in the VACS. By these policies, the VACS (e.g., IPTV) traffic issteered onto the ASQ paths for carrying the traffic across networkdomains. The service orchestration and management capabilities, aswell as the quality guarantees and charging principles greatly impactthe IPTV offerings that are feasible to be monetised. Unmet needsof the VACS providers can also motivate NSPs and clouds to deployinfrastructure services tailored to the respective markets.

11.4.1.5 Pricing and Charging LayersPricing and charging schemes are control mechanisms that operateon the two main layers, namely, wholesale and retail, identified in theprevious section: bulk-data and flow-based charging.

The bulk-data layer includes functions such as rate policing and pathcharacterisation while the higher per-flow layer encompasses func-tions such as rate control and admission control. To the bulk-datalayer, it can correspond to two charging layers: (1) capacity chargingindependent of usage and (2) capacity charging dependent on usage.At the per-flow layer, it corresponds to (3) per-session charging. Theper-session charging, along with suitable clearing functions, performsthe revenue-sharing across edge and core networks. The IPTV sessionwould be initiated by a customer having a certain willingness to pay. Aclearing function would then receive the payment by the 5G IPTV ses-sion initiator and re-apportion the associated revenues to the involvedNSPs for the quality provided. The way revenue is apportioned andused to finance underlying network infrastructure services is crucialfor monetising the required ASQ infrastructure needed for 5G IPTVand similar services.

Page 314: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

300 IPTV Delivery Networks

11.4.2 Business Issues and Challenges

In this section, we discuss business issues and challenges, related tothe technical issues of the Section 11.4.1, for 5G IPTV. We presentpotential solutions to these challenges, in lieu of IPTV use cases, foran open multi-service Internetworking approach, augmenting the cur-rent Internet and 5G architecture.

11.4.2.1 Generic Issues and Challenges

Business strategies for underprovisioning Multi-operator services cur-rently rely on best-effort connectivity enabled by service-agnosticinterconnection agreements pertaining to interdomain traffic aggre-gates. This results in unpredictable network performance and serviceexperiences that mostly depend on insufficient and inefficient over-provisioning (Walrand, 2008). Paired with the increasing overall trafficdemand and the limited incentives for investing in new infrastructure,5G services provisioning is a formidable challenge. Overprovisioningis infeasible for parts of the network where capacity upgrade alsobrings substantial benefit to a less-provisioned interconnected net-work, making the latter also more attractive to end-users (Walrand,2008).

Cut-throat competition The limited willingness of large operators tocooperate with smaller ones is evident in the interconnection linksand peering points and in the lack of quality assurance in the existinginterconnection agreements. In particular, degrading the quality (orrefusing a high quality) of the interconnection can be a profitablestrategy for large ISPs (Buccirossi, Ferrari Bravo and Siciliani, 2005):By following the selective degradation strategy of the interconnection,large ISPs prohibit the expansion of smaller networks and increasetheir market share. Existing business models result in significantentry barriers for new operators, who may not be recognised aspeers by their competing ISPs, thus mitigating competition (Frieden,2000). This cut-throat competition strategy with a focus solely onintra-domain services is no longer viable or sustainable for 5G IPTV.Thus, new coopetitive ways of conducting business are expected toemerge.

Lemon market From an economics standpoint, the lemon market the-ory (Akerlof, 1970) can explain the lack of multi-operator QoS-based

Page 315: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 301

services in the marketplace and why QoS is mostly restricted toindividual network providers, that is, ‘on-net’ services. The lackof quality assurance, interdomain monitoring, SLAs, and monetaryincentive schemes essentially drive quality products out of the market,that is, high-value products are unsustainable as their quality cannotbe communicated to their potential buyers. To improve the current‘on-net’ paradigm and resolve today’s profit-limiting situation, bettercoordination and a more flexible mechanism for information-sharingare required in the context of multi-operator service orchestrationand monitoring, as well as an expressive SLA framework. Factoringin interoperability with the cloud infrastructure, the design of astandardised and open solution requires a holistic approach, which,in addition to technical work, covers standardisation, SLAs andalignment of business processes.

Pricing and charging Operators’ ‘off-net’ pricing strategies (backbonesset their prices in respect to the marginal costs of rival networkswithout taking into account the relationships to their own customers)are robust for various model variations and can result in significantdeviations from the social optimum (Laffont et al., 2003). Such ineffi-ciencies are also discussed in He and Walrand (2006), where providersare assumed to independently set prices for the (interconnecting)links. This model indicates that the distribution of revenues amongthe providers is unfair, which may discourage upgrades by providerswith bottleneck links, thereby limiting the available bandwidth forservices. Clearly, any 5G IPTV service provisioning model must tacklethe issues of sustainable and incentive-compatible pricing, for all theservice layers involved, from the infrastructure network services tothe application layer.

Customer choice Product differentiation is known to increase welfarebecause it increases the number of available choices and allowsheterogeneous consumers to choose consumption bundles moreclosely suited to their individual preferences. User utilities increasewhen QoE aspects are included in the traffic classification process(Wahlmueller, Zwickl and Reichl, 2012): With an application-agnosticbenchmark two-price system, a relatively higher number of users maychoose not to purchase any service at all. This amount is reducedsubstantially if quality expectations are taken into account. This isof high importance for IPTV where different quality levels greatly

Page 316: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

302 IPTV Delivery Networks

impact the user’s willingness to pay for the IPTV service. Thus,service differentiation in terms of content and quality is expectedto play a key role in the commercial success of 5G IPTV. The IPTVservice-level indicator example introduced earlier in this chaptersuggests ways of enabling end-user interaction needed to align thecustomer’s expectations with what is offered.

An open multi-service Internetworking approach The generic chal-lenges discussed earlier in this subsection are interdependent andactually facets of a fundamental challenge: Bootstrapping an openmulti-service Internetworking approach that is highly cost-efficientfor a wide set of services, large number of users and exponentiallyincreasing traffic growth, serving also as a value-creation platformwhere services can be rolled out and monetised. It is not cost-efficientto build a new purpose-built solution from scratch; instead, extendingand evolving the current Internet to meet the new business andtechnical challenges is the way to go. To this end, we discuss in thissection the merits of an open multi-service (differentiated connectiv-ity) Internetworking approach for 5G, under which IPTV is a greatuse case and a high-value service. We also present relevant IPTV usecases that advance the 5G IPTV service from what is currently beingoffered in the market.

11.4.2.2 IPTV Distribution of ‘Small/Medium’ Live EventsThe user demand for live event broadcasts (even at a premium price)tailored to their taste and the high technology readiness levels ofreal-time data analytics has created an immense business potentialfor the IPTV-based distribution of small- and medium-sized liveevents. Coupled with the increasing scatteredness of communitieswith the same interests (e.g., due to decreasing transportation costsand European mobility), sporting events, election races (amongothers) could turn into cash cows for both major and minor contentand network providers.

Consider the following scenario: The Norwegian football teamplays against Hungary in Budapest. In addition to the Norwegianbroadcaster (NRK), there are several national, regional and localmedia teams that would like to produce live event content followingup on pre-match, during-the-match and after-the-match happenings,advanced real-time statistics and interviews suitable to local interests.In such a scenario, the content an actual user sees could be the

Page 317: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 303

result of distributed content production (on-site video feed andcommentary, NRK studio and local studios). In addition to this, someNorwegian viewers/subscribers will be in the area of the live-event(possibly using a roaming mobile broadband connection), some indifferent regions of Norway and some all over Europe, necessitatinga truly multi-operator effort for service delivery. This in turn willtranslate into requirements on (1) inter-operator quality assurance(not only bandwidth, delay and jitter but also potential computationalrequirements e.g., for in-cloud video editing or transcoding), (2)complex SLAs among providers and, perhaps most importantly, (3)a flexible and easy-to-use service creation and delivery platformfor multi-operator services. Figure 11.4 has been inspired by such ause case.

11.4.2.3 User-Generated ContentUser-generated content has been gaining momentum the past yearsin the form of blogs, vlogs, post, tweets, images, audio and video files.A major driver of this trend has been social media that motivate usersto create and share their own content, along with that provided bythe content application providers. This trend is expected to inten-sify the coming years and combined with real-time video streaming,the latter can be just really basic video streaming such as securitycamera videos or extremely high-quality and interactive 360-degreesvideo. The integration of augmented reality is also possible, especiallygiven the increasing investments on related headsets and applications(Oculus, 2016).

Though traditionally these videos were uploaded to some contentapplication provider or portal and then viewed by users, this is alreadychanging. Multiple solutions, which typically include social networkand gamification aspects, such as Stringwire (2016) enable users tostream in real-time video captured by their smartphones or tablets.In fact, traditional (IP)TV providers already integrate such ‘content’as part of their offering; for instance, NBC has acquired Stringwire(2016). The paradigm where IPTV content is created by end-usersthemselves and instantly viewed in real time by other users all overthe globe is a new paradigm imposing additional constraints for theefficient service provisioning. The on-demand elastic provisioningof resources, service management and orchestration across multiplenetworks is required, motivating innovation and reengineering of the

Page 318: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

304 IPTV Delivery Networks

network. Such solutions and architectures are presented in the nextsection.

11.4.3 Solutions and Architecture: The 5GEx Approach

In this section, we present 5GEx, an open multi-operator multi-serviceInternetworking approach, capable of orchestrating, scaling, manag-ing and trading assured quality network infrastructure services, com-bined with storage and compute resources for the support of rich ser-vices such as IPTV in 5G networks. We also present the associatedcoordination models and roadmap considerations, driven by the IPTVuse cases of the previous section, as well as business models and charg-ing issues.

11.4.3.1 5GEx Exchange: An Open Multi-Service InternetworkingApproach5GEx (2015) is wholesale service trading and exchange framework forthe orchestration of both network and cloud resources over multipletechnological and administrative domains. It is an open multi-servicemulti-operator Internetworking approach for orchestrating, tradingand provisioning 5G infrastructure services. Such infrastructureservices (and associated resources) provide the foundation of 5Ghigh-level services (‘verticals’) such as IPTV by relying on lower-level5GEx fundamental services, with the core element being the slice. Aslice is a managed set of 5G resources and network functions tailoredto support a particular type of user or service. Slices are instantiatedon demand using APIs exposed by the management plane, providingdynamic orchestration for multi-layer and multi-domain networks.

SDN and NFV greatly simplify slice and related service orches-tration and management. As depicted in Figure 11.5, the 5GExconceptual architecture anticipates standard interfaces, namely: (1)for multi-domain orchestrator to translate the 5GEx customer (e.g.,Live Event studio) service request to a chain of VNFs and underlyingnetwork, storage and cloud resource requirements; (2) for SLA-basedtrading of slices and 5GEx higher-level services among 5GEx-enabledorchestrators; (3) for the management of own or leased – via interface(2) – slices. The orchestrator/controller bottom layer ensures that5GEx works over multiple technology cloud and network domains,ranging from legacy to modern SDN. This enables the provision

Page 319: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 305

Business management

Enterprise

customer

Service management/control

Data

Orchestrator / controllerOrchestrator /

controller

Orchestrator /

controller

Orchestrator /

controller

DevDriver

SDN nets.

DevDriver

optical

Device driver

opticalDevDriver

data center

Resources

Wrapper

legacy

5G exchange framework

Third-partyorchestrator

(optional)

Multi-domain

orchestrator

1

1

3 3 3 3

22

2

Multi-domain

orchestrator

Figure 11.5 Simplified conceptual architecture of the 5G exchange.

of services such as IPTV over multiple diverse networks, reachingthousands or millions of users.

The 5GEx hierarchy of resources and services is depicted inFigure 11.6. Lower-level resources are the low-margin commoditybuilding blocks of differentiated higher-level services such as IPTV.Virtual resources and NFs are composed into slices under the net-work function virtualisation infrastructure as a service (NFVIaaS)paradigm; slices make up infrastructure services, by the conceptof slice-as-a-service (SlaaS); finally, infrastructure services enablecustom VACS and customer-specific VNFs such as for the supportof IPTV.

5GEx is the stepping stone for the on-demand wholesale servicetrading needed for multi-operator IPTV. Elastic, automated IPTVservice management, SLA-based ASQ connectivity (ASQ path,VACS) and detailed monitoring constitute integral parts of the 5GExarchitecture. Thus, the IPTV service peculiarities can be efficientlymet by the generic 5GEx framework. For instance, in the Norwegianfootball match scenario of Section 11.4.2.2, the first step is to computethe required resources and obtain a multi-operator slice with ASQconnectivity and compute resources for setting up the NFVIaaSresources needed for media production in the data centre in, forexample, Budapest, with load balancing with nearby data centres.Video transcoding/caching can be VNFs also offered by a third party,thus accommodating new roles into the 5G IPTV ecosystem. Local

Page 320: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

$$$$

Very High

$$$

High

$$

Medium

$

Low

5G UsersCorporate and Residential

5G VerticalsSpecific quality requirements

5GEx Wholesale/Use CasesTailor-made requirements

5GEx Building BlocksSlice as a Service, Instantiated VNFs

Out of 5GEx scope

Input to virtualization

Virtualized Resources

Raw Resources

Enterprise

e-health

compute

ASQ

XaaS vCDN VNFaaS VACS

Path VNF VNF RAN Core NFVlaaS

storage network

streaming roaming telepresence

B2C customer SME Telco

Figure 11.6 Levels of 5GEx services and value proposition.

Page 321: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 307

newspaper or live event streaming provider is the 5GEx enterprisecustomer, relying on the local network operator resources as wellas NFVIaaS from clouds/data centres in Budapest to create a slicewith assured network quality links and capable of adaptive streamingto meet the viewers’ needs. ASQs interconnecting the footballstadium, the streaming servers and the end points of fans acrossmultiple locations in Norway and Hungary, combined with VNFs forquality monitoring and providing service-level indicators comprisethe core of the IPTV 5G service in this scenario. These capabilitiesallow to align the service delivery to end-user expectations andservice-delivery choice, and hence, enabling a high level of QoE andcustomer satisfaction. The respective charging issues are overviewedlater in this section.

11.4.3.2 Roadmap and Coordination ModelsThe proposed 5G Exchange Framework allows and supports a varietyof specific deployments and coordination/collaboration models,including: (i) ‘direct peering’ at an already established local or remoteIXP, (ii) distributed multi-party collaboration, where the operatorshost the exchange mechanism in a distributed manner inside theirown infrastructure and (iii) a dedicated exchange-point provideras a standalone entity, offering exchange-point services. Also notethat the customer-facing ‘third-party orchestrator’ in Figure 11.5 isan optional role in the ecosystem, essentially referring to a virtualnetwork operator who implements the multi-domain orchestratorfunctionality, that is, receiving service requests, translating themto resource and elementary service requirements and setting upslices meeting those requirements. The service may be either orches-trated on-demand, that is, based on a customer SLA-request, or theenterprise customer can browse through a catalogue of the availablecustomisable services/slices and purchase one that meets his/herneeds.

A big challenge for the Telco and NSP industry is that of ‘boot-strapping’ the basic solution enablers when faced with so manymulti-stakeholder coordination issues. We anticipate that a fewcollaborating network operators (NSPs, Telcos) can be sufficient asan initial step and to agree on simple direct ASQ peering to cover amarket that is of attractive business interest to get started with suchofferings. With a core and backbone ASQ interconnection solutionin place they have a common platform where additional retail-facing

Page 322: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

308 IPTV Delivery Networks

Network A Network B

ASQ path

Point ofinterconnection (Pol)

$

$

Figure 11.7 The sending party network pays principle.

services can now be introduced. Hence, IPTV and other high valuebusiness services should be seen as part of a roadmap towards a richerset of services and capabilities tailored towards wholesale as well asretail services offerings.

11.4.3.3 Pricing and Charging SolutionsSPNP, shown in Figure 11.7, was introduced in ETICS (2013) andBornstaedt et al. (2011): Two networks exchange assured qualitytraffic according to agreed SLAs: When Network A (buyer) sendsASQ traffic to Network B (provider), Network A pays Network Bfor transporting the IP packets according to the SLA (A-to-B) todestination end-points of an agreed destination region (set of IPprefixes) R-x. For traffic in the opposite direction, the roles of A andB will change, as well as destination region R-y. Under SPNP, thecharges for the traffic in the two directions are in principle separateissues.

SPNP applies between NSPs; NSP offerings to the IPTV serviceprovider is a different issue. To ensure that the ASQ services arelow-cost and scalable, no end-user flow awareness is needed at thepoint of interconnection (PoI). SPNP is best in deciding the trade-offbetween the cost and quality trade-off and is in line with similarcharging solutions from other industries, for example, post, packetdelivery. SPNP can be the means to compensate for the additionaltransit overheads and the service provisioning costs, better reflectingthe service cost and resources. Multiple paths, regions and granu-larities are possible for the SPNP-charged infrastructure networkservices. This way, for instance in the football game use case presentedearlier, ASQ streaming to groups of soccer fans located in different

Page 323: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 309

locations and served by different networks can be supported in therequired granularity for the efficient provisioning and monetisationof the IPTV live event streaming service.

Combining SPNP with 95th-percentile charging is also advanta-geous. 95th-percentile charging is common for Internet transit, thusoperators are familiar with its merits. Results from Dramitinos andStamoulis (2015) show that 95th-percentile charging provides properincentives for traffic shaping of non-critical traffic to both NSPs andservice providers. This results in load balancing and high multiplexingefficiency of the underlying network, which is crucial for IPTV giventhe exponential increase of huge traffic volumes. Therefore, thecombination of SPNP and 95th-percentile charging ensures that theright incentives are offered for rational usage of the ASQ networkinfrastructure. We envision SPNP with 95th percentile as a VNF inthe 5G network.

SPNP can be complemented with a variety of end-customer(retail)-related and service-related business models for ASQ connec-tivity, from any to any end point. On top of the SPNP wholesale layer,additional charging layers and business models can be supported,including scenarios where even the initiating end-customer can payfor traffic in both directions if needed. In this case, the initiating partycustomer is paying his NSP, and this NSP must then pay the remoteNSP for the traffic in the opposite direction, thus supporting multipleend-to-end money flows. For instance, in this way money may flowfrom end-points of customers willing to pay into network regionsthat are less well-developed with end-customers that cannot affordadvanced services. Hence, low-end customers and NSPs in theseregions can also benefit.

Considering the football match scenario again, SPNP applies tothe establishment of ASQ infrastructure of Figure 11.4. Parts ofthe infrastructure in Hungary may be financed by the Norwegiannewspaper/streaming provider to be able to have the requiredquality for service monetisation over multiple end-user devices.Thus, the enterprise customer finances also the ASQ infrastructurein Budapest by paying the Norwegian NSP for the entire ASQinfrastructure of Figure 11.4; a subset of this money is paid from theNorwegian NSP to the Hungarian NSP for streaming of content fromBudapest to both Hungary and Norway. In this way IPNP on top ofSPNP enables money flow towards the Hungarian NSP so that therequired ASQ infrastructure is set by covering for the ASQ traffic

Page 324: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

310 IPTV Delivery Networks

Multiple business models on-top-of SPNP

Sending party network pays (SPNP) principle

• Charging for end-user (customer) ASQ connectivity end-to-end

• The base layer for charging of ASQ traffic exchange

• Can work stand alone

• "SPNP advanced"

Destination-based charging

• Initiating party network pays (IPNP)

• Traffic charging and/or application level charging

Enables money flowing into less developed network regions

Advanced business models and innovative services

Keep it simple

Wh

olesale

Retail

Figure 11.8 Wholesale and retail charging layers.

in the return direction. Access of 5G IPTV end-users to the serviceis a retail application-layer issue, on top of those of Figure 11.8.Subscription-based and on-demand charging for content (pre-match,match, interviews, happenings, commenting) are the two prominentcharging models envisioned. Social media-based business modelsoverviewed previously such as Stringwire (2016) constitute additionalpotential 5G IPTV value propositions.

11.5 Future Research

The IPTV emerging trends, unmet market needs and unresolvedbusiness issues motivate the authors’ research on new innovative5G architecture, service provisioning and business models, alsoin the context of the 5G PPP project 5GEx (2015). The vision isto design, build and validate an exchange platform for the deliv-ery of multi-domain services linking multiple network operators,application providers and other actors in the end-to-end supplychain. The realisation of such a vision can bring many added valuesto the IPTV service market, including accelerated and automatedservice delivery, an exchange where multi-domain (IPTV) servicescan be orchestrated on top of infrastructure services tailored to theorchestration, dimensioning and management needs of the (IPTV)service providers.

Defining the architecture and rules of the exchange, along with auto-mated trading, business processes, management and orchestration

Page 325: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 311

application program interfaces (API)s, service catalogues, protocolsand solutions comprise ongoing research topics. Validating thetechnology and business rationale of 5GEx in the context of IPTV andother popular services and disseminating it by means of standards,industry fora and scientific publications are ongoing work.

Assessing and enhancing existing, as well as defining new SLAframeworks, trading mechanisms and pricing policies as well asschemes also comprise additional research directions. This is tobe combined with new ways of realising a common monitoringcapability and management of requested QoS attributes, as well ascharging and billing models that can maximise the return of everyactor in the 5G multi-operator service provisioning scenario. Theneed for efficiency gains, reducing costs and automation implies thesesolutions should be both generic enough to apply to multiple servicesand customisable so that they can address the needs of a specificservice such as IPTV in a cost-efficient and performance-assuringway in terms of service availability and end-user QoS. The authorsplan to investigate further both the strengths and the limitationsof the 5GEx layered infrastructure services provisioning modeland architecture presented earlier in this chapter, which relies onlower-level fundamental services and SDN/NFV techniques, with thecore element being the slice. The detailed specification of protocolsand solutions for the on-demand instantiation and elastic scaling upand down of slices using APIs exposed by the management plane,allowing dynamic service orchestration and management over thenetwork, storage and cloud domains comprise challenging researchitems.

11.6 Conclusions

In this chapter, we have highlighted the challenges, opportunitiesand important operational, business and customer-centric aspects ofsingle- and multi-operator IPTV services in 5G networks. We havepresented a set of key issues for 5G IPTV and similar QoS-sensitiveservices: Quality assurance, business and service coordination,service-level awareness, elastic and agile service orchestration andtrading. We have provided an overview of the 5GEx framework andits use as a potential solution to the challenges identified over thesefeatures for IPTV, also addressing specific 5G IPTV use cases. We

Page 326: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

312 IPTV Delivery Networks

have argued that 5GEx SDN/NFV-based service architecture andorchestration exchange is technically sound and results in new whole-sale business and service-trading opportunities, and related businessmodels and charging schemes. Going deeper into the coordinationand business models, as well as developing a detailed roadmap andecosystem analysis constitute ongoing work, given also the authors’involvement in the 5GEx project.

Acknowledgement

Gergely Biczók works with MTA-BME Future Internet ResearchGroup, and Laszlo Toka works with MTA-BME Information SystemsResearch Group. Both Gergely Biczók and Laszlo Toka have beensupported by the János Bolyai Research Scholarship of the HungarianAcademy of Sciences. This work has been performed in the frame-work of the H2020-ICT-2014 project 5GEx (Grant Agreement no.671636), which is partly funded by the European Commission. Thisinformation reflects the consortium view, but neither the consortiumnor the European Commission are liable for any use that may be doneof the information contained therein.

References

5GEx (2015). H2020 5G PPP 5GEx Project. [online] Available at: http://www.5gex.eu/ (accessed 15 June 2016).

Akerlof, G.A. (1970). The market for lemons: quality uncertainty and themarket mechanism. The Quarterly Journal of Economics, 84(3),488–500.

Bornstaedt, F., Roettgermann, M., Korthals, I., Johansen, F.T. andLonsethagen, H. (2011, October). “The Sending Party Network Pays”:A First Step Towards End-to-End Quality of Service. In Intelligence inNext Generation Networks (ICIN), 15th International Conference,IEEE, pp. 1–5.

Buccirossi, P., Ferrari Bravo, L. and Siciliani, P. (2005). Competition in theInternet backbone market. World Competition, 28(2), 235–254.

Constantiou, I.D. and Courcoubetis, C. (2001). Information asymmetrymodels in the Internet connectivity market. 4th Internet EconomicsWorkshop, Berlin.

Page 327: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Towards Multi-Operator IPTV Services Over 5G Networks 313

Császár, A., John, W., Kind, M., Meirosu, C., Pongrácz, G., Staessens, D.,… and Westphal, F.J. (2013, December). Unifying Cloud and CarrierNetwork: Eu fp7 Project Unify. In Proceedings of the 2013 IEEE/ACM6th International Conference on Utility and Cloud Computing (IEEEComputer Society), pp. 452–457.

Dramitinos, M. and Stamoulis, G.D. (2015). ICC: AnIncentive-Compatible Inter-Domain Inter-Cloud CommunicationTraffic Management Mechanism. Proceedings of 11th InternationalConference on Network and Service Management (CNSM 2015), pp.36–42.

ETICS (2013). ETICS: Economics and Technologies for Inter-CarrierServices. [online] Available at: www.ict-etics.eu (accessed 15 June2016).

Frieden, R. (2000). Why Internet Peers Become Customers: TheConsequences of Settlement-based Interconnection. Proceedings of3rd Internet Economics Workshop.

Geddes, M. (2016). IPX: Telecoms Salvation or Suffering? [online]Available at: http://www.martingeddes.com/think-tank/ipx-telecoms-salvation-suffering/ (accessed 15 June 2016).

GSMA (2007). GSM Association Official Documentation IPX WhitePaper Version 1.2. [pdf ] Available at: http://www.gsma.com/publicpolicy/wp-content/uploads/2012/03/ipxwp12.pdf (accessed 15June 2016).

He, L. and Walrand.J. (2006). Pricing and revenue sharing strategies forInternet service providers. IEEE JSAC, 24(5), 942–995.

IETF (2004). RFC 3810. Multicast Listener Discovery Version 2 (MLDv2)for IPv6. Available at: https://tools.ietf.org/html/rfc3810 (accessed 15June 2016).

IETF (2006). RFC 4605. Internet Group Management Protocol (IGMP) /Multicast Listener Discovery (MLD)-Based Multicast Forwarding(‘IGMP/MLD Proxying’). Available at: https://tools.ietf.org/html/rfc3810 (accessed 15 June 2016).

ITU-T (2006). Y.1542: Framework for Achieving End-to-End IPPerformance Objectives. [online] Available at: https://www.itu.int/rec/T-REC-Y.1542-200607-S/en (accessed 15 June 2016).

ITU-T (2007). Y.1543: Measurements in IP Networks for Inter-DomainPerformance Assessment. [online] Available at: https://www.itu.int/rec/T-REC-Y.1543-200711-I/en (accessed 15 June 2016).

Page 328: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

314 IPTV Delivery Networks

ITU-T (2008). G.1080: Quality of Experience Requirements for IPTVServices. [online] Available at: https://www.itu.int/rec/T-REC-G.1080-200812-I (accessed 15 June 2016).

Laffont, J.J. Marcus, S., Rey, P. and Tirole, J. (2003). Internetinterconnection and the off-net cost pricing principle. The RANDJournal of Economics, 34(2), 370–390.

Networld2020 (2016). Service Level Awareness and Open Multi-ServiceInternetworking – Principles and Potentials of an Evolved InternetEcosystem. White Paper Ver. 0.9.5 [pdf ] Available at: http://networld2020.eu/wp-content/uploads/2016/03/NetWorld2020_WhPaper_Service-Level-Awareness_Final-Draft_0.9.5.pdf (accessed15 June 2016).

Oculus (2016). Oculus rift. [online] Available at: https://www.oculus.com/en-us/rift/ (accessed 15 June 2016).

Seufert, M., Egger, S. Slanina, M., Zinner, T., Hoßfeld, T. and Tran-Gia, P.(2015). A survey on quality of experience of HTTP adaptive streaming.IEEE Communication Surveys & Tutorials, 17(1), 469–492.

Stringwire (2016). Live Video. Made Social. [online] Available at: https://www.stringwire.com/ (accessed 15 June 2016).

Wahlmueller, S., Zwickl, P. and Reichl, P. (2012). Pricing and regulatingquality of experience. Next Generation Internet (EURO-NGI)Conference, pp. 57–64.

Walrand, J. (2008). Economic models of communication networks.Sigmetrics 2008 Tutorial, Chapter 3, in Performance Modeling andEngineering (eds Z. Liu, C. Xia, Z. Liu and C. Xia), Springer PublishingCompany, Germany.

Wiki (2016). IP Exchange [online] Available at: https://en.wikipedia.org/wiki/IP_exchange (accessed 15 June 2016).

Page 329: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

315

12

Technologies and Architectures for Future IPTelevision ServicesLucile Sassatelli and Marie-José Montpetit

12.1 Introduction

Until the early 2000s, IPTV offers mainly followed the linear TVmodel: The catalogue of channels was increased compared withsubscription-free (Hertzian) and subscription-based (cable) TVservices, but the content remained mostly broadcast (where theviewer does not get to choose the show’s starting time). To do so,the network providers upgraded their infrastructure to support IPmulticast. IPTV providers then started to propose replay services inthe mid-2000s, making the shows available for people to watch anytime after their airing date. Such services developed in parallel withthe advent of video-streaming services launched by providers who didnot own network infrastructure but relied on public Internet to reachtheir consumers; these were called ‘over-the-top’ (OTT) services.Several major and smaller video streaming providers hence devel-oped, with various business models mainly based on advertisement(e.g., YouTube) or subscription fees (e.g., Netflix).

With the advent of ADSL2+, FTTH investments and DOCSIS 3.0and 3.1, the increase in the clients’ access bandwidth in the late 2000sto early 2010s spurred the consumers to subscribe to these type ofunlimited, yet targeted OTT services. An important advantage istheir ability to be delivered from any third-party network, contrary tolegacy IPTV. The huge leap in mobile access (with WiFi, 3G and 4G)and devices (smartphones and tablets) has intensified this trend, somuch so that the legacy TV set and revenue model is being thoroughlydisrupted. However, the counterpart of OTT distribution is that the

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 330: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

316 IPTV Delivery Networks

video experience quality depends heavily on the volatile serviceprovided by the Internet, something the IPTV distribution is notsensitive to owing to the control and reservation of the infrastructure,in turn preventing its distribution outside the walled garden networkof the IPTV provider.

As a result of the afore-mentioned evolution, IPTV services progressalong a path leading to overcome their limitations compared withOTT, so do the OTT services with respect to IPTV. The technologicalevolution of both are hence intertwined, enabling an overhaul of thebusiness model of many actors involved in these delivery systems.This chapter analyses the future and the possibilities of an overhaul.

12.2 The Evolution of Users’ Experience: Usage,Expectations and Reluctances

The video usage and expectations towards TV services are beingdisrupted by the new consumption means, be it with mobile devicessuch as smartphones and tablets, or with network and service offers,such as uncapped mobile data plans and subscription-based videoservices. This section analyses these major changes in the userbehaviours and their impact on the video stakeholders, drawingevolution towards new revenue models.

12.2.1 Broadcast Versus OTT: Towards a SpuriousOpposition

IPTV lies in the immediate legacy of traditional broadcasting systemsdesigned in the twentieth century. Whether it be radio and televisionthrough Hertzian waves or plain-old cable television, these systemswere and are still meant to reach millions of people with real-time con-tent. Thanks to the undifferentiated content sent to the users, thesesystems could scale up very well, and their revenue model was basedon a combination of subscription and advertisement priced on rat-ings. IPTV systems have been introduced by fixed telecommunicationoperators (telcos) to start to offer a television broadcast service, andby cable operators to broaden their channel offer, leveraging on theInternet access they provide.

However, with the rise of OTT video distribution through newglobal services such as Netflix, Hulu, Amazon Prime and others, a

Page 331: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 317

sizeable fraction of users have started moving away from traditionalTV. In particular, cable subscribers have been increasingly annoyedat the overpriced bundles delivering a great quantity of untargetedcontent. On the other hand, 90% of the top 250 shows are availableon iTunes or Amazon (Lifehacker, 2014), and Apple TV reached 10million units in 2014. As of January 2016, such applications are onlysupporting apps and don’t have any Internet-based live TV service.One may hence argue that the future of user experience does not liein the broadcast systems anymore, but instead in OTT distribution,as proclaimed by Netflix CEO Reed Hastings, foreseeing the death oftraditional broadcast by 2030 (Huffington Post, 2014). This clear-cutand somewhat provocative prophecy can be discussed in light of anumber of elements.

First, one of the main widely acknowledged limitations of OTT is interms of scale when it comes to broadcasting live events (in particular,major sport events such as the Super Bowl, the Olympics and so on). Toreach millions or even billions of viewers with a high-quality content,multicast IPTV architecture emanating from broadcast systems hasthe edge, thanks to its better use of bandwidth resources.

Second, the infrastructure allowing efficient large-scale andreal-time broadcast already exists, be it through cable or airwaves(CSI Magazine, 2015).

Finally, the contents desired by the users will always entail acombination of live and not personalised events, fit to broadcast, withinteractive and on-demand shows.

Even though OTT distribution will keep evolving, it is very likelythat sensible evolutions of the video landscape will rather involveadvanced partnerships of the pipe owners, broadcast industry andcontent retailers to smartly marry IPTV and OTT architecture, ratherthan merely wipe out non-OTT systems. The following sectionsmention announcements of big industry players supporting thisclaim.

12.2.2 The Multi-Screen Multi-Device Anywhere Experience

With the advent of subscription-based video-on-demand (SVoD)services along with an array of devices to access such content, thewatching habits have dramatically changed over the past few years.To exemplify the surge of such services, their UK revenue grew by56% over a time span of 12 months, to reach 417 million in 2014,

Page 332: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

318 IPTV Delivery Networks

and it is expected to total over 1 billion by 2019 (Mintel, 2015). Thisphenomenon is accompanied by an increasing number of peopledropping cable, often referred to as ‘cord-cutters’. In 2014, in the USA,Sandvine pinpointed these users for consuming 11 times as muchstreaming content as other typical users, and accounting for nearly54% of the total traffic at evening peak hours, while representingonly 15% of all users (Sandvine, 2014). It is expected that this sharewill increase as the young generations of viewers are growing awayfrom the so-called ‘linear-TV’ model, often being dubbed ‘cordnev-ers’. Additionally, according to IPTV News (2016), the number ofhouseholds without a traditional TV set reached an unprecedented 5million in the USA, the video content being more and more consumedon laptops and mobile device such as smartphones and tablets.

Meanwhile, connected TV devices, in particular, SmartTVs, set-topboxes (STBs) and dongles reached over 200 million in sales in 2015(Strategy Analytics, 2015). As discussed in the first paragraph, the pre-ceding figures of streaming service subscription and ‘zero-TV’ house-holds do not reflect a radical pushback against traditional broadcastingservices, but rather uncover that the use of these gateways to onlinevideo content is fuelled by the desire of users to control how they watchTV. In particular, the multi-device multi-screen needs of consumersare reflected by the increasing number of dongle technologies, suchas Miracast or Chromecast, or more recently the French SoftAtHomeUniversal Cast dongle. This is driven by the desire of users to exploitthe full flexibility allowed by the various screens and devices they pos-sess: Choosing the screen on which they are going to watch a live pre-mium broadcast or an on-demand show (large TV screen, desktop,screen hooked up to a game console, tablet or even smartphone), whilehaving a unified interface to remotely control and switch channels andscreens. This is decisive to the user experience (IPTV News, 2015). Asan example, the SoftAtHome Universal Cast dongle allows to do so byadditionally supporting multiple in-home casting technologies (AppleAirplay and Google Chromecast).

Finally, legacy IPTV networks are, by definition, networks ownedand managed by the operator providing the subscription, which usedto ensure a higher quality of video experience compared with OTT.To meet the user’s expectation of accessing the content they subscribeto from anywhere, as they can with OTT, IPTV systems will have toembrace this ‘anywhere’ access, possibly establishing partnershipswith other networks (this is detailed in Section 12.4.2). The success of

Page 333: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 319

convicted Aereo, a NYC-based company offering such an aggregatedexperience to its subscribers, illustrates sharply the need yet to besatisfied. Current TV solutions offer STBs that must be hooked upto the screen and multiplied to extend to other screens to switchfrom live broadcast to on-demand free or SVoD content. Aereopenetrated the market by relieving the user from the hassle of piecingup all systems together, providing them with a seamless multi-screenanywhere experience of watching all cable, broadcast channels andVoD content they wanted from where they wanted.

Delivering a high-quality and fully converged experience to the sub-scribers wherever they are on whatever screen they want is hence themotto driving the IPTV innovations.

12.2.3 Business Experiences and Inevitable Evolutionfor the Stakeholders

While the aforementioned elements show a demand for stillconsuming broadcast content as it airs, in addition to free orsubscription-based VoD, it also questions the business model onwhich the major broadcast, cable and content creator companiesrely to date. The Aereo adventure, though ended with demise, area watershed moment in this regard. Aereo indeed built its businessby providing users with a wide selection of content through virtualantennas deployed in their premises as IP gateways transducingcontent to re-broadcast it in an aggregated form to their subscribers,thereby making an attempt on the monopolies of the entitled broad-casters. Aereo was eventually taken down by a Supreme Court rulingon 20 June 2014. Nevertheless, its ephemeral success opened theavenue to rethink the way IPTV shall be provided and the revenueopportunities for the legacy broadcasters, whose model based onads and affiliates, and subscription for cable companies, seems tobe getting antiquated rapidly in light of the subscription decrease(BGR, 2015).

First, service providers must make the most of the customers’demand for live and public broadcast by embracing IPTV distribu-tion, partnering with TV gateways and accessing those subscribersthe way they want again. An example of this realisation by somebroadcasters is the recent purchase by the UK TV channel Sky of astart-up providing OTT deployment to newcomer content providers(CPs; CSI Magazine, 2015; IPTV News, 2014).

Page 334: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

320 IPTV Delivery Networks

Second, cable and telcos who own the pipes to the users – andpossibly an IPTV architecture they have already invested in – mustdepart from their stance as the only players entitled to reach userswith high-quality video. They instead have to open up to profitablepartnerships to make the most of the newcomers to the Internetvideo market, whose development is hampered by (i) their lackof proprietary infrastructure (Akamai press release 1, 2012, 2013;Akamai press release 2, 2012, 2013) and (ii) their lack of access to livepublic TV content (see Apple talks with ESPN, CBS [9 to 5 mac, 2016;Macworld, 2016]). It is worth noting that the monetisation of thetelcos’ infrastructure to OTT providers, driven by (i), likely falls intothe net neutrality problems. The successive FCC rulings on this point(spurred by the Netflix/Comcast/Verizon frictions [Time, 2014])underline the intricacy of such partnerships in the Internet sphere.

12.3 Architectural Evolution of IPTV: Towardsa Smart Meld with OTT

The evolutions of the high-level aspects on video consumers andmarket discussed in the previous section are driving the architecturalchanges having been undergone by the IPTV distribution systems.This section presents how IPTV 2.0 is aiming at incorporating allthe assets of OTT, while OTT systems in turn look for embracingIPTV key principles to meet the scaling challenge they are facing.While the first Section 12.3.1 focuses on the evolutions of legacyIPTV to meet with the OTT-induced requirements of the clients,subsequent Sections 12.3.2 and 12.3.3 synthesise how IPTV inspiresOTT evolutions, thereby unveiling the cross-fertilisation increasinglyat work between IPTV and OTT.

12.3.1 The Main Overhauls of IPTV: HTML5, Cloudification,Software-Defined Video

Inheriting from traditional non-IP broadcast systems, IPTV has beenturned from the beginning towards delivering high-quality content tomasses. On the other side, OTT stems from public Internet Web-likedelivery, providing video with native anytime anywhere ability (thankspartly to unicast, see Section 12.3.2), at the expense of hardly support-ing mass live broadcast, for which IPTV keeps using multicast delivery

Page 335: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 321

to easily scale up. A number of OTT-allowed features are howeverkey to the future of IPTV that cannot overlook them to meet users’expectation.

The first of these OTT features are implied by the support of amulti-screen multi-device experience. That necessitates unifyingthe delivery framework, which today is achieved by HTML video,specifically W3C-endorsed HTML5 that specifies the so-calledvideo element as a standard way to embed a video without theneed for additional plugin (e.g., in a webpage). From a standard andalgorithmic point of view, the so-called adaptive bit rate (ABR) andthe corresponding standard MPEG-DASH (ISO/IEC DIS 23009-1,2012) enables the video quality to adapt dynamically to the user’sand network’s environment. The resolution is specific to the screensize, while the video bit rate can be adapted over time to best fit thebandwidth available to the client. More details can be found in recentcontrol-theoretic adaptation logic (Yin et al., 2015). Having such anIP-based video delivery therefore allows for a unified form of contentto serve any sort of device (SmartTV, STB, tablets, Web apps and soon) from any type of access (cable, DSL, cellular, satellite).

The second key OTT feature is offering the access to the unified con-tent from networks not managed by the IPTV provider, to providethe ‘anywhere’ access to the user, by adopting a unicast-based deliverymode not necessitating proprietary infrastructure.

The third key OTT feature IPTV systems must incorporate is thesupport of VoD (embedding seamlessly legacy OTT services such asNetflix) and advanced digital video recorder (DVR) features, such ascatch-up TV, record, pause and rewind. These come natively withOTT services, and IPTV systems do not yet provide such full-fledgedcapabilities.

The preceding features are yet seldom offered, or in a quiterestrictive mode, to early 2016. To fully embrace them, an importantchallenge for IPTV providers is indeed to smartly plan and managethe required resources, in terms of storage, computations and networkbandwidth. It is hence crucial that these resources can ramp up anddown depending on demand variations, so that the provider canmake the most of its resource investment while still fully satisfying itscustomers.

The key enabler of these essential features is for the IPTV providersto rely on cloud resources (additionally to their walled garden),as illustrated in Figure 12.1. The flexibility and scalability of cloud

Page 336: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

322 IPTV Delivery Networks

Content providers Elastic video processing in the cloud

Dynamically scale virtual instances (leased from

could-service providers) for on-demand:

-Transcoding (UHD, H.264, HEVC and so on as

requests fluctuate)

-Storage

-Delivery

-Pay-TV

-Programmers

-Broadcasters

-Connected TV

-Laptops

-Tablets

-Phones

Display devices

Figure 12.1 The cloud resources at the service of IPTV providers for quality andcost optimisation.

resources can be fully exploited by the so-called software-definedvideo (SDV). SDV allows service providers to depart from specialisedvideo hardware and to leverage the computational power of today’sprocessors and distributed computation. This enables them to deploy,scale and keep up-to-date video architecture relying on generic equip-ment seized, specialised and released as demand evolves. Such newsolutions are emerging. For example, Elemental Company (ElementalTechnologies, 2016) provides SDV deployment to IPTV providers,and Mware Solutions (2016) develops middleware solutions based onHTML5 IPTV standards that can be deployed in the chosen cloudprovider as well as in the proprietary infrastructure, targeted at telcosand large Internet service providers (ISPs). The cloudification of IPTVservices is widely seen as the cornerstone of IPTV 2.0 and is expectedto bring the consumers the content and modality of experience theyexpect, while in turn getting back to a sustainable and profitablerevenue model made of a blend of subscriptions, advertisement andpartnerships with content creators and providers.

Page 337: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 323

In addition to the aforementioned improvements provided tocustomers, SDV allows two important advancements for the IPTVprovider. First, keeping up with deploying codecs’ and display formats’evolutions becomes only a matter of software updates, both at theproviders’ resources (possibly at a hosting cloud service) and at theclients’ app. We mention in passing that the current movementsare towards HEVC codec and 4K Ultra HD display format. Second,the right management is a security aspect so far handled differentlyin OTT and IPTV systems. While DRM support is evolving inOTT and the protection technologies will have to evolve for IPTVto reach out to customers from unmanaged networks, it is envi-sioned that softwarisation and cloudification will be key-enablersfor IPTV providers to safely outsource the right management.Enterprises such as Verimatrix (2016) are already in this marketsegment.

12.3.2 Legacy IPTV Extending its Reach by Inspiring OTTEvolution: Multicast, Caching, Peer-to-Peer (P2P)

The general architecture of Internet video distribution is sketched inFigures 12.2 and 12.3. Within the Internet architecture made of thedifferent tier ISPs, a CP can send videos to subscribed clients fromregular servers (Figure 12.2). However, when the clients are scatteredover several ISPs, to limit the transit costs and increase the number ofclients reached with high-quality videos despite the possible conges-tion, the CP resorts to a content delivery network (CDN). Amongst themain global CDN companies, the prominent ones that we can men-tion are Akamai and Limelight. CDNs have points of presence all overthe world, thereby easily peering with local ISPs. The popular con-tent is replicated to be stored close to the users likely to request it,to reduce the risk of having insufficient end-to-end bandwidth by low-ering the number of hops between the selected server and the client(Figure 12.3).

As live streaming demand increases, the OTT stakeholders (CPs,CDNs, ISPs) have their infrastructure strained, which is a majorhurdle for these players to position on the live TV broadcast market.Indeed, Akamai, one of the main CDN companies, recently declared‘Akamai forecasts that 500 million viewers will soon be watchingprime-time live sports online [needing] 1500 Tbps. Today, we do 32Tbps’ (Munford, 2016).

Page 338: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

324 IPTV Delivery Networks

Tier 1

ISP

Tier 1

ISP

Tier 1

ISP

Tier 2

ISP

Tier 2

ISPTier 2

ISP

Tier 2

ISP

TTierier

3 ISP3 ISPTierier

3 ISP3 ISP

Tierier

3 ISP3 ISP

Contentprovider

asdata centre

Tier

3 ISPTier

3 ISP

Tier

3 ISP

Figure 12.2 Video delivery over the Internet without any CDN.

The default use of unicast connections (or ‘sessions’; these terms areinterchangeable here) in OTT delivery is one of the main causes ofthis problem. As illustrated in Figure 12.4, with unicast, a session tothe server is established for each client. If several clients request thesame content, there will be as many flows with the same content goingthrough in the network, thereby wasting bandwidth resources. On thecontrary with multicast, flows are aggregated into a single flow, savingbandwidth resources.

As exemplified in the sequel, Akamai, British Telecom (BT) or com-panies such as Broadpeak aim to deliver broadcast-grade TV servicesacross the Internet, including 4K/UHD content. For VoD distributiontoo, solutions are sought to alleviate unicast limitations. Towards thisgoal, the most promising systems currently heavily investigated by thepreceding actors are not brand new techniques but rather consist incombining revamped architecture that proved efficient in other con-texts, namely: IP multicast, P2P sharing and (proactive) caching.

The first pillar of IPTV live distribution is IP multicast, a hot topicfor OTT at the 2015 International Broadcasting Convention (Bridge

Page 339: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 325

Tier 1

ISP

Tier 1

ISP

Tier 1

ISP

Tier 2

ISP

Tier 2

ISP

Tier 2

ISP

Tier 2

ISP

TTierier

3 ISP3 ISP

Tierier

3 ISP3 ISP

Tierier

3 ISP3 ISP

Video CDN

cache

VideoCDNas

data center

VideoCDNas

data center

Tier

3 ISP

Tier

3 ISP

Tier

3 ISP

Figure 12.3 Video delivery over the Internet with the use of a CDN. Peering linksand caches close to the users help the delivery.

(b)(a)

Figure 12.4 (a) Between the server (on the left) and the three clients, a unicastsession is established for each client. (b) With multicast, flows are aggregated asmuch as possible to save bandwidth resources by avoiding unnecessaryreplicated transmissions.

Technologies, 2015; Streaming Media, 2016). IP multicast is at thecore of the legacy IPTV networks, managed by the telcos or ISPspossibly embodying broadcasters. To date though, IP multicast hasnot been deployed in OTT delivery systems, despite its superiority inresource utilisation and video quality for live shows. The first reason

Page 340: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

326 IPTV Delivery Networks

for IP multicast not being embraced by ISPs and CDNs earlier isthat they have been charging the providers on the aggregate rateused, thereby turning multiple redundant unicast inefficiency into arevenue source (see, e.g., Figure 12.2). The second reason is that somecontent rightholders require a unicast session to identify uniquely auser and establish billing this way. While the introduction of CDNsallowed to relieve core networks from the burden of multiple unicastflows from the origin server (owned by the CP) to the end viewer,multicast is the main technique able to relieve edge networks fromthe heavy strain of numerous live streaming unicast flows sent outfrom the CDN servers to the edge.

By stepping into the OTT delivery market, ISPs and CDNs startentering the privileged group of actors receiving end-user subscrip-tion (The Telegraph, 2016). This shift in subscription revenue targetsuddenly renders IP multicast profitable to these actors: Telcos andCDNs are interested in increasing the number of end-users payingand being reached with high-quality streams at lower infrastructurecosts, rather than being paid by the providers based only on the costincurred on their infrastructure (Streaming Media, 2016). Multicastbeing forecast as a key-enabler of large-scale live OTT distributionyields another dilemma for the business model: (i) either the telcothat has invested in a multicast infrastructure comes into the TVprovider market by offering a unified user experience: This is the caseof ISPs BT and TalkTalk partnering with the British BroadcastingCorporation (BBC) and other channels within the YouView serviceplatform (The Telegraph, 2016), or (ii) the telco’s multicast capabilitiesare leveraged (Broadpeak, 2016; Akamai, 2016; Bumgardner, 2015)and the telco can also rent its multicast spectrum to CPs or CDNs.This is a first element revealing an indisputable convergence oflarge-scale OTT systems towards IPTV’s founding principles.

The IP multicast momentum for broadcast-quality video is sup-ported by the unicast/multicast hybrid solutions based on automaticmulticast without explicit tunnels (AMT) (Octoshape, 2012; Bum-gardner, 2015). AMT has been introduced by Cisco and Octoshapecompanies. As an indicator of the expected weight of IP multicastinto future unified streaming systems, Octoshape has been acquiredby Akamai in early 2015. A few months later, Akamai has rolledout its infinite edge solution on February 2016, embracing AMTand has revealed to intensely negotiate with ISPs to get access totheir multicasting resources (Akamai, 2016). AMT is described in

Page 341: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 327

Content provider

Multicast-enabled ISP

Unicast-only

local provider

Multicast-enabled

local provider

Figure 12.5 Even though CP and core network are multicast-enabled, many edgenetworks remain unicast-only, as the one on the bottom left. Multicast in theglobal Internet is an all-or-nothing solution: If at least one network of the path isnot multicast-enabled, a unicast connection is used end-to-end.

more detail in the next paragraph. A more blunt example of howmere public Internet resources are not sufficient for large-scale OTTdelivery (even for stored/non-live VoD) is the recent deal betweenthe OTT giant Netflix and ISPs Comcast and Verizon to lay ‘datahighways’ (Time, 2014).

The principle of AMT is to perform unicast aggregation as muchas possible, thereby getting back the gains of multicast whereverpossible in the different network segments between the video serversand the clients. Figures 12.5 and 12.6 represent the AMT principle.The AMT architecture is composed of the so-called AMT gatewaysand AMT relays (Octoshape, 2012). An AMT gateway may be a homerouter or a host (STB, gaming console, PC and so on), and mustcontact an AMT relay to initiate the multicast connection. AMTrelays are usually routers at the multicast/unicast boundaries. AMTis a hybrid solution in that it allows to reach any client, multicast- andnon-multicast-enabled alike, while leveraging multicast capabilitieswherever available on the end-to-end path and resorting to unicaston the minimum number of links, instead of falling back into unicaston the whole path between the server and the client if the latter isnot multicast-enabled. The Broadpeak solution NanoCDN allowingfor multicast ABR (M-ABR) builds on a similar principle with theso-called Broadpeak agents in the client premises.

Page 342: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

328 IPTV Delivery Networks

Content provider

Multicast-enabled ISP

AMT

relay

Unicast-only

local provider

Multicast-enabled

local provider

AMT

gateway

Figure 12.6 The negotiation between the AMT gateway and AMT relay enablesthe aggregation of the flows. The AMT relay replicates to downstream receivers,adding a unicast header.

A stark example of such advanced integration is the UK ISP aswell as telco BT, which has brought together the revenue modelsof a regular telco, a CDN and a CP. By setting up and taking partin a leading-edge consortium of telcos (BT and Talk Talk), solutionprovider (Arquiva) and broadcasters (TV channels ITV and Channel5), BT has been able to leverage on the common STB YouView and tobuild up its own in-network CDN. Each new customer or customer’sactivity (subscription upgrade) hence directly benefits BT that hassucceeded, thanks to smart technical choices and partnership, totruly leverage OTT streaming. BT thereby placed itself in the marketof an actual TV cable provider, with a wider offer and unified userexperience of a manifold of legacy broadcast and SVoD contentall brought together in one place (Streaming Media, 2016). Let usmention that cable ISPs such as Comcast (USA) and Virgin (UK), alsomake the move to IP multicast towards their subscriber by investingin an architecture upgrade to DOCSIS, the new cable interfacespecification.

The second heavily explored trail is in-home proactive caching forVoD content. To overcome the decrease in resource availability (dueto volatile events such as flash-crowds) and to spread the load overtime better, pre-positioning content in off-peak hours directly intothe customer’s equipment is closely investigated. This is envisionedfor content expected to be watched with a high probability, suchas subsequent episodes of a series the user has been watching, or

Page 343: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 329

premiers and trailers. Akamai has disclosed to have pre-positioningunder the radar (Munford, 2016). A first proof-of-concept had beenpresented at CES 2014 based on Qualcomm IPQ home gateway andAkamai’s client software allowing pre-positioning of content. Theconcerns on right management and content access are however con-sidered carefully before deploying this kind of system. The NanoCDNsolution of the Broadpeak company leverages the home networkequipment’s storage capability to place such content during the night,additionally employing multicast to do so (Broadpeak, 2016).

The third main investigated avenue to leverage both the in-homecaching capabilities and the locality of content popularity (Leconteet al., 2016) is P2P assistance. Along multicasting and pre-positioning,Akamai envisions peer-assistance to CDN as the third lever insustaining a large-scale broadcast-like delivery of IP streaming, all themore with WebRTC-enabled interoperability, strongly supported byGoogle or Apple (WebRTC project, 2016). A large-scale simulationstudy involving a few million users has been carried out in 2015 bythe BBC and BT (Karamshuk et al., 2015). The start-up Streamroothas been recently awarded in this same realm (Streamroot, 2016).The principle, challenges and preliminary results are detailed inSection 12.4.1.

12.3.3 Coordinating the OTT delivery entities to enforceIPTV-like quality of experience: Collaboration between ISPs,CDNs and CPs

Extending and migrating IPTV services to OTT distribution for thereasons exposed in Section 12.3.1, is conditioned on the ability of OTTto render sufficient quality and reliability, ensuring user/subscriberretention. Video quality is assessed through the user-perceived expe-rience, with the so-called quality of experience (QoE). Despite theintrinsic subjectivity of such experience, the multimedia communityhas agreed on three most important metrics for ABR video, as definedin Dobrian et al. (2011, Section 2.3 therein): The stalls (number andduration), the average bit rate and the instability.

The resulting OTT delivery systems are growing more and morecomplex owing to the decisions made at the different stakeholders:CP, CDN, crossed ISPs and client platform. So far, there is little coor-dination between these different factors in the decision-making. Thedecisions taken at one level are mostly uninformed about the state of

Page 344: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

330 IPTV Delivery Networks

the other level. The very meaning of ‘OTT’ reflects this state of affairs.Specifically, application providers have devised complex workaroundsand try to infer, from the clients’ feedback, their own statistics abouttheir CDNs and ISPs network states and the features of the clients con-nected to each ISP. In addition, the client-side attempts to predict thenetwork state without explicit network feedback. The ISP network hasin turn no lever as to how to bend the decisions taken by the cloudsystem or by the distributed video rate decisions at the edge applica-tions. That is why many solutions enabling explicit collaboration areemerging at different standardisation bodies (MPEG DASH-SAND,IETF RTCWeb, RMCAT working groups) and new solutions aim atmoving the control entirely to a centralised entity (Ganjam et al., 2015;Georgopoulos et al., 2013). In particular, new control planes’ capa-bilities for ISPs, such as software-defined networking (SDN) coupledwith network function virtualisation (NFV), along with the emergenceof ‘big data’ platforms, are seen as further enablers of a comprehen-sive cooperation. Such cooperation aims at supporting high-quality,reliable and massive video delivery, which would not correspond any-more to ‘OTT’ delivery, but to a truly converged unified and managedIP-video delivery.

Amongst the different group or individual proposals (e.g., Geor-gopoulos et al., 2013) for such fully cooperative delivery, we brieflydescribe a representative framework proposal, led, in particular, byDatabricks and Conviva companies in Jiang et al. (2014). Two entities,named application providers (AppPs) and infrastructure providers(InfPs) are distinguished. Each entity is made of different subsystems,for example, client and origin servers for AppPs, and CDNs and ISPsfor InfPs, though CDN may traditionally be envisioned pertaining tothe application overlay. The distinction may fade for major playerssuch as Google (YouTube) and Amazon. The architecture is madeof interfaces between AppPs and InfPs. AppPs can inform InfPsabout the client’s QoE at different time and space scale, with big dataanalytics and real-time processing to come up with meaningful andsynthetic information representation. InfPs in turn inform AppPsabout, for example, the level of congestion, the control decisions orits peering points.

If such an advanced cooperation is not yet effective, other solutionshalfway in this trend are being increasingly adopted. For example,Conviva Company offers solutions to content owners, broadcastersand operators to maximise their subscribers’ engagement through

Page 345: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 331

smart management of QoE. Their clients are major media companies,broadcasters, operators and video sites such as Vevo, ESPN, HBO, Sky,BT, France Televisions or Telefonica. One of their flagship solutions isan ‘Internet-scale control plane for video quality optimisation’ namedC3 (Ganjam et al., 2015). C3 is targeted to handle tens of millions ofclients, with tens to hundreds of thousands of arrivals per minute atpeak hours. The video requested are those from the aforementionedvideo providers who rent CDN hosting from CDN providers (such asLimelight, Akamai and so on). Given the CDN infrastructure rentedby the provider and the video quality measures it gets, the goal of thecentralised control plane is to select the CDN and the video bitrateto serve the viewing client with. The C3 controller does not controlthe CDN distribution logic (cluster and server choices), let aloneISPs, but rather adds a management layer on top of the availabledelivery ecosystem. A first challenge to get the quality data from theviewers is the heterogeneity of the clients’ devices. To not imposean overhaul to the client applications, a thin sensing/actuation layerexporting raw quality measures has been devised to be seamlesslyintegrated to existing apps. The second challenge is leveraging onthe mass of measures of quality available and their relative freshness.This is addressed by a split control plane. First a coarse-grained globalmodel layer builds on the stability (on the order of minutes) of theCDN ranking in video quality for each autonomous system where theviewers reside. A fine-grained per client decision layer then selectsthe video bitrate for the specific client based both on the formercoarse-grained (in time and space) statistics and on the individualup-to-date client state.

12.4 Technical focus

As discussed earlier, many tools are envisioned by the CPs, CDNs andISPs to scale up live and VoD streaming distribution while delivering abroadcast-like quality despite the uncertainty of the Internet. Thesetools are specifically IP multicast, peer-assistance to CDN delivery,caching and content pre-positioning.

In Section 12.4.1, we detail the recent studies and upcomingsolutions for legacy CPs and CDNs to leverage P2P assistance in VoDdistribution. We will bring up information-centric networking (ICN)in this regard.

Page 346: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

332 IPTV Delivery Networks

As video usage through mobile devices amplifies, the last trans-mission hop at the client-side is increasingly wireless, whether it bea cellular or a WiFi channel. Despite link-level retransmissions, it hasbeen shown that the wireless channel impacts hugely the quality ofexperience (QoE) perceived by the client. In particular, even in a WiFihome environment, which can be reckoned as static, the deploymentof multi-screen distribution beyond the STB wired to the wall, is stilla challenge. The second subsection deals with in-home video overWiFi challenges.

To finish, we will discuss the advent of 4K, multi-view experienceand virtual reality (VR), highly liable to render the current distri-bution inoperative, hence calling for a radical change of IP videodistribution infrastructure, supported by an achieved integration ofall technology elements mentioned earlier to truly bring about thenecessary overhaul.

12.4.1 P2P assistance to CDNs, caching and ICN

The principle of P2P assistance to CDN is depicted in Figure 12.7.While statistics (Sandvine, 2014) show that P2P file-sharing steadily

Content

provider

CDN

User

User

User

User

Figure 12.7 Principle of P2Passistance to CDN delivery.

Page 347: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 333

has been decreasing since 2010 owing to the surge of HTTP-basedcontent consumption (and sharing, see, e.g., the shutdown Megau-pload website), P2P has been under the radar of CDNs to improvetheir distribution efficiency. For example, the Akamai Netsessionapplication (Zhao et al., 2013) has been deployed worldwide tooffload traffic from the CDN servers. While other P2P-only or hybridP2P/CDN solutions have been deployed until 2014, they all showeddecreased gains when the user traffic was constrained within the sameISP, owing to the low participation or high churn rate (Balachandranet al., 2013). However, ISP friendliness, that is, keeping the P2Psharing between the users of the same ISP, may be deemed inevitableso as not to incur additional transit costs to their ISPs. Besides, (i)ISP friendliness, on-demand video streaming exhibits the followingfeatures that may hinder gains from P2P sharing assistance to CDN,(ii) as ABR is used, different video bit rates are requested by theuser, restricting the number of users that can serve a given one, (iii)the streaming concept imposes synchronicity of demands, whichshall not be the case with on-demand stored streaming or with DVRcommands (pause, fast forward and backward) and (iv) as for regularP2P systems, user participation is determining (e.g., in AkamaiNetsession, only 30% of users have enabled P2P participation [Zhaoet al., 2013]).

Remarking that the preponderant share of IP peak traffic corre-sponds to long-duration shows, Karamshuk et al. (2015) investigatedwhether such a feature can mitigate asynchronicity and low partic-ipation enough so that P2P can still bring gains to CDN in spite ofthe aforementioned constraints (i)–(iv). To do so, they have carriedout extended simulations on a one-month trace of 16 million BBCiPlayer (OTT show replay service) sessions from the greater Londonarea. Gains are quantified as the ratio between traffic served by peersand total consumed traffic. The important findings are that with ISPfriendliness enforced, only 10% of peers participating, and differentvideo bit rates available, the gains can still reach 80%. By looking at theimpact of users leaving the system before they quit viewing the video(which may happen if the user is able to download the whole contentin a shorter time than the video duration), the authors identifiedthat this can cause gains to drop from 80% to 30%. The ‘online whilewatching’ assumption is hence crucial to P2P assistance efficiency.Finally, having the peers to store the last five contents they have beenwatching increases the swarm capacity by a factor of 10.

Page 348: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

334 IPTV Delivery Networks

Very recently, Streamroot has proposed P2P assistance for live videostreaming (Streamroot, 2016), based on a P2P proprietary moduleand WebRTC for a seamless integration in existing HTML5 videoplayers.

The concept of P2P assistance for video streaming naturally relatesto the paradigm of ICN (Xylomenos et al., 2014), which is part of theresearch activities of the future Internet architecture community. ICNtrades the concept of host-based communication (where one IP clienttries to reach one specific IP server) for the concept of content-basedcommunication, where only the content name is requested to thenetwork, instead of an address. The network equipment has inherentcaching capabilities, allowing the storage of the content ideally closeto the user and the improvement and scaling of performance. A clientthen sends out interest messages, and when a router/cache holdingthe desired content receives such a message, it forwards the databack to the client following the forward path. By construction, ICNnatively supports in-network caching, (multi-source) multicast andmulti-path routing, making it very appealing to scale high-qualityvideo distribution. A recent Internet Research Task Force (IRTF)group has started designing pull-based dynamic adaptive streaming(DAS, no HAS as non-HTTP) in ICN (Lederer et al., 2015).

The performance of DAS in ICN has been investigated veryrecently by Rainer, Posch and Hellwagner (2016), for differentmessage-forwarding and video-quality adaptation strategies. In par-ticular, the authors considered H.264/SVC instead of H.264/MPEG-4AVC video coding (‘SVC’ stands for ‘scalable video coding’). WhileH.264/MPEG-4 AVC is the adopted coding in DASH and allowsto have independent representations of the content (each encodedat a different rate), H.264/SVC provides a layered representationwhere obtained quality is a function of the number of receivedlayers (coarse-grained to fine-grained information). SVC thereforeallows a client, which would have fetched a given quality of a videosegment and happens to experience a hike in its available bandwidth,to fetch additional layers to add them to the already obtained baselayer to improve the quality. The same situation with AVC wouldrequire discarding the first obtained representation to downloadthe higher quality packets. SVC has not been adopted in MPEGDASH (standardised with H.264/AVC), but is instead used by manyvideo conferencing tools provided by manufacturers such as Vidyo,Polycom or Radaya. The reason for SVC not to be used in stored VoD

Page 349: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 335

is its additional storage cost and processing complexity (outbalancedby its advantages for video conferencing). However, owing to the ICNfeature where a client may be served by different caches, Rainer, Poschand Hellwagner (2016) use SVC with MPEG-DASH to increase thehit ratio. Running simulations on different topologies and comparingwith optimal results considering unlimited multi-path routing orcaching, the conclusion is that the current sub-optimality of HTTPstreaming (based on IP) comes from the lack of multi-path support,and that current ICN solutions are still far from optimal wherecaching is available at each network component.

Complementarily, Yu et al. (2015) considered centralised control ofcaching (with SDN) to perform intelligent DASH/AVC representationpre-fetching based on the ISP’s network load to smooth out trafficpeaks that drive network-dimensioning and planning.

Although the aforementioned studies are examples that the ICNconcept is a promising solution to scale up high-quality flexible IPvideo delivery, they also show that the current solutions are highlyimmature and a lot of effort remains to be made. Relevant questionsinclude: (i) Which level of centralised control is realistic and beneficialin ICN? (ii) What kind of information ought to be shared betweennetwork entities and end points? (iii) How can one adapt to a client’sbandwidth variations when considering caching, pre-fetching andlimited transcoding resources? and (iv) How can one deal withfunction placement problems?

12.4.2 The Wireless Video Challenge: In-Home WiFiand Offloading of Cellular Networks

In-home WiFi is an essential component of daily video consumption,but high-quality video delivery over this medium remains challenging,as we shall see.

Outdoor WiFi is more marginal, but is foreseen to be a majorplayer in offloading and improving mobile networks. Data offloadingthrough WiFi is, in particular, included in the LTE architecture (ETSI,2016), though the main LTE/WiFi offloaded traffic share correspondsto delay-tolerant traffic (software updates, file sharing synchronisationand so on) postponed until the mobile device moves and gets a WiFiconnection (Lee et al., 2010). In the framework of heterogeneousnetworks (HetNets; Ericsson, 2011), which aim at bringing togethernetworks of different technologies (LTE, WiFi, Bluetooth and so on)

Page 350: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

336 IPTV Delivery Networks

and reach (macro-cells, femto-cells, pico-cells), new solutions arebeing proposed. For instance, Birdstep Technologies (2016) combinescellular and WiFi to target maximising coverage with the highestquality connection for the user, while managing operator costs.WiFi access points are often connected to hybrid fibre-coax overDOCSIS or ADSL (Free, 2016). An example of the latter is the caseof the French network operator Free where the WiFi APs pertain tothe mobile network operator itself. Indeed, Free is a major Frenchprovider of DSL (with WiFi routers) and mobile accesses. Partnershipsbetween cable and mobile operators may be envisioned, though ageneral framework for seamless integration between licensed andunlicensed spectrum access is still actively under study in the HetNetsand 5G framework (RCR Wireless News, 2015; Akhtar, Wang andHanzo, 2016).

Inside the home with a dedicated WiFi network, service providersare generally reluctant to guarantee video distribution beyond thecord-tethered STB. Indeed, it has been shown that, despite the largenominal bandwidth available and the seemingly static environment,construction characteristics and intermittent interference (e.g., seeKim et al. (2013), Figure 1 therein) can lead to jolting video incurringharsh user dissatisfaction blamed on the STB provider. Next, wemention the main solutions, likely to integrate upcoming systems, ifnot yet partially present.

First, some advanced flow scheduling can be performed at the WiFiaccess point, so as to give video flows the required priority, while notstarving the other flows and ensuring medium utilisation and fairness(avoiding the well-known head-of-line blocking problem). Second,as the self-organising network (SON) has been defined in the LTE(E-UTRAN) standard to smartly handle heavy network loads, one canenvision that a counterpart may be beneficial in home WiFi subjectedto heavy (4K and beyond) highly sensitive traffic and difficult networkconditions. SDN for indoor WiFi may play this role.

Many other proposals also build on the idea of adding forwarderror correction (FEC) coded packets to the initial transmissions,the rationale being that the residual loss rate at the transport layer(after layer-2 corrections), due to the last link being wireless, canoften be as high as 5% (Kim et al., 2013). For example, coded TCP(Kim et al., 2013) is designed to behave as legacy TCP on wired paths(reducing the source rate upon the detection of a loss attributed to abuffer drop), but allows to anticipate on wireless losses by sending the

Page 351: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 337

right amount of redundancy. Another set of the so-called streamingcodes (Karzand et al., 2015), currently under active development,aims at generating periodic redundancy within the video stream itself,allowing to lower the loss recovery delay even more.

Another established observation (Esteban et al., 2012) is thatthe TCP transport of video streams for VoD or RTC applicationsentails many problems (e.g., latency due to connection establishment,poor performance of unbundled connections – one connectionper webpage object with HTTP/1.1, packet loss due to sendingbursts). That is why UDP-based protocols have been devised tomore efficiently transport this kind of traffic. While UDP is used,congestion control (CC), otherwise enforced by TCP, is still needed.Amongst the numerous proposals under considerations at the IETFworking groups RTCWeb, RMCAT and TAPS, QUIC (Quick InternetUDP Connections, by Google) is gaining momentum and currentlysupports half of the communications between Google Chromeand Google servers (Iyengar and Swett, 2015). Other proposals forreal-time flows include, for example, Google CC or network-assisteddynamic adaptation (NADA) CC algorithm (Lundin et al., 2013) thatbuilds on RTP and RTCP signalling to let the source compute moreprecisely the rate it can use, unlike legacy TCP that only allows itto infer the network state of congestion by packet loss detection. Inparticular, QUIC tailors Cubic CC in addition to integrating the keyingredients of HTTP/2.0 such as connections bundling into streams(TCP Cubic is the legacy TCP deployed in Linux, used by more than65% of the servers in the Internet [Yang et al., 2014]). Furthermore,QUIC enables acknowledgement disambiguation by its own sequencenumbering, as well as FEC to retrieve from packet losses withouthaving the receiver necessarily ask for retransmission.

12.4.3 VR: The greatest technological challenge ahead?

While the aforementioned solutions either start appearing for Internetvideo/television delivery, or are likely to appear in the upcoming years,a tremendous revolution in the user’s experience lies ahead: VR. Early2016, many major events have meaningfully focused on VR: CES 2016and Google I/O 2016 were announced to be milestones in the still earlyoutset of VR.

As an intermediate step between legacy video experience (with flator 3D images, small definition or 4K) and VR, we can mention the

Page 352: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

338 IPTV Delivery Networks

so-called interactive broadcast experience, which provides the userwith the possibility of deciding from which camera he wants to viewthe show/event. Recently, free-viewpoint television (FTV) (Chen, Gaoand Nahrstedt, 2016) has been proposed as an immersive experiencewhere the user can decide an arbitrary viewpoint by having differentcamera streams combined at the player. In particular, the networkchallenges of doing so for live delivery and sizeable audience areinvestigated in Chen, Gao and Nahrstedt (2016).

Some systems currently available early 2016 are tagged ‘VR’. Forexample, Oculus Rift and HTC Vive headsets render 4K/360∘ videocapturing, and possibly in 3D. Such headsets require consequentcomputational power to do so (CNET, 2016). Google provides a merecardboard box to slide a smartphone in and watch a 360∘ flat video aninch away from the eyes with magnifying lenses. There is much debateas to whether this kind of low-cost VR should actually be pegged asVR (Cisco Newsroom, 2016).

The very sense of VR indeed refers to making the content appearas reality to the human user. A precise definition of what we, ashumans, perceive as ‘reality’ is hence necessary to assess whether thesystem truly provides VR. In 2016, Begole (2016), a researcher fromHuawei, conducted a detailed analysis on the human senses that areinvolved in VR. Begole found that not only the visual sense involved,however all the other senses. This includes the hearing sense, whichwe already know to remotely stimulate as the eye (Begole, 2016).Taking into account our fovea’s dot detection capability, the fieldof view and the eye’s shift speed, Begole comes up with a bit rateof 5.2 Gbps (considering best current codec H.265 HEVC). Even a100-times-lower bit rate would be unsustainable by most broadbandaccesses, as defined by the US FCC at 25 Mbps (and storage may bean issue too). VR hence poses tremendous and daunting challenges todelivery through network, and these challenges are open avenues formost innovative research.

References

9 to 5 mac (2016). ESPN President Says Apple ‘Frustrated’ Over BuildingTV Service, Expects New Packages in 2016. [online] Available at:http://tinyurl.com/hddneg3 (accessed 20 June 2016).

Page 353: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 339

Akamai press release 1 (2012). Akamai and AT&T Forge Global StrategicAlliance to Provide Content Delivery Network Solutions. [online]Available at: http://tinyurl.com/goort83 (accessed 20 June 2016).

Akamai press release 1 (2013). KT and Akamai Expand StrategicPartnership. [online] Available at: http://tinyurl.com/zlozpeb(accessed 20 June 2016).

Akamai press release 2 (2012). Orange and Akamai form ContentDelivery Strategic Alliance. [online] Available at: http://tinyurl.com/z6j3uh6 (accessed 20 June 2016).

Akamai press release 2 (2013). Swisscom and Akamai Enter into aStrategic Partnership. [online] Available at: http://tinyurl.com/h7bt5m8 (accessed 20 June 2016).

Akamai (2016). Infinite Edge Solution. [online] Available at: http://tinyurl.com/jpuunr9 (accessed 20 June 2016).

Akhtar, A.M., Wang, X. and Hanzo, L. (2016). Synergistic spectrumsharing in 5G HetNets: A harmonized SDN-enabled approach. IEEECommunications Magazine, 54(1), 40–47.

Balachandran, A., Sekar, V., Akella, A. and Seshan, S. (2013). Analyzingthe Potential Benefits of CDN Augmentation Strategies for InternetVideo Workloads. Proceedings of ACM Internet MeasurementConference (IMC), Barcelona, Spain, pp. 43–56.

Begole, B. (2016). Why the Internet Pipes Will Burst When Virtual RealityTakes Off . Forbes. [online] Available at: http://tinyurl.com/zhvbdjm(accessed 20 June 2016).

BGR (2015). Cable Providers Still Have No Answer for Netflix asCord-Cutting Accelerates. [online] Available at: http://tinyurl.com/hg2h6fq (accessed on 20 June 2016).

Birdstep Technologies (2016). Product solutions. [online] Available at:www.smithmicro.com (accessed 20 June 2016).

Bridge Technologies (2015). Bridging with a Virtual Probe for CoreNetworks. [online] Available at: http://tinyurl.com/zxyjojz (accessed20 June 2016).

Broadpeak (2016). NanoCDN Multicast ABR. [online] Available at:http://tinyurl.com/j4hfbv2 (accessed 20 June 2016).

Bumgardner, G. (2015). Automatic Multicast Tunneling. IETF draft.Chen, S., Gao, Z. and Nahrstedt, K. (2016). F. Live: Towards Interactive

Live Broadcast FTV Experience. Proceedings of IEEE Conference onComputer Communications (INFOCOM), San Francisco, CA, USA.

Page 354: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

340 IPTV Delivery Networks

Cisco Newsroom (2016). Coming to a Headset Near You: The VirtualReality Revolution. [online] Available at: http://tinyurl.com/jjkfvut(accessed 20 June 2016).

CNET (2016). Everyone Wanted a Piece of Virtual Reality at this Year’sCES. [online] Available at: http://tinyurl.com/j8ls34g (accessed 20 June2016).

CSI Magazine (2015). New Building Blocks: Is OTT the Future of IPTV?(Sony to trial DVB-T2 to mobile in Asia). [online] Available at: http://tinyurl.com/jxkhryf (accessed 20 June 2016).

Dobrian, F., Sekar, V., Awan, A., Stoica, I., Joseph, D., Ganjam, A., Zhan,J. and Zhang, H. (2011). Understanding the impact of video quality onuser engagement. SIGCOMM Computer Communication, 41(4),362–373.

Elemental Technologies (2016). Product Solutions. [online] Available at:www.elementaltechnologies.com (accessed 20 June 2016).

Ericsson (2011). Heterogeneous Networks (HetNet). White paper.Esteban, J., Benno, S.A., Beck, A., Guo, Y., Hilt, V. and Rimac, I. (2012).

Interactions Between HTTP Adaptive Streaming and TCP.Proceedings of the ACM conference on Network and OperatingSystem Support for Digital Audio and Video (NOSSDAV), Toronto,ON, Canada, pp. 21–26.

ETSI (2016). Digital Cellular Telecommunications System (Phase 2+).Technical Report [online] Available at: http://tinyurl.com/hrtfmh4(accessed 20 June 2016).

Free (2016). Réseau communautaire FreeWiFi_Secure – EAP-SIM.[online] Available at: http://tinyurl.com/hrer8jj (accessed 20 June2016).

Ganjam, A., Siddiqui, F., Zhan, J., Liu, X., Stoica, I., Jiang, J., Sekar, V. andZhang, H. (2015). C3: Internet-Scale Control Plane for Video QualityOptimization. Proceedings of USENIX NSDI, Oakland, CA, USA, pp.131–144.

Georgopoulos, P., Elkhatib Y., Broadbent, M., Mu, M. and Race, N.(2013). Towards Network-Wide QoE Fairness UsingOpenflow-Assisted Adaptive Video Streaming. Proceedings of ACMSIGCOMM Conference, Hong Kong, China, pp. 15–20.

Huffington Post (2014). Broadcast TV Dead By 2030, Netflix CEO ReedHastings Says. [online] Available at: http://tinyurl.com/gn7v4nr(accessed 20 June 2016).

Page 355: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 341

IPTV News (2014). What Does the Future Hold for IPTV? (Lessonslearned from Aereo). [online] Available at: http://tinyurl.com/zg8a834(accessed on 20 June 2016).

IPTV News (2015). 9/10 Demand Single App Experience for TV. [online]Available at: http://tinyurl.com/zvw5bv3 (accessed on 20 June 2016).

IPTV News (2016). 81% of US households Have DVR, Netflix, or VOD.[online] Available at: http://tinyurl.com/h9odze4 (accessed on 20 June2016).

ISO/IEC DIS 23009-1 (2012). Dynamic Adaptive Streaming Over HTTP(DASH).

Iyengar, J. and Swett, I. (2015). Quic: A UDP-Based Secure and ReliableTransport for HTTP/2. IETF draft.

Jiang, J., Liu, X., Sekar, V., Stoica, I. and Zhang, H. (2014). EONA:Experience-Oriented Network Architecture. Proceedings of the 13thACM Workshop on Hot Topics in Networks (HotNets-XIII), LosAngeles, CA, USA.

Karamshuk, D., Sastry, N., Secker, A., and Chandaria, J. (2015, April).ISP-Friendly Peer-Assisted On-Demand Streaming of Long DurationContent in BBC iPlayer. In IEEE Conference on ComputerCommunications (INFOCOM), IEEE, pp. 289–297.

Karzand, M., Leith, D.J., Cloud, J. and Médard, M. (2015). Low DelayRandom Linear Coding Over a Stream. Arxiv Preprint. Availablethrough: http://arxiv.org/abs/1509.00167 (accessed 20 June 2016).

Kim, M., Cloud, J., ParandehGheibi, A., Urbina, L., Fouli, K., Leith, D.and Medard, M. (2013). Network Coded TCP (CTCP). Arxiv Preprint.Available through: http://arxiv.org/abs/1212.2291 (accessed 20 June2016).

Leconte, M., Paschos, G., Gkatzikis, L., Draief, M., Vassilaras, S. andChouvardas, S. (2016). Placing Dynamic Content in Caches with SmallPopulation. Proceedings of IEEE Conference on ComputerCommunications (INFOCOM), San Francisco, CA, USA.

Lederer, S., Posch, D., Timmerer, C., Westphal, C., Azgin, A., Liu, S.,Muller, C., Detti, A. and Corujo, C. (2015). Video Streaming OverICN. Internet Draft, ICNRG/IETF.

Lee, K., Lee, J., Yi, Y., Rhee, I. and Chong, S. (2010). Mobile DataOffloading: How Much Can WiFi Deliver? Proceedings of ACMInternational Conference on emerging Networking EXperiments andTechnologies (CoNEXT), Philadelphia, PA, USA, pp. 536–550.

Page 356: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

342 IPTV Delivery Networks

Lifehacker (2014). TV Streaming Head-to-Head: Netflix vs. Hulu vs.Amazon Prime. [online] Available at: http://tinyurl.com/jrw2egl(accessed 20 June 2016).

Lundin, H., Holmer, S. and Alvestrand, H. (2013). Google CongestionControl Algorithm for Real-Time Communication on the World WideWeb. IETF draft.

Macworld (2016). Apple TV Streaming Service Release Date Rumours:CBS CEO Says Talks with Apple Have Stopped. [online] Available at:http://tinyurl.com/ha3vh9c (accessed 20 June 2016).

Mintel (2015). Mintel Report. [online] Available at: http://tinyurl.com/z25gl8t (accessed 20 June 2016).

Munford, I. (2016). For the Win! Live Sports Are Driving Streaming VideoInnovation. [online] Available at: http://tinyurl.com/jkq959b (accessed20 June 2016).

Mware Solutions (2016). Product Solutions. [online] Available at: http://iptvmiddleware.com/ (accessed 20 June 2016).

Octoshape (2012). Automatic Multicast Without Tunnels. [online]Available at: http://tinyurl.com/z5vzhzo (accessed 20 June 2016).

Rainer, B., Posch, D. and Hellwagner, H. (2016). Investigating thePerformance of Pull-based Dynamic Adaptive Streaming in NDN.IEEE Journal on Selected in Area on Communications, 34(8),2130–2140.

RCR Wireless News (2015). Ericsson on 5G – HetNet Happenings:Episode 23. [online] Available at: http://tinyurl.com/hd5sfun (accessed20 June 2016).

Sandvine (2014). Global Internet Phenomena Report. 1st half 2014.Streaming Media (2016). The Return of Multicast: Why it Succeeds in a

Live Linear World. [online] Available at: http://tinyurl.com/ze47ssw(accessed 20 June 2016).

Streamroot (2016). Product solutions. [online] Available at: www.streamroot.io (accessed 20 June 2016).

Strategy Analytics (2015). Chromecast Leads Global Digital MediaStreamer Market for Fifth Straight Quarter.[online] Available at:http://tinyurl.com/z7srjlb (accessed on 20 June 2016).

The Telegraph (2016). BT Explores Deal with TalkTalk for Full Control ofTV Tech. [online] Available at: http://tinyurl.com/zyvqwg7 (accessed20 June 2016.

Time (2014). Netflix’s Disputes with Verizon, Comcast UnderInvestigation. [online] Available at: http://tinyurl.com/h7tbez3(accessed 20 June 2016).

Page 357: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Technologies and Architectures for Future IP Television Services 343

Verimatrix (2016). Product Solutions. [online] Available at: www.verimatrix.com (accessed 20 June 2016).

WebRTC project (2016). WebRTC. [online] Available at: https://webrtc.org/ (accessed 20 June 2016).

Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., Tsilopoulos, C.,Vasilakos, X., Katsaros, K. and. Polyzos, G. (2014). A survey ofinformation-centric networking research. IEEE CommunicationsSurveys and Tutorials, 16 (2), 1024–1049.

Yang, P., Luo, W., Xu, L., Deogun, J. and Lu, Y. (2014). TCP congestionavoidance algorithm identification. IEEE/ACM Transactions onNetworking, 22 (4), 1311–1324.

Yin, X., Jindal, A., Sekar, V. and Sinopoli, B. (2015). A Control-TheoreticApproach for Dynamic Adaptive Video Streaming over HTTP.Proceedings of ACM SIGCOMM Conference, London, UK, pp.325–338.

Yu, Y., Bronzino, F., Fan, R., Westphal, C. and Gerla, M. (2015).Congestion-Aware Edge Caching for Adaptive Video Streaming inInformation-Centric Networks. Proceedings of IEEE ConsumerCommunications & Networking Conference (CCNC), Las Vegas, NV,USA, pp. 588–596.

Zhao, M., Aditya, P., Chen, A., Lin Y., Haeberlen, A., Druschel, P., Maggs,B., Wishon, B. and Ponec, M. (2013). Peer-Assisted ContentDistribution in Akamai Netsession. Proceedings of ACM InternetMeasurement Conference (IMC), Barcelona, Spain, pp. 31–42.

Page 358: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

345

Contributor Biographies

Alireza Abdollahpouri is assistant professor of computer networksat the Department of Computer and IT Engineering, Universityof Kurdistan, Sanandaj, Iran. He has obtained a PhD (computernetworks) in 2012 from the University of Hamburg, Germany. Hereceived a BS in computer engineering from Isfahan University ofTechnology, Iran, and a master’s degree from Amirkabir Universityof Technology, Tehran, Iran. He worked as system programmer atTelecommunication Company of Tehran from 2001 until 2005. Hejoined the University of Kurdistan, Iraq, as a faculty member in 2005.His main research interests are in the fields such as IPTV over wirelessnetworks, performance evaluation and modelling network systems.

Mohiuddin Ahmed is a PhD candidate at the University of NewSouth Wales, Canberra, Australia. His areas of research interest andstudy include big data mining, machine learning and network security.He has been working to develop efficient and accurate anomaly detec-tion techniques for network traffic analysis to handle emerging bigdata problems. He has made practical and theoretical contributionstowards data summarisation for network traffic analysis. His researchhas a high impact on critical infrastructure protection (SCADAsystems, smart grid), information security against DoS attacks andcomplicated health data (heart disease, nutrition) analysis. He haspublished many papers in journals and presented at many reputedcomputer science conferences. Mohiuddin holds a BS in computerscience and information technology with high distinction from theIslamic University of Technology, OIC, Dhaka, Bangladesh.

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 359: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

346 Contributor Biographies

Saiful Azad received his PhD in information engineering from theUniversity of Padova, Italy, in 2013. He completed his graduationfrom the Islamic University of Technology, Dhaka, Bangladesh, incomputer and information technology, and postgraduation fromthe International Islamic University Malaysia (IIUM), Malaysia, incomputer and information engineering. After completing his doc-torate, he joined the Department of Computer Science at AmericanInternational University – Bangladesh (AIUB) as faculty member.He is currently with the Faculty of Computer Systems and SoftwareEngineering at the University Malaysia Pahang (UMP), Malaysia. Hestarted working on underwater acoustic networks during his doctoralresearch, and it still remains his focus of study. His research interestsalso include designing and implementing communication protocolsfor any network architecture, quality-of-service (QoS) issues, networksecurity and simulator design. He is one of the developers of thedesign, simulate, emulate and realise test-beds (DESERT) underwatersimulator. He is also the author of many scientific papers publishedin renowned international peer-reviewed journals and conferences.He is an editor/author of the 2014 book Practical Cryptography:Algorithms and Implementations using C++ (CRC Press, USA). Healso serves as reviewer and technical programme committee memberof many renowned peer-reviewed journals and conferences.

Gergely Biczók is assistant professor at Budapest University ofTechnology of Economics, where he received his PhD in computerscience in 2010. Previously, he was a postdoctoral research scholarat the Norwegian University of Science and Technology, a Fulbrightscholar at Northwestern University and a research fellow at EricssonResearch. His research interests centre around the economics ofnetworked systems.

Pedro Comesaña received a telecommunications engineering degree(with specialisations in both computer science and communications)from the University of Vigo, Spain, in 2002, and a PhD in telecom-munications engineering from the same university in 2006. He alsograduated in mathematics from the Universidad Nacional de Edu-cación a Distancia, Spain, in 2010. His PhD thesis was recognised bythe Spanish Official Institute of Telecommunications Engineers as thebest PhD thesis in security and defence in 2006. Pedro has been asso-ciate professor at the Signal Theory and Communications Department

Page 360: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contributor Biographies 347

of the University of Vigo since 2012. He conducted research stays atthe Technische Universiteit Eindhoven, the Netherlands, for 6 monthsin 2004; at the University College Dublin, Ireland, for 6 months in2006; at the Università degli Studi de Siena, Italy, for 10 months in2007 and 2008; at the University of New Mexico, USA, for 12 monthsin 2010 and 2011, sponsored by the Prince of Asturias Endowed Chair;and at the State University of New York at Binghamton, USA, for 4months in 2015. He has co-authored more than 50 papers publishedin international journals and conference proceedings, and holds atriadic patent on the field of video-surveillance authentication. Hereceived the Best Paper Award of the IEEE Workshop on InformationForensics and Security (IEEE-WIFS) in 2014, and the Best PaperAward of the International Workshop on Digital-Forensics andWatermarking (IWDW) in 2011. From November 2012 to December2015, Pedro was a member of the IEEE SPS Information Forensics andSecurity-Technical Committee (IEEE IFS-TC). He serves as a memberof the IEEE SPS Student Services Committee and as associate editor ofthe IEEE Transactions on Circuits and Systems for Video Technology,IEEE Signal Processing Letters and IET Information Security. He wastechnical co-chair of ACM IH&MMSEC 2015, area chair of IEEEICIP 2015 and tutorials chair of IEEE WIFS 2012. He is currentlythe publication chair of IH&MMSEC 2016. Pedro participated inthe FP6 ECRYPT European NoE and in the FP7 European ProjectsREWIND and NIFTY; he was also the principal investigator of severalregional projects in multimedia security and has signed 14 innovationprojects. His main research interests comprise multimedia security,multimedia forensics, watermarking and data hiding, statistical signalprocessing and digital communications.

Luis M. Contreras completed a 6-year telecom engineering degree atthe Universidad Politécnica of Madrid in 1997, and received a master’sdegree in Telematics from the Universidad Carlos III of Madrid in2010. In 1997, he joined Alcatel Spain, taking several positions in R&D,standardisation, product development and customer engineering inboth wireless and fixed network fields. In 2006, he joined the NetworkPlanning department of Orange Spain (France Télécom group), takingresponsibilities on the IP backbone and Packet Switched MobileCore (SGSN, GGSN) planning, and as Internet peering technicalmanager. Between 2002 and 2010, he was also adjunct lecturer atthe Telematics Department of the Universidad Carlos III, where he

Page 361: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

348 Contributor Biographies

is currently a PhD student. Since August 2011, he has been a part ofTelefónica I+D/Telefónica Global CTO, working on SDN, transportnetworks and their interactions with cloud and distributed services aswell as interconnected topics. He has also been active in research andinnovation activities, participating in the EU FP7 projects GEYSERSand XIFI; the EU H2020 projects 5G-Crosshaul and 5GEx; and theESA-funded project CloudSat. In July 2012, he co-organised theInternational Workshop on Cross-Stratum Optimisation for CloudComputing and Distributed Networked Applications, co-located withthe 10th IEEE International Symposium on Parallel and DistributedProcessing with Applications (ISPA2012), in Leganés, Spain. He hasbeen an active contributor to the IETF (authoring two RFCs), ETSIand ONF, where he has organised and coordinated the first-everproof-of-concept on the application of SDN to microwave networks,held in October 2015.

Subhrajyoti Deb completed his graduation and postgraduation incomputer applications from the Department of Information Tech-nology, Tripura University, Suryamaninagar, India. He received hismaster’s degree in technology from the Department of ComputerScience and Engineering, National Institute of Technology, Agartala,India. He is currently working as a junior research fellow (JRF)at the Department of Computer Science and Engineering, TripuraUniversity. His areas of research include wireless mesh network, IPTVand network security.

Manos Dramitinos is a researcher in the Department of Informat-ics at Athens University of Economics and Business. He completedhis doctoral research at AUEB in 2006 and his postdoctoral researchat INRIA Rhône-Alpes, RESO Team, in Lyon in 2009. His researchinterests include network economics and traffic management, mobilenetworks, large-scale information systems, auction theory, networkinterconnection and regulation. He has published many papers in sci-entific journals and conferences and has received multiple awards suchas the ICQT’06 best student paper award. He is the author of the bookAuction Theory for Telecoms (Nova Science, UK).

Suliman Mohamed Fati received his PhD in computer science fromthe Universiti Sains Malaysia (USM), Malaysia, in 2014. He completedhis graduation from Ain Shams University and postgraduation fromCairo University in Egypt. After completing his PhD, he joined as

Page 362: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contributor Biographies 349

assistant professor in the Faculty of Information and CommunicationTechnology, Universiti Tunku Abdul Rahman (UTAR), Malaysia. He iscurrently working as senior lecturer (assistant professor) in the Facultyof Information Technology and Sciences (FITS), INTI InternationalUniversity, Malaysia. His doctoral research focus was on optimisingIPTV delivery networks. His current research interests include mul-timedia applications, content distribution networks, optimisation,cloud computing and the Internet of Things. He has authored manypapers in international conferences and peer-reviewed journals. Healso serves as a reviewer for a couple of renowned peer-reviewedjournals and conferences. He is a member of IEEE, ICIT and IAENG.

Niaz-Ul Haque is working in the field on IPTV technology and videoprocessing as a media room software professional with Ericsson,Canada. Niaz has been involved with next generation of TV platformtechnology. He received his master’s degree in electrical and computerengineering from the University of Western Ontario, Canada, in 2011.He also worked with Emirates Integrated Telecommunications Com-pany as an IPTV engineer before moving to Canada for a postgraduatedegree. He holds a graduate degree in electrical and electronic engi-neering from the Islamic University of Technology, OIC, Dhaka,Bangladesh.

Seongik Hong received a PhD in computer science from North Car-olina State University, Raleigh, North Carolina, USA, in 2010. From1998 to 2005, he was a Member of Technical Staff with the Telecom-munications and Operations Support Laboratory, Korea Telecom(KT), Seongnam, Korea. From 2010 to 2015, he worked in the areas ofcontent-centric networking and content delivery networks as principalresearcher at the Samsung Advanced Institute of Technology (SAIT),Samsung Electronics, Yongin, Korea. Currently, he works for AmazonWeb Services in Cambridge, Massachusetts, USA. His researchinterests include content delivery networks and cloud systems.

I-Shyan Hwang received a BS in electrical engineering in 1982 andan MS in electronic engineering in 1984 from Chung-Yuan ChristianUniversity, Chung-Li, Taiwan, and an MS in 1991 and a PhD in 1994in electrical and computer engineering from the State University ofNew York at Buffalo, New York, USA. In February 2007, he was pro-moted to full professor in the Department of Computer Science andEngineering at the Yuan Ze University, Chung-Li, Taiwan. His current

Page 363: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

350 Contributor Biographies

research interests comprise high-speed networks, fixed mobileconvergence, heterogeneous multimedia services over fibre opticnetworks, NGN, optical-network-based infrastructure over cloudcomputing and SDN. He serves as a member of the editorial boardfor Springer’s Photonic Network Communications Journal.

Nazrul Kabir received his bachelor’s degree in 2015 from theDepartment of Computer Science and Engineering at AmericanInternational University-Bangladesh, in Dhaka, Bangladesh. Hisresearch interests include usable security, near-field communications,human–computer interactions, data management systems, and Inter-net and web technologies.

Andrew Tanny Liem received a BS in 2003 from the Departmentof Computer Science, Adventist University of Indonesia, Bandung,Indonesia, and an MS in 2006. He received a PhD in ComputerScience and Engineering from Yuan Ze University, Taiwan, in 2014.He is currently with the Department of Computer Science at KlabatUniversity, Manado, Indonesia. His recent focus has been on NGNand P2P over EPON.

Håkon Lønsethagen is senior adviser at Telenor Research. Hereceived a BS in 1987 in electrical engineering and computer sciencefrom the University of Colorado, Boulder, Colorado, USA. He wasgranted an MS from the Norwegian Institute of Technology in1988. Since 1990, he has been working with telecom network andservice management and control, including systems integration anddistributed systems frameworks, architectures and middleware. Since2000, his research activities have been related to network control andmanagement of packet-based networks and intelligent optical net-works, including techno-economic analysis. Over the past years, hisfocus has been on inter-NSP network services and business models,most recently including SDN, NFV and 5G ecosystem analysis. He hasparticipated in several EU projects, often as WP or task leader. He hasmade several contributions to the TM Forum, and has been an advi-sory board member of EU research projects NEAT and SmartenIT.

Abhishek Majumder received a bachelor’s degree in computerscience and engineering in 2006 from the National Institute of Tech-nology, Agartala, Tripura, India, and a master’s degree in informationtechnology in 2008 from Tezpur University, Assam, India. He is

Page 364: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contributor Biographies 351

currently pursuing a PhD with the Department of Computer Scienceand Engineering, Assam University, Silchar, Assam, India. He worksas assistant professor in the Department of Computer Science andEngineering, Tripura University, in Suryamaninagar, Tripura, India.He is a member of IEEE and associate member of the Institution ofEngineers India (IEI). His areas of interest include wireless ad hocnetworks, wireless mesh networks, IPTV and cloud computing.

Miguel Masciopinto received a master’s degree in telecommu-nication engineering in 2013 from the University of Vigo, Vigo,Spain, where he is currently working with the Signal Processing inCommunications Group (GPSC) as a research engineer. His researchinterests lie in the fields of multimedia forensics and security.

Marie-José Montpetit is a senior member of IEEE. She received aPhD in electrical engineering and computer science in 1991 fromEcole Polytechnique of Montreal, Montreal, QC, Canada. She is aresearch scientist in the Research Laboratory of Electronics, Mas-sachusetts Institute of Technology, Cambridge, Massachusetts, USA,focused on network coding for video transmission. Her researchinterests include converged video applications, social and multiscreenmedia dissemination and wireless networks. She was a recipient ofthe MIT Technology Review TR10 in 2010.

AliAkbar Nikoukar received a BS in mathematics and an MS in com-puter science from Johns Hopkins University, India. He received a PhDin computer science and engineering from the Yuan Ze University, Tai-wan, in 2015. He is currently with the Department of Mathematicsat Yasouj University, Yasouj, Iran. His current research interests arehigh-speed networks, NGN, and multimedia services over fibre-opticnetworks.

N. Nourin Nisa received a bachelor’s degree in 2015 from the Depart-ment of Computer Science and Engineering at American InternationalUniversity-Bangladesh, in Dhaka, Bangladesh. Her research interestsmainly include network security, Internet of Things, wireless and sen-sor networks and near-field communication.

Fernando Pérez-González received his PhD in telecommunicationengineering from the University of Vigo, Spain, in 1993. Since 2000,he has been professor at the Signal Theory and Communications

Page 365: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

352 Contributor Biographies

Department, University of Vigo, where he leads the signal processingand communications group (GPSC). From 2007 to 2014, he was thefounding executive director of the Galician Research and Develop-ment Center in Advanced Telecommunications (GRADIANT), asemi-private research centre. From 2009 to 2012, he was the holderof the prestigious Prince of Asturias Endowed Chair on informationscience and technology at the University of New Mexico (UNM).His research interests include the crossroads of signal processing,security/privacy and communications, particularly those problems inwhich an adversary is present. Pérez-González has co-authored morethan 200 journal and conference papers, holds 15 international patentsand has participated in five European projects related to multimediasecurity. He has served on the editorial board of several internationaljournals, including IEEE Transactions on Information Forensics andSecurity and IEEE Signal Processing Letters. He is a member of theGalician Royal Academy of Sciences, and is an IEEE Fellow.

Akbar Ghaffarpour Rahbar received his bachelor’s degree in 1992in computer hardware and his master’s degree in 1995 in computerarchitecture, both from the Iran University of Science and Tech-nology, Tehran, Iran, and a PhD in 2006 in computer science fromthe University of Ottawa, Ottawa, Canada. He is currently professorat the Department of Electrical Engineering, Sahand Universityof Technology, Sahand New Town, Tabriz, Iran, where he is alsodirector of the Computer Networks Research Laboratory. Rahbar is asenior member of the IEEE. He is currently on the editorial board ofWiley’s Transactions on Emerging Telecommunications Technologiesjournal and the Journal of Convergence Information Technology. Heis editor-in-chief of the Journal of Nonlinear Systems in ElectricalEngineering. His current research interests include optical networks,optical packet switching, scheduling, PON, IPTV, network modelling,analysis and performance evaluation, the results of which can befound in over 110 technical papers.

Mohammed Mostafizur Rahman obtained his PhD in informa-tion engineering from the University of Padova, Italy, in 2011. Heis a mathematician, with a bachelor’s degree in mathematics anda master’s degree in applied mathematics from the University ofDhaka, Bangladesh. His research interests include algorithm optimi-sation and mathematical modelling of the neuromuscular junction.

Page 366: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contributor Biographies 353

He is currently assistant professor at American InternationalUniversity-Bangladesh, in Dhaka, Bangladesh.

M. S. A Noman Ranak is currently pursuing his master’s degreein computer science at the University Malaysia Pahang, Malaysia.He received his bachelor’s degree in 2015 from the American Inter-national University-Bangladesh, Dhaka, Bangladesh, after whichhe joined Dynamic Solution Innovators Ltd, Bangladesh, as juniorsoftware developer. He is currently working as software developerin the same company. His research interests include informationsecurity, human–computer interaction and software engineering.

Sudipta Roy received his master of computer applications degreefrom Birla Institute of Technology, Mesra, Jharkhand, India, and hismaster of technology degree in software engineering from JadavpurUniversity, Kolkata, West Bengal, India. He received a PhD from theDepartment of Information Technology, Assam University, Assam,India. He is currently professor at the Department of ComputerScience and Engineering, Assam University, Silchar, Assam, India,where he is also the Dean of the School of Technology. He is a seniormember of IEEE, member of the Institution of Engineers India (IEI)and member of the Computer Society of India (CSI). His areas ofinterests include wireless networks, IPTV, image processing andcloud computing.

B. M. F. Kamal Ruhee received a bachelor’s degree in 2015 fromthe Department of Computer Science and Engineering at Amer-ican International University-Bangladesh, Dhaka, Bangladesh.His current research interests include cloud computing security,human–computer interaction, big data, wireless and sensor systems.

Lucile Sassatelli has been an assistant professor at Université NiceSophia Antipolis, France, since 2009. She received an MSc in 2005from École Nationale Supérieure de l’Électronique et de ses Applica-tions, Cergy-Pontoise, France, and a PhD in 2008 in telecommunicationengineering from the University of Cergy-Pontoise, France. During2008–2009, she was postdoctoral fellow in the Reliable Communi-cations and Network Coding Group (RLE) at Massachusetts Insti-tute of Technology, Cambridge, Massachusetts, USA. Her researchactivities include network coding, disruption-tolerant networks andmobile social networks, video streaming and optimisation.

Page 367: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

354 Contributor Biographies

George D. Stamoulis is professor in the Department of Informaticsin Athens University of Economics and Business. He received hisdiploma in electrical engineering in 1987, with honours, from theNational Technical University of Athens, Greece, and an MS in1988 and a PhD in 1991 in electrical engineering from the Mas-sachusetts Institute of Technology, Cambridge, Massachusetts, USA.His research interests include economic and business models fornetworks in clouds and smart grids, Internet traffic management withemphasis on the use of economic mechanisms, demand response inenergy consumption, auction mechanisms for bandwidth and digitalgoods, telecommunications and power regulation, and reputationand recommendation mechanisms for electronic environments. Hehas published over 85 articles both in scientific journals such asIEEE/ACM Transactions on Networks, Telecommunications Systems,Computer Communications, IEEE Transactions on Communications,Journal of the ACM and IEEE Transactions on Information Theory,and in scientific conferences such as INFOCOM, ITC, ACM SIG-METRICS, GLOBECOM, ICQT, IFIP Networking, SmartGridComm,CloudNet and GP2PC. He has also collaborated with Greek RegulatoryAuthorities for Communications and Power on auction design.

Putra Sumari obtained a master’s degree in 1997 and a PhD in 2000from the University of Liverpool, UK. Currently, he is associate pro-fessor at the School of Computer Science, Universiti Sains Malaysia,Penang, Malaysia, where he is also the head of the MultimediaResearch Group. His research areas include the video-on-demandsystem, multimedia storage servers, MPEG standards, image/videocompression and retrieval and image cryptography. He has publishedmore than 70 papers in these areas.

Laszlo Toka is currently a postdoctoral researcher at the Hungar-ian Academy of Sciences, and works as assistant professor at theDepartment of Telecommunications at the Budapest University ofTechnology and Economics, Budapest, Hungary. He received hisPhD in 2011 from Télécom ParisTech, after which he worked atEricsson Research for 3 years before re-joining academia. His mainresearch topics include software-defined networking, data analyticsand economic modelling of distributed systems.

Seyyed Mohammad Hosseini Verki is currently a graduate studentin information technology engineering at Payame Noor University of

Page 368: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Contributor Biographies 355

Qazvin, Iran. His research interests include hardware cooling systems,PHP and IPTV.

Kamal Z. Zamli obtained a bachelor’s degree in electrical engineeringin 1992 from Worcester Polytechnic Institute, Massachusetts, USA.He then received a master’s degree in real-time software engineer-ing in 2000, from Universiti Teknologi, Malaysia, and a PhD in soft-ware engineering from the University of Newcastle upon Tyne, UK,in 2003. He has written nearly 350 papers in journals and conferencesworldwide, mainly in (combinatorial t-way) software testing as wellas search-based software engineering. He was the runner-up for theQ-Merit Award conferred by the Malaysian Software Testing Board(MSTB, 2011), based on his contribution to the field of software testingin Malaysia.

Sajjad Zare received a technician’s degree in computer software fromImam Khomeini International University, Qazvin, Iran, in 2006, anda BS in computer software engineering from Zanjan University, Zan-jan, Iran, in 2008. Zare received his MS in computer networks fromSahand University of Technology, Sahand New Town, Tabriz, Iran, in2010. At present, he is a lecturer with the information technology engi-neering group in Payame Noor University in Qazvin, Iran. His mainresearch interests are optical networks, scheduling, wireless networks,IPTV and VoIP.

Page 369: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

357

Index

aAccess network 66–70, 72, 77,

88, 90, 106, 133, 134, 173,174, 196, 197, 241

Access point 251, 252, 276, 336Anomaly detection 225, 227,

229, 230, 232, 233, 235, 242,243

Assured service quality (ASQ)297

Attacks of the IPTV deliverynetworks 222

bBig data 225, 227, 235, 237–241,

243, 330Broadcast-like delivery 329

cCaching 12, 18, 98, 131, 152, 192,

196, 197, 305, 323, 324, 328,329, 331, 332, 334, 335

Cellular networks 335Channel change 129, 131, 133,

137, 139–141, 147, 151,166, 167, 171, 172, 174, 175,178, 187–190, 197, 199

Channel zapping time 132, 133,135, 151, 155, 157–160,163, 164, 169, 172,175–178, 180

Classification 25, 27, 28, 33–39,41–60, 230, 232, 249, 250,301

Client-based methods 158, 177,178

Cloud 12, 198, 199, 293, 294,301, 303, 304, 311,321–323, 330, 348–351,353

Complex data 228, 229Content-based methods 163,

177, 178Content delivery network

(CDN)/contentdistribution network(CDN) 11, 323, 339

Content provider 9, 10, 15, 26,45

dDigital video broadcast-satellite

(DVB-S) 27, 29, 30, 32,33, 37–39, 46–48, 50–56,58, 59, 289

IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services,First Edition. Edited by Suliman Mohamed Fati, Saiful Azad, Al-Sakib Khan Pathan.© 2018 John Wiley & Sons Ltd. Published 2018 by John Wiley & Sons Ltd.

Page 370: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

358 Index

Digital video broadcast-terrestrial(DVB-T) 27, 29, 30, 33,37–39, 46–48, 50–54, 56,58, 59, 289

DVD 26, 27, 29–31, 33, 37–39,42, 43, 46–48, 50, 52, 53,56, 58–60

Dynamic adaptive streaming overHTTP (DASH) 193, 194,321, 330, 334, 335

eEthernet passive optical networks

(EPON) 65, 67, 69, 71–77,79, 81, 83, 85–91, 181, 350

Exchange 72, 130, 157, 213, 228,284, 287, 293, 298, 304, 305,307, 308, 310, 312, 314

f5th generation mobile networks

(5G) 68, 198, 283, 284,287, 294, 295, 297, 299, 300,302, 304–307, 309–311,336, 350

gGroup of pictures (GOP) 131,

164, 189

hHandoff 248, 253, 255, 258, 259,

266–269, 273–276, 280, 282Hierarchical heavy hitters (HHH)

230, 231High definition IPTV 185, 187,

189, 191, 193, 195, 197, 199,201

High performance architecture194

iI-frame 130–132, 135, 143, 144,

157, 163–166, 169,172–175, 179, 190, 197

Internet Protocol television(IPTV) 27, 247

architecture 9, 15, 21, 66, 67,89, 90, 153, 317, 320

business models 26, 154delivery networks threats 206mobile 66, 67, 90, 247–249,

279, 280, 284, 289networks 203, 205–209, 213,

220, 222, 225, 227–233,236, 241, 242, 318, 325

network security 203, 219protocol vulnerabilities 205,

214threats on 203threats on IPTV Networks 204

Internet service provider (ISP) 3,107, 228, 313, 322

Intra-domain 247–251, 253, 255,257, 259–261, 263, 265,267–271, 273–275,277–281, 300

lLivestream 30, 155, 323, 326

mMachine learning 36, 55, 147,

345Mesh client (MC) 248, 249, 270Mesh gateway (GW) 248, 249,

262Mesh router (MR) 248, 249, 255,

261, 262, 275Mobility management 247–280

Page 371: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

Index 359

Moving Picture Experts Group(MPEG) 247–251,253–255, 257–272

Multicast 7, 25, 26, 28, 75–80,94, 96, 97, 111, 129–131,134–137, 141, 143–147,152, 153, 157, 167, 169,172–175, 190, 191,193–198, 208, 214–220,242, 250, 260, 281, 285, 288,290–292, 315, 317,323–329, 331, 334

Multicast delivery 88, 320Multicasting-based schemes 251,

267, 278, 280Multi-screen 241, 242, 317–319,

321, 332

oOperational data 227–230, 233,

234Over-the-top 240, 284, 315

pPassive optical networks (PON)

352Peer-to-peer (P2P) 66, 89, 152,

154, 181, 323Prediction-based prejoin 135,

136, 141, 147Pricing 118, 288, 299, 301, 308,

311Programme-based method 176,

177

qQuality of experience (QoE) 4,

65, 106, 129, 131, 151, 189,203, 237, 284, 329, 332

Quality of service (QoS) 4, 65,94, 102, 103, 187, 203, 239,248, 293

rRouting-based schemes 250, 251,

258, 265, 273, 277, 279, 280

sScalable video coding (SVC) 67,

134, 135, 163, 164, 334Seasonality 227, 229, 232, 233Service orchestration 284, 299,

301, 304, 311Set top box (STB) 7, 130, 151,

195, 204, 225Software-defined networking

(SDN) 284, 295, 297, 304,305, 311, 312, 330, 335, 336,348, 350

Software-defined video (SDV)320, 322

Sparsity 227Streaming 4, 5, 7, 11, 12, 25–30,

32, 33, 35, 38, 39, 41, 45, 57,59, 60, 75, 76, 95, 103, 117,155, 180, 187, 188,190–196, 199, 203, 223,235, 236, 241, 285, 287, 288,290, 303, 306–309, 315,318, 323, 325, 326, 328, 329,331, 333–335, 337

Support vector machine (SVM)36–41, 44–46, 48–54, 59

Surfing period 135, 147, 160,161, 176

tTDM-PON 70, 72, 88Time series 230–233, 235, 243

Page 372: IPTV Delivery Networks: Next Generation Architectures for Live and Video-on-Demand Services

360 Index

Timestamp 33, 144Traffic localization 335, 345,

354Transport Stream 29, 31, 189,

190Tunneling-based schemes 250

uUnicast 7, 75, 76, 131, 135, 144,

147, 190, 195, 216, 242, 285,288, 290, 326, 327

User behavior 96

vVideo forensics 347, 351Video on demand 4, 7, 94, 152,

185, 225, 283, 317Video streaming 11, 27, 28, 30,

75, 188, 191, 196, 199, 241,285, 287, 303, 315, 333

Virtual network functions (VNF)296, 304, 306, 307

Virtual reality 332Volatility 227

wWireless fidelity (WiFi) 68, 315,

332, 335, 336Wireless mesh network (WMN)

247Worldwide interoperability for

microwave access(WiMAX) 67, 68,135–137, 142–144, 147, 175

zZapping delay 129–135, 142,

144–147, 156, 175, 177Zipf-like distribution (Zipf ) 114,

137, 143, 147