Reducing IPTV Channel Zapping Time for Scrambled Services

Transcription

1 Reducing IPTV Channel Zapping Time for Scrambled Services Y.S. Hong and T.G.Kim Dongguk University Department of Computer Engineering Seoul Korea {hongys, Abstract In general, IPTV is defined as a multimedia delivery service and it is extended from the VoD service by unicast to live TV service by multicast. In the live TV environment, the QoE of IPTV service includes convenient user interfaces, quality of audio/video, and response time. The channel zapping time is one of the most important factors in QoE, and there have been many researches to improve it. Especially, because channel zapping in scrambled services includes a process for descrambling the contents, it is important to transmit the descramble keys efficiently to reduce the zapping time in scrambled services. In this paper, we improve this problem by receiving descramble keys from neighbor IP-STBs instead of from the multicast stream. Keywords-component; IPTV, channel zapping time, CAS, ECM, IGMP I. INTRODUCTION With the development of high-speed Internet technology, the transmission medium for digital TV service is shifting from the air to networks. Since a broadcaster can supply not only live TV service but also VoD, data service, and t-commerce via two-way communication, and a network provider can get more subscribers by offering triple-play service with Internet, telephone, and TV services, this change is desirable for both broadcasters and network providers. The IPTV technology consists of head-end technology that includes audio/video compression and security, network technology that includes data transmission over an IP network and a QoS guarantee, and terminal technology. With regard to the network technology, multicast transmission is used for live TV service and efficiently reduces the network bandwidth by transmitting one stream per channel regardless of the number of users who want to watch it. The channel zapping time is meaningful with regard to user responsiveness in IPTV. It is very difficult to reduce it because it is affected by all IPTV components including the head-end, network, and terminal. There are many factors that contribute to the channel zapping time in IPTV, such as delay in receiving the key frame and the initial buffering time that prevents jitter related to video compression, delay in the JOIN/LEAVE operation in a multicast group related to an IP multicast, and delay in receiving SI/PSI and Conditional Access System (CAS) information related to the video/audio contents. Table 1 shows the major factors of the channel zapping time in the real world [1]. TABLE I. MAJOR COMPOMENT OF CHANNEL CHANGE LATENCY[1] Channel change latency factor Typical latency (ms) IP Protocol and remote control button delay 25 Multicast leave for old channel 50 Delay for multicast stream to stop 150 Multicast join for new channel 50 Jitter buffer fill 200 CAS (Conditional Access System) delay 0~2000 I-frame delay 500 There have been many studies to reduce the channel zapping time, as, for example receiving key frames or additional data for video decoding from additional server with a unicast burst [2], using small GOP [3], and joining a new multicast group before leaving the current one [4]. But such studies did not consider pay TV with scrambled services. In this paper, we propose a new scheme to reduce the channel zapping time for scrambled services. In section 2 we introduce CAS and IGMP, in section 3 we propose new solution to reduce channel zapping time for scrambled services, in section 4 we provide experimental results and in section 5 we come to conclusion. II. BACKGROUND Figure 1 shows the typical network architecture for IPTV service. IPTV service is transmitted via multicast, and Protocol Independent Multicast(PIM) and Internet Group Management Protocol(IGMP) are commonly used to support an IP multicast /11/$ IEEE 103 ICOIN 2011

2 A multicast is a delivery method that shares a data stream with users interested in it, and it uses the network bandwidth effectively by transmitting a single copy of each data stream. In the IPTV environment, the head-end that broadcasts TV services is the multicast source and the user who wants to view these services is the receiver. In other words, the multicast source sends data using the multicast group address and the receiver receives the data by joining this multicast group. Figure 3. General architecture of CAS [6] Figure 1. Network Architecture for IPTV service IGMP[5] is used to manage multicast groups between edge routers and hosts and its main purpose is to determine whether a router forwards multicast traffic or not. Therefore a router does not forward multicast traffic when there is no multicast group member in the hosts that are connected to it. As IGMP is used only to restrict unnecessary multicast traffic on the subnet, each host on the subnet does not keep any information on the multicast group members and also the router merely keeps information on whether or not there are members in a given multicast group. IGMP uses a Membership Query message to allow the router to learn which group has members on the subnet, and a Membership Report message to allow the host to indicate which group it wants to join. Figure 4. Descrambling in a typical set-top box [6] Figure 2. IGMP membership query and report In the digital TV environment, which includes IPTV, only authorized subscribers are allowed to access the contents of pay TV service, and CAS is one of the most important factors in identifying authorized subscribers. CAS scrambles the contents of pay TV service at the head-end and allows only authorized users to descramble these contents at their terminal. In other words, CAS must be able to authorize subscribers to watch scrambled contents and distribute the decryption keys to authorized users to allow them to descramble the contents. Figures 3 and 4 describe the general architecture of CAS and the descrambling process in IP-STB. CAS uses an Entitlement Management Message (EMM) to deliver authority to subscribers, and uses an Entitlement Control Message (ECM) and the smartcard system to distribute control words, decryption keys. For fast channel change, ECM is repeated in a multicast stream that contains scrambled contents in a short period, and EMM is delivered to the terminal via additional communication when there is a change in the users authority. Looking at the channel change sequence in the IPTV environment based on a multicast and CAS, IP-STB stops receiving data by leaving the multicast group for current channel, and it starts receiving data by joining the multicast group for a new channel. When an edge router receives a join message, if there is no member in this group in the subnet, it requests its upper router to forward multicast traffic so that a new member in this group can receive data. When IP-STB starts receiving multicast data, it first checks SI/PSI to discover service information in the multicast data. If the received service is scrambled, it gets information on which CAS is used to scramble the service and which PID is assigned to ECM from 104

3 PMT in SI/PSI, and it waits for arriving ECM by filtering it from the multicast stream with this information. After receiving the ECM, IP-STB gets the control word from the EMM and the ECM in cooperation with the smartcard system, and decrypts the scrambled contents using the control word. Then it finds the key frame in the descrambled stream and starts initial buffering to prevent a buffer under-run. III. PROPOSED SCHEMES There have been many researches to reduce the channel zapping time in IPTV, and the most representative method is by receiving the key information to start decoding from additional servers via unicast burst [2]. In this approach, which overlaps with the sequence for channel change, IP-STB can receive some data needed to change channels quickly, but the extra cost of the additional server may be very high when many IP-STBs perform channel change. Therefore, we propose a new approach to receive some data needed to change channels, especially an ECM that contains the descramble key from other IP-STBs in the same subnet instead of an additional server. Because an ECM is valid for a few seconds, it is the key idea that IP-STB can receive a valid ECM without extra cost from other IP-STBs watching the channel that the IP-STB performing channel change is about to watch. It is very important to receive ECM quickly for changing scrambled channels because the cost of communication with the smartcard system is needed to get the control word from the ECM. To receive ECM from other IP-STBs in the proposed approach, it requires finding quickly other IP-STBs to send the ECM. IGMP v3[5] was used in this approach to keep the multicast group member list in order to find the member. Because IGMP aims to forward multicast traffic to a router, the router keeps only the list of the multicast group that the hosts join and the hosts in the subnet also do not keep any multicast group member list. It is possible, however, for the hosts to make a multicast group member list by listening to IGMP membership report messages on the subnet. IGMP v3 supports Source Specific Multicast (SSM), and there is a multicast source address list field in addition to a multicast group address list field in a membership report message as shown in figure 5. It is possible for hosts to join the multicast group G using the membership report {*, G} and leave the multicast group G using the membership report {EMPTY, G}. Unlike the previous version, in version 3, a membership report is delivered with an IP destination multicast group address of and it is possible for the hosts to find out which member joins a group or leaves a group by listening to this group address. We devise a way to keep a multicast group member list in the subnet and a new approach to receive ECM quickly from other IP-STBs, in which IP-STBs that recognize a new member of a group send an ECM without receiving any request. Figure 5. IGMP v3 membership report To do this, the IP-STBs perform the following sequence. Each IP-STB monitors the group address in membership reports on the subnet, and when the report is for the group it joined, it checks the source address of the report packet. If this source address is not on the group member list, IP-STB recognizes the host of this source address as a new member in the group it joined and adds this source address to the group member list. If there is a new member in the group, other members of the group elect the member responsible for sending the ECM by a simple rule such as by order of joining or by order of their IP addresses, and the member elected sends an ECM and the group member list it keeps to a new member. If the report is for leaving the group, each IP-STB deletes the source address of the report from the group member list. When the IP-STB performing channel change receives the ECM and the group member list from another IP- STB, it updates its own group member list and it tries to get the control word from the smartcard system with an ECM. Figure 6. Group member list from membership report 105

4 The proposed scheme has a limitation when there is a layer 2 switch that supports IGMP snooping between an edge router and the hosts. The limitation is that the hosts outside the switch s domain cannot receive the membership reports of other hosts because the switch that supports IGMP snooping follows the rule that it must forward membership reports only to the port connected to a router. This rule is to prevent from missing membership reports for the switch to snoop them due to IGMP report suppression. This limitation is resolved in IGMP v3, however, in which there is no IGMP report suppression [7]. channel that the IP-STB performing channel change is about to watch. IV. ANALYSIS AND EXPERIMENTAL RESULTS As expressed in the following equation, the delay in receiving an ECM from a multicast source has three main components; delay in leaving/joining a multicast group, delay in a router s forwarding of multicast traffic, and delay in discovering SI/PSI and parsing an ECM. On the other hand, the delay in receiving an ECM in the proposed scheme is expressed in the delay in receiving it from other members, as in the following equation, wherein ρ is the probability that there are other IP-STBs watching the channel that the IP-STB performing channel change is about to watch. Because the delay in receiving an ECM from other IP-STBs in the subnet is very small compared to the delay in receiving an ECM from a multicast source, the more the probability ρ is, the less delay there will be in IP-STB s receiving of an ECM. The probability ρ depends on the number of channels, the popularity of the channels, and the number of hosts connected to a router, in the same subnet. If it is assumed that the popularity of the channels follows an exponential distribution, as follows, the average probability ρ may be expressed as in the following equation, wherein c is the number of channels and n is the number of hosts in the same subnet [1]. Figure 7. the probability ρ according to the number of hosts in the same subnet With the simulation, we verified the probability that there are members joining the multicast group for a certain channel and evaluated the ECM transmission delay. Table 2 summarizes the parameters used in the simulation. TABLE II. PARAMETERS USED IN THE SIMULATION Parameters Value Period of transmisson of ECM 200ms Delay of communication between hosts <1ms Number of channels 100 Number of hosts in the same subnet 10~100 The pattern of channel change in the IP-STBs used in the simulation is defined in figure 8. Each IP-STB changed its state every 1000ms, and the probabilities of transition between states were based on our own discretion. In the experiments, we measured the delay in the transmission of an ECM with the increase in the number of hosts from 10 to 200 for 60 sec in three times. Wherein the λ value is 0.05, the number of channels is 100, and the number of hosts in the same subnet increases from 10 to 200, Figure 7 shows the curve for the probability ρ. Figure 7 shows that the greater the increase in the number of hosts in the subnet is, the greater the probability will be that the members in the multicast group for a certain channel will increase with the fixed number of channels. That is, the probability is higher that there are other IP-STBs watching the Figure 8. State diagram of channel change 106

5 The experiment results are shown in Figure 9. The probability ρ increased with the increase in the number of hosts in the same subnet, similar to Figure 7, the probability in the analysis. Figure 9. Probability ρ according to the number of hosts in the same subnet Figure 10 shows the simulation results, in which the delay in the transmission of an ECM from a multicast source was about 100 ms on the average, and the delays in the proposed scheme were 86 ms, 63 ms, and 37 ms on the average in the cases in which the numbers of hosts in the subnet were 10, 50, and 100, respectively. These results show that the transmission from other hosts was about 63% faster than from the multicast source when the hosts in the same subnet were as many as the number of channels. According to the simulation results, the proposed method is more effective because it allows an IP-STB to receive an ECM from other IP-STBs instead of from the multicast source. The proposed method may contribute to reducing the channel zapping time in a scrambled service because an IP-STB can prepare the control word for descrambling the contents with the smartcard system while receiving the multicast data. V. CONCLUSION In this paper, we proposed a new scheme to reduce the channel zapping time for a scrambled service. The key idea of the proposed scheme is to receive an ECM from other IP-STBs on the same subnet instead of from the multicast source. The proposed scheme uses the IGMP v3 membership report to make a group member list in each host to allow the existing members to send an ECM to a new member. The simulation results showed that an ECM can be received from other IP-STBs faster than from the multicast source with an increasing number of IP-STBs in the same subnet. The proposed scheme may reduce the cost of additional servers, and it may also be used for fast and effective transmission not only of an ECM but also of some other data, including the key frames and SI/PSI needed to change channels. REFERENCES [1] Zlatan Begić, Melika Bolić, Himzo Bajrić "Effect of Multicast on IPTV Channel Change Performance", 50th International Symposium ELMAR-2008, [2] Ali C. Begen, Neil Glazebrook and William Ver Steeg "A Unified Approach for Repairing Packet Loss and Accelerating Channel Changes in Multicast IPTV", IEEE 6th Consumer Communications and Networking Conference, [3] Peter Siebert, Tom N. M. Van Caenegem, Marcel Wagner "Analysis and Improvements of Zapping Times in IPTV Systems", IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE [4] Mounir Sarni, Benoit Hilt, Pascal Lorenz "A Novel Channel Switching Scenario in Multicast IPTV Networks", IEEE Fifth International Conference on Networking and Service, [5] RFC 3376, "Internet Group Management Protocol, Version 3" [6] H. Cruickshank, M.P. Howarth, S.Iyengar, Z. Sun, and L. Claverotte. "A Comparison between satellite DVB conditional access and secure IP multicast". IST-Mobile & Wireless Communications Summit June [7] RFC 4547, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping" Figure 10. Delay in receiving an ECM according to the number of hosts in the subnet 107