Seamless Handover of IPTV Streams in a Wireless LAN Network

Seamless Handover of IPTV Streams in a Wireless LAN Network Ger Cunningham, Philip Perry, Member, IEEE, John Murphy, Senior Member, IEEE and Liam Murphy, Member, IEEE

Abstract— A robust mechanism to enable seamless handover of streamed IPTV in a WLAN is presented. Handover in a wireless network is usually based on signal strength measurements, but that approach does not consider levels of congestion within the network. Here, the case of stationary nodes with varying levels of network congestion is considered. A scheme that analyses the jitter is used to establish the relationship between congestion and loss in WLANs. This Moving Average of Negative Jitter is used as the basis of a handover scheme which can minimize loss. The handover scheme uses a client with two simultaneous connections to the same server through two separate WLANs, and it is shown that the client can compare the jitter in the two streams to determine which network delivers the best performance; this information is then used to determine when to perform a handover. The proposed scheme is implemented and results are presented that show the successful handover of an RTP over UDP stream in a live WLAN environment. The test scenario used is aimed at “Over-The-Top” service delivery, but the core algorithm is expected to be more broadly applicable. Keywords- IPTV, Handover, Streamed Video, Wireless LAN1.

I.

INTRODUCTION

The delivery of video content to subscribers has been the subject of a considerable amount of research and standardization activity. Early research into digital broadcast systems yielded the MPEG-2 Transport Stream that has been incorporated into a family of Digital Video Broadcast standards. Recently there has been a strong shift towards Internet Protocol TeleVision (IPTV) technologies as this offers the possibility of applying sophisticated techniques to adapt to changing network conditions [1] or use admission control to optimize revenue to the service provider [2]. The economics of deploying IPTV solutions has increased interest in providing such service on top of existing broadband infrastructure – also known as “Over-The–Top” (OTT) deployments which present particular problems as the traffic load is not controlled by the service provider. The purpose of this work is not to present a complete system, but rather to present a network selection algorithm that is more quality oriented than other systems that rely on signal strength as the primary indicator of network suitability.

1

