# Seamless Video Session Handoff between WLANs

Authors: Claudio de Castro Monteiro; Paulo Roberto de Lira Gondim; Vinícius de Miranda Rios
Journal: Journal of Computer Systems, Networks, and Communications
 (2010)

---

## Abstract

Handoff in a distributed IEEE 802.11 Wireless LAN network is a source of significant amount of problems on the video transmission environment. The visual quality of video streaming applications is lowered when stations are in handoff status. In this paper, we introduce an architecture of a session proxy (SP), which tries to preserve the quality of the streaming video upon each handoff between access points. We have evaluated thresholds of RSSI and Loss Frame Rate (LFR) for deciding the moment when the handoff process shall begin. Our solution performance was evaluated in a testbed implementation for MPEG-4 video on demand with one video server (VLS) and two FreeBSD-based access points supporting  Mobile IP, DHCP Server and IAPP approach.


---

## Body

## 1. Introduction

Nowadays, the most used pattern for WLANs by the market is IEEE 802.11 [1] and its extensions such as 802.11a [2] 802.11b [3], 802.11g [4], 802.11e [5], 802.11n [6], among others.Several studies have been conducted with the intention of analyzing the advantages and disadvantages of the use of wireless networks [7–10],  also approaching possible methods or mechanisms to avoid or reduce the problems inherent in their use.The success story of 802.11 Wireless LAN can be attributed due to its high bit rate, easy installation, and low price. The 802.11 MAC protocol originally has objective to work at the home or office environment, but nowadays the IEEE is extending the protocol towards mobile environments, with direct application for data delivery to distant access, integrating branches of the 3G technology [1]. However, currently, seamless session continuity is still out of reach, especially for video streaming applications. The first step to achieve session continuity during handoffs in WLAN was made by the IEEE 802.11f Inter Access Point Protocol (IAPP) [11], that recommend this as a good practice. In order to limit the packets loss due to the network disconnection of a wireless client during handoff, this standard recommend, the transfer of the “context” from the previous access point to the next. This technique can work very well for nonreal time applications and transport protocols such as web browsing using TCP. We will show in this paper that this is not the case for video streaming real-time applications, especially for streaming video on demand.The focus of our work is to preserve real-time video streaming session during handoff process in WLANs. For this, we analyzed fading of the wireless signal. However, in case of a handoff between two WLAN access points, a sudden loss of packet occurs and the mobile node will not be able to preserve the visual quality. That is the reason we chose to analyze the Rate Frame Loss (RFL) also, trying to identify the moment of handoff process start.We can find studies about this problem. Some use techniques of crosslayer to adapt the video quality when WLAN is congested [12]. In our network, the unique source of packet loss is handoff related.Other approaches adopt frames network retransmission, changing the ARQ mechanism, using information from link layer to adapt the frames’ retransmission [13].Here we assume that our Session Proxy (SP) and Access Points (APs) have buffer enough to store packets to overcome the delay variation and frame loss rate caused by the handoff. Thus SP always has enough data to send to AP and the AP to the mobile node (MN).In this paper we propose a solution based on a Session Proxy, located in the mobile operator network. We assume Access Points (AP) architecture with IP router, Mobile IP, and 802.11-IAPP functionalities. The SP is RTSP session aware and tries to preserve the quality streaming video, during handoff process in WLAN. We evaluated the performance of our solution and it has been compared to the standard IAPP approach. In the next sections we are going to comment about related works in the literature, our network solution architecture, experiment methodology, and testbed used and show the results. We finish with a conclusion.


## 2. Related Works

