Table of Contents Author Guidelines Submit a Manuscript
International Journal of Digital Multimedia Broadcasting
Volume 2019, Article ID 2495310, 12 pages
https://doi.org/10.1155/2019/2495310
Research Article

Peer-Assisted Content Delivery to Reduce the Bandwidth of TSTV Service in IPTV System

LESSI Laboratory, Department of Physics, Faculty of Sciences Dhar El Mehraz Fez, Morocco

Correspondence should be addressed to El Hassane Khabbiza; am.ca.abmsu@azibbahk.enassahle

Received 8 February 2019; Accepted 25 March 2019; Published 14 April 2019

Academic Editor: Jintao Wang

Copyright © 2019 El Hassane Khabbiza et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

With great technologies, emerge new needs and requirements. The progress achieved in Access broadband rates accentuated the demand on IPTV (Internet Protocol Television) services specially Video on Demand (VOD) and Time Shift TV (TSTV) which led subsequently to a great need for efficiency in the use of bandwidth consumed by those services. Optimization solutions are considered by IPTV service providers to lighten the service load especially on Access Nodes uplinks. This paper describes an optimization of TSTV dedicated bandwidth based on a peer-assisting TSTV content delivery, a solution in which the users STBs (set-top-boxes) assist the central TSTV servers in the service fulfillment. For this purpose, for each TSTV request, the STB will be receiving the TSTV stream from a neighbor STB instead of the central server. By using this method, the unicast traffic will not pass through the IP network; it will be a peer-to-peer communication within the access network. Extensive simulation results were included to illustrate the validity of the proposed new solution.

1. Introduction

Recently the IPTV service has become widely used as a result of the variety of provided services such as multicast TV, Video on Demand (VOD), and Time Shift TV (TSTV) taking advantages from the IP network expansion and the increase of broadband users [1].

Traditional TV uses large bandwidth with no user specific video delivery. IPTV on the other hand has strict requirements on performance and reliability and furthermore needs small latency and packet loss beside a tight control of jitter, in order to assure the expected end user experience. In the last few years, many researches on IPTV and bandwidth management were proposed. Ken Kerpez et al. [2] propose a bandwidth reduction via localized peer-to-peer (P2P) Video. Authors of [3] highlighted the relevance of the wireless transport in today’s IPTV solutions. Georg Acher et al. [4] present a hardware and software implementation of the proposed NetCeiver architecture which can stream services concurrently from up to six full transponders. In [5], authors proposed a design of an IPTV multicast system for the Internet backbone network, by using a resource reservation algorithm to reserve bandwidth.

As illustrated in Figure 1, in the standard topology of an IPTV system, the STB is provided by connectivity parameters via the Access Server. Using DHCP (Dynamic Host Configuration Protocol) [6] or PPPOE (Point-to-Point Protocol over Ethernet) [7] and the access granted, when a user selects a specific channel (turning on his STB or zapping), his STB is correspondingly sending a request to join the corresponding multicast group using IGMP protocol (Internet Group Management Protocol) [8, 9]. The IPTV platform that received the request responds by delivering the RTP (Real Time Transport Protocol) [10] encapsulated video stream in IP packets to the user passing by the AGR (Aggregated Router), AN (Access Node), and HG (Home Gateway).

Figure 1: Architecture of IPTV system.

Video content digitalization, compression, and packetization increase the channel change time (CCT) significantly. Generally in IPTV systems, this delay has three underlying types [11]:(i)Decoding delay: which is time between the user entry of a channel change and receipt of decodable multicast data.(ii)IGMP delay: the time needed to process the IGMP leave and join messages.(iii)Buffering delay: the time needed to buffer the content before displaying it on the user TV.

2. Related Works

In the last few years, many techniques [12, 13] have been proposed as a mitigation for the CCT in IPTV systems. FCC (Fast Channel Change) based on unicast is the most popular channel change solution deployed by operators over the world thanks to its simplicity and reliability and compatibility with the existing network elements with no modification required to implement it.

2.1. FCC Unicast Based

