Abstract
Channel change time is a critical quality of experience (QOE) metric for IP-based video delivery systems such as Internet Protocol Television (IPTV). An interesting channel change acceleration scheme based on peer-assisted delivery was recently proposed, which consists of deploying one FCC server (Fast Channel Change Server) in the IP backbone in order to send the unicast stream to the STB (Set-Top Box) before sending the normal multicast stream after each channel change. However, deploying such a solution will cause high bandwidth usage in the network because of the huge unicast traffic sent by the FCC server to the STBs. In this paper, we propose a new solution to reduce the bandwidth occupancy of the unicast traffic, by deploying the FCC server capabilities on the user STB. This means that, after each channel change request, the STB will receive the unicast traffic from another 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 via the Access Network only. Extensive simulation results are presented to demonstrate the robustness of our new solution.
1. Introduction
Recently, the IPTV (Internet Protocol Television) solution has become widely used since it provides various services such as multicast TV, Video on Demand (VOD), and Pause Live TV (PLTV), taking advantage of the IP network expansion and the increase of Internet users.
Instead of traditional TV, which provides large bandwidth and no single video delivery to each user, IPTV distribution requires a strict requirement on both performance and reliability needs, lower latency, tighter control of jitter, and small packet loss in order to guarantee the expected video quality.
Figure 1 illustrates the basic topology of an IPTV system. When a user switches to a specific channel (or when the user turns on his/her STB), the STB sends a request to join the corresponding multicast group using IGMP (Internet Group Management Protocol) [1]. Then, if successful, the IPTV platform delivers the video stream encapsulated in RTP (Real-Time Transport Protocol) packet to the user through the AGR (Aggregated Router), AN (Access Node), and HG (Home Gateway).
During each channel change, the STB sends the IGMP multicasting message to join the new channel; during this change, the STB must wait more for the arrival of the decodable frame, which is called the I-frame. In order to solve this problem, many techniques have been proposed to reduce this waiting time; one of the most famous techniques is the unicast peer-assisted solution, which consists in sending the I-frame faster to allow the STB to decode the multicast stream instead of waiting for the arrival of the original I-frame.
The objective of this paper is to propose a novel method to reduce the bandwidth occupancy of the unicast traffic consumed during channel changes by enabling communication between STBs. Using this method, the STB will join the stream, decode it, and display it on the user screen. In addition, at the same time, STB can buffer this stream for several seconds to deliver it to another STB (which belongs to the same AN) in case it is required by that STB.
This paper is organized as follows. Section 2 reviews the methods used for reducing the channel change time. The proposed method is detailed in Section 3. In Section 4, we evaluate our method followed by a conclusion in Section 5.
2. Related Work
The video stream is composed of a series of frames (or pictures) taken at regular intervals (typically every 33.3 or 40 milliseconds); the bitrate of this stream will be significantly high and can reach up to 200 Mb/s for SDTV (Standard Definition Television) and up to 1 GB/s for HDTV (High Definition Television) [2].
Since network bandwidth is a scarce resource, many compression techniques have been recently used to save network bandwidth and storage. Efficient media stream schemes have therefore been developed, such as MPEG-2 and MPEG-4, taking advantage of the temporal correlation between frames. This correlation can significantly increase the compression efficiency.
The video stream in this scheme is compressed into a series of frames grouped in a group of pictures (GOP) as illustrated in Figure 2. Each GOP is composed of three frames: I-frame, P-frame, and B-frame. The I-frame is the reference frame, which exploits the spatial correlation of pixels within the frame, and it is very independent of the other frames. The P- and B-frames are predicted frames and depend always on other frames to be decoded; they cannot be decoded alone.
To decode the video stream, the decoder needs an I-frame, which is the reference frame, as it is the basic information for decoding all GOP. To increase the playout time and reduce delay, it is highly recommended to transmit the I-frame frequently. However, transmitting the I-frame more frequently will increase the bitrate of the video stream because those frames are relatively larger than P- and B-frames.
The choice of the GOP size should be well suited to have an average between GOP size and decoding delay. Generally, there is a tradeoff between the playout performance on the one hand and the compression efficiency on the other hand; in practice, the GOP duration is usually chosen to be between 1 and 3 seconds.
2.1. Channel Change Delay
In the traditional TV systems, the channel change time (CCT) was almost simultaneous (around 200 milliseconds), as the user just needs to change the carrier frequency, demodulate the content, and display it on the TV screen.
With the digitalization and compression of the video stream, the channel change time (CCT) has increased significantly; generally, in IPTV systems, this has three underlying components [3]:(i)Decoding delay: the 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.
In the last few years, many techniques [4] have been proposed as a solution to mitigate the CCT of IPTV systems. Most of those techniques focused on reducing the decoding delay based on an auxiliary stream, which starts with an I-frame. This auxiliary stream is sent to the STB when the user changes the channel in order to allow the STB to catch the I-frame earlier and start decoding and displaying it on the screen without being obliged to wait until the arrival of the original I-frame, which will help to minimize the CCT.
There have been three basic techniques to exploit the auxiliary stream.
Technique 1. Prejoin the most likely next channel based on user behavior or the adjacent channel in parallel with the current channel [5–7]. This way, the STB will decode the stream of the new channels very quickly since it has already received the I-frame before switching the channel.
Technique 2. Encode a low-quality auxiliary stream with frequent I-frames into the regular stream for each channel [8, 9].
Technique 3. This technique is FCC unicast-based, which consists in deploying one Fast Channel Change (FCC) server in the network in order to buffer the media stream and deliver it to the STB with a higher speed after each channel change request [10–12].
2.2. FCC Unicast-Based
FCC based on unicast is the most popular channel change solution deployed by operators over the world because of its simplicity and reliability, and it does not require any modification in the other network elements to implement it. Figure 3 shows one simple topology of an IPTV system based on FCC unicast solution, and Figure 4 illustrates the working mechanism of this technique.
This solution consists of installing one FCC server inside the IP backbone in order to cover the maximum number of ANs; this server is connected to the multicast source to catch the last few seconds of the content stream for each channel. Once the IPTV user presses the button on the remote control to change the channel, the STB will immediately send one FCC request to the FCC server to request the unicast in parallel with an IGMP leave message in order to leave the previous multicast group corresponding to the previous channel. The FCC server sends to the STB a short stream of video from the new channel for immediate playback, starting at some entry point in the past.
The FCC server sends the data to the STB at a data rate faster than the channel’s data rate and after a few seconds catches up with the multicast stream for that channel, and then the FCC server instructs the STB to join the new channel.
After joining the new channel and receiving the first multicast packet, the STB informs the FCC to stop the unicast stream [13].
2.3. FCC Unicast Bandwidth Evaluation
FCC based unicast does not take into consideration the transmission bandwidth limitation, because the unicast stream is used in parallel with the multicast stream to deliver the IPTV service to the end user. Bandwidth limitations become more and more serious when the users switch the channels in a frequent or simultaneous manner due to their own behavior (searching for interesting programs) or to avoid commercial breaks (advertisements).
This bandwidth will be added to the multicast bandwidth and bandwidth of other services (especially when the AN is offering other services to the end users), such as HSI (High-Speed Internet), VoIP (Voice over IP), and POTS (Plain Old Telephone Service), which can cause many congestion problems between the AN and the AGR and between the AGR and the IP backbone.
The total unicast bandwidth () consumed during the channel change for one AN is the sum of all the unicast traffic () sent to each STB during each channel change (as shown in Figure 5) and can be expressed by the following function:
3. The New FCC Unicast-Based Solution
To reduce the unicast bandwidth consumed during the channel changes of all IPTV users connected to one AN, we proposed a new solution as shown in Figure 6, which consists of the implementation of the FCC server capabilities on each user STB in parallel with the central FCC server, which will act as an FCC controller (FCCC) and at the same time as a traditional FCC server. Once the STB receives the channel stream, it will decode and display it on the user screen and at the same time can buffer this stream for several seconds to deliver it to another STB (which belongs to the same AN) in case it is required by that STB.
Our proposition is mainly addressed to high-speed Access Network technologies such as VDSL (Very High Bit Rate Digital Subscriber Line) [14], GPON (Gigabit Passive Optical Network) [15], and Ethernet which provide a large uplink bandwidth.
To determine the user’s physical location, we will exploit dynamic access protocols such as DHCP [16] (Dynamic Host Configuration Protocol) and PPPOE [17] (Point-to-Point Protocol over Ethernet) since they are the most popular protocols used for IPTV authentication.
We propose to enable the DHCP option 82 [18] or PPPOE option 82 [19] (depending on the access protocol DHCP or PPPOE) on the AN. This way, the AN information will be sent to the access server through the DHCP discovery or PPPOE Active Discovery Initiation (PADI) messages. Once the access server gets this information, it will forward it (with STB IP address) to the FCC server to build the FCC database (Figure 7).
3.1. Possible Scenarios
During each channel change, five scenarios could happen.
Scenario 1 (STB keeps joining the same channel during the FCC period). Figure 8 shows the workflow and main steps during this scenario. When the user wants to switch the channel to a new one, the STB1 sends one FCC request to the FCCC server; the FCCC server will first update the information related to STB1 in the FCC database including the time of the channel change, the STB IP address, and the ID of the new channel.
The time at which the channel has been changed will be added to that database in order to facilitate the verification of the buffer fulfillment and to decide whether this STB can act as an FCC for other STBs or not.
When the FCCC server finds out that one STB is already connected to the same AN and is joining the new channel with a full buffer, the FCCC server will request this STB (STB2) to send the stream to STB1.
At some point, the STB2 instructs the STB1 to join the new channel. After joining the new channel and receiving the first multicast packet, the STB1 informs the STB2 to stop the unicast stream.
Scenario 2 (STB changes the channel during the FCC period). If the STB changes the channel during the FCC period, the STB (receiver) will request the FCCC to resume the stream delivery by reporting the last RTP sequence number to the FCCC [20].
Scenario 3 (STB switched off during the FCC period). If the STB is switched off during the FCC period, the STB (receiver) will request the FCCC to resume the stream delivery by reporting the last RTP sequence number to the FCCC.
Scenario 4 (in case there is some packet loss during the delivery of the stream). In case there is some packet loss during the stream delivery, the STB (receiver) can demand the missing RTP packet from the FCCC server by reporting the sequence number of this packet.
Scenario 5 (there is no STB that can satisfy the requirement). If the FCCC server does not find any STB fulfilling the requirements of the FCC server, it will deliver the unicast stream by itself as described previously in the section titled FCC Unicast-Based.
The datagram in Figure 9 resumes the main steps of the new solution.
3.2. FCCC Algorithm
The novelty in this contribution is that the new FCC controller server (the FCCC) has two functions: the first one is the normal FCC server and the second function is the FCC control server, which will control and select the suitable STB to act as a local FCC server.
The FCCC builds the FCC database based on the information received from the access server and channel change requests. The database is composed of multiple databases; each Access Node has its own database in the FCCC, and we consider the FCCC database as a matrix (Figure 10) where the number of columns is the number of online STBs and the number of rows is the buffer time divided by the time sampling interval.
Once the FCCC server receives one FCC request, it will update the entry of the STB in the database. To save memory, the FCC server will record only the information about some few seconds. For example, in Figure 10, the STB4 is changing from channel 3 to channel 1, and after receiving the channel change request from the STB, the FCCC server will update row number 4 corresponding to the STB4 at time from channel 3 to channel 1.
The FCCC server will then analyze all matrix rows to check whether one STB has a full buffer for channel 1. After verification, the result will be STB2 since this STB is receiving the traffic of this channel over a long period higher than buffer duration, which means STB2 has a full buffer and therefore can be used as an FCC server.
To avoid the congestion of uplink traffic and load problems, the FCCC will not select the STB more than once during the FCC period. After each FCC selection, the FCCC will start a countdown timer (the timer duration is equal to the FCC duration) and bind it to the selected STB; this way, the FCCC will not select this STB because the timer has not yet expired; once the timer expires, the STB can be selected again as an FCC server.
Generally, the FCCC server calculates the STB ID, which can act as an FCC server for the user at the instant based on the following function:where(i) is a unit matrix;(ii) is a square matrix, of size , with elements of vector on the main diagonal and zero elsewhere:(iii) is a column vector of size , which contains the information about each STB at the instant ; this vector will be used to exclude the STB, which is switched off at the instant ; even its buffer is full as per the FCCC database;(iv) is an infinity integer, to neglect the values lower than one by applying the factor;(v) is a square matrix, of size , which consists of diagonal values, each equal to the sum of rows, elements of matrix , and zero elsewhere:(vi) is a square matrix, of size m, which consists of diagonal values each equal to the multiplication of rows, elements of matrix , and zero elsewhere:(vii) is the channel change matrix, which contains the latest channel changes information for each user; it is composed of column and rows;(viii);(ix) is the sampling interval, the distance between points at which information is taken;(x)buffer duration is the duration of the FCC buffer;(xi) is the number of online STBs;(xii) is a column vector of size , with numbers increasing by increments of 1.
Note(i)In the main function, the matrices P, S, and C have been modified in order to eliminate the non-one elements by applying the functions and .(ii)If the result of the function above is zero, this means no STB with the described requirements; in this case, the FCCC should take charge of the delivery of the unicast stream to the STB .
4. Performance Evaluation
To confirm the performance and efficiency of the proposed scheme, we created a simulation of the unicast bandwidth between AN and AGR using MATLAB.
We have considered in this example (Figure 11) that we have 120 users that can change up to 60 SD channels (the speed of each channel is 3 Mb/s) in total, frequently for a period of 1200 seconds. The FCC buffer has a capacity of 3 seconds.
The new solution reduced the unicast bandwidth sent by the FCCC to the STBs during the channels change; local FCC servers (STBs) replace the central FCCC server to forward the unicast traffic needed during the channel change.
Figure 12 shows the bandwidth behavior in terms of the number of channels; the number of users is fixed at 60 users and they can perform up to 40 channel changes during a period of 400 seconds. We remark in this example that when the number of channels is smaller to the users number, the efficiency of our scheme is very important because the probability of finding more users watching the same channel is high. This means that when a user switches to a new channel, we have a higher chance of finding another user watching the same channel, which can support sending the unicast stream instead of the central FCC server.
Increasing the number of channels means that users have more choices during channel surfing, so when a user switches to a new channel, it is harder to find more people watching the same channel.
In the old scheme, the unicast bandwidth consumed by all users during channels change is proportional to the number of users, but in the new scheme this bandwidth decreases once the number of users becomes higher than the number of channels. This means that we have good optimization once we have more users watching the same channel as illustrated in Figure 13.
Figure 14 shows the bandwidth behavior in terms of watching duration; the old and new schemes behave in a similar way when the watching duration is long, but when the users switch the channels frequently, the new scheme becomes more optimal regarding saving bandwidth.
In summary, the simulation of the proposed scheme shows very good management of the bandwidth of the AN uplink port especially when there are a significantly high number of channel change requests and the number of users is higher than the number of channels available.
5. Conclusion and Future Work
We presented in this paper a new solution to efficiently manage bandwidth resources of unicast traffic on IP networks during IPTV channel change by implementing the unicast peer-assisted solution on the user STB. This means that if there is one STB already joining one channel and this channel is requested by another STB, which is connected to the same Access Node, this STB can deliver the FCC unicast traffic to its neighbor instead of the central FCC server (FCCC). In cases where there is no STB joining this channel, the FCCC will deliver the unicast traffic to STB by itself as per the old FCC unicast-based method.
The full process is controlled by the central FCC 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 on both the FCC server and the user STB. For future development, we will expand this new solution to optimize the unicast bandwidth of the PLTV (Pause Live TV) by taking benefit from the communication between the user STBs.
Conflicts of Interest
The authors declare that they have no conflicts of interest.