The problem caused on video quality by the handoff in WLAN has been discussed by some works. However, this problem has been divided in two parts: the part that study adaptation forms WLANs for video streams traffic; and part which studies forms to keep adaptation when a handoff process occurs. We analyze works that follow these two scenarios.In [14] is proposed a novel mechanism of RTS classification based on stations transmission rate. This work aims to control the multitransmission rate anomaly in 802.11 networks, improving video streaming quality to receivers.A proposal of novel adaptive algorithm that improves the efficiency of datagram streaming over IEEE 802.11 networks is presented in [15]. It uses the signal quality information to adapt the transmission and therefore improves the network utilization. This work estimates thresholds based on SNR and packets loss rate to adapt stream application.A proposal of a handoff study in Mobile IP networks and Mobile IP Protocol Extensions for Handoff Latency Minimization was showed in [16], indicating that native Mobile IP has high handoff latency and that its proposed to improve in 15% the performance of handoff latency.In [17] was proposed a proxy-based multimedia scheme for control Real-Time Streaming Protocol (RTSP) to support fast signaling at home network. The testbed implementation showed that the proposed scheme improves the  performance compared with RTSP in terms of latency time, but not resolve the RTSP session continuity problem. The proposal reduces latency time but the loss rate is big enough for RTSP session not to continue.A proposal of an Ethernet Soft Switch architecture to solve the problem of frame loss during handoff process at video streaming transmission is present in [18]. In this work, on-demand video streams were transmitted to mobile node while it moves between access points. In these experiments, there were limited resources and mobile node had enough cache for receive the frames in the access points. The base of the proposal is to establish different retransmissions methods for I, B, and P frames, to keep the received video stream quality.A discussion about how WLAN roaming habilities are affected by new standards is present in [19]. The standards considered were IEEE 802.11i, IEEE 802.11e, and new IEEE 802.11r. This last one was developed to address issues faced by real-time applications that implement the service’s security and quality enhancements. The performance evaluation of 802.11r prototype and the 802.11i baseline mechanisms shows a voice application using 802.11r to achieve significantly shorter transition time and reduced packet loss during AP-AP transition and can therefore realize a noticeable improvement in voice quality, but nothing is noticed about video streaming transmission.In [20], is proposed a low-latency Mobile IP handoff scheme that can reduce the handoff infrastructure’s latency mode in wireless LANs to less than 100 milliseconds. The proposal tries to resolve the mobility intra-WLAN measuring multiple AP’s signal strength working in infrastructure mode. It accelerates the detection of link-layer handoff by replaying cached foreign agent advertisements. The proposal is transparent to the Mobile IP software installed on mobile and wired nodes. The authors show how efficient the proposal is, with a mechanism of bandwidth guarantee in 802.11e-based standard wireless LAN. This implementation does not predict mobile node’s handoff, leaving this work under responsibility of IAPP mechanism. It proposes an acceleration handoff’s detection.In work developed in [21], one analytical modeling of handoff latency for FMIPv6 and HMIPv6, using WLANs as access networks, was present. This model considers factors of both link and network layer that influences the Mobile IP handoff delay. The results show an improving performance in the MIPv6, which help in the handoff process. However, the solution forces clients to have support MIPv6.In [22] is proposed a framework for multimedia delivery and adaptation in mobile environments. This work introduces the concept of Personal Address (PA), which is a network address associated to the user instead of a network interface. The proposed framework works at the network layer and it moves the PA among networks and devices to deliver media in a seamless and transparent way. The authors claim that location’s transparency sponsored by PA allows the user to receive multimedia data independent of the IP network. However, the solution presented uses Mobile IP and do not show the impact generated in the transmission multimedia session continuity, caused by implementing the entities managed by PAs.All related works studied try to resolve problems in video streams quality in 802.11 networks. Some tries to test technologies with Mobile IP, others to implement IEEE 802.11f and its recommendations, and others yet to bring new concepts with “personal address.” However, this problems increase when there is one video stream transmission during handoff process. Usually, video stream sessions have a synchronization time that does not support the handoff latency between two access points. The studies found in the literature handle problems with enlace retransmission techniques, with the separation frames types and delivering only the necessary or usually with application Mobile IP and IAPP’s technologies. Then, our solution is based on set that meets Mobile IP, IAPP, AP router based, and the Session Proxy (SP). The proposal tries to resolve the session continuity problem after handoff, ensuring the transmitted video’s quality on receiver (PSNR).


## 3. Proposal

In our proposal, we suggest the insertion, in the architecture of wireless operator, of two components: a session proxy (SP), and an 802.11 access point FreeBSD-based with IP router, DHCP server, and IAPP functionality. In Figure1, these components and its links can be seen.Figure 1
Proposed elements in our testbed scenery.


