F
ACULDADE DEE
NGENHARIA DAU
NIVERSIDADE DOP
ORTORemote Control of Unmanned Aerial
Vehicles Through the Internet and
IEEE 802.11
André Filipe Pinto Coelho
Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Supervisor: Prof. Manuel Alberto Pereira Ricardo
Co-Supervisor: Jaime Sousa Dias Co-Supervisor: Rui Lopes Campos
c
Abstract
In recent years, the advances in miniaturisation technologies, such as control systems, sens-ing, batteries and communication devices, have allowed the exponential development of small and low cost Unmanned Aerial Vehicles (UAVs), which can be used in different activity areas. Typ-ically, the UAV needs to be in line-of-sight, in order to be controlled, because usually there are no other ways to know the UAV position and surrounding obstacles in real-time. This can limit considerably the user experience and usage scenarios. On the other hand, IEEE 802.11 is wide-spreading, offering indoor but also outdoor coverage, paving the way as an alternative to cellular networks. Yet, the main challenges of using IEEE 802.11 networks for mobile communications is intermittent connectivity, high handover delays, or lack of handover support.
In recent years, many solutions related to remote control of UAVs were proposed. However, they are either based on mobile operator networks or on IEEE 802.11 networks, in most cases with a single Access Point (AP). None of the solutions rely on remote control through the Internet and IEEE 802.11 networks with multiple APs belonging to different IP networks. There is a lack of solutions enabling remote control of UAVs through the Internet and over large areas, based on IEEE 802.11 networks, possibly belonging to different IP networks.
In order to address this problem, a solution to enable remote control of UAVs through TCP/IP over IEEE 802.11 from a remote Control Station (CS) is presented in this Dissertation. Firstly, a UAV’s real-time control module, which enables users to control the UAV in real-time using the CS’s keyboard, was developed. Additionally, to allow fast handovers between IEEE 802.11 APs belonging to different IP networks, an Internet Protocol Security (IPsec) based solution, using the version two of Internet Key Exchange (IKEv2) protocol and the IKE Mobility and Multihoming (MOBIKE) protocol, was implemented. The UAV is able to stream to CS a real-time video cap-tured by an on-board video-camera. On the other hand, the CS is be able to communicate with the UAV’s Autopilot and exchange messages, in real-time, using the Micro Air Vehicle Communica-tion (MAVLink) protocol.
To validate the UAV’s real-time control module, the Software In the Loop (SITL) was used, which provides a graphical representation of the behaviour of the control module, in response to the users inputs. Moreover, in order to evaluate the proposed solution in real scenarios, two testbed were designed – indoor and outdoor testbeds. In both testbeds, experimental results validate the proposed solution, and show handover delays compatible with real-time video streaming.
Resumo
Nos últimos anos, o fabrico de componentes eletrónicos cada vez mais pequenos, tais como sistemas de controlo, sensores, baterias e dispositivos de comunicação, permitiu o desenvolvi-mento exponencial de pequenos veículos aéreos não tripulados (UAVs), a preços acessíveis, que podem ser utilizados em diferentes áreas de atividade. Tipicamente, é necessário manter o UAV em linha de vista, de modo a este poder ser controlado, uma vez que, geralmente, esta é a única forma de saber, em tempo real, a sua posição e os obstáculos circundantes. Isto pode limitar, consideravelmente, a experiência do utilizador e os cenários de utilização. Por outro lado, IEEE 802.11 é amplamente utilizado, oferecendo cobertura dentro de edifícios, mas também em ambi-entes exteriores, constituindo-se, assim, uma alternativa às redes celulares. Contudo, os principais desafios do uso de redes IEEE 802.11 para comunicações móveis são a conectividade intermitente, os elevados atrasos de handover, ou a falta de suporte para o handover.
Nos últimos anos, foram propostas muitas soluções que permitem o controlo remoto de UAVs, contudo estas são baseadas em redes de operadores móveis, ou em redes IEEE 802.11, em muitos casos, com apenas um Access Point (AP). Nenhuma das soluções se baseia no controlo remoto sobre a Internet, em redes IEEE 802.11 com múltiplos APs pertencentes a diferentes redes IP. Assim, existe uma falta de soluções para o controlo remoto de UAVs via Internet e ao longo de largas áreas, tendo por base redes IEEE 802.11, possivelmente pertencentes a diferentes redes IP.
Para resolver este problema, é apresentada nesta Dissertação uma solução para permitir o con-trolo remoto de UAVs sobre TCP/IP através de 802.11, a partir de uma estação de concon-trolo (CS) remota. Em primeiro lugar, foi desenvolvido um módulo de controlo que permite aos utilizadores controlar um UAV em tempo-real usando o teclado da CS. Adicionalmente, para permitir rápi-dos handovers entre APs IEEE 802.11 pertencentes a diferentes redes IP, foi implementada uma solução baseada em Internet Protocol Security (IPsec), usando a versão 2 do protocolo Internet Key Exchange(IKEv2) e o protocolo IKE Mobility and Multihoming (MOBIKE). O UAV está ha-bilitado a enviar para a CS, em tempo-real, um fluxo de vídeo capturado por uma câmara de vídeo a bordo. Por outro lado, a CS é capaz de comunicar com o Autopilot do UAV e trocar mensagens com este, em tempo-real, usando o protocolo Micro Air Vehicle Communication (MAVLink).
Para validar o módulo de controlo do UAV, foi usado o simulador Software In The Loop (SITL), que permite uma representação gráfica do comportamento do módulo de controlo, em resposta às entradas dos utilizadores. Além disso, para validar a solução proposta em cenários reais, foram projetados dois testbeds – testbeds interior e exterior. Em ambos os testbeds, resultados experi-mentais validam a solução proposta, e mostram atrasos de handover compatíveis com a transmis-são de vídeo em tempo-real.
Acknowledgments
First, I would like to express my gratitude to my supervisors, Professor Manuel Ricardo, Jaime Dias, and Rui Campos, for allowing me to join this interesting and challenging project, and for having me integrated in the Wireless Networks (WiN) research group, at the Centre for Telecom-munications and Multimedia (CTM) of INESC TEC. I would also like to thank for their guidance, support, suggestions, and for all the valuable knowledge transmitted during this Dissertation.
To Eduardo Almeida, my sincere gratitude for his permanent availability to discuss my work, for his suggestions to improve it, and for helping me in the field tests.
I would also like to thank to all elements of the WiN research group, for the help gave during this Dissertation, by providing components for the testbed, and sometimes helping me to solve some problems.
Finally, a special thanks to my family and friends for their unconditional support throughout this Dissertation.
André Filipe Pinto Coelho
“There is a driving force more powerful than steam, electricity and atomic energy: the will.”
Albert Einstein
Contents
1 Introduction 1
1.1 Context . . . 1
1.2 Motivation and Problem . . . 2
1.3 Objectives . . . 2
1.4 Document Structure . . . 3
2 State of the Art 5 2.1 IEEE 802.11 . . . 5
2.2 Mobility Management . . . 6
2.2.1 Handover Approaches . . . 6
2.2.2 Scanning Methods . . . 8
2.2.3 Authentication . . . 8
2.2.4 Integrity and Security . . . 9
2.2.5 Low Latency Handover Solutions . . . 10
2.2.6 Mobile IPv4 (MIPv4) . . . 13
2.2.7 Mobile IPv6 (MIPv6) . . . 14
2.2.8 Handoff-Aware Wireless Access Internet Infrastructure (HAWAII) . . . . 16
2.3 IP Mobility Support for Vehicular Networks . . . 17
2.3.1 Vehicle-to-Vehicle (V2V) versus Vehicle-to-Infrastructure (V2I) Commu-nications . . . 17
2.3.2 NEtwork MObility (NEMO) Support Solutions . . . 17
2.4 Video Streaming . . . 17 2.4.1 Streaming Protocols . . . 18 2.4.2 Codecs . . . 19 2.5 Related Work . . . 20 2.6 Summary . . . 22 3 Proposed Solution 25 3.1 System Architecture . . . 25 3.1.1 UAV . . . 25 3.1.2 IEEE 802.11 APs . . . 25 3.1.3 Gateway . . . 26 3.1.4 Control Station (CS) . . . 27 3.2 Communication Protocol . . . 27 3.2.1 MAVLink Protocol . . . 27
3.2.2 Communication Link Between UAV and CS . . . 28
3.2.3 Real-time Video . . . 29
3.2.4 Mobility Management . . . 29
x CONTENTS
3.3 UAV Movement Control . . . 30
4 Implementation 31 4.1 Software . . . 31
4.1.1 Flight Stack . . . 31
4.1.2 Ground Control Station (GCS) . . . 32
4.1.3 Media Software . . . 33
4.1.4 IPsec-based VPN Software . . . 35
4.1.5 UAV Simulator . . . 35
4.1.6 Control Code for UAVs . . . 36
4.2 Hardware . . . 36
4.2.1 UAV . . . 37
4.2.2 Autopilot . . . 37
4.2.3 Radio Controller (RC) . . . 38
4.2.4 GPS and Compass . . . 38
4.2.5 IEEE 802.11 Network Card . . . 38
4.2.6 Video-Camera . . . 39
4.2.7 Gateway . . . 39
4.2.8 IEEE 802.11 APs . . . 40
4.2.9 Control Station (CS) . . . 41
4.3 UAV’s Real-time Control Module . . . 41
4.3.1 Development . . . 41
4.3.2 Simulation . . . 43
4.4 Integration and Configuration . . . 44
4.4.1 Erle-Copter Assembly . . . 44
4.4.2 Erle-Brain 2 Setup . . . 46
4.4.3 Gateway Setup . . . 46
4.4.4 Control Station (CS) Setup . . . 47
4.4.5 strongSwan Configuration . . . 48
5 Experimental Evaluation 51 5.1 Experimental Scenarios . . . 51
5.2 Testbeds . . . 51
5.2.1 Indoor Testbed Setup . . . 53
5.2.2 Outdoor Testbed Setup . . . 53
5.2.3 Network Configuration . . . 54 5.3 Performed Tests . . . 55 5.4 Test Results . . . 55 5.4.1 Packet Rate . . . 55 5.4.2 ICMP Ping . . . 56 5.4.3 Packet Lenghts . . . 59
5.4.4 Performance Results Summary . . . 60
5.5 Discussion . . . 61
6 Conclusion 63
List of Figures
1.1 Illustration of the remote control system with the UAV, remote CS, and IEEE 802.11 APs. The CS is a PC with a network interface connected to the Internet . 3
2.1 Three phases during an handover procedure, without considering protocol specific
issues . . . 8
2.2 RADIUS authentication procedure . . . 9
2.3 TCP connection release procedure . . . 11
2.4 Two wait states introduced in the handover procedure . . . 12
2.5 Implementation of the two-interface dynamic algorithm . . . 14
2.6 A Mobile IPv4 Network Architecture . . . 15
2.7 A Mobile IPv6 System Architecture . . . 16
2.8 V2V and V2I communication . . . 18
2.9 Buffer occupancy for a video: Consumption Rate (CR) versus Block Transmission (BT) . . . 20
3.1 Remote Control System Architecture . . . 26
3.2 MAVLink frame . . . 28
3.3 Local NED coordinate system . . . 30
4.1 APM Planner 2.0 main screen . . . 33
4.2 Erle-Copter . . . 37
4.3 Erle-Brain 2 . . . 37
4.4 RC transmitter (on top) and receiver (on bottom) . . . 38
4.5 GPS Neo-M8N and compass . . . 38
4.6 Edimax EW-7811 UTC . . . 39
4.7 Raspberry Pi NoIR Camera . . . 39
4.8 Raspberry Pi model B . . . 40
4.9 Wireless Dual Band Gigabit Router series . . . 40
4.10 Behaviour of the UAV’s real-time control module. The red line represents the trajectory tracked by the UAV, in response to the user inputs . . . 43
4.11 Log of the actions performed by the UAV . . . 44
4.13 Erle-Copter Assembly . . . 45
4.12 Motor order diagram . . . 45
5.1 Experimental Scenario A – single IP network . . . 52
5.2 Experimental Scenario B – an IP network per IEEE 802.11 AP . . . 52
5.3 Final indoor testbed . . . 53
5.4 Final outdoor testbed . . . 54
5.5 Packet Rate in scenario of a single IP network, indoor . . . 55
xii LIST OF FIGURES
5.6 Packet Rate in scenario of a single IP network, outdoor . . . 56
5.7 Packet Rate in scenario of an IP network per AP, indoor . . . 56
5.8 Packet Rate in scenario of an IP network per AP, outdoor . . . 56
5.9 ICMP RTT over time in scenario of a single IP network, indoor . . . 57
5.10 ICMP RTT over time in scenario of a single IP network, outdoor . . . 57
5.11 ICMP RTT over time in scenario of an IP network per AP, indoor . . . 57
5.12 ICMP RTT over time in scenario of an IP network per AP, outdoor . . . 58
5.13 ICMP RTT histogram in scenario of a single IP network, indoor . . . 58
5.14 ICMP RTT histogram in scenario of a single IP network, outdoor . . . 58
5.15 ICMP RTT histogram in scenario of an IP network per AP, indoor . . . 59
5.16 ICMP RTT histogram in scenario of an IP network per AP, outdoor . . . 59
5.17 Packet Lengths histogram in scenario of a single IP network, indoor . . . 59
5.18 Packet Lengths histogram in scenario of a single IP network, outdoor . . . 60
5.19 Packet Lengths histogram in scenario of an IP network per AP, indoor . . . 60
List of Tables
2.1 Wireless Local Area Network (WLAN) Throughput by IEEE Standard . . . 7
5.1 Packet Rate Results Summary . . . 61
5.2 ICMP Results Summary . . . 61
5.3 Packet Length Results Summary . . . 61
List of Algorithms
1 UAV’s real-time control module . . . 42
Acronyms
AES Advanced Encryption Standard AH Authentication Header
AP Access Point
API Application Programming Interface APM ArduPilot Mega
AR Access Router
ARP Address Resolution Protocol AVC Advanced Video Coding BER Bit Error Rate
BS Base Station BU Binding Update
CDMA Code Division Multiple Access CN Correspondent Node
CoA Care of Address CS Control Station
DAD Duplicate Address Detection
DHCP Dynamic Host Configuration Protocol DPD Dead Peer Detection
DSP Digital Signal Processing
EAP Extensible Authentication Protocol ESC Electronic Speed Controller ESP Encapsulating Security Payload ESSID Extended Service Set Identification FA Foreign Agent
FBN Flying Backhaul Network
FCC States Federal Communications Commission FMIPv6 Fast Handovers for Mobile IP version 6 FN Foreign Network
GCS Ground Control Station
GIMP GNU Image Manipulation Program GOP Group Of Pictures
GPL General Public License GPS Global Positioning System
GSM Global System for Mobile Communications GTK+ GIMP Toolkit
GUI Graphical User Interface
HA Home Agent
HAWAII Handoff-Aware Wireless Access Internet Infrastructure xvii
xviii ACRONYMS
HMIPv6 Hierarchical Mobile IP version 6 HN Home Network
HTTP HyperText Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force
IGW Internet Gateway IKE Internet Key Exchange IoT Internet-of-Things IP Internet Protocol
IPsec Internet Protocol Security ISM Industrial, Medical and Scientific ISP Internet Service Provider
ITU International Telecommunications Union JPEG Joint Photographic Experts Group L2TP Layer-2 Tunneling Protocol LAN Local Area Network LDPC Low-Density Parity Check LGPL Lesser GPL
MAC Medium Access Control
MACSAP Media Access Control Layer Service Access Point MANET Mobile Ad Hoc Network
MAVLink Micro Air Vehicle Communication Protocol MIMO Multiple-Input and Multiple-Output
MIPS Microprocessor without Interlocked Pipeline Stages MIPv4 Mobile IP version 4
MIPv6 Mobile IP version 6
MJPEG Motion Joint Photographic Experts Group MMS Microsoft Media Server
MN Mobile Node
MOBIKE IKE Mobility and Multihoming Protocol MPEG Moving Picture Experts Group
NAT Network Address Translation NED North-East-Down
NEMO BS Network Mobility Basic Support Protocol NoIR No Infrared
OBU On Board Unit
OCS On-board Communication Station
OFDM Orthogonal Frequency Division Multiplexing OSI Open Systems Interconnection
OTA Over-The-Air PC Personal Computer PCB Printed Circuit Board PHY Physical Layer
PMIPv6 Proxy Mobile IP version 6 PSK Pre-Shared Key
ACRONYMS xix
QoS Quality of Service
RADIUS Remote Authentication Dial In User Service RC Radio Controller
ROS Robot Operating System
RSSI Received Signal Strength Indicator RSU RoadSide Units
RSVP Resource reSerVation Protocol RTP Real-time Transport Protocol RTPCP RTP Control Protocol
RTSP Real Time Streaming Protocol RTT Round Trip Time
SA Security Association SAP Service Access Point SaaS Software-as-a-Service
SDM Spartial Division Multiplexing SISO Single-Input and Single-Output SITL Software In The Loop
SoC System on a Chip SSID Service Set IDentifier SVC Scalable Video Coding TCP Transmission Control Protocol TDMA Time Division Multiple Access TKIP Temporal Key Integrity Protocol UAV Unmanned Aerial Vehicle UDP User Datagram Protocol UGV Unmanned Ground Vehicle
UMTS Universal Mobile Telecommunications System V2I Vehicle-to-Infrastructure
V2V Vehicle-to-Vehicle
VANET Vehicular Ad Hoc Network VLC VideoLAN Client
VPN Virtual Private Network WEP Wired Equivalent Privacy WGS World Geodetic System WLAN Wireless Local Area Network WPA Wi-Fi Protected Access WPS Wi-Fi Protected Setup XML eXtensible Markup Language
Chapter 1
Introduction
1.1
Context
Nowadays, Unmanned Aerial Vehicles (UAVs) have become popular, for instance, for tasks where security and safety of humans can not be guaranteed. Due to the absence of human pilots on-board, UAVs can perform many tasks with reduced cost, lower danger, and higher performance. Some examples are surveillance and reconnaissance, fire-fighting and rescue, remote sensing and exploration, pesticide spraying and geophysical survey, logistics and payload transport, and ad-hoc communication gateways [1]. Moreover, with the dissemination of the Internet-of-Things (IoT) paradigm, UAVs are also finding their way into those services, and are being used, for instance, in live video streaming applications [2], in Flying Backhaul Networks (FBNs) providing broadband Internet access dynamically self-configured according to the users’ needs [3], and to carry sensors that measure anything, anywhere [4]. However, due to the particularities of such tasks, fully autonomous systems might not be suitable. To perform those tasks, a better solution is the use of semi-autonomous vehicles, equipped with cameras and any other suitable equipment, remotely controlled by humans. Additionally, in terms of regulation, autonomous UAVs are currently not authorised for use in many countries, and public authorities, including the European Union, do not currently seek to regulate them [5].
IEEE 802.11 is widely adopted and rapidly evolving to provide ever-increasing data through-put capabilities, bandwidth and efficiency of the modulation, being nowadays largely used in busi-ness and personal applications, and regarded as a fundamental technology. Generally, it is cheap, readily available, well understood by developers, and widely supported by software and operating systems [6], resulting in a rapidly increasing number of devices that connect to the Internet using it, namely laptops, smartphones, tablets, embedded computers (e.g. Raspberry Pi), and wearable devices (e.g. smartwatches) [3,7].
It is in this context that an IEEE 802.11 based solution is proposed to support the commu-nication between a Control Station (CS) and a UAV through the Internet, intending itself as an alternative to the existing commercial solutions based on proprietary control protocols, and to ad-dress the lack of remote control solutions that exploit (1) the rising popularity of UAVs and (2) the
2 Introduction
ubiquity of IEEE 802.11 networks.
1.2
Motivation and Problem
When controlling a UAV, it is crucial for the remote user to be able to control the vehicle with a real-time perception of its position and possible approach to obstacles. For this to happen, both the Internet connection and the IEEE 802.11 network access to the UAV must have (a) low latency and (b) low packet loss to transport control commands between the CS and the UAV and real-time video feeds from the UAV to the CS. Real-time video streaming usually requires a lot of bandwidth, and the link degradation causes strong video loss [6] – a single missing packet can cause the loss of seconds of video data – letting the controlling user blind to the surrounding of the UAV. This is particularly difficult during handovers because the large majority of IEEE 802.11 networks do not implement any fast handover solution between APs, thus disrupting the communication between the CS and the UAV, especially if the IEEE 802.11 APs belong to different IP networks.
In recent years, many solutions related with remote control of UAVs were proposed [8], how-ever they are either based on mobile operator networks, or on IEEE 802.11 networks, in most cases, with just one Access Point (AP), but none of the solutions rely on remote control through the Internet and IEEE 802.11 networks with multiple APs. So, there is a lack of solutions to im-plement remote control of UAVs through the Internet and over large areas, based on IEEE 802.11.
1.3
Objectives
The main objective of this Dissertation is to develop a solution for remote control of UAVs through the Internet and IEEE 802.11 networks formed by multiple APs belonging to different IP networks, using off-the-shelf UAVs and open-source platforms. To achieve this, the following specific objectives are defined:
• Develop a control module, allowing the user to control the UAV, in real-time, from a remote CS.
• Develop a solution that enables video streaming from the UAV to a remote CS.
• Implement an IEEE 802.11 fast handover solution that allows real-time and low packet loss ratio.
• Validate the implemented solution.
The system proposed by this Dissertation is summarized by the remote control system depicted in Figure1.1.
1.4 Document Structure 3
Figure 1.1: Illustration of the remote control system with the UAV, remote CS, and IEEE 802.11 APs. The remote CS is a PC with a network interface connected to the Internet [9,10].
1.4
Document Structure
The remainder of this document is organized as follows. Chapter2presents the state of the art on the most important topics related to this Dissertation, including the evolution and descrip-tion of IEEE 802.11 standard, mobility management, IP mobility support for vehicular networks, video streaming protocols and codecs. Chapter 3presents the proposed solution to address the goals of this Dissertation. In Chapter4, we describe the implementation of the proposed solution, with focus on the used software, selected hardware components, developed UAV’s real-time con-trol module, and integration and configuration of all the components forming the designed remote control system. Chapter5presents two experimental scenarios with different network configura-tions, in order to evaluate the fast handover solution between IEEE 802.11 APs, and two testbeds designed to validate the implemented solution in laboratory and field environments. The obtained results after several laboratory and field tests are also detailed and discussed. Finally, in Chapter6, we review all the work developed, present the most relevant conclusions, and foresee future work.
Chapter 2
State of the Art
This chapter presents a review of the state of the art on the most important topics related to this Dissertation. In Section2.1, the evolution of the IEEE 802.11 standard is presented, namely the main improvements, and used technologies. After that, in Section2.2, a review about mobility management is made, namely considering handover procedures, authentication methods, integrity and security, and low latency handover solutions. In Section2.3, a survey of the major IP mobility support solutions that have been proposed for vehicular networks is made. Section2.4describes the main streaming protocols and codecs used nowadays. Then, Section2.5 makes a description of the related work. Lastly, in Section2.6, we summarize the state of the art reviewed.
2.1
IEEE 802.11
IEEE 802.11 was born in 1985, when States Federal Communications Commission (FCC) opened several bands of the wireless spectrum for use without government license. To operate in these bands devices were required to use spread spectrum technology, which spreads a radio signal out over a radio range of frequencies, minimising interferences and interceptions of the signal [11]. In 1990, a new IEEE committee, named IEEE 802.11, was founded to create an open stan-dard. The success with wireless devices was so high that, when the new standard was published (in 1997), they were already shipping. The original IEEE 802.11 standard provided three ini-tial specifications for the physical layer, two of which described radio-based PHYs employing a 2.4 GHz carrier. The standard defines, basically, an over-the-air interface between a wireless client and an AP, or between two or more clients. The original standard was designed to support 1 and 2 Mbit/s data rates, however, along the years, it suffered several improvements, and some become known by the name of amendments. Three examples are: IEEE 802.11b, IEEE 802.11g and IEEE 802.11n. Each of these amendments defines a maximum speed of operation, the radio frequency band of operation, how data is encoded for transmission, and the characteristics of the transmitters and receivers. The first two amendments were IEEE 802.11a – which operates in the available 5 GHz bands (5.15-5.35 GHz, 5.47-5.725 GHz, and 5.725-5.825 GHz) – and IEEE 802.11b – which operates in the Industrial, Medical and Scientific (ISM) band (2.4 GHz). IEEE
6 State of the Art
802.11b extended data rates up to 11 Mbit/s, however the throughput achieved in practice did not exceed 5 Mbit/s, which is insufficient for many video-based applications. IEEE 802.11a defined a new radio-based PHY using Orthogonal Frequency Division Multiplexing (OFDM), allowing data rates up to 54 Mbit/s [11].
Nevertheless, it was concluded that it was impossible manufacturing devices capable of to support both 2.4 and 5.2 GHz technologies. IEEE 802.11g was developed with PHY specifications similar to those of IEEE 802.11a, but operating on a 2.4 GHz carrier. Although IEEE 802.11g has good performance for most applications, the additional need of high-quality video streaming for multiple users motivated the development of IEEE 802.11n. IEEE 802.11n includes enhancements to both physical and medium access control (MAC) layers, including modifications to the PHY layer.
The IEEE 802.11n solution is fast, but not enough to handle the growing number of devices connected to an AP and with users requirements to high performances in activities such as video streaming and game play. Regarding these challenges, a study group to work on the next IEEE 802.11 amendment was formed, in 2007. IEEE 802.11ac and IEEE 802.11ad were the ones pro-posed for development. IEEE 802.11ac is designed to use the 5 GHz spectrum, which is less susceptible for signal interferences than the 2.4 GHz spectrum, which is congested by current wireless communications. On the other hand, IEEE 802.11ad uses the 60 GHz spectrum, which has even more room to allocate different communications channels side by side. This version al-lows a delivery rate up to 7 Gbit/s, however it is easily obstructed by air, water and walls, hence the best performance is reached only for short distances [11]. The throughput values by IEEE standard versions are presented in Table2.1.
2.2
Mobility Management
In mobile radio systems, handover (or handoff) consists in the process by which a mobile terminal changes actual communication channel, in order to maintain the communication in the best conditions as possible. In the literature, despite the stated IP mobility solutions for general vehicular networks (which will be presented in Section2.3), there is not much information about the handover procedures in the context of UAVs [12]. So, as a starting point, we analysed what happens in other network systems that need similar handover procedures. Some examples are [12]: • GSM. Before the association between the mobile terminal and the new base station be established, the old one must be released. The Quality of Service (QoS), in this case, is dependent of the speed which the transaction is made.
• UMTS. It can receive signals from multiple cells, simultaneously. So, instead of a instant release, the resource is maintained until be verified the reliability of a new channel.
2.2.1 Handover Approaches
2.2 Mobility Management 7
Table 2.1: Wireless Local Area Network (WLAN) Throughput by IEEE Standard [11]. IEEE WLAN Standard Over-the-Air (OTA) Esti-mates Media Access Control Layer, Service Access Point (MAC SAP) Estimates IEEE 802.11b 11 Mbit/s 5 Mbit/s
IEEE 802.11g 54 Mbit/s 25 Mbit/s (when IEEE 802.11b is not present) IEEE 802.11a 54 Mbit/s 25 Mbit/s IEEE 802.11n Up to 600 Mbit/s Up to 400 Mbit/s IEEE 802.11ac Up to 867 Mbit/s with 2 antennas and 80 MHz; Up to 1.3 Gbit/s with 3 antennas and 80 MHz Up to 600 Mbit/s with 2 antennas and 80 MHz; Up to 900 Mbit/s with 3 antennas and 80 MHz
IEEE 802.11ad At least 1.1 Gbit/s (up to 4.6 Gbit/s in some first generation products) Up to 700 Mbit/s for 1.1 Gbit/s OTA (up to 3 Gbit/s for 4.6 Gbit/s OTA)
• Hard radio handover approach. Radio handover is done in break-before-make mode. Mobile terminal stops the communication on the old channel and immediately joins the new channel. If the mobile terminal does not receive a feedback on new channel, it re-joins to the old one – "ping-pong" effect.
• Soft radio handover approach. Radio joins to a new channel before, and only if the QoS is acceptable it releases the old one.
In WLAN context, the handover is the procedure by which a terminal moves its association from an AP to another one. The operations performed are the following [12]:
• Scanning for new APs in the area.
• Authentication messages exchange with the new found AP.
• Re-association messages exchange to establish connection with the new AP.
These phases are illustrated in Figure2.1, where Mobile Node (MN) represents, in this context, the UAV.
8 State of the Art
same network and extended service set, ESS. Due to
this implementation the handover is not controllable
by the user and the timing is unpredictable. This
paper contains an outline of the critical aspect in a
handover procedure, and propose two methods that
ensures a low handover time. In the following, a GS
is denoted a Host and the UAV is denoted a Mobile
Node, MN, to generalise the approach in this paper.
Related Work
Prior research related to handover procedures
in-volves several types of handovers; some relies on
changes in the link layer (L2) and other introduces
changes in the network layer (L3) of the OSI model.
A method implementing a L3 handover mechanism, is
Mobile IP. Mobile IP requires a Home Agent to
mana-ge the routing of traffic to the MN and offers roaming
throughout e.g. the internet, by letting the MN act as
it is located in its home network. However, this
proto-col does not provide low latency handovers, as it relies
on the existing link layer [2] [7]. Other approaches to
improve the handover latency introduces changes in
the implementation of the link layer. Common issues
for all approaches are long scan time [4], which some of
the methods handle by caching available APs based on
channel-wise scanning [6]. However, these approaches
require hardware, supported by advanced open source
drivers as MadWifi or HostAP and all violates the
IEEE 802.11 standard specifying scan of all channels
when performing active scanning [3].
II
Handover
Method
Using
Static
Timing
A handover in an IEEE 802.11 wireless network
can generally be divided into three separate phases:
Scanning, authentication, and association [1]. These
phases are illustrated in Figure 2. The figure shows the
handover procedure, where a data stream to a Host is
interrupted by the handover and passed on to a new
Host connected through a new AP.
By manually configuring the MAC addresses and
frequencies of the APs, an active scanning to locate
available APs during a handover should be avoided.
However, this obviously requires that the MAC
ad-dress and frequency of any AP is known in advance,
and does not entirely ensure that no scanning takes
place during the handover. This is due to the
oc-casional scanning performed by the wireless network
interface card, in order to cache available APs in its
vicinity. This is shown as the scan event in Figure 2.
Data Time MN Probe Request 1 Probe Response 1 Authentication Request Authentication Response Reassociation Response Reassociation Request Data Probe Request 14 Probe Response 14 Sc a n Ass ociati on Probe Request 1 Probe Response 1 Probe Request 14 Probe Response 14 Au th en tic a tion Host (new) AP (old) AP (new) Host (old)
Figure 2: Event diagram for a normal handover showing the three phases during a handover procedure, without considering protocol specific issues.
The MN can authenticate with an AP either by
means of a shared key, or without any authentication.
The latter only involves a 2-way handshake as shown
in Figure 2. By not using any authentication in the
handover procedure, a fast negotiation between the
MN and the AP is ensured.
First Timing Issue
When performing a handover, two points in the
pro-cedure are time critical. The first timing issue occurs
when the first connection is closed, initiating the
hand-over. If the close command for the TCP connection
is not completed properly before proceeding with the
handover procedure, the handover is prolonged.
Figu-re 3 illustrates the process of a TCP connection Figu-release
used when closing a TCP connection.
Time
ACK
FIN, ACK
ACK FIN, ACK
Mobile node Host
Figure 3: Event diagram for the TCP connection release pro-cedure.
If timing is not considered the <ACK> and
<FIN, ACK>
from the Host is not received at the MN,
and the TCP protocol repeatedly inquires for the
mis-sing response from the Host.
This timing issue is
solved by introducing a wait state, wait 1, before
switching to another AP as illustrated in Figure 4.
2
Figure 2.1: Three phases during an handover procedure, without considering protocol specific issues [13].
2.2.2 Scanning Methods
In WLANs context there are two scanning methods: passive scan methods, and active scan methods [14].
In passive scan, the client listens to the wireless medium for beacon frames from all APs, on a specific channel, and for intervals of 100 ms. Next, the client switches to another channel and selects the AP with best Received Signal Strength Indicator (RSSI) [14].
By the other side, in the active scan, the client broadcasts a probe request frame to all APs into range. In turn, the recipient AP will send a response, that will be used by the client to chose the AP to connect. If no response is received, the client waits during a MinChannelTime, which is around 33 ms. To receive the probe response messages the client waits for a MaxChannelTime, which is around 55 ms. Active scan mode has, typically, a lower latency associated of about 35 ms per channel, being the best option for real-time applications. However, the latency associated to that mode is dependent of two variables: the number of scanned channels, and the waiting time per channel [14].
2.2.3 Authentication
The authentication in IEEE 802.11 can be made by two primitive methods: open-system au-thentication and shared key auau-thentication. The client, after select the AP, sends an auau-thentication message with its identity. The AP will send an authentication response message indicating the rejecting or acceptance. If accepted, the client will transmit, embedded in an association request, some informations, like data rate and Service Set IDentifier (SSID), and waits for an association response. This four-way handshake is constituted by authentication and association messages.
2.2 Mobility Management 9
However, in open-system authentication, the first ones are considered null, because there is no identity verification [14].
The shared key authentication uses the denominated Wired Equivalent Privacy (WEP) security algorithm. A challenge is sent by the AP to the client, which must be encrypted by the client and sent back. Then, the AP will decrypt and encrypt the response sent by the client. If the challenge sent by the AP matches the response, the client is accepted and a connection between both is established successfully. The static WEP key used during authentication will now be used to encrypt the data frames [14].
The vulnerabilities of WEP, exponentiated with the grow of hacking capabilities, motivated the development of other authentication and encryption methods. So, it was introduced the IEEE 802.11i standard, which includes the methods Wi-Fi Protected Setup (WPS), Wi-Fi Protected Ac-cess (WPA) and WPA2. Depending of the certificate used, WPA2 can be, additionally, catalogued as personal (WPA2-personal) and enterprise (WPA2-enterprise). The IEEE 802.11i standard con-tains protocols such as Temporal Key Integrity Protocol (TKIP), 802.1x, Advanced Encryption Standard (AES) and Extensible Authentication Protocol (EAP), which combined provide better data security and mutual authentication [15].
Another authentication solution is the Remote Authentication Dial In User Service (RADIUS), which uses digital signatures. The RADIUS server sends encrypted bytes to clients as way to verify their identity. These bytes will be used by the clients to encrypt the response messages. This is illustrated in Figure2.2. The use of encryption protocols makes of RADIUS an efficient protection against packet sniffing techniques for instance [15].
Figure 2.2: RADIUS authentication procedure [15].
The improvement of the authentication and security methods was good to address many secu-rity issues, however has a negative impact in the time elapsed during handover procedure, as can be seen in [15].
2.2.4 Integrity and Security
Solutions designed to UAVs communications must be attentive the integrity and security of the exchanged data. Integrity, since transmitted instructions can be modified in the route, and interrupt or destabilize the UAV control. Similarly, hostile users can get the exchanged informations and,
10 State of the Art
possibly, take full control of vehicle. In the following, a security approach, foreseeing mobility management, is presented.
2.2.4.1 Internet Protocol Security (IPsec)
IPsec provides an host-to-host security mechanism to IP datagrams. Using cryptography, this mechanism allows access control, integrity, data source authentication, detection and rejection of replays, confidentiality (by using encryption) and limited flow traffic confidentiality. These services are achieved using the IP Encapsulation Security Payload (ESP) and the Authentication Header (AH) protocols, in tunnel or transport modes [16].
A key concept related about IPsec is the Security Association (SA). SA is a set of parameters agreed by both sides of communication, constituted by items such as: type of security services, properties of the traffic wanted to keep secured, and cryptographic functions with the needed shared keys [16].
For the establishment and management of the SAs, including the key agreement, the IPsec standard suggests the version two of the Internet Key Exchange (IKEv2) protocol. This extension allows to perform mutual authentication of two hosts, by establishing two SAs: IKE-SA and IPsec-SA, which includes the shared key information of them [16].
2.2.4.2 IKEv2 Mobility and Multihoming Protocol (MOBIKE)
MOBIKE protocol is an extension of IKEv2 protocol, developed for mobility and multihoming of its nodes. By using this protocol, the IP addresses corresponding to IKE-SA and IPsec-SA can be changed being no needed to disconnect the established SAs and to establish new ones. MO-BIKE supports only tunnel mode for IPsec-SAs. The mobility for these connections is transparent in the viewpoint of internal applications, being only updated the IP addresses of outer IP headers of tunnels [16].
MOBIKE allows to the peers inform each other of the existence of potential pairs of IP ad-dresses that can be used in continue. The decision of which of these pairs to use has in con-sideration several factors. Firstly, is taken in count the parties’ preferences, for instance, due to performance and cost reasons, and secondly the decision is restricted by the fact that some pairs may not work at all, due to network incompatibilities. To solve these issues, MOBIKE takes a sim-ple approach: the party that initiated the SA – a client in a remote VPN scenario – is responsible for deciding which IP address will be used, being responsible for to collect the needed information to take that decision. The other party – the gateway in a remote access VPN scenario – just indicates to the client its IP address. Each side can update the information about IP addresses in the initial exchanges, and also during the connection by using INFORMATIONAL exchanges [17,16].
2.2.5 Low Latency Handover Solutions
When the link quality between an AP and the UAV decreases to a critical level, an handover to another AP that allows a better performance must be initiated. In order to achieve minimum
2.2 Mobility Management 11
package loss and minimum latency, the handover time must be as low as possible [13]. Researches related to this topic returns different handover procedures to achieve that goal: some are based on changes in the link layer, and other in the network layer of the Open Systems Interconnection (OSI) model.
Mobile IP is an example of a network layer handover procedure. This technique requires an Home Agent (HA) to route the traffic to the MN, offering roaming to it, throughout the Internet. However, this mechanism does not provide low latency handovers, so it is not a solution for this Dissertation’s context [13].
There are also some approaches that implement changes in the link layer, however common is-sues for all approaches are long scan time, which some of the methods handle by caching available APs, configuring manually the MAC addresses and frequencies of them. It is a feasible possible, sure, however requires hardware supported by advanced open source drivers and violates the IEEE 802.11 standard [13].
2.2.5.1 Handover Method Using Static Timing
The handover is time critical in two specific points. The first one is related with the closure of the first connection. If the close command for the Transmission Control Protocol (TCP) connection is not finished, the handover proceeding is prolonged [13]. This can be solved using a wait state (Wait 1), before switching to another AP. Otherwise, the <ACK> and <FIN, ACK> sent by the MN can not be received (Figure2.3) [13].
same network and extended service set, ESS. Due to
this implementation the handover is not controllable
by the user and the timing is unpredictable. This
paper contains an outline of the critical aspect in a
handover procedure, and propose two methods that
ensures a low handover time. In the following, a GS
is denoted a Host and the UAV is denoted a Mobile
Node, MN, to generalise the approach in this paper.
Related Work
Prior research related to handover procedures
in-volves several types of handovers; some relies on
changes in the link layer (L2) and other introduces
changes in the network layer (L3) of the OSI model.
A method implementing a L3 handover mechanism, is
Mobile IP. Mobile IP requires a Home Agent to
mana-ge the routing of traffic to the MN and offers roaming
throughout e.g. the internet, by letting the MN act as
it is located in its home network. However, this
proto-col does not provide low latency handovers, as it relies
on the existing link layer [2] [7]. Other approaches to
improve the handover latency introduces changes in
the implementation of the link layer. Common issues
for all approaches are long scan time [4], which some of
the methods handle by caching available APs based on
channel-wise scanning [6]. However, these approaches
require hardware, supported by advanced open source
drivers as MadWifi or HostAP and all violates the
IEEE 802.11 standard specifying scan of all channels
when performing active scanning [3].
II
Handover
Method
Using
Static
Timing
A handover in an IEEE 802.11 wireless network
can generally be divided into three separate phases:
Scanning, authentication, and association [1]. These
phases are illustrated in Figure 2. The figure shows the
handover procedure, where a data stream to a Host is
interrupted by the handover and passed on to a new
Host connected through a new AP.
By manually configuring the MAC addresses and
frequencies of the APs, an active scanning to locate
available APs during a handover should be avoided.
However, this obviously requires that the MAC
ad-dress and frequency of any AP is known in advance,
and does not entirely ensure that no scanning takes
place during the handover. This is due to the
oc-casional scanning performed by the wireless network
interface card, in order to cache available APs in its
vicinity. This is shown as the scan event in Figure 2.
Data
Time
MN
Probe Request 1 Probe Response 1 Authentication Request Authentication Response Reassociation Response Reassociation Request Data Probe Request 14 Probe Response 14 Sc a n Ass ociati on Probe Request 1 Probe Response 1 Probe Request 14 Probe Response 14 Au th en tic a tionHost
(new)
AP
(old)
AP
(new)
Host
(old)
Figure 2: Event diagram for a normal handover showing the
three phases during a handover procedure, without considering
protocol specific issues.
The MN can authenticate with an AP either by
means of a shared key, or without any authentication.
The latter only involves a 2-way handshake as shown
in Figure 2. By not using any authentication in the
handover procedure, a fast negotiation between the
MN and the AP is ensured.
First Timing Issue
When performing a handover, two points in the
pro-cedure are time critical. The first timing issue occurs
when the first connection is closed, initiating the
hand-over. If the close command for the TCP connection
is not completed properly before proceeding with the
handover procedure, the handover is prolonged.
Figu-re 3 illustrates the process of a TCP connection Figu-release
used when closing a TCP connection.
Time
ACK
FIN, ACK
ACK
FIN, ACK
Mobile node
Host
Figure 3: Event diagram for the TCP connection release
pro-cedure.
If timing is not considered the <ACK> and
<FIN, ACK>
from the Host is not received at the MN,
and the TCP protocol repeatedly inquires for the
mis-sing response from the Host.
This timing issue is
solved by introducing a wait state, wait 1, before
switching to another AP as illustrated in Figure 4.
2
Figure 2.3: TCP connection release procedure [13].
The second timing issue happens after the handover be performed, when the MAC address and frequency of new AP are already set. At this point, before calling the connect command (responsible to connect the sockets between the host and the MN), it is important to ensure that association phase is completed, otherwise such command fails, and the TCP protocol continues attempting to reestablish a connection to the host. Hence, this failure results in a longer handover
12 State of the Art
time [13]. To handle this issue, a possible solution is to introduce a second wait time (Wait 2) before the socket be connected, in order to ensure that association phase is completed [13].
In Figure2.4, a diagram with the two wait times inserted, including the three-way handshake that characterises a TCP connection opening, is depicted.
Second Timing Issue
The second timing issue occurs after the handover is performed, that is, after the MAC address and fre-quency of the new AP is set. At this point it is im-portant to ensure that the MN is associated with the new AP before calling the connect command. The
connectcommand connects a socket at the MN with a
socket at the Host. If the association phase is not com-pleted before connecting, the connect call fails and the TCP protocol occasionally attempts to reestab-lish a connection to the Host. This results in a longer connection time and thus a longer handover time. To ensure that the association phase with the new AP is finished before calling connect, a wait state, wait 2, is introduced before the sockets are connected, allowing the association to complete.
An extended diagram of Figure 2 is shown in Figure 4, where the inserted wait states are illustrated. Also the TCP connection release is shown, along with the TCP 3-way handshake performed when a new connec-tion is opened. Time Host (new) AP (old) AP (new) MN Wa it 1 Authentication Request Authentication Response Reassociation Response Reassociation Request Host (old) Sc a n Data TCP Connection Release Data TCP 3-way handshake Probe Request 1 Probe Response 1 Probe Request 14 Probe Response 14 Probe Request 1 Probe Response 1 Probe Request 14
Probe Response 14 Auth
en ti cati on As soc iation Wa it 2 MAC addre ss and fre q ue nc y s et
Figure 4: Extended event diagram, showing the introduced wait states emphasized in the handover test. Also the TCP opera-tions between MN and Hosts are shown.
The length of the first wait state is determined by observing the TCP connection release, using the pro-tocol analyzer Wireshark. The length of the second wait state is determined by trial and error.
A limitation of this method is the fact that not all situations are accounted for, when determining the length of the static wait states. Thus, situations can arise where the length of the static waits are either in-sufficient or exaggerated, as the duration of the hand-over procedure varies.
III
Handover Method Using Dynamic
Timing
This method is based on the same time critical points resolved in the Handover Method Using Static Timing. These time critical points are resolved in this method by a dynamic approach, as an alternative to the static waits in Figure 4. Furthermore the method uses static elements in the Address Resolution Proto-col, ARP, table to optimise the handover mechanism. The first time critical point concerns proper TCP connection release before initiating a handover. To ensure the TCP connection release before initiating a handover, the linger socket option must be set for the used socket. By specifying this socket option the closure of the socket waits until the existing TCP con-nection is correctly closed and the timing is improved. The second time critical point is to ensure associ-ation to the new AP before connecting the sockets. After parsing the MAC address and frequency to the new AP, a check for the ESSID is periodically per-formed, as some phases during the handover proce-dure are time varying. The ESSID is the only avail-able information to test for and is received in a probe response from the specified AP. As shown in Figure 4, the probe response is not in the final phase of the handover procedure and a reception of the ESSID is not a guarantee for an association. Thus a wait state is necessary after the ESSID is received. The dura-tion of this wait state ensures the associadura-tion after the ESSID is received, before connecting the sockets.
When sending data over a network, an Address Re-solution Protocol, ARP, is necessary. In general the ARP must map the logical IP addresses to physical MAC addresses in order to transmit data from one node to another node on a network. Even though the ARP stores the mapping in an ARP cache, the cache is periodically updated. This causes a problem if the update of the ARP cache happens during a handover, as this prolongs the handover procedure. To avoid an update of the ARP cache during the handover proce-dure, static elements are added to the ARP cache.
IV
Experimental Design
To analyse the handover times obtained by use of the two methods a test bed was designed. The test was performed with use of two Asus WL-500g Deluxe-V APs each having a PC connected that represented the Host. The employed Hosts were installed with Ubuntu 6.06 kernel 2.6.15-29-686 and Ubuntu 7.10 3
Figure 2.4: Two wait states introduced in the handover procedure [13].
2.2.5.2 Handover Method Using Dynamic Timing
This method proposes a dynamic approach to solve the same issues addressed in Section2.2.5.1. It is also tried an optimisation of the handover mechanism, using static elements in the Address Resolution Protocol (ARP) table. So, to solve the first issue, that is, to ensure that TCP connection with the old AP is correctly completed, is proposed as solution the setting of the linger socket option. This option guarantees that closure of the socket is done only when the TCP connection is closed [13].
In the other hand, to ensure the association to the new AP before connecting the sockets, a wait state after the Extended Service Set Identification (ESSID) be received is proposed. After setting the MAC address and frequency of new AP, periodically a ESSID check is performed, received in a probe response of the new specified AP. However, this probe is not a guarantee of a complete association. Hence, it is necessary a wait state after ESSID be received, with enough duration to ensure a complete association, before connecting the sockets [13].
ARP is responsible for associating a given IP address to a MAC address, in order to connect successfully a host to another one, on a network. After this association be performed, it is cached, been periodically updated. If this update takes place when an handover is being performed, the handover procedure is prolonged. To avoid this possibility, static elements are added to the ARP cache [13].
2.2 Mobility Management 13
2.2.5.3 Two-interface Dynamic Algorithm
Using the IEEE 802.11 handover paradigm, several tasks in order to inspect the best APs in vicinity of the UAV must be performed. A possible solution is to use a second interface to perform those tasks. In other words, one interface is associated with the current AP, being responsible for the Internet connection – data interface; a second interface actively inspects for APs in the vicinity – control interface. Hence, when an AP with best RSSI is detected, the switching takes place before the connection with the current AP be broken: make-before-break approach [18].
The two-interface dynamic algorithm has as goal soften the disconnection snapshot during handover. For this, two interfaces switch between the role of control interface and data interface. Initially, for instance, the UAV uses the interface I1 as the data interface to connect to the Internet, via AP1, being the IP address (IP1) associated with this interface; at the same time, the interface I2 performs the role of control interface, being responsible of probe other APs in the vicinity. Sup-posing that the RSSI associated to AP1 decreases bellow a given threshold, and that C2 identifies the AP2 as the best candidate do substitute AP1: at this time, C2 starts the authentication and association procedures with AP2, while C1 still receiving/sending data from/to the Internet, via AP1. When the association is performed, that is, when the handover is completed, I2 gets the IP1 address. Data from/to the Internet will now be received/sent by I2, via AP2. Hence, I1 becomes the control interface, and I2 the data interface. These changes in the address mapping between I1 and I2 are reflected in the routing table of the UAV. Also another ARP’s cache should be sent to the router in order to it has a reverse path to the UAV [18]. With this solution, the scanning, channel switching, and authentication delays are widely decreased [18]. The handover procedure following the two-interface dynamic algorithm is depicted in Figure2.5.
2.2.6 Mobile IPv4 (MIPv4)
Mobile IP is a proposed standard by the Internet Engineering Task Force (IETF) to enable a MN to maintain its IP address between different networks. Mobile IP has associated two types of IP addresses: the home address – the permanent address of the MN –, and the Care of Address (CoA) – a temporal address used by the MN to communicate with its Correspondent Nodes (CNs) when roaming in visited networks [20]. MIPv4 is formed by four main elements, namely: the MN, the Home Agent (HA), the Foreign Agent (FA), and the CN. These elements are presented in Figure2.6. Whenever a MN moves from its Home Network (HN) to a Foreign Network (FN) a intersubnet handover is performed. As soon as the MN is in the range of FN, it obtains a CoA from the FA, being reachable through this CoA while it is visiting the FN. After the MN’s registration step be performed, the subsequent packets destined for the MN’s home address are intercepted by HA, being encapsulated and tunneled to the MN’s CoA. At the end, the packets are decapsulated and forwarded to the MN [20].
The major drawback of MIPv4 is known as triangle routing problem, due to all the packets from CN to MN have to take a detour to pass the HA. This can result in routing path stretch, which means that the current routing path can be longer than the shortest one [21].
14 State of the Art
Figure 2.5: Implementation of the two-interface dynamic algorithm [19].
2.2.7 Mobile IPv6 (MIPv6)
MIPv6 presents relevant advantages for use in vehicular networks when compared with MIPv4 [20]: • The 128-bit address space, compared to the 32-bit address space in MIPv4, makes MIPv6
more flexible and scalable.
• The absence of FAs optimizes the routing tasks, by avoiding the triangular routing, and hence decreasing signalling overheads and handover latency.
2.2 Mobility Management 15
82||| Ieee vehIcuLar techNoLoGy MaGazINe | deceMBer 2012 only tailored for single-hop connectivity to network
infrastructure [3], [5], and thus cannot be used for mul-tihop communications utilizing intermediate network infrastructure.
Host Mobility Support (Mobile IP) Solutions
IP mobility support for individual MNs, commonly known as Mobile IP, is a proposed standard by the IETF to enable an MN to maintain its IP address whenever it attaches to a new network [6]. There are basically two types of IP addresses in Mobile IP: the home address (the permanent address of the MN from which it can send or receive IP packets when in its home network) and the care of address (CoA), a temporal address the MN uses to communicate with its correspondent nodes (CNs) when roaming in visited networks. Mobile IP can be based on IPv4, IPv6, or a hybrid of the two.
Mobile IPv4 (MIPv4)
In mobile IPv4 (MIPv4), there are four major distinct elements. These are the MN, the home agent (HA), the foreign agent (FA), and the CN [6] (see Figure 6). When an MN moves from its home network (HN) to a foreign network (FN) while communicating with its CN, a sub-net change occurs and, therefore, an intersubsub-net handover must be performed. As soon as the MN enters the coverage area of the FN, it obtains a CoA from the FA. The MN is reachable through this CoA as long as it resides within the FN. Once a CoA is obtained, the MN sends a registration request to its HA via the current FA informing the HA about the MN’s new location. Then, the HA sends back a registration reply to the MN via the FA, acknowledging the registra-tion request. The CN sends packets destined for
the MN to the MN’s home address in its home network. The HA intercepts and encap-sulates these packets a n d t u n n e l s t h e m through a bidirectional tunnel to the MN’s CoA. At the end of the tunnel, the FA decapsu-lates the IP packet and forwards it to the MN.
Mobile IPv6
Mobile IPv6 (MIPv6) is widely regarded as the future IP mobility proto-col for all-IP NGNs. This view was recently vali-dated by the announce-ment by the Internet Assigned Number Authority of the complete exhaustion of IPv4 addresses. MIPv6 comes with the following advantages for deployment in vehicular networks over its predecessor:
1) The larger address space of 128 bits compared to 32 bits in MIPv4 makes it more flexible and scalable. 2) The absence of FAs guarantees optimized routing by
avoiding the triangular routing that increases signal-ing overheads and handover latency in MIPv4. 3) Autoconfiguration of IP addresses in MIPv6 simplifies
the MN’s CoA assignment.
4) In MIPv6, MNs work transparently with other nodes that do not support mobility.
An MIPv6 network consisting of an MN moving between two subnets is illustrated in Figure 7. When an MN com-municating with its CN moves from subnet A to subnet B, a two-part handover process occurs: 1) a link layer handover that involves the MN changing its wireless link from APa to APb, and 2) a network layer handover where the MN changes its attachment to the Internet from its previous AR (ARa) to the new AR (ARb) follows.
Handover performance plays a vital role in QoS pro-visioning for real-time services. Handover latency is the time interval between the last moment when an MN can send and receive packets through the ARa and the first moment when it can receive and send packets through the ARb. This corresponds to the time during which the MN can neither receive nor send IP traffic and is used as a measure of handover performance [7].
In conventional MIPv6 networks, link layer (L2) hando-ver precedes network layer (L3) handohando-ver and the total handover latency comprises both the L2 and L3 handover latencies. Figure 8 shows the range of typical values for components of L2 and L3 handover latencies in ms [3], [7]. Registration Request Registration Reply MN FA HA CN Data Packets Destined for MN Data Packets Forwarded to MN Tunneled Packets Bidirectional Tunnel INTERNET
Figure 6 a mobile IPv4 network architecture [6].
Figure 2.6: A Mobile IPv4 Network Architecture [20].
• MN works transparently with other nodes that do not support mobility.
A MIPv6 network consists of a MN moving between two subnets, as depited in Figure2.7. When the MN, communicating with its CN, moves from subnet A to subnet B, a two-part handover process is triggered [20]:
1. A link layer handover – MN changes its wireless link from APa to APb.
2. A network layer handover – MN changes its attachment to the Internet from its previous AR (ARa) to the new AR (ARb).
The long handover latency in MIPv6 is the main drawback, resulting in high packet loss and hence degrading the QoS of real-time applications. Furthermore, the high signalling overhead, generated by the vehicles moving fast, makes the MIPv6 not sufficiently scalable for vehicular networks. To handle with these limitations, the IETF has developed some extensions to MIPv6, which are presented bellow [20].
2.2.7.1 Fast Handovers for Mobile IPv6 (FMIPv6)
In FMIPv6 the movement detection latency is reduced by providing the MN with the informa-tion about the new AP and the associated subnet prefix informainforma-tion, when the MN is still connected to its current subnet. FMIPv6 can be implemented in either predictive or reactive mode. In the predictive mode, using a Layer-2 (L2) trigger through the scanning process, the MN can to de-tect if the RSSI from the APs or Base Stations (BSs) in vicinity is stronger than that the current AP or BS. Based on the results of the L2 triggers, the Layer-3 (L3) handover is initiated and fin-ished before L2 handover be started. The FMIPv6 reactive mode is similar to the predictive mode, however the connection between the MN and the previous AR is terminated due to L2 handover execution [20].
16 State of the Art
deceMBer 2012 | Ieee vehIcuLar techNoLoGy MaGazINe ||| 83
L2 handover latency is the time taken for the MN to switch its link layer connection from one wire-less AP to another and consists of three phases: scanning, authenti-cation, and association or reasso-ciation phase delays. L2 handover delay ranges from 50 ms to about 400 ms and always exhibits great variations since it is media or technology dependent.
The delay due to router discovery is the time taken for the MN to determine whether a subnet change has occurred. Typical values of router discovery delay range from 100 ms to about 500 ms.
Address configuration (AC) de-lay is the time taken to configure a CoA by either stateful or stateless means followed by a duplicate
ad-dress detection (DAD) test so as to ascertain the unique-ness of the configured CoA. AC delay ranges from 500 ms to 1000 ms in typical MIPv6 scenarios.
The mapping of the MN’s home address and its CoA is called binding and the binding cache is stored in the HA that is a specialized router found in the home network (HN) of the MN. The HA is responsible for forwarding IP data packets to the MN. When the MN is away from its HN, it registers its new CoA with its HN by sending binding update (BU) messages to the HA and the CN. The HA and CN then reply by sending binding acknowledgement (BAck) messages to the MN. Registration (binding update) delay is the time taken for the MN to send BU messages to the HA and CN and the time taken to receive the BAck from the HA and CN. The BU delay lasts from 120 ms to about 140 ms in typical MIPv6 scenarios.
MIPv4/MIPv6 Dual Stack
The mobile IPv6 protocol was developed with the principle of being able to interoperate with IPv4 and thus to avoid the sudden termination or disruption of services and applications running between the two IP platforms. This coexistence between IPv4 and IPv6 forms the basis of the dual stack (IPv4 and IPv6 togeth-er) implementation. The dual stack approach is easy to implement as all the networking devices and applica-tions are able to communicate using either version. The limitation of this approach is that communicating nodes must be able to support both versions.
Standard Extensions of MIPv6
Despite the strengths outlined above, MIPv6 has several inherent drawbacks that make it unsuitable for vehicu-lar network communication. In particuvehicu-lar, the long
50-400 ms 100-500 ms 500-1000 ms 120-140 ms
Link Layer Handover Router Discovery AC & DAD Binding Update AcknowledgmentBinding
Link Layer Network Layer
Address Configuration Address Registration Attachment
Figure 8 typical handover latencies in Mobile IPv6.
Internet Home Network CN HA ARa ARb APa APb MN MN Subnet A Subnet B
AP: Access Point AR: Access Router CN: Correspondent Node HA: Home Agent MN: Mobile Node
Figure 7 a mobile IPv6 system architecture.
Figure 2.7: A Mobile IPv6 System Architecture [20].
2.2.7.2 Hierarchical Mobile IPv6 (HMIPv6)
HMIPv6 is an extension to basic MIPv6, designed by IETF, for micromobility management solutions. HMIPv6 aims to reduce the heavy signalling due to the movement of the nodes, by introducing a local mobility agent known as Mobility Anchor Point (MAP). The MAP acts as a local HA within its domains, intercepting all the packets destinated to the MN [20].
2.2.7.3 Proxy Mobile IPv6 (PMIPv6)
PMIPv6 was initially proposed by Cisco, before it became an IETF standard. In PMIPV6, the home address is maintained when the MN moves from one AR to another one, acting the new AR as the MN’s HA. The Binding Update (BU) messages are sent to the nearest server rather than to the MN’s HA, so reducing the BU latency. The Duplicate Address Detection (DAD) procedure is avoided and the BU Round Trip Time (RTT) is decreased, being the address configuration and BU’s processes optimized [20].
2.2.8 Handoff-Aware Wireless Access Internet Infrastructure (HAWAII)
HAWAII was proposed by Lucent Technologies Bell Labs as a micromobility solution in the MN’s visited domain. This solution aims to improve the performance by QoS provisioning and reliability enhancement. The HAWAII protocol is composed by two schemes for implementing handover procedures within a Base Station (BS): forwarding and nonforwarding schemes. In the forwarding scheme, data packets are directly sent from the previous BS to the new BS; in the nonforwarding scheme, data packets from the previous BS are routed in the crossover router. The forwarding scheme is optimized for networks where the MN can receive/transmit data from/to only one BS (e.g. Time Division Multiple Access (TDMA) networks); the nonforwarding scheme
2.3 IP Mobility Support for Vehicular Networks 17
is optimized for networks where the MN can receive/transmit data from/to two or more BS simul-taneously (e.g. Code Division Multiple Access (CDMA) networks) [20].
2.3
IP Mobility Support for Vehicular Networks
In [20] a survey about the main IP mobility solutions for vehicular networks is provided. Next, the most relevant aspects that can be availed to address the problem proposed by this Dissertation will be presented.
2.3.1 Vehicle-to-Vehicle (V2V) versus Vehicle-to-Infrastructure (V2I)
Communica-tions
The two main types of communications in vehicular networks are Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications. V2V communication systems are infrastructure-free, being the On Board Units (OBUs) the only communicating nodes, forming a Vehicular Ad Hoc Network (VANET). In turn, V2I communication systems involve communication between OBUs and RoadSide Units (RSUs) – typically APs connected to the Internet via Internet Gate-ways (IGWs). The IGWs provide global addresses and Internet connectivity to OBUs. These vehicular communication types are illustrated in Figure2.8.
Mobility management is one the most important challenges in vehicular networks, in order to support delay-sensitive and throughput-sensitive applications. The combination of high-mobility OBUs with varying speeds and directions, and static RSUs forms a complex communication sce-nario, due to fast changing network topologies and highly variable wireless links. In order to achieve an interruption-free communication, the designed solutions must perform two important functions: handover management and location management. Handover management allows main-taining the connection between two communication nodes while they move freely, whereas loca-tion management means identifying and updating the current localoca-tion of a MN.
2.3.2 NEtwork MObility (NEMO) Support Solutions
NEMO Basic Support (BS) is a IP mobility solution standardized by the IETF for NEMO support in VANETs. The main advantage offered by NEMO BS is that the handover signalling for all nodes can be aggregated by the mobile router, hence reducing the signalling overhead. However, it is only suitable for single-hop connectivity to network infrastructure, thereby being not supported in multihop communications using an intermediate network infraestructure.
2.4
Video Streaming
This section presents a review about the mostly used streaming protocols and codecs. The best solutions for real-time applications are also identified.