This solution, as illustrated by a typical topology in Figure 2, is based on a FCC server recording the last few seconds of the content stream of each channel from the multicast source. Such server is installed in the IP backbone to cover a large number of Access Nodes. An IPTV user changing the watched channel is sending via the STB not only an IGMP leave message in order to leave the previous multicast group corresponding to the previous channel but also an FCC request to the FCC server to request the unicast video content. As result, The FCC server responds to the STB by sending a fragment of the video stream of new requested channel for immediate playback, starting at some entry point in the past. The FCC server sends the data to the STB faster in terms of rate than the channel’s data rate but later in terms of time to catch up with the multicast stream for the requested channel and then instructs the STB to join the multicast channel group via IGMP [1416].

Figure 2: Working principle of FCC.

After joining the new channel and receiving the first multicast packet, the STB informs the FCC to stop sending the unicast stream [1719]. Figure 3 shows the working mechanism of this technique.

Figure 3: FCC work flow.
2.2. Time Shift TV Service

One of the most important features of IPTV is the ability to interact with the content server, namely, the VOD. When a user can choose what to watch, why not watching what he missed. This is Time Shift TV (TSTV) [20]. Such a gainful service pushes IPTV operators to invest on its scalability by extending the TSTV platform capacity (storage) and adding more regional servers in the access network layer while maintaining the bandwidth usage at lower rates.

A TSTV server deployed within the IP backbone, in order to cover the maximum number of ANs, is continuously loop recording the last hours or days of multicast live channel content depending on the operator strategy and server capacity.

Using the EPG (Electronic Program Guide), as in Figure 4, the user selects a channel with a specific time shift; then the STB sends a request to the TSTV server including related information. Upon request reception, the TSTV server sends the exact requested part of the content stream to the STB by unicast.

Figure 4: Working principle of TSTV service.

The normal IPTV channels are delivered through multicast, which is highly scalable with the growth of subscribers’ quantity. TSTV content, on the other hand, is typically delivered using unicast, which puts a heavy load on the TSTV servers and all system components until end-user set-top-boxes (STBs) as the demand increases [21]. With the rapid growth of IPTV subscriber number and the shift in video watching habits, IPTV service providers and related intervenes are in big need of efficiently reducing the huge throughput of TSTV content and figure out an alternative for content delivery [2123].

3. Proposed Approach

3.1. New Solution Architecture

In [24] we described and analyzed a new solution to reduce the unicast bandwidth consumed by TSTV service in the IP backbone; in this paper we will highlight the robustness of this new TSTV service model illustrated in Figure 5 by advanced network simulations.

Figure 5: The new TSTV solution principle.

Our solution is based mainly on the implementation of some of the TSTV server light capabilities on each user STB controlled by TSTV server, which will act as TSTV controller in addition to its TSTV server role. Multicast channel stream requested by the user will be decoded and displayed on the user TV and at the same time recorded locally for a specific time to be available to other neighboring STBs (STB belonging to the same AN) if needed.

This new scheme is totally controlled by the TSTV server that has all necessary information about all live IPTV users and TSTV users stored in the TSTV database (Figure 6). To build and update this database that contains all the historic information about STBs and the list of the channel (live TV channels) that each STB watched in the past, we will take benefit of the existing FCC solution.

Figure 6: Example of TSTV database.

The TSTV server should have a full updated knowledge of the current and historic channels watching situation. This can be achieved by sending one additional FCC request to the TSTV server after each channel changes event as illustrated in Figure 7.

Figure 7: TSTV database update mechanism.