### 3.1. Functionality

The main idea is to use the SP to ensure the session’s continuity even after long periods of link’s discontinuity, using for this, the prediction of handoff of the MN, through the thresholds defined after extensive experiments detailed at session B and displayed in Table1.Table 1
Thresholds for prediction of handoff.
ALFARSSI> 40LFR< 10%PSNR> 35BETA40≥ RSSI > 30LFR< 20%29> PSNR > 26GAMA30≥ RSSILFR≥ 20%PSNR< 18Thus, the MN authenticates is associated with AP1 and receives an IP address dynamically through DHCP server. The MN requests an open session’s RTSP with the video server. This request will be received by SP, registered with the structure shown in Table2 and then forward to the video server, according with Algorithm 1.Table 2
Session registration cache structure.
Session IDService IDIP associationFrame IDAlgorithm 1:
receive_socket(socket, RTSP_request);registered_session(session_ID, RTSP, IP_MAC, 0);open_socket(socket1, IP_server);send_socket(socket1, RTSP_request);receive_socket(socket1, RTSP_response);send_socket(socket, RTSP_response);while(Session_ID< >0){receive_socket(socket, RTSP_packets);receive_socket(socket2, status, MAC_AP);if(status==1){FrameID=frame_ID;start_cache(Session_ID);}if(status< >1){send_socket(socket1, RTSP_packets);}sendcache_socket(socket1, RTSP_packets);}The video server then opens an RTSP session with the SP, which will begin to receive the frames, transferring them to AP1, which deliver it to MN. This process will continue up until the AP1 that identifies the mobile node is coming at handoff zone (where RSSI and LFR are at BETA level), starting the frame cache then indicating to SP for start frame cache also. At this point, AP1 cache frames intended to mobile node and SP cache frames intended to AP1, using the data structure shown in Table2.When the MN reaches the GAMA level, the AP1 records in the session registration cache the identifier of the last frame received by the MN and continues with the video server session open, receiving frames, inserting in the cache and transmitting to AP1, which will also be doing caching of frames received. Record done, AP1 finishes the association with the MN and informs the SP that the mobile is not in its association’s list. This fact informs to AP1 that must start transmission of frames in its cache since the last frame that was received by the MN should be sent to AP2 via IAPP.


### 3.2. Handoff Decision

To achieve these thresholds, we performed 200 video stream transfers in the MPEG-4 format, for each of the three scenarios below, that was obtained with the average results of the values expressed in Table1 and in Figures 2 and 3.Figure 2
Thresholds RSSI and PSNR levels.Figure 3
Thresholds packets LOSS levels.Thus, to predict the handoff of the mobile node, the APs uses the Algorithm2 to determine the signal levels of the link mobile, starting so the cache of frames.Algorithm 2:
l_loss=icmp_request(IP_MN);l_rssi=rssi_verify(MAC_MN);if (l_rssi<= 40  and  l_rssi>30){if(l_loss<20){send_SP(1, MAC_AP);start_cache(sessao_ID, ID_Frame);}}else if ( l_rssi<= 30){if (l_loss>= 20 ){send_SP(2,ID_Frame);handoff(MAC);start_cache(sessao_ID,ID_Frame);send_IAPP(MAC_AP, ID_Frame+1);}}…After the frames start being cached by AP1 and SP, the MN starts the GAMA level, which will have its RTSP session open with the SP discontinued and their frames will be saved in their caches. Therefore, if the MN is back to BETA level, associated with either AP1 or AP2, it will receive the video from the next frame after the last received, generating a guarantee of delivery the entire video’s contents.


## 3.1. Functionality

