Abstract
The Internet protocol television brought seamless potential that has revolutionized the media and telecommunication industries by providing a platform for transmitting digitized television services. However, zapping delay is a critical factor that affects the quality of experience in the Internet protocol television. This problem is intrinsically caused by command processing time, network delay, jitter, buffer delay, and video decoding delay. The overarching objective of this paper is to use a hybrid delivery method that agglutinates multicast- and unicast-enabled services over a converged network to minimize zapping delay to the bare minimum. The hybrid method will deliver Internet protocol television channels to subscribers using the unicast stream coupled with differentiated service quality of experience when zapping delay is greater than 0.43 s. This aids a faster transmission by sending a join message to the multicast stream at the service provider zone to acquire the requested channel. The hybrid method reported in this paper is benchmarked with the state-of-the-art multicast stream and unicast stream methods. Results show that the hybrid method has an excellent performance by lowering point-to-point queuing delay, end-to-end packet delay, and packet variation and increasing throughput rate.
1. Introduction
The demand for a higher bandwidth has been overwhelming in recent years because of the deployment of a broadband converged network and delivering service paradigm. Convergence is the capability of the Internet to act as a single foundation for various functions that traditionally had their own platform [1]. The service paradigm is rapidly evolving and expanding to a true triple-play service represented by voice, Internet, and video [2]. The Internet Protocol Television (IPTV) is a key broadcasting service in a converged network that has brought immense potential to give network providers the capacity to expand their market value and revenue generated by increasing the number of subscribers [3].
IPTV in a converged network is a technique that aggregates data, voice, and digital television on a single-network infrastructure line to give subscribers a packed broadband service experience and helping with the utilization of broadband services [4]. IPTV is based on a multicast system for transmitting video across the Internet Protocol (IP) infrastructure because not all channels can be sent to the subscriber home gateway as a result of the limited network bandwidth [5, 6]. IPTV is the future of TV broadcasting because it offers a real-time video service by transmitting varieties of video contents over a converged network.
The Digital Subscriber Line (DSL) is a dominant network infrastructure for delivering IPTV services in a converged network. DSL access line employs a twisted copper cable between the Digital Subscriber Line Access Multiplexer (DSLAM) in the last mile and the customer premise. Asymmetric Digital Subscriber Line (ADSL) is a type of DSL that has a maximum bitrate of 8 Mb/s and can only support one High Definition Television (HDTV) channel at a time while ADSL2 and Very-high-bit-rate Digital Subscriber Line (VDSL), respectively, support up to 24 Mb/s and 50 Mb/s [7]. An IPTV stream requires about 2–4 Mb/s sustained bandwidth per Standard Definition (SD) stream, using the MPEG4 compression standard with high definition increasing the bandwidth demand to 7–8 Mb/s per stream [8, 9].
The Quality of Service (QoS), which is an important metric frequently used to measure network performance is required in order to guarantee end-to-end IPTV deployment over a converged network and to provide Quality of Experience (QoE) assurance to subscribers. QoS is essential for providing a seamless IPTV service that aids QoE for subscribers. A satisfactory level of the service provided by a network provider is determined by the QoE perceived by subscribers [10]. The lower the QoE, the higher the level of dissatisfaction and the chances of subscribers abandoning such a service. QoE is composed of a variety of metrics frequently used to measure satisfaction by subscribers. The metrics include network performance parameters such as the end-to-end delay and jitter as well as the service quality parameters such as cost, reliability, availability, and usability [11].
However, when compared to the traditional cable and terrestrial broadcasting services, zapping delay becomes the deterrent to the widespread use of IPTV. Zapping delay problem sets in when a change of channel takes 0.43 seconds or more [8, 12, 13] that affects the QoE perceived by subscribers. Zare et al. [14] explain zapping delay as a problem that occurs when a subscriber desires to change a channel, but has to wait several seconds for the desired channel to be made available. The problem gets heightened when network delay and jitter occur such that the channel selected by a subscriber experiences more than 2 second delay when compared to the same channel aired on the traditional broadcasting service.
In view of this, we propose the use of an adaptive hybrid delivery method that agglutinates multicast and unicast methods to address the zapping delay problem in the IPTV over a converged network. In literature, many adaptive network methods have been proposed to address the zapping delay problem over a converged network. The methods include the Data-Centric Network Architecture (DCNA) that supports both data-centric and host-centric applications in order to address the Internet challenges. The DCNA approach is based on the inclusion of a shim layer between the application layer and the transport layer with appropriate interfaces to efficiently connect these layers [15]. Furthermore, a collaborative Internet architecture using the Smart Identifier NETworking (SINET) was proposed to completely eliminate resource location, data content, and user network restrictions. Consequently, the SINET method was designed to absorb all kinds of traffic dominance while compliantly meeting the various future IPTV requirements such as the vehicular network that provides inordinate prospects to address many of the challenging issues facing the current Internet architecture [16, 17].
2. Related Work
There are various methods developed over the years for improving zapping delay in IPTV. Zapping delay is usually caused by command processing time, network delay, buffer delay, multicast leave and join times, processing time in the display device, size of video buffer in encoder, and video decoding delay [14, 18]. In this section, we discuss some of these methods such as the substituting multicast-based IPTV service with the unicast-based IPTV service. A multicast-based IPTV service comes with some intrinsic downfalls in that all network devices deployed within the network must support the Internet Group Management Protocol (IGMP) [19]. However, troubleshooting multicast service is complex, which further heightens the incurred cost of implementation.
In sharp contrast, Jackson et al. [20] explained that the substitution of multicast service with unicast service is not viable because as the number of subscribers increases, the required bandwidth increases. Consequently, it becomes more expensive for the QoE required by the subscribers. Nikoukar et al. [21] proposed a method that sends adjacent channel alongside the channel requested by a subscriber. They assumed that subscribers are likely to watch an adjacent channel to the requested channel. However, this method did not solve the zapping delay problem because if a subscriber does not switch to the adjacent channel, it forfeits the purpose. Lee et al. [22] improved on this method by adding channel popularity with adjacent-based prefetching. This method is used in prefetching the contents of adjacent channels before they are requested. It differentiates the channels prefetched using up and down direction buttons on the Set-Top-Box (STB) remote control based on channel popularity. However, the disadvantage of this method is that the bandwidth load becomes high, causing overload, and it ends up not reflecting the desired channel a subscriber would likely watch.
A new method that predicts the desired channel that a subscriber might likely watch was proposed to address the downside of the channel popularity with adjacent-based prefetching method [22]. This method provides Intelligent Fast Channel Switching (IFCS) based on the behavior of a subscriber. It predicts channel traffic in advance for the subscriber who wishes to watch the channel in the next few moments. Moreover, it analyzes the behaviors of subscribers and obtains their preferences of watching channels to reduce the waiting time of the subscribers [23].
In spite of the number of literature studies addressing the zapping delay problem in recent years, there seems to be no sufficient literature covering IPTV zapping delay in a converged network. This gap intrinsically served a strong motivation for this study. In response to this gap, our proposed method addresses the overall problem of zapping delay by using an adaptive hybrid delivery for fast channel navigation.
3. IPTV Architecture
IPTV in a converged network is a service that uses the IP protocol to deliver multicasting contents to subscribers via a broadband connection. The IPTV architecture spans across four zones as shown in Figure 1. The customer premise where we find devices such as TV, STB, PC, IP Phone, and ADSL router presents IPTV contents to a subscriber. The network provider zone allows a connection between the consumer premise and service provider zone. The service provider zone is responsible for providing services to subscribers. The content provider zone owns or is licensed to air contents and encoded video [24].
3.1. Multicast
IP multicast is a one-to-many method for simultaneously delivering content to a group of nodes instead of one. IP multicast is required to provide IPTV services by joining the multicast group through a channel request initiated from the remote control of the subscriber's set-up box. This multicast service saves bandwidth at both the core and access networks because there is a high probability that multiple subscribers would likely watch the same program at the same time [25, 26].
IPTV channels are distributed to subscribers through the network provider by multicast service rather than broadcast service in order to reduce bandwidth load [27]. The IGMP is used for management purposes, allowing IPTV subscribers to report group memberships to any neighboring routers that are multicast enabled to manage multicast video streams at the service provider zone [28]. The STB performs the process of sending IGMP multicasting tree when an IPTV subscriber switches between channels using a remote control. The leaving group sends a leave message to the edge router at the service provider zone on receiving the IGMP leave message. The edge router will react by sending a specific multicast video stream and terminate the specific multicast channel while the join group message is used to obtain a new channel. After waiting for the IPTV content of the requested channel to be delivered, the STB waits for a decodable frame, called an Intra-coded frame (I-frame). The requested channel is ready to be displayed on the TV set once the requested channel is delivered to the STB of the subscriber [22, 29].
3.2. Unicast
The unicast service is a one-to-one connection method that conventionally uses the Real-Time Streaming Protocol (RTSP) and Real-Time Protocol (RTP) to recover lost packets. It accelerates a channel change by delivering IPTV contents at a higher rate than the streaming rate of video [30]. A unicast service requires a dedicated zapping server to transmit a unicast burst when a subscriber initiates a channel change request. This stream is sent at a higher bitrate than the usual bitrate that allows the playout buffer to be quickly filled, making a channel readily available to a subscriber [31]. It can significantly reduce the waiting and the buffering time for I-frame, which is the first decodable video frame made available to a subscriber [32, 33].
The downside of a unicast stream is that there is a burst load on the bandwidth imposing significant input and output demands on the video servers. This is heightened because of the huge requests from subscribers coupled with the variation of the unicast packet rate of transmission and ability to the recover lost packet. Chase [5] summarizes that IP multicast is used as a countermeasure because it provides huge bandwidth efficiency over the unicast delivery.
3.3. Zapping Delay
In the traditional terrestrial TV broadcasts, all channels are being broadcasted once to a viewer, making channel changes almost immediately. This instantaneous change of channel involves the TV receiver tuning to a specific carrier frequency, demodulating the content, and displaying it on the TV screen [21, 34]. Terrestrial viewers through their experiences expect channel requests to be instantaneous because zapping delay in this system is less than 0.20 s. However, zapping delay occurs in IPTV when the channel change time is above 0.43 s because one requested channel is sent to a subscriber at a time due to high bandwidth consumption that deters the widespread use of IPTV service [35]. In addition, the problem occurs when an IPTV subscriber desires to change a channel but needs to wait until the target channel is available [36]. Zapping delay is considered one of the most important parameters of QoE that defines the acceptability of how subscribers would perceive IPTV contents and services. This is intrinsically caused by command processing time (), network delay (), buffer delay (), and video decoding delay () [6] as shown in Figure 2. The zapping delay factor () is expressed as follows:
The first factor that causes zapping delay in IPTV is the command processing time, which is the time required to examine the header of a frame in order to determine where to direct the frame [37]. The command processing time causes a delay that ensues at the instance a subscriber initiates a channel change request. That is, the time it takes the IGMP leave group message to leave the current channel while the IGMP joint group message is initiated through the multicast network service at the service provider zone to request for the desired channel.
Thereafter is the network delay, which is the time it takes for the requested channel to arrive after the initiation of the IGMP join group message. The buffering delay arises from buffering video frames after the arrival of the first I-frame. It is the time it takes to repair and retransmit content in order to provide reliability when packets are lost. This buffering is designed to help overcome the intrinsic problems caused by reordering and fluctuations of packets by the unavailability of content resulting from packet loss ratio (PLR), end-to-end delay, network jitter, and throughput rate [38, 39]. Packet loss is bound to occur if the network parameter for receiving IPTV traffic is not appropriately coupled with the different transmission rate. Consequently, PLR is the corrupted, lost, or excessively delayed packets divided by the total number of packets expected at the STB of a subscriber as follows [38]:
The end-to-end delay is the time taken for a packet to be transmitted across a network from the IPTV headend to the STB. It is computed as follows [39]:where is the network parameter between the IPTV headend and subscribers, customer premise zone, is the processing delay, is the queuing delay, is the transmission delay, and is the propagation delay.
The network jitter in IPTV is defined as a variation in the end-to-end delay of receiving video stream. At the IPTV headend, video streams are sent in a continuous stream with the packets spaced evenly apart. It is numerically determined as follows [38]:where is the actual time it takes for the IPTV packet to be received by a subscriber and is the expected time it takes for the IPTV packet to get to the subscriber.
The throughput () is the ratio of network capacity (), that is, the network bandwidth over the cumulated load () of the average amount of IPTV traffic that passes through to the STB. It is determined numerically as follows [39]:
Finally, a video decoding delay is the time it takes for a compressed video to be decoded, which is achieved by using I-frames. It is related to the encoding structure, and the maximum video decoding delay is the length of a group of pictures [40]. IPTV contents are compressed by encoding multicast video stream over IP network where the video streams are divided into groups of pictures [41].
4. Methodology
The essential steps of our adaptive hybrid delivery method that agglutinates multicast and unicast to minimize zapping delay in a converged network are shown in Figure 3. Once zapping delay occurs, a unicast method with Differentiated Service (DiffServ) QoS will be used to deliver IPTV contents from a multicast group to subscribers. This method addresses the requirements of delay, jitter, and real-time sensitive traffic during short periods of congestion. The overprovisioning of bandwidth will help to minimize the long-term average level of congestion within the converged network [42]. It is imperative to use DiffServ QoS to fairly prioritize bandwidth from the unicast stream when zapping delay set in because different services run on a converged network. DiffServ admission control solves the scalability issues and provides IPTV subscribers with a consistently high-quality video with a responsively reduced channel zapping delay time. In addition, it reduces bandwidth consumption by policing IPTV traffic to ensure that it conforms to the service level agreement [43].
As shown in Figure 3, a decision is needed as to when to provide a hybrid stream and a multicast stream for a channel request. This is accomplished when the channel request is received and zapping delay is greater than 0.43 s. The hybrid stream is used for content delivery while a dedicated bandwidth is allocated using the DiffServ for an IPTV content in order to avoid delay and jitter. However, if zapping delay is less than 0.43 s, the channel content stream will be delivered with a multicast stream. The adaptive hybrid delivery method for channel navigation can reduce the problem of zapping delay during IPTV content delivery. Moreover, it can optimize the usage of network bandwidth while providing a resilient quality of service to subscribers. In addition, it can aid bandwidth saving and reduce zapping delay as channel request over the converged network must provide a real-time service.
5. Simulation Experiment and Results
To simulate a realistic hybrid delivery method that will produce an accurate result within an acceptable timeframe, we have used the Optimized Network Engineering Tool (OPNET) Modeler 14.5. The OPNET is an application software that provides a comprehensive Integrated Development Environment (IDE) for the specification, simulation, analysis, and evaluation of the performance of communication networks [44]. The performance of the adaptive hybrid delivery method has been compared with the performances of the state-of-the-art multicast and unicast methods within the OPNET IDE.
Qing and Cong [45] explain that the OPNET modeler provides different levels of modeling, depending on the requirements of the simulation. The graphic user interface of OPNET modeler establishes an overall environment called a project. The operator can develop several network scenarios from a project in order to evaluate and analyze the performance of that network in different “what-if” scenarios. The modeler has to be configured as shown in Figure 4 in order to obtain desirable results. For the simulation experiment, we created a converged network with two routers, which are first hop router and last hop router connected to the cloud with a digital signal level 3 T-carrier link of 44.736 Mbit/s data circuit. The first hop router is connected to the converged network service with the IPTV headend, VoIP server, and data server.
Table 1 shows the network parameters used to configure the converged network topology in Figure 4. This topology has servers equipped for transmitting video, voice, and data services to subscribers. The Protocol Independent Multicast Dense Mode (PIM_DM) was added to the network node model for the simulation of the multicast stream. This has helped to efficiently generate, process, and deliver multicast packet within the converged network [46]. Furthermore, multicast services were enabled on all nodes in order to support efficient multicast stream delivery. The application model of the OPNET was configured to generate and process unicast stream for the simulation of the unicast steam. The OPNET configuration for the simulation of a converged network runs for the duration of 15 min in order to improve the processing speed.
Figure 5 shows the IPTV traffic received from the headend and traffic sent to 12 subscribers. Specifically, Figure 5(a) shows the IPTV traffic received by the headend from the subscribers for multicast, unicast, and our hybrid methods. All these methods received the same amount of traffic over a period of time. At the same time, the traffic sent by the IPTV headend to subscribers as shown in Figure 5(b) has the same traffic value for all methods. This provides a fair comparison of the simulated methods.
(a)
(b)
Figures 6(a) and 6(b) depict the IPTV traffic load from the headend versus the throughput rate for the traffic delivered to subscribers for the unicast and multicast methods, respectively. Although the throughput of the unicast method was higher than that of multicast, the downside effect is that it consumes excessive network resources while multicast has resource allocation challenge [25, 26]. However, Figure 6(c) illustrates the throughput rate of our hybrid method for the traffic delivered to subscribers, which is higher than the load. This result indicates that the hybrid method outclassed the state-of-the-art methods, which is possible by concomitantly taking the advantages of both unicast and multicast methods.
(a)
(b)
(c)
Figure 7(a) shows the performance result of the IPTV headend processing time in responding to requests from subscribers. The comparative result shows that our proposed hybrid method, when compared with the unicast and multicast methods, has the lowest processing time despite having a higher traffic request per second as shown in Figure 7(b). Consequently, our hybrid method efficiently shares network resources evenly without affecting the network performance.
(a)
(b)
Figure 8 illustrates the end-to-end delay of all packets received at the IPTV headend. The result shows that although our hybrid method has the highest traffic request, the end-to-end delay is low when compared with the results of the unicast and multicast state-of-the-art methods.
In Figure 9, the packet delay variation (jitter) of our hybrid method is significantly less when compared to the unicast and multicast methods. This would help to reduce the zapping delay problem in IPTV.
The queuing delay in Figure 10 is the time it takes the IPTV packet to wait in a queue until it is forwarded to the IPTV subscriber. The hybrid method has the least waiting time when it comes to delivering packets. This can reduce the network delay time and zapping delay in order to increase the perceived quality of experience by a subscriber.
6. Conclusion
In this paper, we have developed and evaluated an adaptive hybrid delivery method that agglutinates the state-of-the-art multicast and unicast methods for fast channel navigation in Internet protocol Television over a converged network. The simulation results show that the hybrid delivery method has a better performance by lowering point-to-point queuing delay, end-to-end packet delay, jitter, and network throughput. The use of the hybrid delivery method reported in this paper can provide efficient, resilient, and reliable IPTV video distribution to subscribers. Moreover, it provides a mechanism for reducing the zapping delay often experienced by IPTV subscribers during channel navigation.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.