Our proposition is mainly addressed to high speed access network technologies such as VDSL (Very High Bit Rate Digital Subscriber Line) [25], GPON (Gigabit Passive Optical Network [26], and Ethernet that provide a large uplink bandwidth.

The user physical location is mandatory to judge STB neighboring relationship. Such information will be extracted from dynamic access protocols (DHCP and PPPOE) generally used for IPTV access guarantee.

The DHCP option 82 [27] or PPPOE option 82 [28] should be enabled on the Access Node so that the user location information will be reported to the Access server through the DHCP discover or PPPOE Active Discovery Initiation (PADI) messages [29]. Once the Access Server gets this information, it will forward it (with STB IP address) to the TSTV server to build the TSTV database (Figure 8).

Figure 8: Collecting the STB location information.

The datagram in the Figure 9 sums up the main steps of the new solution; when STB_R (“R” for receiver) requests the TSTV content from the TSTV server, the TSTV server will trigger conditions matching for the optimal content source STB_S (“S” for source):(i)STB_S and STB_R should be connected to the same Access Node.(ii)STB_S should have the requested content.(iii)STB_S is excluded if it is already sending TSTV stream to another STB_R to save the uplink bandwidth of STBs.

Figure 9: The proposed TSTV solution main steps.

The STB_S fulfilling those conditions will be instructed by the TSTV server to send via a unicast stream the chosen content to STB_R or else, if no STB matching the conditions, the TSTV server will grant STB_R request by itself.

If the STB_S is switched off during the TSTV streaming, the STB_R will request the TSTV server to resume the stream delivery of the needed content by reporting the exact interruption time.

In case there is some packet loss during the stream delivery, the STB_R can demand the missing RTP packet from the STB_S by reporting the sequence number of this packet [18].

3.2. New Solution Algorithm

In this algorithm, to choose the STB_S (source of the unicast stream) that will be providing service to STB “i” at the instant “j”, the TSTV server runs the algorithm in Figure 10.

Figure 10: STB_S selection algorithm.

4. Performance Evaluation

4.1. New Solution Emulation on GNS3

In this part, we will be testing the solution on LAB environment. For the flexibility of the implementation, emulation software is used. Only open-source software or freeware are utilized. We will be detailing below the used software and versions.

The Cisco GNS3 (Graphical Network Simulator-3) [30] was chosen, as for its performance, stability, easiness to use, open-source nature, and the possibility for integration with VMs (Virtual Machine) and connectivity to Host local or remote interfaces or equipment. The latest available version of the software was used (V1.3.13 for reference). Since multicast routing has become a basic functionality, any type of routers would do the job. The used routers and version were the preexisting routers provided with GNS3 (router version C3660-TELCOENTK9-M v12.4).

The IPTV source was emulated by a video broadcasting over IP software installed on a Linux based VM. Oracle VirtualBox Virtual Machine was used as Hypervisor. VirtualBox is a small open-source and handy Hypervisor. The used version is 5.0.16 r105871.

Only basic functionalities are needed to run the video broadcasting software, so we choose the lightest handy Linux OS that is Lubuntu 17.10 in order to create instances for multicast server and receivers with the minimum load on the host. To emulate the STB, a Lubuntu based VirtualBox VM as in the multicast server with VLC player installed was used.

We used the well-known strong and stable video broadcaster and player VLC (version v2.2.6) [31], open-source software with plenty of features. Some of its strongest features are the ability to read network streams, record it, and use script to stream it out.

A MPEG-4 [32] sample video with 320x258 resolution and 30.1 MB in size is the content streamed.

4.1.1. Network Topology

As shown in Figure 11 to build the LAB L3 network, three similar routers were used. Interconnection IP addresses were given accordingly. To emulate an Access Node (AN) a router with switching fabric is used. Users’ Home Gateway was also emulated with the same type of router; multicast server and users STB were Lubuntu VM and VLC.

Figure 11: Typical IPTV system emulated on GNS3: IPTV multicast and TSTV flow of two users.

Multicast server, users STB, and HomeGW were given static IPs with a default gateway to first connected router. The HomeGW is enabling IGMP v2 protocol in order to request the multicast traffic from the network. The Access Node (AN) (router) is enabled with switching functionalities including IGMP snooping. The L3 routed network was assured via OSPF [33] on which PIM SM [34] was enabled to provide multicast routing within.

4.1.2. Simulation of the Existing Live Multicast Service

Since the PIM SM is used, the multicast flow will start by going through the RP (rendezvous point) and then follow the short path tree passing directly from AGR. Traces were taken in three points to illustrate the multicast flow arriving to user 1.

When checking the tracing points, the traffic is in fact flowing out from multicast source (10.10.10.2) in destination of the selected multicast address 224.1.1.1. The routers are effectively passing through the flow and it is reaching the user 1. The video player installed in STB_1 allowed us to watch the received stream correctly since user 1 is a member of the multicast group. All these results were illustrated in Figure 12.

Figure 12: Multicast content flowing out from the source to user 1 trace and preview.

User 2 in opposite does not receive any flow since IGMP snooping is enabled in AN.

Multicast simulation succeeding the TSTV service should be also simulated to build the whole solution correctly. The following part will be dedicated then to TSTV service simulation.

4.1.3. Simulation of the Existing TSTV Service

As per normal behavior, the user 2 will request the TSTV content from the TSTV server. Traces were taken in two points to illustrate the unicast flow arriving to user 2.

When checking the tracing points, the traffic is in fact flowing out from TSTV server (10.10.10.2) with a unicast address as destination this time that is the ip address of user 2 (192.168.22.2). The routers are effectively passing through the flow and they are reaching the user 2. The video player installed in STB_2 allowed us to watch the received stream correctly, when reading the flow pointed to the user 2 IP address. All these results were illustrated in Figure 13.

Figure 13: TSTV server to user 2 solution simulation content preview and traces.

Since the TSTV user is served by the TSTV server, the load on the link AGR-AN will be as much as users requesting this service.

As simulated, user 1 was able to watch multicast stream and user 2 was able to watch TSTV stream from TSTV server. By all components of IPTV and TSTV services built, we will be introducing the proposed TSTV solution.

4.1.4. Simulation of the Proposed TSTV Solution

The solution starts by a neighbor watching and recording multicast video content and then sending it to requesting user under TSTV control. These two steps will be detailed in the next parts.(i)Watching and recording multicast.

As proposed in the solution and shown in the previous figures, the user 1 will start recording the requested traffic locally for the predefined period of time. The stream is reaching STB_1 and it is recording it as the file “recorded.mp4”.(ii)The recorded stream relaying to user 2.

In this stage, in order to notify the change on AN uplink, the user 1 stops requesting the multicast flow and the user 2 will be using the recorded content from user 1 as proposed in the solution (Figure 14).

Figure 14: The proposed solution service flow.

This content will be streamed out with a user 2 unicast address as destination.

As in the proposed solution, no traffic will be training from the TSTV server to user 2 confirmed in the trace in Figure 15. TSTV unicast is flowing out instead from the STB_1 to destination STB_2. The same traffic is traced reaching STB_2 coming from STB_1.

Figure 15: User 1 to user 2 TSTV content relay simulation results.

The video content is successfully watchable in streaming with no difference felt at user 2 side.

To sum up, using a lab environment similar to the typical IPTV and TSTV network, a TSTV user was able to get requested video service relayed by a neighbor user connected to the same Access Node without reusing the link AGR-AN.

The proposed solution, based on a TSTV server controlled recording for a specified period of multicast content and sharing with neighboring users, succeeded then to display a realistic efficiency by reducing AN uplink load.

4.2. Simulation of Bandwidth Optimization Using Matlab

In this sampling environment, we assume that there are 100 live IPTV users, 60 standard definition channels to watch (3 Mb/s the bandwidth of each channel), and 80 TSTV users able to request the recorded IPTV content (of these 60 channels) on the TSTV server.

The live IPTV and TSTV simulation for our sample users has been launched at the same time for 20 minutes (1200 seconds); the live IPTV STB_S receive the multicast content, decode it, and send it to the TV screen and record it in the same time using built-in local DVR for specified time (for this sample the maximum recording duration is 50 seconds).

Figure 16 describes the behavior of the Access Node uplink link. At the beginning, no STB had channel contents recorded locally. All STBs were receiving the TSTV flow from the TSTV server, consuming then the Access Node uplink bandwidth. After that a minimum watching and recording time was reached; STBs start sharing contents with neighboring STBs and users stop requesting it from TSTV server. Consequently, the Access Node uplink bandwidth falls remarkably.

Figure 16: TSTV Bandwidth usage before and after using the new solution.

5. Conclusion

We presented in this paper a new solution to manage efficiently the bandwidth resources of the unicast traffic on the IP network consumed by TSTV service by implementing the unicast peer-assisted solution on the user STB. That means if there is one STB already joining one channel and this channel is requested by another STB connected to the same Access Node, this STB can deliver the TSTV unicast traffic to its neighbor instead of the central TSTV server. In cases where there is no STB having this content, the TSTV server will deliver the unicast traffic to the requesting user STB by itself as per the normal TSTV solution.

The full process is controlled by the central TSTV server based on the information collected from channel change requests received from the STBs and STBs locations received from the Access server.

Our solution does not need any additional resource or new hardware integration in the other network elements. It requires only some software upgrade or tweak on both the TSTV server and the user STB. For future development, we will expand this new solution to optimize the unicast bandwidth of the VOD (Video on Demand) by taking benefit from the communication between the user STBs.

Data Availability

The data used to support the findings of this study are included within the article.

Disclosure

Our research was funded by our own means.

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.

References

  1. M. Verhoeyen, D. De Vleeschauwer, and D. Robinson, “Content storage architectures for boosted IPTV service,” Bell Labs Technical Journal, vol. 13, no. 3, pp. 29–44, 2008. View at Publisher · View at Google Scholar · View at Scopus
  2. K. Kerpez, Y. Luo, and F. J. Effenberger, “Bandwidth reduction via localized Peer-to-Peer (P2P) video,” International Journal of Digital Multimedia Broadcasting, vol. 2010, Article ID 562832, 10 pages, 2010. View at Publisher · View at Google Scholar · View at Scopus
  3. T. Jursonovics and S. Imre, “Bandwidth management in wireless home networks for IPTV solutions,” International Journal of Digital Multimedia Broadcasting, vol. 2013, Article ID 474212, 7 pages, 2013. View at Publisher · View at Google Scholar · View at Scopus
  4. G. Acher, D. Fliegl, and T. Fuhrmann, “A software and hardware IPTV architecture for scalable DVB distribution,” International Journal of Digital Multimedia Broadcasting, vol. 2009, Article ID 617203, 9 pages, 2009. View at Publisher · View at Google Scholar · View at Scopus
  5. T. H. Szymanski and D. Gilbert, “Design of an IPTV multicast system for internet backbone networks,” International Journal of Digital Multimedia Broadcasting, vol. 2010, Article ID 169140, 14 pages, 2010. View at Publisher · View at Google Scholar
  6. R. Droms, “Dynamic Host Configuration Protocol,” Tech. Rep., Network Working Group, 1997, https://tools.ietf.org/pdf/rfc2131.pdf. View at Google Scholar
  7. L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, and R. Wheeler, “A Method for Transmitting PPP Over Ethernet (PPPoE),” Tech. Rep., 1999. View at Google Scholar
  8. S. Shoaf and M. Bernstein, Introduction to IGMP for IPTV Networks, 2006.
  9. Y. Kim, J. K. Park, H. J. Choi et al., “Reducing IPTV channel zapping time based on viewer's surfing behavior and preference,” in Proceedings of the IEEE International Symposium on Broadband Multimedia Systems and Broadcasting 2008, Broadband Multimedia Symposium 2008, BMSB, USA, April 2008. View at Scopus
  10. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications Status of this Memo,” Control RFC3550, 2003. View at Publisher · View at Google Scholar
  11. V. Joseph and S. Mulugu, “Deploying Next Generation Multicast-Enabled Applications: Label Switched Multicast for MPLS VPNs, VPLS, and Wholesale Ethernet,” Morgan Kaufmann, 2012. View at Google Scholar
  12. X. Tian, Y. Cheng, and X. Shen, “Fast channel zapping with destination-oriented multicast for IP video delivery,” IEEE Transactions on Parallel and Distributed Systems, vol. 24, no. 2, pp. 327–341, 2013. View at Publisher · View at Google Scholar · View at Scopus
  13. C.-Ch. Wen and Ch.-S. Wu, “QoS supported IPTV service architecture over hybrid-tree-based explicit routed multicast network,” International Journal of Digital Multimedia Broadcasting, vol. 2012, Article ID 263470, 11 pages, 2012. View at Publisher · View at Google Scholar
  14. T. Arul and A. Shoufan, “Subscription-free Pay-TV over IPTV,” Journal of Systems Architecture, vol. 64, pp. 37–49, 2016. View at Publisher · View at Google Scholar · View at Scopus
  15. J. Yoon, S. Park, and S. Choe, “Implementation of EIGMP for fast IPTV channel change in GEPON,” IEEE Transactions on Consumer Electronics, vol. 57, no. 2, pp. 484–491, 2011. View at Publisher · View at Google Scholar · View at Scopus
  16. A. Nikoukar, I.-S. Hwang, A. T. Liem, and J.-Y. Lee, “Mitigating the IPTV Zap time in enhanced EPON systems,” Journal of Optical Communications and Networking, vol. 8, no. 6, pp. 451–461, 2016. View at Publisher · View at Google Scholar · View at Scopus
  17. R. Haimi-Cohen and J. P. Hearn, “Fast channel change handling of late multicast join,” US 8,161,515 B2, 2012. View at Google Scholar
  18. B. Ver, A. Begen, T. Van, and Z. Vax, “Unicast-Based Rapid Acquisition of Multicast RTP Sessions,” Tech. Rep. RFC6285, 2011. View at Publisher · View at Google Scholar
  19. E. H. Khabbiza, R. El Alami, and H. Qjidaa, “A novel approach to reduce the unicast bandwidth of an IPTV system in a high-speed access network,” International Journal of Digital Multimedia Broadcasting, vol. 2017, Article ID 2456814, 9 pages, 2017. View at Publisher · View at Google Scholar · View at Scopus
  20. Volume 4a - Examples of IPTV Protocol Sequences, [V2.3] - [2014-01-24], “Open IPTV Forum Release 2 Specification,” http://www.oipf.tv/web-spec/volume4a.html.
  21. Y.-F. R. Chen, R. Jana, D. Stern et al., “Zebroid: Using IPTV data to support STB-assisted VoD content delivery,” Multimedia Systems, vol. 16, no. 3, pp. 199–214, 2010. View at Publisher · View at Google Scholar · View at Scopus
  22. J. Zhuo, J. Li, G. Wu, and S. Xu, “Efficient cache placement scheme for clustered time-shifted TV servers,” IEEE Transactions on Consumer Electronics, vol. 54, no. 4, pp. 1947–1955, 2008. View at Publisher · View at Google Scholar · View at Scopus
  23. W. Xiang, G. Wu, Q. Ling, and L. Wang, “Piecewise patching for time-shifted TV over HFC networks,” IEEE Transactions on Consumer Electronics, vol. 53, no. 3, pp. 891–897, 2007. View at Publisher · View at Google Scholar · View at Scopus
  24. E. H. Khabbiza, R. El Alami, and H. Qjidaa, “A new solution to optimize the time shift TV bandwidth,” in Proceedings of the 2018 International Conference on Intelligent Systems and Computer Vision, ISCV 2018, pp. 1–5, Morocco, April 2018. View at Scopus
  25. Itu-T, Very high speed digital subscriber line transceivers, 2004.
  26. Itu-T, “G.984.1 Gigabit-capable passive optical networks (GPON): General characteristics,” Networks, pp. 1–43, 2008. View at Google Scholar
  27. M. Patrick, “DHCP relay agent information option,” Tech. Rep. 3046, 2001. View at Publisher · View at Google Scholar
  28. V. Mammoliti, G. Zorn, P. Arberg, and R. Rennison, “DSL forum vendor-specific RADIUS attributes,” Tech. Rep. 4679, 2006. View at Publisher · View at Google Scholar
  29. D. I. Allan, “ENF SELECTION FOR NFVI, 20160156718, 2016”.
  30. “RedNectar” Chris Welsh, GNS3 Network Simulation Guide. Packt Publishing Ltd, 2013.
  31. H. Fallon, A. de Lattre, J. Bilien, A. Daoud, M. Gautier, and C. Stenac, VLC User Guide, 2003.
  32. J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, and P. Gentric, “rfc3640: RTP Payload Format for Transport of MPEG-4 Elementary Streams,” Netw. Work. Gr, 2003. View at Google Scholar
  33. RFC 2328, J. Moy, “Internet Engineering Task Force,” Netw. Work. Gr Ascend Com, 1998.
  34. B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” Netw. Work. Gr RFC4601, 2006. View at Publisher · View at Google Scholar