The main idea is to use the SP to ensure the session’s continuity even after long periods of link’s discontinuity, using for this, the prediction of handoff of the MN, through the thresholds defined after extensive experiments detailed at session B and displayed in Table1.Table 1
Thresholds for prediction of handoff.
ALFARSSI> 40LFR< 10%PSNR> 35BETA40≥ RSSI > 30LFR< 20%29> PSNR > 26GAMA30≥ RSSILFR≥ 20%PSNR< 18Thus, the MN authenticates is associated with AP1 and receives an IP address dynamically through DHCP server. The MN requests an open session’s RTSP with the video server. This request will be received by SP, registered with the structure shown in Table2 and then forward to the video server, according with Algorithm 1.Table 2
Session registration cache structure.
Session IDService IDIP associationFrame IDAlgorithm 1:
receive_socket(socket, RTSP_request);registered_session(session_ID, RTSP, IP_MAC, 0);open_socket(socket1, IP_server);send_socket(socket1, RTSP_request);receive_socket(socket1, RTSP_response);send_socket(socket, RTSP_response);while(Session_ID< >0){receive_socket(socket, RTSP_packets);receive_socket(socket2, status, MAC_AP);if(status==1){FrameID=frame_ID;start_cache(Session_ID);}if(status< >1){send_socket(socket1, RTSP_packets);}sendcache_socket(socket1, RTSP_packets);}The video server then opens an RTSP session with the SP, which will begin to receive the frames, transferring them to AP1, which deliver it to MN. This process will continue up until the AP1 that identifies the mobile node is coming at handoff zone (where RSSI and LFR are at BETA level), starting the frame cache then indicating to SP for start frame cache also. At this point, AP1 cache frames intended to mobile node and SP cache frames intended to AP1, using the data structure shown in Table2.When the MN reaches the GAMA level, the AP1 records in the session registration cache the identifier of the last frame received by the MN and continues with the video server session open, receiving frames, inserting in the cache and transmitting to AP1, which will also be doing caching of frames received. Record done, AP1 finishes the association with the MN and informs the SP that the mobile is not in its association’s list. This fact informs to AP1 that must start transmission of frames in its cache since the last frame that was received by the MN should be sent to AP2 via IAPP.


## 3.2. Handoff Decision

To achieve these thresholds, we performed 200 video stream transfers in the MPEG-4 format, for each of the three scenarios below, that was obtained with the average results of the values expressed in Table1 and in Figures 2 and 3.Figure 2
Thresholds RSSI and PSNR levels.Figure 3
Thresholds packets LOSS levels.Thus, to predict the handoff of the mobile node, the APs uses the Algorithm2 to determine the signal levels of the link mobile, starting so the cache of frames.Algorithm 2:
l_loss=icmp_request(IP_MN);l_rssi=rssi_verify(MAC_MN);if (l_rssi<= 40  and  l_rssi>30){if(l_loss<20){send_SP(1, MAC_AP);start_cache(sessao_ID, ID_Frame);}}else if ( l_rssi<= 30){if (l_loss>= 20 ){send_SP(2,ID_Frame);handoff(MAC);start_cache(sessao_ID,ID_Frame);send_IAPP(MAC_AP, ID_Frame+1);}}…After the frames start being cached by AP1 and SP, the MN starts the GAMA level, which will have its RTSP session open with the SP discontinued and their frames will be saved in their caches. Therefore, if the MN is back to BETA level, associated with either AP1 or AP2, it will receive the video from the next frame after the last received, generating a guarantee of delivery the entire video’s contents.


## 4. Testbed Scenario

To validate our proposal, we set up a scenery’s piece illustrated in Figure1. We use a set of software and hardware that generate the desired scenario’s implementation.In our testbed, we use three computers with VLS [23] doing RTSP video stream, one computer doing the SP functions, two access points FreeBSD-based with Mobile IP KAME [24], and IAPP implementations.The linksvideo servers→SP, SP→AP, and AP→AP at 100 Mbps and links AP→MN at 54 Mpbs.Each station can establish AP connection if and only if its transmission rate is equal or higher than 2 Mbps, according to selection RTS mechanism proposed for [14].The APs were configured in channels 1 and 11, respectively, to avoid adjacent channel interference.A reduced and expert version of FreeBSD operating system was developed [25] and embedded on IDE flash card. Each AP has three network interfaces: two IEEE 802.3 at 100 Mbps and one at IEEE 802.11g at 54 Mbps with Atheros chipset.For tests, we use a video file with 16.6 minutes, at MPEG-4 format. This video was stored at video server and streamed for VLS to SP at 30 fps. The video was streamed 200 times at scenarios shown in Table3. Use the UNIX ifconfig command in AP reducing RSSI levels during the time transmission in order to simulate the changes in proposed levels (MN movement). The results are the average of  these 200 transmissions.Table 3
Scenarios for obtaining of thresholds.
An AP1 at channel 10Scenario 1An AP2 at channel 09 (adjacent channel interference)An station without movement at 2 m of AP1An AP1 at channel 10Scenario 2An AP2 at channel 09 (adjacent channel interference)An station without movement at 10 m of AP1An AP1 at channel 10Scenario 3An AP2 at channel 09 (adjacent channel interference)An station without movement at 25 m of AP1