Manuscript received April 1, 2009. This work was supported in part by Informatics Research initiative of Enterprise Ireland. The authors are with the School of Computer Science and Informatics, University College Dublin, Dublin, Ireland. (e-mail: gercunningham at hotmail.com, {philip.perry, j.murphy, liam.murphy}at ucd.ie.

These changes in video distribution techniques have resulted in increased availability of content to users, which, in turn, has created an increased desire for improved quality and ubiquitous access. This consumer demand is fuelling a renewed drive in the industry to make high quality video systems available on mobile devices. Of particular significance are Ultra-Wide Band (UWB) technologies that promises data rates in excess of 1Gbps with a range of a few metres and IEEE802.11n that can offer several hundred Mbps with a slightly better range than UWB. Such systems could be used to provide high capacity wireless networking and possibly use Wireless Mesh Networking (WMN) technology to reach subscribers [3]. The issue of making systems inter-work is a key requirement for ubiquitous service provision and is particularly difficult with a number of wireless technologies being available for transport of IPTV. It has been proposed that a cross layer approach can be used to facilitate interworking between WLAN and DVB-T systems [4]. In the work presented here, the use of WLAN technology is of particular interest as this is a major access technology that can accommodate multi Mbps. The WLAN systems currently deployed use a Carrier Sense Multiple Access (CSMA) technique which means that there is no inherent admission control or bandwidth control that are so important to maintain high quality video links. That is, the quality that is perceived by a video streaming user in a WLAN area is dependent on the level of congestion in that network and therefore dependent on the other users in the vicinity. At present a user will typically be attached to one WLAN Access Point (AP) and will use that for the duration of a streaming session. If multiple AP’s are available to the user, the terminal device will typically attach to the AP with the strongest signal, rather than the network that can provide the best quality. Moreover, such attachment decisions are rarely updated as the session progresses. Such issues have been explored in the context of VoIP using the Stream Control Transmission Protocol (SCTP) [5] and have also been used to develop a generic video handover scheme [6]. Other recent work, such as [7] and [8] have addressed the issues of multimedia streaming over WLANs using network centric QoS systems such as IEEE802.11e. The work presented here, however, assumes that there are no sophisticated systems in the network as there are many regular IEEE802.11b networks already deployed.

In this paper, the case in which a number of legacy IEEE802.11b WLAN access networks are available for streaming IPTV content is considered. The work presented in [6] used a measure of the difference between available paths, while the work presented here introduces a new quality metric that can be applied to each stream independently. This allows the system to evaluate the quality performance of a single stream and then decide when to start looking for handover opportunities. Three key issues are identified:•

How to determine which network is “best”.

•

How to determine when the quality of the present link is degrading, but before catastrophic loss rates are incurred.

•

How to switch to the best network without incurring packet loss.

These issues essentially constitute the familiar handover problem in a cellular system, but with the added complexity that the two networks in question may have no means of sharing control information. That is, the client and server in the video streaming session must manage the handover in this case. Historically, handover has been considered mainly as an issue related to mobility and to fluctuations in signal quality. The focus of this work, however, is on the case in which handover can be desirable due to network congestion. The particular target application is IPTV delivery which will typically use UDP transport [9] over WLAN to static users with varying numbers of active clients in an AP coverage area. The paper is laid out as follows. Section 2 discusses handover techniques that have been proposed in the literature. The following section then examines the relationship between congestion and loss in a WLAN. Section 4 then presents the rationale for using measured jitter as the basis for deciding when to perform a handover. The proposed handover scheme is then described in detail in section 5. In the following section results are presented from a handover in a live WLAN environment with UDP transport. Conclusions and future work are discussed in section 7. II.

RELATED WORK

Although the work presented here relates to the handover due to network congestion, rather than signal strength variation, most related works are cast in a mobility scenario. It is also useful to introduce the concepts of soft handover and hard handover. While these terms have been used elsewhere in the literature in some senses, some specific meaning is required here. In this context, soft handover is a handover in which the same data is delivered to the terminal device via the two access networks simultaneously as shown in Figure 1. Clearly, this can be resource intensive, but it does make the possibility of data loss during the handover very small. In contrast, a hard handover is one in which data is streamed via one network at any time: thus at some specific time, a decision is made to receive the data through one network rather than the other. While hard handover is more parsimonious with network resources, it can result in data loss at the user terminal, depending on how quickly the handover is executed and the

data rate. In this work, a static terminal shown in figure 1 is attached to a WLAN AP. If the number of active users in that cell increases, then the system can detect when congestion is becoming problematic and then uses a soft handover scheme to compare two available network connections. The IEEE 802.11b standard for WLANs allows for handover between overlapping WLAN cells at the link layer [10]. Since this only permits connection to one WLAN at a time, it falls into the category of hard handovers. In [11] it was shown that the handover latency can be significant and subject to large variations. During this latency period the station is unable to send or receive traffic and packets queued at the old WLAN will be lost, making it unsuitable for the handover of multimedia traffic. Before

*

*

During

*

After

*

*

*

*

Terminal Access

Figure 1. Soft handover process.

An approach which has received significant interest within the research community is that of Mobile IP [12], which enables a Mobile Node (Client) to receive IP packets through a packet forwarding procedure. This approach is well suited to solving the problem of locating a terminal that may be attached to one of a number of networks. However, handovers in Mobile IP are slow and packets can be lost during the handover procedure [13], making it unsuitable for the handover of IPTV traffic. Extensions have also been proposed to the mobility support provided in the Session Initiation Protocol (SIP) [14, 15, 16]. Since SIP is an application layer protocol for establishing and tearing down multimedia sessions, it can help provide personal mobility, terminal mobility, and session mobility. SIP uses hard handover and “in-flight” packets can be lost during the handover period. In [15] it was estimated that packet loss can occur for up to 50ms during the handover period. This estimate did not take into account network initialisation procedures such as user authentication or address assignment, which can be a major part of the overall handover delay. SIP therefore is not good at providing seamless handover of IPTV streams. Clearly, the above solutions are inadequate for handover of IPTV, primarily because they break the old connection before they make the connection to the new cell. As loss of video data can result in video artifacts, soft handover is the preferred option and forms the basis of the approach proposed here. In [5] a modified transport layer protocol used path delay to initiate a soft handover with a voice application. The work presented here considers the handover of video in the application layer. Providing handover functionality in the

application layer means changes do not have to be made to operating systems and protocol stacks. An approach to realizing handover based on a new socket abstraction was proposed in [18]. While this interesting contribution focused on the mechanics of implementing a hard or soft handover, it did not address when to handover as it did not monitor the quality of independent links. Earlier work on UDP handover presented in [6] has been extended and applied to an IPTV scenario in this present paper. III.

LOSSES IN A CONGESTED NETWORK

Experiments were performed to investigate the relationship between congestion in WLANs and packet loss. An example of these experiments is outlined in this section and the results are presented for UDP traffic, although similar results were also obtained for TCP traffic. A server and client were connected to an 802.11b WLAN as shown in figure 2 and an RTP over UDP session was established. To emulate IPTV traffic, the server transmitted RTP packets at 30 packets per second and each packet contained 1000 bytes of RTP data each. Six other stationary computers (BG) were used to generate background traffic on the WLAN. The background computers sent UDP packets at BG

Iperf Sink

transmitting. When three background computers were active, delay was relatively small. Thereafter, the delay began to increase substantially, and when all six background computers were transmitting some packets were lost. Table 1 shows the packet numbers of the packets that were lost. The losses were in clusters and they occurred when the packet delay was very high suggesting the losses were due to queue overflow, rather than by unsuccessful retransmissions at the link layer. The test was repeated a number of times with similar levels of delay and packet losses observed as above. Increasing the traffic rate of the background computers led to greater packet loss. More background stations in the test outlined above would also result in greater packet loss with subsequent loss of intelligible IPTV content. The above results clearly demonstrate the expected correlation between congestion in a WLAN and packet loss: when congestion is high, delays can be large – of the order of some hundreds of milliseconds – and the system is liable to suffer packet loss. In the next section a scheme is proposed that enables a client to determine the level of congestion in a WLAN.

BG BG BG BG

2BG

3BG

4BG

5BG

6BG

AP BG Video Server

Client

Wire Wireless 2

1.2Mbit/s each to an Iperf Sink via the AP. The IPTV client remained stationary throughout the test.

Figure 3. Packet Delay and Loss measured during congestion testing experiments.

TABLE I.

Figure 2. Experimental setup to determine impact of congestion.

At the beginning of the test only the video server transmitted packets. After 30 seconds two of the background traffic generators were activated, and the remainder were activated in succession, with a minute between each activation. Two minutes after the last one was activated, all of the background traffic generators were deactivated, leaving only the video server transmitting packets. Figure 3 shows a graph of the packet delay and packet loss experienced by the RTP packets that were transmitted by the video server to the Client. It shows that the packets experienced some minor jitter when two background computers were 2

Iperf is a tool for measuring maximum TCP and UDP bandwidth, and is used here to generate background traffic.

Cluster Number

LOST PACKETS ID of Lost Packets

1

12378,12380 12381,12386,12388 12391,12393 12395 12401

2

12510, 12511, 12512, 12513, 12518

IV.

DETERMINING CONGESTION

The previous results showed an increase in delay and delay variation before packet loss was incurred. However, the behaviour is rather chaotic and presents no obvious way of determining if a transient delay is a precursor of packet loss. The plot in Figure 4(a) shows the delays that occurred in repeat tests of the test outlined in the last section, with the

background computers transmitting at 1Mbit/s each. Figure 4(b) shows the corresponding jitter of the packets when they arrived at the client, where jitter is defined as the difference between the expected arrival time of a packet and the actual arrival time of that packet. Although the results show that jitter increases with congestion, it is still difficult to extract a clear trend. Analysis of the arrival time of packets at the client shows that when congestion occurs, the pattern of jitter shown in Figure 5 occurs. When there is no delay, there is no jitter. When a delay occurs, the jitter is initially positive and large and this is followed by negative jitter that is less pronounced and persists until the delay subsides.

To further explore the use of jitter to determine the level of congestion in a network, a moving average of the jitter relative to the expected time of arrival is performed in the Client. Then the absolute value of the negative jitter values are used and the positive jitter values are replaced by zeros. This moving average is referred to as the moving average of the negative jitter (MANJ) in the rest of this paper. The moving average uses 150 samples, which corresponds to 4.5 seconds. The moving average of the negative jitter was captured in the tests above and this is shown in figure 4(c). This shows that the MANJ is roughly correlated with the level of congestion: when there is little congestion the MANJ is low, and when the congestion is high the MANJ is high. In the following section a handover scheme is outlined that makes use of the MANJ. V.

6BG

2BG

3BG

4BG

5BG

HANDOVER SCHEME

For the purposes of this investigation it is assumed that the delays between the server and the APs is of a lower order than the delays experienced by packets in getting through the WLAN. Such a scenario can be envisaged for a system located in a metropolitan area or smaller. Figure 6 shows content being streamed through two access networks during a soft handover in the above scenario. The Client has two WLAN interfaces, so that it can handover from one WLAN to another. The Client uses soft handover in the application layer, enabling the video decoder in the Client to present an uninterrupted video stream to the user. In the experiments it was necessary to use two WLAN cards in the Client to access two APs simultaneously. However, it should also be possible to use MultiNet from Microsoft, where a single physical WLAN interface can be used to simultaneously access multiple APs [17].

Figure 5. Inter-packet delays during a period of congestion.

Figure 4. Measured Delay, Jitter and MANJ in a WLAN with IPTV traffic.

Each of the two WLAN interfaces in the Client has a unique IP address, so that the two streams are independently routed through the networks. Most of the time the Client has one connection to the server which is used to carry the desired video stream, while the second wireless interface looks for another AP. When it discovers another WLAN, it registers with the network and performs any necessary initialisation procedures . Initially no traffic will flow through the new

WLAN, until the current WLAN begins to become congested and the measured MANJ exceeds some threshold which can be set by the service provider to suit the bit rate and quality requirements of the service. At that time, the Client makes another connection to the IPTV server and the server initiates a second, synchronised, identical video stream to the Client via the new WLAN. It should be noted that deciding when to request a second stream and how often to do so is for further study and is outside the scope of this paper. It is expected that empirical adjustment of MANJ thresholds and hysteresis will be central to that solution to avoid flooding the network with unnecessary requests and to avoid ping-ponging. MANJ depends on the IPTV server transmitting the packets at a constant rate and the time interval between these packets, denoted ts, is known by the client. The server duplicates packets that are sent in the packet stream via the current radio interface and sends this duplicate packet stream to the client via the candidate radio interface that is to be evaluated3. While the mobile device is receiving the two streams, it timestamps the incoming packets on arrival in the client, this time is denoted ti for the ith packet. The client computes the time difference between successive packets from the same stream using these timestamps. For the ith packet, the inter-packet arrival time is given by: tm(i) = ti – ti-1 These values are then modified according to the following algorithm: 1. If tm(i)< ts, then tm(i)=abs(ts - tm(i)). This is referred to as negative jitter. 2. If tm(i)>= ts, then tm(i)=0. This is referred to as positive jitter and is removed from the calculation by setting it to zero.

When the second stream is streaming for a duration long enough for the client to generate a MANJ value – a period of 5 to 6 seconds – the client subtracts the moving averages of the jitter of the two streams to determine which access network is the most congested and then drops the stream passing through that access network. An application layer agent was created to implement this scheme and was used for gathering the results presented below. VI.

A video server was fitted with two LAN cards and was connected to two 802.11b APs as shown in figure 7. The Client was multihomed and had two WLAN cards. Initially the server streamed two simultaneous streams of RTP packets to the Client via the two APs. The RTP streams were used to model CBR video traffic. The packets were transmitted at 30 packets per second and contained 1000 bytes of RTP data each. The client defaulted to choosing the stream via AP 1. Six background computers were used as before to generate background UDP traffic, at 1.2 Mbit/s each, to the Iperf Sink via AP1. The background computers were stationary, and were positioned away from each other and well within range of the AP. The Client remained stationary throughout the test.

∑ a t (i − j ) N

where the value of aj may be set to unity for an un-weighted average or it may decrease with increasing j to yield a weighted moving average; more specifically, it may exponentially decrease with increasing j to yield an exponentially weighted moving average. WLAN A Video Server

Client WLAN B Wire Wireless Figure 6. Soft Handover Scenario

3

A packet train–based probing scheme may also be used for a more resource efficient implementation.

BG BG

AP 1 Client AP 2

j m

BG

BG

Video Server

N −1 j =0

BG

Iperf Sink

An application layer agent then calculates a MANJ value for each stream, using the N preceding packets, so that:

MANJ (i ) =

WLAN HANDOVER RESULTS

Tests were performed to demonstrate a handover of streamed video in a congested WLAN by a stationary Client, in the metropolitan scenario described above.

Wire Wireless

Figure 7. WLAN Test Setup

At the beginning of the test only the video server transmitted packets. After 30 seconds two of the background traffic generators were activated, and the remainder were activated in succession, with one minute delay between each activation. Two minutes after the last one was activated, all of the background traffic generators were deactivated, leaving only the video server transmitting packets. The trace shown in figure 8(a) shows the delay experienced by the packets from the server that passed through AP1. The packets from the server that passed through AP2 experienced no delays. As described in the last section, the client generated a moving average of the negative jitter for each of the two streams arriving from the server. Figure 8(b) shows the resulting moving average for the stream that passed through AP1. The moving average of the negative jitter for the other

stream was zero throughout and is therefore not shown here. Figure 8(b) also shows the handover point where the moving average of the negative jitter of the two streams were compared and a handover performed. The diagram also shows that the client performed a handover to the other stream shortly after the jitter in both streams were compared. Figure 8 shows that the traffic caused by the background computers resulted in substantial packet delays in AP1, and that this resulted in the decision to handover to the other network.

ACKNOWLEDGMENTS The support of the Informatics Research initiative of Enterprise Ireland is gratefully acknowledged. Thanks also to Andrew Kelly and Tony Martinez for help in the setting up of the experiments. REFERENCES [1]

[2]

[3]

6BG 2BG

3BG

4BG

[4]

5BG [5]

3BG

4BG

5BG

[6]

[7]

Handover point

[8]

[9]

[10] Figure 8. Delay, MANJ and Handover for IPTV traffic

It is desirable to limit the frequency of handovers as the operation of handing over consumes significant network and device resources. Using a moving average of the jitter and choosing a high threshold in figure 8(c) limits the frequency of handovers.

[11]

[12] [13]

VII. CONCLUSIONS AND FUTURE WORK

[14]

In this paper we showed that substantial packet delay and packet loss can occur in a congested WLAN. We showed that jitter can be used to determine the level of congestion in a WLAN, and that this can be used to determine which stream to drop during a soft handover. We showed how a stationary Client can apply this in a congested WLAN to determine when to handover. We described a scheme that can be implemented in the Client to achieve this. Finally, we presented results showing a successful handover in a live WLAN environment.

[15]

Further investigation is planned to address some of the issues mentioned above. These include investigation of issues associated with initiating a second stream, and the number of samples in the moving average.

[16]

[17]

[18]

A. Davy, D. Botvitch and B. Jennings,”Revenue optimised IPTV admission control using empirical effective bandwidth estimation”, IEEE Trans. Broadcasting, Vol. 54, No. 3, pp 599-611, September 2008. G. M. Muntean, P. Perry and L. Murphy, “A comparison based study of quality-oriented video on demand”, IEEE Trans. Broadcasting, Vol. 53, No. 1, pp 92-102, March 2007. E. Shihab, L. Cai, F. Wan, A. Gulliver, and N. Tin, “Mesh Network for In-Home IPTV Distribution,” IEEE Network Magazine, Special Issue on Wireless Mesh Networks: Applications, Architectures and Protocols, Vol. 22, No. 1, pp. 52-57, Jan./Feb. 2008. I. Djama and T Ahmed, “A cross-layer interworking of DVB-T and WLAN for Mobile IPTV Service Delivery”, IEEE Trans. Broadcasting, Vol. 53, No. 1, pp 382-390, March 2007 L. Murphy, J. Noonan, P. Perry and J. Murphy, “An Application-qualitybased Mobility Management Scheme”, Proc. 9th IFIP/IEEE International Conference on Mobile and Wireless Communications Networks (MWCN 2007), Cork, Ireland, September 19-21, 2007. Ger Cunningham, Sean Murphy, Philip Perry and Liam Murphy,"Seamless Handover of Streamed Video over UDP Between Wireless LANs", IEEE CCNC, Consumer Communications and Networking Conference, Las Vegas, USA, January 2005. J. Villalóna, P. Cuencaa, L. Orozco-Barbosa,, and A. Garrido, “BEDCA: A QoS mechanism for multimedia communications over heterogeneous 802.11/802.11e WLANs”, Elsevier Computer Communications, Volume 31, Issue 17, Nov. 2008, pp 3905-3921 J.-P. Laulajainen, “Implementing QoS Support in a Wireless Home Network”, IEEE Wireless Communications and Networking Conference (WCNC), 2008, pp 3273-3278 D. Ciullo, M. Mellia and M. Meo, "Traditional IP measurements: What changes in a today multimedia IP network",Telecommunication Networking Workshop on QoS in Multiservice IP Networks, pp262-267, Feb. 2008. IEEE 802.11b/d3.0, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification,” August 1999. A. Mishra, M. Shin, and W. Arbaugh, “An empirical analysis of the IEEE 802.11 MAC layer handoff process,” ACM SIGCOMM Computer Communication Review, April 2003. C. Perkins, “IP mobility support,” RFC (Proposed Standard) 2002, IETF, Oct 1996. A. Stephane and A. H. Aghvami, “Fast handover schemes for future wireless IP networks: a proposal and analysis” , Proc. IEEE Vehicular Technology Conference, pp. 2046-2050, May 2001. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: session initiation protocol”, RFC 2543, IETF, Mar 1999. E. Wedlund and H. Schulzrinne, “Mobility support using SIP”, Proc. ACM WoWMoM'99, USA, pp 76-82, Aug 1999. E. Wedlund and H. Schulzrinne, “Application layer mobility using SIP”, Mobile Computing and Communications Review, Volume 1, Number 2, 2001. R. Chandra, Pr. Bahl, and Pl. Bahl, “Multinet: connecting to multiple IEEE 802.11 networks using a single wireless card”, Proc. IEEE Infocom, 2004. J. Kristiansson and P. Parnes, “Application-layer mobility support for streaming real-time media”, Proc. IEEE Wireless Communications and Networking Conference, 2004.