## 5. Obtained Results

After the experiments, notice that the farther from the AP is MN, in other words, approaching the limits of his cell, the MN has reduced its level of RSSI. In the configured environment with Mobile IP and IAPP, the level of the MN's RSSI reaches zero at the physical handoff, recovering their intensity once MN is associated to the new AP.The time between the link-off of the old AP and link-on in the new AP, taking into account its authentication, combined with the time taken by the DHCP server to provide an IP address to the MN and the time of negotiation between the HA and FA was in our experiment, about 10 seconds, enough time to RTSP started session with the server to be closed by an absolute inability of the protocol to resequence the frames lost (in the case30fps×10s=300frames).Thus, without the application of SP, proposed in this work, the level packets loss generated by the handoff between APs reaches 1500 frames in the interval of 50 seconds, showing a total connection loss. After the handoff done, the RTSP session is lost and the frames’ level lost does not recover anymore, remaining in 1500, as shown in Figure4.Figure 4
Average of number of loss frames during transmissions without and with proposal.The visual impact on the quality of received video is large. Considering that the PSNR measured every 50 seconds of transmission can be seen in Figure5; after the handoff, the PSNR values remain at zero until the end of transmission, considering the permanent loss session’s RTSP.Figure 5
Average of PSNR and RSSI during transmissions without and with proposal.While analyzing Figures4 and 5, we can see that with the implementation of our proposal the frame loss is not prevented during the handoff, but we signal to the SP and the APs, to the cache of frames transmitted to the MN, delivering the same to it, as soon as the association with the other AP is complete and that the RSSI level is sufficient (BETA level). This allows the packets lost recovery, reducing the frame loss’ rate after the handoff, so MN receives the frames that was not received during the connection discontinuation. This increases the average PSNR of the video forwarded, monitored in the transmission each 50 seconds.In Figure6 is shown an example of sequence frames received before and after handoff, between 400 and 600 seconds. MN receives the frame 13170 at 439. After this time, MN entering in GAMA level ends the AP that does not send next frames. Without our proposal implementation, notice that PSNR measured at Figure 5 remains in zero after 450 seconds, due to high-loss frame.Video sequence after and before handoff without proposal.
(a)(b)Moreover, Figure7 shows other sequence frames, with our proposal implementation. Note that different frames continue being received, increasing the PSNR values. The same way, at 400 seconds, the MN receives frame 13170. After this time, our SP mechanism works the cache frames. Then, after 490 seconds, the MN reaches the acceptable BETA RSSI level (after handoff) and receives the frames 13171 and all others from the video.Video sequence after and before handoff with proposal.
(a)(b)We can verify that the advantage of our proposal is preserve the continuity session, ensuring that user in MN receive all video’s content.


## 6. Conclusions

After experiments being conducted, we concluded that during handoff between access points, the use of IAPP and Mobile IP is not sufficient to solve continuity frames problems, as a result of long time passed during handoff, generating high packet loss. The SP’s idea brought higher implementation flexibility, considering that it acts in networks level, receiving physical level information to decide the moment that comes before physical handoff.Our proposal offers a good solution for IPTV scenarios, with delivery video-on-demand and live transmissions (without interaction) at last miles, where users can move it between APs forming BSSs (typically airports, bus stations, shoppings, university campus, etc).As future works, we can quote the application of our proposal in ubiquitous environment, considering two access networks: UMTS and WLAN. We want to show that SP implementation works well with heterogeneous networks too, taking that implements the level sensitivity at mobile node.



---

*Source: 602973-2010-03-17.xml*