intelligent communication media scheduler for vehicular ...€¦ · the research work of this...
TRANSCRIPT
Master thesis for Electrical Engineering
University of Twente
Faculty of Electrical Engineering, Mathematics and
Computer Science (EEMCS)
Design and Analysis of Communication Systems (DACS)
Intelligent Communication Media Scheduler For
Vehicular Networking
Chenxi Lei
November 2011
Supervisors:
Dr.ir. Georgios Karagiannis
Dr.ir. Geert Heijenk
Prof.dr. Hans van den Berg
Abstract
The fast development of wireless technologies is changing vehicles from mere transportation
tools into smart objects. Through the communication via base stations and access points installed
at the road side, vehicles can get access to the internet and support all types of IP-based
applications. The booming of wireless technologies does not only provide vehicles the method of
accessing the internet, but also offer vehicles multiple choices of used wireless technologies such
as UMTS, WLAN and WiMAX. Meanwhile, different users inside the vehicles may have
different requirements on the used wireless technology. The vehicle has to make selections on
the wireless technology to be used.
The research work of this master thesis is based on a vehicle to infrastructure communication
environment. The main goal of this assignment is to design an intelligent communication media
(medium) scheduler, which can help a vehicle to select a suitable wireless technology from a set
of available wireless technologies. The intelligent scheduler uses as input (1) the user
requirements, (2) the performance characteristics associated with the available wireless
technologies, (3) the road topology and the mobility pattern of the vehicle. Furthermore, the
performance of the designed intelligent scheduler is evaluated using simulation experiments.
Preface
This master thesis presents and concludes the research work that I have already done in the past
ten months. All of the research work is done in the chair for Design and Analysis of
Communication Systems (DACS), Faculty of Electrical Engineering, Mathematics and
Computer Science (EEMCS), at the University of Twente, The Netherlands.
During this ten months and the longer period staying in DACS, I receive help from many people
and I would like to acknowledge them here.
First, I will give my thanks to my first supervisor Dr.ir. Georgios Karagiannis. In this period, we
talk, discuss, and even debate with each other just to find the truth. From him, I learned to be
professional, patient, and open-minded. Furthermore, I would like to thank my two other
supervisors, Dr.ir. Geert Heijenk and Prof.dr. Hans van den Berg, for their valuable guidance
and comments.
Then I would like to thank my parents, Mr Maolin Lei and Mrs Qiuxia Liu, my girl friend Miss
Lei Wang. Without their love and support, this master thesis could not be finished.
Last but not least, I appreciate the too much help offered by Msc. Martijn van Eenennaam during
my time in DACS.
前言
这篇硕士论文是我在过去十个月中研究工作的展示与结尾。所有这些研究工作都完成于
荷兰屯特大学电子工程计算机科学数学学院下属的通信系统设计与分析研究组（简称
DACS)。
在 DACS 的这十个月乃至更长的研究时间里， 我得到了很多人的帮助， 我将在这里答谢。
首先我要感谢我的第一导师 Georgios Karagiannis 博士。 在这段时间里，我们相互交流，
讨论甚至争论，只为寻求真理。从他身上，我懂得了专业，耐心与开通。 然后，我要感
谢的另外两位导师，Geert Heijenk博士和 Hans van den Berg教授， 感谢他们有效地指导
与点评。
我还要感谢我的父母，雷茂林先生和刘秋霞女士以及我的女朋友王蕾小姐，这篇论文的
完成离不开他们的爱和支持。
最后，我感激 Martijn van Eenennaam 硕士在 DACS 这段时间给予我的太多的帮助。
Table of Contents
CHAPTER 1: INTRODUCTION .......................................................................... 1
1.1 V2V AND V2I COMMUNICATION ................................................................................... 1
1.2 VERTICAL HANDOVER AND ACCESS TECHNOLOGY SELECTION METHOD ................................... 3
1.3 PROBLEM STATEMENT ................................................................................................ 4
1.4 RESEARCH QUESTIONS ................................................................................................ 5
1.5 OUTLINE OF THIS REPORT ............................................................................................. 6
CHAPTER 2: V2V AND V2I COMMUNICATION ARCHITECTURES ....... 7
2.1 CAR TO CAR COMMUNICATION CONSORTIUM (C2C-CC) .................................................... 7
2.1.1 Draft reference architecture-communication domains ................................... 7
2.1.2 Protocol architecture ...................................................................................... 8
2.2 IEEE 1609 (WAVE) [13-16] ................................................................................... 10
2.2.1 WAVE reference model................................................................................. 10
2.2.2 Protocol architecture .................................................................................... 11
2.3 ETSI ITS COMMUNICATIONS ARCHITECTURE [19] ........................................................... 13
2.4 ISO CALM ............................................................................................................ 17
2.4.1 CALM communication services ..................................................................... 17
2.4.2 Protocol architecture .................................................................................... 18
2.5 CONCLUSIONS ......................................................................................................... 23
CHAPTER 3: DECISION-MAKING MECHANISMS ..................................... 25
3.1 APPLICATION CATEGORIES AND DECISION MAKING CRITERIA .............................................. 25
3.2 DECISION MAKING IN ISO CALM ................................................................................ 28
3.3 MULTI-CRITERIA DECISION-MAKING METHODS .............................................................. 30
3.3.1 Analytic Hierarchy Process (AHP) .................................................................. 30
3.3.2 Cost Function-based method ....................................................................... 41
3.3.3 Utility Function-based method ..................................................................... 43
3.3.4 Fuzzy logic and neural networks based method............................................ 44
3.3.5 Geometric Speed-based Method .................................................................. 45
3.4 CONCLUSIONS ......................................................................................................... 47
CHAPTER 4: HANDOVER MECHANISMS.................................................... 49
4.1 IEEE 802.21-MEDIA-INDEPENDENT HANDOVER ............................................................ 49
4.2 3GPP-DEFINED VERTICAL HANDOVER MECHANISMS ......................................................... 53
4.3 IP-BASED MOBILITY MANAGEMENT MECHANISMS ............................................................ 59
4.3.1 Mobile IP (both IPv4 &IPv6) ......................................................................... 59
4.3.2 Hierarchical Mobile IP (HMIP) ...................................................................... 60
4.3.3 Fast Handover for Mobile IPv6 (FMIP) .......................................................... 60
4.3.4 Network Mobility (NEMO) ........................................................................... 61
4.3.5 Proxy Mobile IP (PMIP) ................................................................................ 61
4.3.6 An example about implementation of mobility management mechanisms in
vehicular network ................................................................................................. 63
4.4 CONCLUSIONS AND SUPPLEMENTED ISSUES REGARDING TO VERTICAL HANDOVER ..................... 65
CHAPTER 5: ARCHITECTURE SPECIFICATION AND DESIGN ............. 67
5.1 REQUIREMENTS AND CHOICES .................................................................................... 67
5.1.1 Requirements on designing Decision-making Mechanism ............................ 67
5.1.2 Requirements on designing Handover Mechanism ...................................... 68
5.1.3 Selection of the V2I Communication Architecture ........................................ 68
5.1.4 Selection of the Decision-Making Method and the Handover Mechanism ... 69
5.2 DEPLOYMENT SCENARIO AND USED ENTITIES ................................................................. 71
5.2.1 Deployment Scenario ................................................................................... 71
5.2.2 Used Network Entities ................................................................................. 72
5.3 INTELLIGENT SCHEDULER AND ITS REQUIREMENTS ............................................................ 76
5.3.1 Selection making procedure......................................................................... 78
5.3.2 Handover procedure .................................................................................... 80
5.4 SUMMARY ............................................................................................................. 82
CHAPTER 6 SIMULATION MODELS.............................................................. 83
6.1 AHP IMPLEMENTATION AND VALIDATION MODEL ............................................................ 83
6.1.1 AHP algorithm in Matlab .............................................................................. 83
6.1.2 AHP validation model in Matlab ................................................................... 85
6.2 SIMULATION ENVIRONMENT AND MODELS ..................................................................... 89
6.2.1 Simulation environments ............................................................................. 89
6.2.2 Simulation topology ..................................................................................... 94
6.2.3 SUMO model ............................................................................................... 96
6.2.4 INET/OMNeT++ model ................................................................................. 98
6.2.5 Integrated simulation model ...................................................................... 112
CHAPTER 7: EXPERIMENTS AND RESULTS ........................................... 115
7.1 SELECTION-MAKING MECHANISM VALIDATION .............................................................. 115
7.1.1 Verification of the Simulink model ............................................................. 115
7.1.2 Verification of the Additive Normalization model in C++ ............................ 118
7.2 EVALUATION EXPERIMENTS ...................................................................................... 118
7.2.1 Performance measure ................................................................................ 118
7.2.2 Simulation parameters ............................................................................... 119
7.2.3 Accuracy investigation for video watching .................................................. 123
7.2.4 Accuracy investigation for VoIP ................................................................... 129
7.2.5 Summary .................................................................................................... 133
CHAPTER 8: CONCLUSIONS AND FUTURE WORK ............................... 135
8.1 CONCLUSIONS ....................................................................................................... 135
8.2 DISCUSSIONS ........................................................................................................ 136
8.3 FUTURE WORK ...................................................................................................... 137
REFERENCE ........................................................................................................ 139
APPENDIX A: ..................................................................................................... 147
APPENDIX B: ..................................................................................................... 149
ACRONYMS ......................................................................................................... 155
1
Chapter 1: Introduction
This chapter gives a brief overview of the concepts used in this assignment and introduces the
research questions to be addressed. First, those illustrated concepts include vehicle-to-vehicle
(V2V), vehicle-to-infrastructure (V2I) communication, vertical handover and access technology
selection mechanism. Then, the problem statement is given, where the main goal of this
assignment is also included. Furthermore, the research questions are listed and the outline of this
report is presented.
1.1 V2V and V2I communication Nowadays, the role of a vehicle is not mere transportation any more, but has already been
changed into a smart object as it embraces the technology of vehicular networking. Two types of
vehicular networks can be distinguished- vehicle-to-vehicle (V2V) and vehicle-to-infrastructure
(V2I). V2V refers to the communication between vehicles and V2I refers to the communication
between vehicles and fixed communication infrastructure. Scenarios of communication between
vehicles (V2V) and communication between vehicle and infrastructure (V2I) can be seen in
Figure 1.
Figure 1 V2V and V2I scenarios (copied from [1])
In Figure 1, it can be seen that several vehicles driving on the road are able to communicate with
each other and exchange information using V2V communication. For example, one vehicle can
inform its following vehicles about the accident in front of itself for safety purpose. For V2I
shown in Figure 1, the vehicle can communicate via bases stations, traffic lights and other road
side units (RSUs) with the infrastructure and e.g., get access to the Internet.
For V2V, vehicles themselves constitute an ad hoc network. The information used by vehicles is
mainly disseminated by the wireless technology—IEEE 802.11p [2], which is an approved
amendment to the IEEE 802.11 standard to add wireless access in vehicular environments
2
(WAVE). In Europe, the 5.855–5.925 GHz band is assigned for IEEE 802.11p, while in the
United States the 5.85–5.925 GHz band is assigned.
Generally, characteristics of the V2V communication environment can be summarized as: (1)
high mobility of communicating nodes, (2) road topology is known, (3) rapidly changing
network topology as a result of the high-mobility communicating nodes, (4) potentially
unbounded communication network size. These characteristics are different than the
characteristics of typical Mobile Ad hoc network and 3G cellular communication environments.
These characteristics make V2V an attractive field of research.
Though for V2V, it is possible to build an ad hoc network with unbounded size, using such a
network for multi-hop communication between vehicles having a large inter-vehicle distance, is
quite difficult because of the V2V communication‘s own characteristics, such as the rapidly
changing topology, which might interrupt the communication between vehicles from time to
time, and the hidden terminal problem, which also hampers the V2V being used for a long-
distance communication. As a result, the applications of V2V are usually used for a local area,
for example, collision avoidance between two neighboring vehicles or among a platoon of
vehicles and the information dissemination for a platoon of vehicles.
For V2I, the vehicle can communicate via bases stations, traffic lights and other road side units
(RSUs) with the infrastructure and e.g., get access to the Internet. Thus, multiple IP-based
services become available for vehicles with embedded on-board units (OBU). The driver is able
to collect the latest traffic information for a larger area and make his/her decision on planning
the route timely.
Different from V2V, multiple access wireless technologies can be used for the information
dissemination in V2I, such as IEEE 802.11p, IEEE 802.11a [3], IEEE 802.16 [4], Infrared
technology and cellular networks, e.g., UMTS, LTE. Besides, since the infrastructure part is
fixed, V2I is more appropriate to be used for long distance communication. Furthermore, the
V2I can easily have a larger communication range than the V2V communication range. Thus, for
V2I, information can be disseminated at a certain area in one communication hop, while V2V
will need to use multi-hop communication to disseminate the same information at the same area.
According to [5], V2I communications have the potential to considerably increase scalability of
vehicular networking protocols and to ease coordination between vehicles, through the
deployment of a relatively cheap, not necessarily dense, infrastructure. However, the main
drawback of the V2I communication compared to the V2V communication is the higher
communication delay involved in disseminating information between two neighbouring vehicles.
In this research work, only the V2I communication is being considered as explained in section
1.3.
3
1.2 Vertical Handover and Access Technology Selection
Method Handover refers to the process by which a cellular radio network transfers a call as the mobile
station (MS) moves out of the range of one base station (BS) in one cell and comes into the
range of another base station.
The Handover can be defined as the process of transferring an ongoing call or data session from
one base station (or access point) to another base station (or AP).
Nowadays, most handovers can be categorized as ―horizontal handovers‖ which refer to
handovers between base stations or APs using a homogeneous technology, e.g. handover of a
cell phone call from a GSM base station to another one, or a handover of a streaming service on
a laptop from one Wi-Fi access point to another one. ―Horizontal handover‖ is sometimes called
―homogeneous handover‖, see [6].
Another type of handover is the ―vertical handoff‖ (or ―vertical handover‖), see [7], which
represents the handover across two radio coverage cells belonging to different access networks.
In this research assignment, ―vertical handover‖ is defined as the handover across two base
stations or APs using different technologies or in other words, using heterogeneous access
technologies. ―Vertical handover‖ is also denoted as ―heterogeneous handover‖ such as in [6].
If a ―vertical handover‖ can be made as seamless as ―horizontal handover‖ is today, then an on-
going call or data session can still be maintained when a mobile station moves from a radio
coverage cell belonging to specific access network to another radio coverage cell belonging to
another type of access network technology. Apart from the possibility of providing seamless
handover among multiple types of networks to prevent service interruption, in the areas where
multiple types of access networks are providing simultaneous coverage, by using a selection
mechanism, the ―vertical handover‖ can help the mobile station handover to a chosen network
which suits user‘s preferences better.
The access network technology selection mechanism assures that a mobile station (in our case,
the vehicle) is Always Best Connected (ABC) [8]. The ABC concept allows a user to connect to
applications using the devices and access technologies that best suit his or her needs. The access
selection mechanism (or decision making) may be characterized as ―a process of choosing or
selecting 'sufficiently good' alternative(s) or course(s) of action, from a set of alternatives, to
attain a goal or goals‖ [9].
In a traditional horizontal handover, a handover is initiated when the received signal strength
(RSS) is not strong enough or the serving base station (or access point) is traffic overloaded by
the supported data traffic. So an access network which can supply a strong enough RSS or
enough resources to a mobile station can be selected. Usually, only one of these two criteria
(RSS and traffic load) is used to trigger the handover. So the traditional horizontal handover
decision is based on one single criterion (RSS or traffic load). While for vertical handover,
besides the basic requirement on availability (e.g. RSS and traffic load) to guarantee the basic
on-going connection, in case that multiple types of networks are available as candidates, more
4
criteria can be taken into consideration to make sure that the user receives the ABC. These
criteria can be the monetary/financial cost of the connection, bandwidth of the candidate
networks, network performance (e.g. initial delay), and the speed of the vehicle (mobile station),
etc.
When a vertical handover is supported, then the access technology selection mechanism uses
three main phases [10]: (1) monitoring and link measurement, (2) target cell determination and
handover triggering (3) handover execution (effective link transfer). The decision on when to
trigger a handover can be based on one single criterion or multiple criteria: If the availability of
the currently serving network cannot be guaranteed e.g., due to poor RSS, a handover is
triggered, similar to the horizontal handover. While if the availability of the currently serving
access network can be guaranteed but there are other available networks suiting the user‘s need
better (e.g. charge less with the same QoS), a handover can also be triggered, which is based on
multiple criteria (e.g. monetary cost and supplied QoS). The decision on to which network the
handover should be performed is based on multiple criteria.
The vertical handover and access technology mechanisms that are developed in typical beyond
3G networks [11] cannot directly be applied in vehicular environments. This is due to the fact
that these existing mechanisms are not taking into account the characteristics of vehicular
environments, such as (1) high mobility of communicating nodes, i.e., vehicles, (2) the fact that
the road topology is known, (3) rapidly changing network topology as a result of the high-
mobility communicating nodes, (4) potentially unbounded communication network size.
Therefore, other types of vertical handover and access technology mechanisms are needed to
satisfy these vehicular environment characteristics.
More details about access technology selection-making mechanisms (i.e., decision-making) can
be found in Chapter 3. In this report, the term ―selection-making‖ and ―decision-making‖ can be
used interchangeably.
1.3 Problem Statement As already mentioned, in V2V, the information used by vehicles is disseminated by using
wireless communication between vehicles and the main wireless technology used in V2V is
IEEE 802.11p. In V2I the information used by a vehicle is disseminated using a wireless
communication medium between the vehicle and the infrastructure. This wireless
communication medium could be provided by various wireless technologies, such as IEEE
802.11a, IEEE 802.16, Infrared technology and cellular networks, e.g., UMTS, LTE. In such
situations, the vehicle or the infrastructure needs to select a proper wireless communication
medium to make the vehicle ―always best connected‖.
For an on-going call or data session, the vehicle may select different access technologies in order
to assure itself ―always best connected‖ as time and position change. Once a newly-selected
access technology is different from the one the vehicle is using, the vehicle has to make a
vertical handover to this selected technology. Because heterogeneous access technologies need
to be considered for vertical handover, existing successful horizontal handover mechanisms
which only consider networks using homogeneous access technology may not be simply applied.
5
An intelligent communication medium scheduler should be able to help the vehicle select a
communication medium (access technology), and together with a vertical handover mechanism,
it can help the vehicle handover to the selected communication medium.
The main goal of this assignment is to design and evaluate an intelligent communication medium
scheduler to be applied in vehicular networking. This intelligent communication medium
scheduler targets at the dynamic and real time selection of the ―best‖ communication medium
(e.g., IEEE802.11p or cellular technology) used by the vehicle for V2I communication.
The main contributions of this M.Sc. assignment include:
investigation and selection of the environment wherein the intelligent communication
medium scheduler is implemented. This includes the vehicular networking architecture,
the used selection making mechanism and the vertical handover protocol.
design of the intelligent communication medium scheduler.
implementation of the intelligent communication medium scheduler simulation model
using matlab, and the SUMO and INET/OMNeT++ simulation environments.
performance evaluation of the intelligent communication medium scheduler from the
point of view of accuracy.
1.4 Research Questions The main research question of this master assignment is: how to design an intelligent
communication medium scheduler that can be used in V2I communication and helps to select the
used communication medium?
In order to achieve our main goal and answer the main research question, the following sub-
research questions need to be answered:
Which vehicular networking communication architecture can be used to implement an
intelligent communication medium scheduler?
Which existing intelligent communication medium schedulers are applied in wireless
networks?
Which requirements and features should be supported by the V2I-based intelligent
communication medium scheduler?
How to design the V2I-based intelligent communication medium scheduler to satisfy the
derived requirements and provide ―always best connected‖ communications?
Which experiments can be accomplished in order to evaluate and analyze the designed
V2I-based intelligent communication medium scheduler?
How is the performance of the proposed scheduler from the point of view of the selected
performance measure(s)?
The first two sub-research questions are answered by the method of literature study. The
subsequent two research questions are answered by designing the intelligent communication
medium scheduler. The last two sub-research questions are answered by implementing a
simulation model of the simulation scenario and performing simulation experiments. The
implemented simulation model uses the SUMO traffic and INET/OMNeT++ network simulation
environments.
6
1.5 Outline of this report This report is organized as follows. In Chapter 2 different architectures for vehicular networking
will be introduced, and in this way, the first research question is answered. Chapter 3 and
Chapter 4 will present several access technology selection mechanisms and vertical handover
mechanisms, respectively, which will answer the second research question. In Chapter 5, the
scenario where the intelligent communication medium scheduler is going to be deployed is
defined. Based on this defined scenario, the intelligent communication medium scheduler is
designed. Then, the models used for the evaluation of the intelligent communication medium
scheduler are described in Chapter6. Designing of the experiments and analysis of the
corresponding results are given in Chapter 7. Finally, in Chapter 8, the conclusions and
recommendation for future activities are given.
7
Chapter 2: V2V and V2I Communication Architectures
In this chapter, several important communication architectures for vehicular networking are
introduced. By studying these communication architectures, a proper one will be selected to
implement the to-be-designed intelligent communication medium scheduler. Even though that
only the V2I communication is considered in this assignment, the communication architectures
described in this chapter can support both V2V and V2I communication.
2.1 Car to Car Communication Consortium (C2C-CC) The Car 2 Car Communication Consortium is a non-profit organization initiated by European
vehicle manufacturers, which is open for suppliers, research organizations and other partners. In
this section, we will introduce the Car to Car communication architecture based on [1].
2.1.1 Draft reference architecture-communication domains Here, we would like to introduce the draft reference architecture (see Figure 2) which defines
different domains in C2C communication.
Figure 2 Draft reference architecture (copied from [1])
As shown in Figure 2, the draft reference architecture of the C2C Communication System
comprises three distinct domains: in-vehicle, ad hoc, and infrastructure domain.
The in-vehicle domain is logically built of one OBU (potentially multiple) and application units
(AUs). AUs are typically dedicated devices those execute different applications or different sets
of applications utilizing the OBU‘s communication capabilities. These devices can be either
integrated to the vehicle or be portable (including plug-in) devices. Wired or wireless
8
technologies can both be applied in communication between AU and OBU. Moreover, AU and
OBU can be collocated at a single physical unit.
The ad hoc domain, or Vehicular Ad hoc Network (VANET), is composed of mobile units-
vehicles equipped with OBUs and stationary road-side units (RSUs) along the road. An OBU is
at least equipped with a (short range) wireless communication device dedicated (i.e. device that
supports IEEE 802.11p) for road safety and potentially other devices (e.g. traditional WLAN
devices, cellular communication devices). OBUs in the VANET communicate with each other in
a fully distributed manner without the need for a centralized coordination instance. This
communication can be direct with wireless connection or be multi-hop without direct wireless
connection. RSUs are also seen as nodes of an ad hoc network, capable of sending, receiving or
forwarding data in this domain.
Besides, an RSU can also be attached to an infrastructure network so that it can provide access
service to the Internet, by which it is possible for AUs registered to an OBU to communicate
with any host on the Internet. Furthermore, an OBU might also be able to connect to an
infrastructure network by such as a WLAN hot spot (HS) directly instead of being bridged by
RSU if it is equipped with corresponding radio interface. RSU and HS are the two types of
infrastructure domain access. OBUs can also utilize communication capabilities of cellular
radio networks (GSM, GPRS, UMTS, HSDPA, WiMAX, 4G) if correspondent wireless
interfaces are integrated in the OBU, in particular for non-safety applications.
2.1.2 Protocol architecture
In this section a layered architecture of protocols will be presented, which can be seen in Figure
3.
Figure 3 Protocol architecture of the C2C Communication System (copied from [1])
9
Principally, as shown in Figure 3, three basic types of radio wireless technologies are
distinguished by the C2C-CC: IEEE 802.11p wireless technology, traditional WLAN
technologies based on IEEE 802.11a/b/g/n and other radio technologies (like GPRS or UMTS).
On top of these wirelesses technology-specific PHY and MAC, the network layer provides
wireless multi-hop communications based on geographical addressing and routing, and executes
functions specific to vehicular communications like congestion control and vehicles‘ movement
dissemination (beaconing). Still according to [1], in eventual implementation, separate MAC
layers may be combined into one, and C2C Network may also access certain other radio types.
C2C-CC classifies applications into safety applications (refers to the driving safety) and non-
safety applications. Non-safety applications use the traditional protocol stack with TCP and UDP
over IPv6 and can access wireless multi-hop communications to communicate with other
applications in vehicles, road-side unit or Internet nodes. Also, non-safety applications can
bypass the C2C Network layer and disseminate data via the IEEE 802.11a/b/g network
interfaces. For safety applications, they regularly communicate with the left-side column of the
protocol stack via the C2C Communication Transport and Network Layers over the IEEE
802.11p, however, they are not restricted to use the left-side column.
A brief introduction of C2C-specific layers is given below, and details can be found in [1]:
C2C Communication Application Layer
The C2C Communication Application Layer provides common applications such as Active
Safety Application, Traffic Efficiency Application and Infotainment Application. It maintains
local data bases, sends, receives and process messages and local sensors‘ data. Applications can
interact with users (e.g. by human-machine interface) and with local sensor data in the vehicle. A
set of applications are mandatory to be implemented to guarantee the C2C communication with
minimum requirements.
C2C Communication Transport Layer This layer provides several services same as other types of transport layers, such as data
multiplexing and de-multiplexing, and may also offer unicast-based connection-oriented, reliable
data transfer according to the requirements of the safety applications. Another task of this layer
is to combine data from different applications in order to carry them in the payload of a single
packet and deliver them to the applications on the receiving side.
C2C Communication Network Layer This layer provides wireless multi-hop communications based on geographical addressing and
routing comprising beaconing, local-service and forwarding of data packets. Due to limited
wireless bandwidth, flooding should be scoped in its range. Nodes‘ movement and position can
be used to deal with the fast changes in network topology. Moreover, this layer should be able to
cope with all densities of equipped vehicles. Besides, three data delivery scheme are defined:
geographical broadcast, single-hop broadcast and beacon packets as a specific case of single-hop
broadcast. Some algorithms can be implemented at the network layer in order to control the
network congestion, e.g. a cross-layer method utilizing the state information provided by the
MAC layer.
10
C2C Communication MAC/LLC Layer The C2C Communication MAC Layer adopts standard Collision Sense Multiple Access with
Collision Avoidance (CSMA-CA) as MAC algorithm and it is based on the IEEE 802.11 MAC
protocol but with many simplifications in the services and enhancements in the cross-layer
integration. For simplifications, all IEEE 802.11 services for nodes, including authentication, de-
authentication and privacy, except data delivery, are not included, which means without the need
for any association procedure, all nodes that conform to the C2C-CC standard are members of a
single independent basic service set (IBSS), referring to IEEE 802.11 terminology.
For enhancements, several necessary features not included in IEEE 802.11 standard are
specified:
The MAC layer should provide to the upper layers information about the current estimated channel load by which the upper layers can use different strategies to prevent
medium congestion,
The LLC layer should provide to the network layer a per-packet parameters control, in particular regarding the transmission power,
A client/server interface for channel observation and control commands between the MAC layer and all the upper layers is required,
The MAC layer should implement a differentiated queuing scheme according to the priority of the message as specified by the applications, e.g. as specified in IEEE802.11e
[12].
C2C Communication Physical Layer The C2C-CC considers the IEEE 802.11p radio technology, which modifies and amends the
IEEE 802.11a, like no usage of association/authentication, usage of specific transmit power and
of multiple channels with different bandwidth per channel, however basic algorithms and
modulation schemes are remain unchanged.
There are numerous other network entities out of scope of C2C-CC which are essential for the
infrastructure domain, such as the Home Agent (HA) Mobile network entity.
2.2 IEEE 1609 (WAVE) [13-16] The IEEE 1609 Family of Standards for Wireless Access in Vehicular Environments (WAVE)
define an architecture and a complementary, standardized set of services and interfaces that
collectively enable secure vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless
communications. Together these standards are designed to provide the foundation for a broad
range of applications in the transportation environment, including vehicle safety, automated
tolling, enhanced navigation, traffic management and many others.
2.2.1 WAVE reference model Components of a WAVE system comprise RSUs installed in light poles, traffic lights, road
signs, etc., and OBUs mounted in vehicles. Three types of WAVE basic service sets (WBSSs)
are shown in Figure 4, which is similar to Figure 4 in section 2.1.1.
11
Figure 4 WAVE basic service sets (copied from [17])
In Figure 4, three types of WBSSs are shown: information can be exchanged between OBUs and
RSUs (V2I shown in WBSS 1); with appropriate portal, OBUs can get access to Internet by RSU
(V2I shown in WBSS 2); and OBUs communicate with each other (V2V, shown in WBSS 3).
2.2.2 Protocol architecture The WAVE architecture supports two protocol stacks for data plane as shown in Figure 5.
Figure 5 WAVE architecture (copied from [17])
12
In OSI model terminology, the two data plane stacks shown in Figure 5 use the same physical
layer and data-link layer but different network layer and transport layer. The WAVE standards
do not specify the session, presentation, or application layers. However, two elements which do
not easily fit the OSI model are defined: the resource manager and the security services blocks
[17]:
The Resource Manager is defined in IEEE 1609.1 [13], which describes the key components of
WAVE system architecture; defines data flows and resources, command message formats and
data storage formats; and specifies the types of devices that may by supported by OBU [18].
The security services are defined in IEEE 1609.2 [14], which defines secure message formats
and processing circumstances for using secure message exchanges.
With two data plane stacks, the TCP/UDP IP part is able to support traditional and less
demanding exchanges while a proprietary WAVE Short-Message Protocol (WSMP) can
accommodate high-priority, time-sensitive communications such as an accident announcement
which has scarce requirements in terms of datagram length or complexity but very strict ones in
terms of latency and probability of error. Though WSMP is able to support send short messages
and directly control certain parameters of the radio resource to try to guarantee the messages‘
reception in time, it was not able to support typical Internet applications and more effort has to
be done to reduce the cost of implementing IPv6.
IEEE 1609.3 [15] specifies the aforementioned WSMP, like the definition of network and
transport layer services, including addressing and routing, in support of secure WAVE data
exchange and definition of WAVE Short Messages (WSM), providing an efficient WAVE-
specific alternative to IP that can be directly supported by applications, and explains how to
incorporate traditional IPv6, UDP, and TCP in the systems. That document also defines a set of
management functions (labelled WAVE management entity (WME) in Figure 5) that must be
used to provide networking services.
IEEE 802.11p specifies not only the data transmission portion of the protocols but also the
management functions associated with the corresponding layer (the physical layer management
entity (PLME) and the MAC layer management entity (MLME) blocks in Figure 5).
Unlike traditional wireless LAN stations, WAVE units might be required to divide their time
between the control channel (CCH) and the service channels (SCHs), while in C2C-CC, they are
called control channel (CCH) and public channels respectively Therefore, a sub-layer specified
in IEEE 1609.4 [16] is included at the level of the OSI layer two (see Figure 5), dedicated to
controlling this multichannel operation (such a sub-layer is not clearly shown for C2C-CC
architecture in Figure 3) .
Therefore, according to these IEEE 1609 specifications, it can be deduced that for WAVE, only
IEEE 802.11p is considered as the wireless access technology.
13
2.3 ETSI ITS Communications Architecture [19] Intelligent Transport Systems (ITS) are systems developed to support transportation of goods
and humans with information and communication technologies in order to efficiently and safely
use the transport infrastructure and transport means (vehicles). ITS elements are standardized in
Europe by the ETSI TC ITS on a regional level compared to ISO TC204 (see section 2.4) where
standardization is done on an international level.
In [19], the architecture of communications in ITS (ITSC) supporting a variety of existing and
new access technologies and ITS application are specified. The term ITSC refers to
communications protocols, related management, and additional functionality. The reference
architecture of ITS station is shown in Figure 6.
Figure 6 ITS station reference architecture (copied from [19])
In Figure 6, the lower three blocks contain functionality of the OSI communication protocol
stack: ―Access‖ corresponds to the ITS station‘s OSI layers 1 and 2; ―Networking & Transport‖
corresponds to the ITS station‘s OSI layers 3 and 4; ―Facilities‖ represent ITS station‘s OSI
14
layer 5, 6 and 7. And the block named ―Applications‖ on top of the communication architecture
presents the ITS station applications which make use of the ITS station services. The
―Management‖ block at the left side of Figure 6 is responsible for communications management
in the ITS station, while the ―Security‖ block at the right side of Figure 6 provides security
services to the OSI communication protocol stack. Names of interfaces which are used to
interconnect different blocks are also shown in Figure 6 and details about these interfaces
(except for MA, FA and SA) can be found in [20-28].
Applications
An ITS application is an association of two or more complementary ITS station applications, e.g.
sever part and client part. Initially, ITS applications are grouped into ―Road Safety‖, ―Traffic
Efficiency‖ and ―Other Applications‖ which impose requirements on ITS communication with
respect of: reliability; security; latency and other performance parameters. It is specified that
every ITS application should be assigned an ITS application priority according to the functional
and operational requirement of the ITS application. Details can be found in clause 6.1.3 of [19].
Access
The ―Access‖ block shown in Figure 6, supports multiple communication interfaces e.g. infra
red incoherent light (IR), Millimeter (MM), 5GHz microwave (M5), GPS, Bluetooth, cellular
network and Ethernet. Moreover, communication interfaces (CIs) are distinguished as station-
external interface and station-interface. The station-external interface is used to interconnect the
ITS with other networks such as vehicular ad hoc networks, proprietary networks, core network
and so on, while the station-internal interface is used to communicate in the V2I access
networks. The details of the ―Access‖ block can be seen in Figure 7:
Figure 7 ITSC Access layer adaptation (copied from [19])
The ―Access‖ block consists of three main parts: PHY connecting physically to the
communication medium; DLL, composed of MAC managing the access to the communication
medium and LLC, a Layer management which manages PHY and DLL.
The interface ―IN‖ is used to connect the ITSC ―Networking & Transport‖ layer to DLL and
provide DLL communication services; the interface ―MI‖ connecting to the ITS station and
15
communication management entity provides management services; the interface ―SI‖ connecting
to the ITS station and ITSC security entity provides security services.
The communication adaptation sub-layer (CAL) can be interpreted as the upper layer of the
DLL, which shall provide the services of the IN interface; the management adaptation entity
(MAE) can be interpreted as part of the layer management, which shall provide the services of
the ―IM‖ interface; the security adaptation entity (SAE) can also be interpreted as a part of the
layer management provides the services of the ―SI‖ interface
Networking & Transport
As shown in Figure 6, for transport layer protocols, ITSC supports UDP/TCP, dedicated ITSC
transport protocols and others. For networking protocols, it supports the GeoNetworking
protocol as specified in [29], IPv6 with mobility support, IPv6 over GeoNetworking as specified
in [30], CALM FAST protocol as specified in [31]; other ways of IPv6 networking and other
protocols. A more detailed view of the ―Networking & transport‖ block can be seen in Figure 8:
Figure 8 ITSC networking & transport layer (copied from [19])
Besides the Transport layer protocols and Network layer protocols, there is another Layer
management shown in Figure 8 similar to that in ―Access‖ block.
The interface ―NF‖ connecting the ITSC facility layer and this block provides communication
services; the interface ―NM‖ connecting the ITSC station and communication management
entity provides management services; the interface ―SN‖ connecting to the ITSC security entity
provides security services and the interface ―IN‖ connecting to the ―Access‖ block provide
communication services.
Facilities
A detailed view of the ITSC Facilities Layer is presented in Figure 9.
16
Figure 9 ITSC facilities layer (copied from [19])
As shown in Figure 9, this block comprises several parts: application support; information
support; communication support; session support and a facilities layer management.
The interface ―FA‖ is used to connect to the ITS applications; ―MF‖ and ―SF‖ respectively
connect to ITSC station and communication management entity and ITSC security entity to
provide management and security services; the interface ―NF‖ provides communication services
from lower layers.
The facilities that can be supported may include: Generic HMI support; Support for data
presentation; Addressing support, Position and time support and so on. Details of supported
facilities can be found in section 6.3.3 of [19].
Management
The ITSC management entity contains management elements which may be functionality
grouped into ―Application management‖, ―Station management‖, ―Cross-layer management‖
and ―Regulatory management‖ as presented in Figure 6.The additional functionality can be e.g.
Communication service management, Management of general congestion control, Management
of service advertisement and so on.
ITS basically may support push and pull mechanisms in order to allow an ITS station to identify
existence of ITS services. The push mechanism is named "ITS service advertisement". The pull
mechanism is known e.g. from Internet protocols. ITS service advertisement may be
implemented optionally in different ways and for different contexts. One option of advertising
ITS services in single-hop wireless links is the FAST service advertisement that is specified in
[32].
Some functionalities are introduced in clause 7 of [19] including the: General congestion control,
CI/ITS-S application mapping, Local node map, Inter-management communication, Regulatory
information management, ITS application management and ITS communication service
management. Particularly the CI/ITS-S application mapping is about the selection of the ―best‖
communication interface where our interest lies. The building blocks and data flows in the ITSC
17
management required to dynamically select the optimum communication interface can be seen in
Figure 10.
Figure 10 CI/ITS-S application mapping (copied from [19])
In order to make the decision during ―Mapping process‖ shown in Figure 10, the requirement of
the ITS station applications, the available communication interfaces and their status and rules
(policy) have to be known. This data is maintained by the: ―CI status list‖, ―ITS application
requirement list‖ and ―Set of rules‖. Since this function is almost the same as that defined in
CALM, much more details can be found in section 3.2 of this report.
Security
The ―security‖ block is beyond the scope of our research work. Details about this part can be
found in clause 8 of [19].
The communication architecture defined by ETSI actually is quite similar to the ISO CALM
architecture, see Section 2.4.
2.4 ISO CALM ISO TC204 WG16 is developing a family of International Standards based on the CALM
(Communications access for land mobiles) concept, which aims at providing a standardized set
of air interface protocols and parameters for wireless digital data communication using one or
more of several media, in order to enable efficient "Intelligent Transport Systems" (ITS)
communications services and applications [33].
2.4.1 CALM communication services
Communication services provided by CALM [33] can be classified into the following categories
which is similar to those specified in C2C-CC and WAVE:
Vehicle-Vehicle: A low latency peer-peer network with the capability to carry safety related
data such as collision avoidance, and other vehicle-vehicle services such as ad-hoc networks
linking multiple vehicles.
18
Vehicle-Roadside: Basically the same as Vehicle-Vehicle, where a vehicle communicates to a
Road Side Unit (RSU) that is not connected to an infrastructure. However, it might be connected
to a local network of ITS stations, e.g. around a cross-section.
Vehicle-Infrastructure: Multipoint communication parameters are automatically negotiated,
and subsequent communication may be initiated by either RSU or vehicle. The roadside station
is connected to an infrastructure, e.g. Internet or others.
Infrastructure-Infrastructure/Roadside-Roadside: Wired communication links are used to
interconnect (1) infrastructure to infrastructure and (2) RSU to RSU.
2.4.2 Protocol architecture As part of this family of standards, ISO/DIS 21217 [34] describes the common architectural
framework of CALM. In this standard, CALM-compliant communication entities called (ITS)
stations are instantiated [35]. The basic building block of an ITS station is the ITS Station
Communication Unit (ITS-SCU), formerly referred to as CALM communications kernel (CCK),
which can be seen in Figure 11.
Figure 11 ITS Station Communication Unit (CCK) copied from [36])
As seen in Figure 11, the communication architecture of CALM consists of four major blocks:
CALM User Services/Applications, CALM networking layer, Physical/Data Link Layer and
Management block outside the communication stack, which are connected by several kinds of
Service Access Points:
19
A-SAP is the management SAP that enables the CALM management to interact with the
OSI layers 5 through 7.
C-SAP is the communication SAP that connects a communication interface to the
CALM network layer.
M-SAP is the management SAP that enables the CALM management to interact with a
communication interface.
N-SAP is the management SAP that enables the CALM management to interact with the
OSI layers 3 and 4.
T-SAP is the communication SAP that connects the CALM transport layer to the CALM
upper OSI layers. A brief overview of these blocks is given below [34]:
CALM User Services/Applications
These applications generally can be classified into two categories: CALM aware applications
and Non-CALM-aware applications.
―CALM aware applications‖ implement user application specific functionality with the ability to
control the interaction with the CALM environment. They are able to respond to CALM
management entity (CME in the CALM Management block of Figure 11) requests for
registration information or request registration upon initialization.
Two types of CALM aware user applications are distinguished:
CALM FAST: can get real-time access to pre-selected parameters of specific CALM
communication interfaces (CIs) and CALM networking layer in line with applicable regulations in order to control the real-time behavior of the communication link,
including e.g. power settings, channel settings, beam pointing. These applications
typically use the CALM FAST networking or CALM geo-routing protocol in CALM networking layer.
Other applications, which are named ―CALM IP-based‖ (generic "CALM-aware
Applications"), which typically use IPv6 networking.
―Non-CALM-aware applications‖ do not have the functionality of controlling the interaction
with CALM environment. Instead they require from the user to submit registration information
to the CALM management entity in order to operate properly with the assumption that a normal
UDP or TCP connection is being established for communication. In particular, Non-CALM
aware applications implement application specific functionality without the ability to control any
interaction with the CALM environment. Besides, the CALM management entity must hide all
CALM environment peculiarities from these applications. For example, the switching of a data
stream from one specific communication interface to another is not important to the Non-
CALM-aware applications as long as the data transfers in a timely manner.
―The CALM service layer‖ is constituted by the OSI layer 5 through 7. This layer shall provide
an application programmer interface (API) to user applications, and it shall provide the A-SAP
to the CME. Details of this layer depend on the user applications being implemented in a CALM
system.
20
CALM networking layer
Actually according to Figure 11this major block, includes not only the networking layer entities,
but also the transport layer is included.
The transport layer directs the data to and from specific programs via the CALM service layer
and provides transparent transfer of data between the communicating entities. On top of IPv6,
just at the block of ―Internet‖, UDP and optionally TCP are used (see [37]), while on top of the
CALM non-IP networking protocols, at the block named ―Local port transport protocol‖, a
dedicated CALM FAST transport protocol is used; also optionally supporting connection-
oriented data transfer, reliable data transfer, and multiplexing / de-multiplexing functionality
(see [31]).
Below the transport layer, the network layer routes packets to the appropriate functional unit or
program addressed. It also isolates the upper OSI layers from the different communication
interfaces.
CALM supports multiple optional and complementary network protocols running independent
of each other, including network protocols in Figure 11: ―IPv6‖, ―CALM FAST‖, and ―Geo-
routing‖. The first one is for Internet Protocol networking while the other two are used for Non-
IP mobile connectivity and routing in fast ad-hoc network situations.
―IPv6‖: IPv6 mobility support protocols are required for Internet reachability, session
continuity and seamless communications.
―CALM FAST‖: This network protocol is required for user applications with severe
timing constraints and low latency requirements, e.g. time-critical safety related applications.
―Geo-routing‖: This is a network protocol that uses the geographical location of the
CALM stations as communication addresses and is needed for road safety and traffic
efficiency applications.
Physical/ Data Link Layer
Several distinct physical layers are accommodated by the CALM architecture, and they can be
mainly banded together in two different groups. The first group incorporates wireless interfaces
used by vehicles and infrastructure to communicate with each other. The second group
incorporates the wired interfaces used internally in a vehicle or used to connect infrastructure
equipment.
The wireless interfaces of CALM architecture include: CALM Originated Interfaces, Protocol
Managed Interfaces and ISO15628 [38] compatible Interfaces as shown in Figure 12:
21
Figure 12 CALM Air Interface Classes (copied from [39])
Three classes of CALM Air Interfaces are presented in Figure 12:
CALM Originated Interfaces
This class of air interfaces is specifically designed for CALM. This class of interfaces includes
CALM Infrared, CALM M5 and CALM Millimeter, whose corresponding ISO Standards are
also shown in Figure 12. Note that CALM M5 uses the IEEE 802.11p wireless technology.
Protocol Managed Interfaces
This class of air interfaces is not specifically designed for CALM, but for generic wireless
telecommunications session such as 3G cellular communications, wireless mobile broadband, or
satellite communication. Corresponding ISO standards are also shown in Figure 12.
ISO15628 Compatible Interfaces
As stated in [39], any air interface that can support ISO 15628 should be able to link into the
application services that will use CALM, so CALM ISO 15628 compliant systems form the third
class of CALM Air interfaces.
In the future, other interfaces can be added to CALM.
For the Data Link Layer, there is a dedicated MAC sub-layer for every PHY layer. Details of
the MAC layer are specified together with the related PHY layer in International Standards and
are referenced in the appropriate CALM media standards. Details of the effective LLC
functionality are specified in [40].
22
The concept of a CALM communications interface (CI) [40]
The concept of a CALM communication interface is shown in Figure 13:
Figure 13 CALM Communication Interface (copied from [40])
CALM is open for existing communication modules (CM), while CMs are not aware of CALM,
and CALM native CMs. Therefore it is necessary to adapt the interfaces of such existing CMs to
those are aware of CALM as shown in Figure 13. The task includes:
adapting the CM protocol layers (CMPL), i.e. OSI layers 1 and 2, of a CM to the
common CALM network layer by means of a communication adaptation layer (CAL),
which provides a smooth interface between each medium specific layer 2 (MAC and LLC) and the common functionality of the CALM network layer and can be interpreted
as an LLC extension of existing communication technologies.
adapting the CM management entity (CMME) of the CM to the interface management
entity (IME) by means of a CI management adaptation entity (CIMAE) which provides
the M-SAP by which is same for all CIs to be used between the CALM management and the CIMAE.
The sum of CM (including CMPL and CMME) and CAL and CIMAE in figure is named
"Communication Interface" (CI).
CMME and CIMAE constitute the "Communication Interface Management Entity" (CIME).
CAL and CMPL together constitute the "Communication Interface Protocol Layers" (CIPL).
CALM Management
The CALM Management functionalities are grouped into three groups as shown in Figure 11,
including:
a) "Interface Management Entity" (IME) whose role is to directly control the communication
interfaces, and to allow access to a communication interface for the purpose of receiving and
transmitting management data packets.
23
b) "Network Management Entity" (NME) whose role is to directly control the transport and
network layer protocols.
c) "CALM Management Entity" (CME) whose role is to provide the decision-making process to
the CALM mechanism. It collects specification of communication parameters and requirements
from each of applications from the initialization process and then monitors the availability of
lower level communication mechanisms and issues. Then a decision on how to route data
packets based on these information and policies is made. And CME directly controls the CALM
Service Layer.
In the CALM architecture, the decision-making process is specified to be realized in CME, see
Figure 14.
Figure 14 the CALM Management Entity (copied from [39])
This decision-making process of CME is shown in, where the media requirements from
application parameters, static capabilities of the available communication media parameters, and
the dynamic performance of the available communication media are together with the Medium
Selection Policies contributing to the selection of medium interface. This process is going to be
discussed in detail in section 3.
Disregard of this grouping, the CALM management is one entity, and there are no observable or
testable interfaces between IME, NME and CME [34]. CALM International Standards being
balloted before creation of this International Standard (ISO 21217) may have specified service
access points between IME, NME and CME, together with the related service primitives. Such
specifications shall be considered as examples of implementation, rather than normative and
testable requirements.
Security-related issues are out of the scope of our research work.
2.5 Conclusions In this section, three important V2V and V2I communication architectures are introduced. The
communication architectures include the communication scenarios: communication between
vehicles; communication between vehicle and RSU; and communication with fixed
infrastructure connected to Internet, For C2C-CC and CALM, different radio technologies can
be used while for WAVE, the radio technology is specified to be based on IEEE 802.11p, which
24
is therefore not suitable for vertical handover where the station must be able to switch among
different access networks.
Besides IEEE 802.11p, C2C-CC and CALM support other radio technologies. However, CALM
supports much more interfaces than C2C-CC. Different from that C2C-CC hold different
protocol stacks as shown in Figure 3, CALM adapts different communication modules and
connect them to the network layer with a common C-SAP as shown in Figure 11 such that the
networking layer isolates the upper OSI layers from different interfaces and which is beneficial
for the purpose of making the vertical handover transparent to the user (the handover is
seamless). In addition, ETSI and CALM are two quite similar architectures but defined by
different standardization bodies: ETSI is a European standard, while CALM is a worldwide
standard. The decision on the communication architecture to implement the intelligent scheduler
is made as stated in Section 5.1.3.
25
Chapter 3: Decision-Making Mechanisms
This chapter describes the existing decision making mechanisms, including the one used in the
ISO CALM architecture. Furthermore, the basic IP-based application categories applied in
vehicular environments that may use an ―intelligent scheduler‖ are introduced. Moreover, the
criteria that should be considered during the decision making process are given.
3.1 Application Categories and Decision Making Criteria
Typical application classifications
As fast development of car electronics and telecommunication techniques takes place, more and
more applications can be used for vehicles. The decision making process can be based on QoS
requirements of application types, since several applications have common features and similar
QoS requirements [41].
In [42], vehicle networking applications are divided into three generic service types: Streaming
Services, Messaging Services and Interactive Services. These three generic service types have
distinct features and different QoS requirements, see Table 1.
Table 1 summary of generic services’ examples, features and requirements (copied from [41])
Streaming Service (SS)
A Streaming Service needs constant throughput and generally the data packets are constantly
being sent with a relatively constant Inter Packet Delay (IPD). In advance, this generic service
can be classified in three sub services:
-Public Streaming Service (PSS): this type of service supports broadcasting of data. Usually, this
service is provided at low cost (or even for free) and a low level of security. Examples of such
services are: dissemination of traffic conditions, radio broadcasting via Digital Audio
Broadcasting (DAB). It is important to note that the amount and latency of the disseminated data
depends on the QoS requirements of the application.
-Selective Streaming Service (SSS): Selective Streaming Service is not supplied on single users‘
requests or to the broad public but ―members‖ who subscribe to a group or belong to it by
sharing a common situation or location in the form of ―a stream of messages‖. Using such a
service might be charged and need special precautions with regards to security.
26
-Backwards Streaming Service (BSS): This type of service is used to send, e.g., positions to a
central server. Such service might be useful for tracking vehicles (rescue service; dangerous
loads; etc.) and is generally a narrowband type of service and quite different from the
broadcasting messaging service, since information is sent on a regular basis, i.e. streamed.
Messaging Service (MS)
A Messaging Service requires a small Initial Delay, i.e. the initiation of the data transport should
be accomplished immediately. Usually, this service just sends few packets which are not
acknowledged. The Initial Delay is therefore, a much more critical factor than throughput. Short
Message Service (SMS) is one typical example of this service. When an accident happens, this
information can be transmitted using such service to an aid server requiring help of some kind.
Interactive Service (IS)
An Interactive Service consists of a request by a client which is processed and answered by a
server. Here the initial delay should also be considered. Interactive Service is classified into two
sub services in advance:
-Personal Interactive Service (PIS): This type of service addresses the user‘s need for
information. A request message sent by the user will be processed by the server and replied in
the form of another message. The response should happen within a reasonable time frame,
therefore sufficient throughput and small round trip delay time should be guaranteed.
-Personal Download Service (PDS): Different from PIS, here a request message will cause a
reply of considerable number of data packets. Thus, this service can be considered as a
combination of two basic services, the interactive and the streaming service, providing a means
to download a bulk of data, e.g. advantageous when entering a new area where a specific map is
needed.
These generic services are also referred in [43].
Different from above kind of classification of applications where only the communication
between vehicles and network servers is considered (where our interest lies), in [44],
applications are categorized into four classes also considering communication between vehicles
and from the view of different service class‘s functionality:
1) General information services: Services for which delayed or lost information does not
compromise safety or render application useless.
2) Information services for vehicle safety: Services for which delayed information may result in
compromised safety or may cause that the application becomes useless.
3) Individual motion control using inter-vehicle communication: Applications that issue operator
warnings or regulate local vehicle actuators to ensure safe and/or efficient operation.
4) Group motion control using inter-vehicle communication: Vehicle motion planning involving
global optimizations or negotiations and that may or may not involve group motion regulation.
27
The first two classes of applications are used for the purpose of information service, while other
two classes of applications aim at providing motion control.
Besides, in [45], applications are classified according to more specific features from a wireless
networking perspective.
Application classification specific to vertical handover
As discussed above, there are multiple classification methods with different scopes and depth of
considerations: considering just communication between vehicles and servers; considering both
V2I and V2V; and considering more specific features during the decision making process.
During vertical handover controlled by our ―intelligent scheduler‖, the same criteria may be of
different importance for different categories of applications, e.g. throughput is critical for
streaming service but not so important for messaging service. Therefore, in order to target the
decision making mechanism to select the ―best‖ candidate network before executing the vertical
handover, it is needed to distinguish among application classes.
The decision making mechanism used in the ―intelligent scheduler‖ is applied only for the
selection of the communication network/interface used to support the V2I communication (not
the V2V communication). Moreover, it is considered that the decision making mechanism is
able to distinguish between the Service, Messaging Service and Interactive Service application
classes Though all these classifications just take data communication into consideration,
conventional/voice services can be simply considered as being Interactive Services.
Hence, it is considered that the application classes supported by the V2I communication are:
Streaming Service, Messaging Service, and Interactive Service.
Decision Making Criteria
As stated in Section 1.2, for vertical handover, multiple criteria should be considered, which is
different from that of horizontal handover where only a single type of criteria is used. Moreover,
the information related to these criteria can be ―dynamic‖ or ―static‖, see [41, 43, 46-57])
―Dynamic‖ information refers to information whose values might frequently change and have to
be on-line monitored, while ―static‖ information refers to the information whose values that do
not frequently change and can be measured a priory. Here, we adopt the terminology used in
[37] and call the ―dynamic‖ and ―static‖ information of interest ―dynamic capabilities‖ and
―static capabilities‖, respectively.
―Dynamic‖ capabilities are represented by: (1) network availability; (2) RSS and current
network traffic load; speed of vehicle; (3) battery power; (4) location information; (5)
throughput; (6) Round Trip Time; (7) jitter; (8) packet loss and other information about the
network‘s performance.
―Static‖ capabilities are represented by: (1) offered bandwidth; (2) initial delay for connection
establishment; (3) user-specified application type; (4) user‘s preference on monetary cost (or
affordable cost of service); (5) directional loss and other QoS requirements of services and user
preferences.
28
When more criteria are taken into consideration then the decision making can become more
complex. Therefore, a careful selection of the used criteria is significant.
3.2 Decision making in ISO CALM Before describing the existent decision-making mechanisms, it is necessary to introduce the
decision making feature used in ISO CALM (see section 2.4).
The concept of selecting an optimum CI is named ―CI selection management‖ [37], which is
used by the vehicular networking applications that are using the IPv6 networking based solutions
(see the ―CALM networking layer‖ block in Figure 11). This concept is realized by CME, NME
and IME. In particular, the CME makes the decision based on the information provided by the
―Medium Selection Policies‖ shown in Figure 14. CME compares the capabilities of the
available CIs against the communication requirements from the application. This comparison is
performed: either after the application request is registered with the CME, or after the indication
of availability of new CI, or after the change of capabilities of the CI notified by NME to CME.
The building blocks and data flows of CI selection management can be seen in Figure 15:
Figure 15 CI selection management (copied from [32])
From Figure 15, we can see ―CI selection‖ decision-making function is based on inputs of
―CI/VCI status list‖, ―Set of rules‖, and ―User application requirement list‖.
“CI/VCI status list” shall contain the properties, statuses and performance parameters of all CIs
and virtual communication interfaces (VCI) in a CALM station. The CI/VCI status list shall be
frequently updated via M-SAP. A CALM router may advertise its properties to all CALM hosts,
or a CALM host may perform a scan of all CIs attached to the local network. Here, the concept
of a VCI provides a quick and efficient method to set the properties of a CI on a packet-by-
packet basis without the continuous involvement of the CALM management entities. More
details can be found in [40].
“Set of rules” may be set by users by using the Man Machine Interface (MMI). The existence of
MMI is determined by the implementation, and not required as part of CALM International
29
Standards. Here ―rules‖ means policies which regulate CI selection. In our report, ―rule‖ and
―policy‖ can be used exchangeable. There are no rules specified in [40], but several examples
are given:
-Back seat screens shall get access only to low cost links.
-Emergency messages shall always be delivered on any/all available media or a specific medium
or a choice of media.
-Video transfer shall use high throughput media.
-Public safety messages shall use high QoS-performance media.
-Internet applications shall only use media costing less than a given limit.
The rules that will be used by our proposed ―intelligent scheduler‖ will be discussed in the
following sections.
User applications shall register at the CME via A-SAP, and shall present their requirements for
communication. This information shall be stored in a “user application requirement list”. The
―user application requirement list‖ shall be frequently updated.
With information from these three blocks, the CI selection can make a multi-criteria decision on
which interface suits best for information distribution
Generally, the decision-making process in CALM can be divided into three steps:
First step: the information related to both static and dynamic capabilities of available CIs should
be collected. Referring to Figure 15, such information includes communication requirements
from the ―User application requirement list‖ block, policy regulation from the ―Set of rules‖
block, and other static capabilities. This information contains all ―static‖ rules that can be set by
user, the application requirements and static capabilities that are stored from applications during
registration and from the CIs after power up [37]. Moreover, information related to dynamic
capabilities is provided by each CI via IME and NME and it is stored in the ―CI/VCI status list‖
block.
Second step: the information collected at the first step should be evaluated according to the
available rules in order to help decision making on which a communication interface is found as
being the optimal one for V2I communication. This step should be accomplished in the ―CI
selection‖ block. However, no specific algorithm is defined in the CALM standards to make
such a multi-criteria decision making. Existing methods on multi-criteria decision making will
be discussed in Section 3.3.
Third step: after an optimal CI‘s selected, and if it is not the CI currently under use, a handover
has to be made; in other words, the selection and decision making procedure has to be executed.
According to [37], the network mobility support (NEMO) is used as the mobility management
mechanism during a vertical handover for CALM. However, a specific mobility management
30
mechanism specific for CALM is still under discussion [37]. Potential solutions will be
discussed in Section 4.
3.3 Multi-Criteria Decision-Making Methods As mentioned in Section 1.2, the selection of the optimal communication interface has to be
made using many factors and rules, including the ―dynamic capabilities‖ and ―static capabilities‖
introduced in Section 3.1. Several multi-criteria decision making algorithms stated in existent
literature have been studied. Those algorithms described and compared in this section are:
The Analytic Hierarchy Process (AHP)-based algorithm is one widely-used algorithm for
multi-criteria decision-making. This algorithm assigns weights to different criteria based on the
importance of the criteria and to different candidate networks based on these networks‘
performance against specific criteria. And with these weights, each candidate network is given a
calculated score and the one with the highest score is selected as optimal.
Another method is based on a ―cost function‖. Here, different criteria are also assigned with
different weights by the designer. But these weights are directly assigned instead of being
calculated as that of AHP (see section 3.3.1). Performance values corresponding to the ―static
capabilities‖ and ―dynamic capabilities‖ of candidate networks‘ are also directly used in the
―cost function‖ to calculate the ―cost‖ of the candidate network (see section 3.3.2). Finally, the
candidate network with the least ―cost‖ is selected as optimal.
There are other not widely-used algorithms such as the algorithm using a modified Elman
neural network (MENN) to predict traffic load and the geography-based algorithm.
3.3.1 Analytic Hierarchy Process (AHP)
AHP was proposed by Thomas L. Saaty in [58]. The AHP is a structured technique for dealing
with complex decisions and is widely used in the fields such as government, business, industry,
healthcare, and education.
AHP is a process of organizing decisions that people are already dealing with. In the context of
our assignment AHP can be used to calculate the weights of different selection criteria and
corresponding weights of different candidate networks/interfaces for some specific criteria.
However, in order to use AHP it is needed to make decisions on either (1) the importance of the
different selection criteria, and (2) on how much each candidate network suits a specific
selection criterion or instead (3) the relative importance of different criteria and (4) how more a
candidate network suits a specific criteria than another candidate network.
Moreover, after the above decisions are made it will be possible to calculate the normalized
weight of each candidate network/interface for a specific criterion and as well the weight of each
selection criterion. In addition, we can use different mechanisms which combine these weights
to calculate the final scores for each of the different candidate networks/interfaces [59].
31
In order to clarify the above description, an example discussed in this paper [43] is used, which
applies the AHP-based algorithm for the handover support between WLAN and Cellular
Networks.
Suppose that a vehicle is entering an area where the WLAN, UMTS and GPRS technologies are
supported. Furthermore, it is considered that a passenger in the backseat of this vehicle uses a
laptop that supports the three wireless technologies. Since the vehicle is moving in a common
WLAN, UMTS and GPRS coverage area the passenger in the backseat needs to select one of
these three technologies at the moment that he wants to watch a video from some video-sharing
website.
In this example AHP is used to select the most suitable candidate network for the passenger to
watch the video. Before applying the selection procedure it is needed to decide which criteria
will be used in the selection procedure. In [43], many selection criteria are taken into
consideration, but in this assignment only a sub set of these criteria will be taken into
consideration. The ―static capabilities‖ considered in this assignment are: offered bandwidth
(link capacity), initial delay, cost and the ―dynamic capabilities‖ considered are throughput,
losses and round trip time. With the target of Always Best Connected (ABC), a hierarchy of
these selection criteria and candidate networks are drawn in Figure 16.
Figure 16 Hierarchy of criteria and candidate networks with target of ABC
From Figure 16, it can be seen that ABC can be achieved by selecting one of the three candidate
networks WLAN, UMTS, GPRS by using the six selection criteria mentioned above.
The used selection process can be accomplished in three steps:
Step 1 includes the initial scoring, where the following are verified (1) the importance of each
selection criterion and (2) how much each candidate wireless network/interface suits a specific
selection criterion.
32
Step 2 includes the weight calculation, where AHP is used to select the weights for the selection
criteria.
Step 3 includes the final score calculation, where the methods to calculate the final score of
each candidate network, with respect to the six criteria, are being utilized.
Step 1: Initial Scoring
This section describes three solutions found in the literature [54], [60] and [43], used in the
initial scoring step.
In criteria scoring, users specify their preference. According to [54], all criteria are first ranked
based on user‘s preference and then their rankings are compared pairwise. Applying the criteria
scoring method in [54] to our example, we consider that the video application used by the
passenger, is treated as a streaming application. Here, suppose the passenger ranks these six
criteria in a decreasing order of importance: throughput, losses, cost, offered bandwidth, Round
Trip Time and Initial delay. Suppose and are the highest and lowest possible score for each
criterion and is the number of considered criteria, so I (see Equation 1) is the numeric space
gap between two subsequent scores, which is rounded off to the nearest integer:
Equation 1
When =9, =1, =6, then I=1. Note that in this example a higher score is given to the most
important criterion, while in [54], the lowest score is given to the most important criterion.
Therefore the scores for throughput, losses, cost, offered bandwidth, Round Trip Time and
Initial delay are given the values: 6, 5, 4, 3, 2, and 1. We use
to denote the
importance comparison between criterion i and criterion j.
In [54], criteria of the same importance is not mentioned. If we treat throughput and losses of the
same importance, cost and offered bandwidth of the same importance, then we have four levels
of importance and we can set =4 so I=2. As a result, the score for throughput and losses are 7,
for cost and offered bandwidth are 5, for Round Trip Time is 3, and for Initial delay is 1. Then
we can calculate for each pair of criteria.
Network scoring in [54] scores each candidate network in a similar way (see Equation 2 and
Equation 3) as that for criteria scoring:
Equation
2
Equation 3
33
Where and are, respectively, upper and lower score limits for a criterion, and is the value
offered by a network for that criterion. We would assign a network with a better performance a
higher score. The Equation 2 is used for the criteria: losses, cost, Round Trip Time and Initial
delay, where a higher value of indicating a worse performance would result a lower score;
while the Equation 3 is used for the criteria: throughput and offered bandwidth, where a higher
value of indicating a better performance would result a higher score. We use
to denote the performance comparison for a specific criteria between
candidate network i and candidate network j.
Another solution used for initial network scoring is presented in [60], where scoring does not
have to be linear. In [60] these scores are called membership values. GPRS, UMTS and Satellite
are considered in [60] as candidate networks.
Criteria scoring and networking scoring described in [43] are quite different than those
described in [54]. Criteria scoring in [43] does not need to rank all criteria considered before
comparison, instead here criteria are directly compared pairwise: still means the importance
of criterion i with respect to the importance of criterion j. According to [9], the value of can
be: 1 - both criteria are equally important; 3 - criteria i is weakly more important; 5 - criteria i is
strongly more important; 7 - criteria i is demonstrably more important; 9 - criteria i is absolutely
more important. Therefore, =1, when i=j and =
. Here we mark the criteria-offered
bandwidth (OB), initial delay (ID), cost, throughput, losses and round trip time (RTT)-with the
number 1, 2, 3, 4, 5 and 6. And the pairwise comparison results between the importance of
criteria for the streaming application in our example (can be deemed as a matrix for the value
of ) can be seen in Table 2.
Table 2 Comparison of Criteria for Streaming Service
The value shown in Table 2 will be used for following steps of our example.
Performance of candidate networks can also be compared directly. The value of can be: 1 -
both candidate networks‘ performance are equal; 3 - candidate network i‘s performance is
1 OB 2 ID 3 Cost 4 Throughput 5 Losses 6 RTT
1 OB 1 5 1/5 1/5 1/5 1
2 ID 1/5 1 1/7 1/7 1/7 1/3
3 Cost 5 7 1 1 1 5
4 Throughput 5 7 1 1 1 5
5 Losses 5 7 1 1 1 5
6 RTT 1 3 1/5 1/5 1/5 1
34
weakly better; 5 - candidate network i‘s performance is strongly better; 7 - candidate network i‘s
performance is demonstrably better; 9 - candidate network i‘s performance is absolutely better.
The pairwise comparison results between the performance of candidate networks with respect to
each criterion for the streaming application in our example (can be seen as a matrix for the value
of ) can be seen from Table 3 to Table 8, where we mark the candidate networks-WLAN,
UMTS, and GPRS-with the number 1, 2 and 3.
Table 3 Comparison of candidate networks with respect to OB
for ID 1 WLAN 2 UMTS 3 GPRS
1 WLAN 1 7 3
2 UMTS 1/7 1 1/5
3 GPRS 1/3 5 1
Table 4 Comparison of candidate networks with respect to ID
for OB 1 WLAN 2 UMTS 3 GPRS
1 WLAN 1 5 9
2 UMTS 1/5 1 5
3 GPRS 1/9 1/5 1
Table 5 Comparison of candidate networks with respect to Cost
for Cost 1 WLAN 2 UMTS 3 GPRS
1 WLAN 1 1 1
2 UMTS 1 1 1
3 GPRS 1 1 1
Table 6 Comparison of candidate networks with respect to Throughput
for Throughput 1 WLAN 2 UMTS 3 GPRS
1 WLAN 1 1 1
2 UMTS 1 1 1
3 GPRS 1 1 1
Table 7 Comparison of candidate networks with respect to Losses
for Losses 1 WLAN 2 UMTS 3 GPRS
1 WLAN 1 1 1
2 UMTS 1 1 1
3 GPRS 1 1 1
35
Table 8 Comparison of candidate networks with respect to RTT
for RTT 1 WLAN 2 UMTS 3 GPRS
1 WLAN 1 5 9
2 UMTS 1/5 1 5
3 GPRS 1/9 1/5 1
Values in above tables are derived from [43]:
With regard to OB, WLAN offers strongly more bandwidth than UMTS ( =5), and
absolutely more than GPRS ( =9, =5).
With regard to ID, WLAN is demonstrably faster than UMTS ( =7) and is weakly faster than
GPRS ( =3). GPRS can be strongly faster than UMTS ( =5).
With regard to Cost, Modern subscriptions imply flat rate so all attributes are deemed equal.
( = = =1).
With regard to Throughput and Losses, No particularities regarding throughput, i.e. all attributes
are considered equal. ( = = =1).
With regard to RTT, WLAN displays strongly shorter RTT than UMTS and absolutely shorter
RTT than GPRS ( =5, =9 and =5).
Compared to the methods where criteria and candidate networks are ranked and/or assigned
values before pairwise comparison, here only direct pairwise comparison is enough.
Note in following steps of our example, for criteria scoring and network scoring, those values
from the method of direct comparison (those from Table 3 to Table 8) will be adopted.
Step 2: Weights Calculation
For weight calculation the solutions described in [43], [54], [58], [61], [62], [63] and [64].
In order to calculate the weight of criteria, we have to normalize each column of the matrices of
and (shown in Figure 17, which is correspondent to Table 3 to Table 8 ) first.
36
Figure 17 matrices of and
We denote elements of the matrix whose columns have already been normalized with for
criteria score comparison and with for network score comparison. The normalization
equations are Equation 4 and Equation 5 [43].
Equation
4
Equation
5
where ―6‖ in Equation 4 means number of rows of matrix of and ―3‖ in Equation 5 means
number of rows of matrix of . Then each row of and
should be summed up, resulting
in matrices of Rij‘‘ and Rsij‘‘, according to Equation 6 and Equation 7:
Equation 6
Equation 7
Where ―6‖ in Equation 6 means number of columns of matrix of and ―3‖ in Equation 7
means number of columns of matrix of . Based on Equation 8 and Equation 9, we would be
37
able to calculate weight of criteria ―i‖ ( ) and that of candidate network ―s‖ with respect to
specific criteria ―i‖ ( ).
Equation 8
Equation 9
Where ―6‖ in Equation 8 is the dimension of the vector and ―3‖ Equation 9 is the dimension
of the vector ‘. Then we got the vectors for the weights shown in Figure 18:
Figure 18 calculated weights for criteria and candidate networks
Then, we finish the calculation of weights of criteria and candidate networks. Besides, in [54],
the method on normalization of columns for each matrix is slightly different, where the
equations given below are used:
Equation 10
Equation 11
According to [58], we still need to check for the consistency of the comparison results. This is
accomplished using the consistency index (CI) that is calculated using Equation 12:
Equation
12
Here, is the maximum eigenvalue of a matrix and n is the size of such a matrix.
The consistency ratio (CR) is obtained by dividing CI with the random index (RI) Equation 13,
i.e. CR=CI/RI.
DeSchutter conjectured relationship between the index RI and n [61] in Equation 13:
38
Equation 13
Where 1.98 is the average value of the ratio of each value computed so far from n = 3 to 15
divided by for the corresponding value of n, see [62]. The level of inconsistency is
acceptable if the CR value is less than 0.10 in AHP models [63]. The CI, RI and CR of above
matrices are listed in Table 9:
Table 9 Consistency Parameter values for criteria and candidate network matrices
Consistency
Parameter
For
criteria
For
OB
For ID For
Cost
For
Throughput
For
Losses
For
RTT
CI 0.0585 0.0585
RI 0.66 0.66
CR 0.0877 0.0877
We can see from Table 9 that all listed CR values are less than 0.10, so the level of inconsistency
for each matrix is deemed as acceptable. The tool we used to calculate the maximum eigenvalues
is ―Calculator for Eigenvalues and Eigenvectors‖ described in [64].
Step 3: Final Score Calculation
In this step, the weights obtained in Step 2 will be used to calculate the final score for each
candidate network. In [59], a survey of four methods is described: SAW (Simple Additive
Weighting) [65], TOPSIS (Technique for Order Preference by Similarity to Ideal Solution) [65],
GRA (Grey Relational Analysis) [66] and MEW (Multiplicative Exponent Weighting) [67].
Simple Additive Weighting (SAW)
This method is also applied in [43], which is also used in our example. Here, the overall score of
a candidate network is determined by the weighted sum of all the attribute values as shown in
Equation 14:
= *
Equation 14
where ― ‖ means the final score for candidate network ―n‖; ― ‖ is the weight of candidate
network ―n‖ for the criteria ―i‖; ― ‖ is the weight of criteria ―i‖ and ― ‖ is the number of
criteria. In our example, =6 and the weights can be found in Figure 18. Therefore, we can
the calculated final score for each candidate network as listed in Table 10.
Table 10 final score of candidate networks by SAW
Candidate
Network
WLAN UMTS GPRS
Final
Score
0.3972 0.3088 0.29374
According to the result shown in Table 10, WLAN is the most suitable choice for our example.
39
Technique for Order Preference by Similarity to Ideal Solution (TOPSIS)
As shown in [65], for TOPSIS, the selected candidate network is the one which is closest to the
ideal solution (and the farthest from the worst case solution). The ideal solution is obtained by
using the best values for each metric. In our example, as shown in Step 1, we assign a candidate
network with better performance a higher score, so for the last 6 vectors of candidate network‘s
performance shown in Figure 18, the largest number in each vector characterizes the candidate
network with the best performance for corresponding criteria and the smallest number in each
vector characterizes the candidate network with the worst performance for corresponding
criteria. Therefore, the vectors of scores of different candidate networks (weighted by the criteria
weights, in other words, multiplied with the first vector in Figure 18) and the vectors of best
score (highest in our example) and worst score (lowest in our example) for each criterion are all
shown in Table 11.
Table 11 vectors of scores of candidate networks, ideal solution and worst solution
Vector Name OB ID Cost Throughput Losses RTT
0.0544 0.0199 0.0922 0.0922 0.0922 0.0464
0.0162 0.0023 0.0922 0.0922 0.0922 0.0138
0.0046 0.0087 0.0922 0.0922 0.0922 0.0039
0.0544 0.0199 0.0922 0.0922 0.0922 0.0464
0.0046 0.0023 0.0922 0.0922 0.0922 0.0039
With respect to [65], then we need to calculate the distance between score vector of each
candidate network and the vector of highest values and the vector of lowest values respectively
shown in Equation 15 and Equation 16.
Distance from the vector of scores of candidate network ―net‖ to the vector of best values:
Equation
15
Distance from the vector of scores of candidate network ―net‖ to the vector of worst values:
Equation
16
Where means the score of candidate network ―net‖ specific to criteria ―i‖; and
denote the best (highest in this example) and worst (lowest in this example) score
specific to criteria ―i‖ respectively. Equation 17 is the equation of calculating relative closeness
defined in [65]:
Equation 17
40
From Equation 17, we can see that if the candidate network is close to the ideal solution and/or
far away from the worst case solution, the relative closeness should be near to 1.
Thus, the closeness calculated by Equation 17 for each candidate network can be seen in table:
Table 12 Closeness of candidate networks by TOPSIS
Candidate Network WLAN UMTS GPRS Closeness(CL) 1 0.2227 0.0879
In our example, WLAN is just the ideal solution (relative closeness=1) and it should be selected
as ―best‖.
Grey Relational Analysis (GRA)
The idea of GRA is similar to that of TOPSIS, and in our example, we should select the
candidate network of the largest grey relational coefficient (GRC) instead of relative closeness in
TOPSIS. Here we just introduce how to calculate GRC in our example and a more detailed
description can be found in [66]. In [66], multiple UMTS and WLAN candidate networks are
considered. First, weight of each candidate network has to be normalized by equation.
=
Equation 18
where is the weight of candidate network ―i‖ specific to criteria ―j‖; and are
respectively the smallest and largest weight among all the candidate networks specific to criteria
―j‖. Since in our example, for some criteria like ―Cost‖, every candidate network has the same
weight, which can be treated as either the smallest (case 1) or the largest weight (case 2).
Then we can use these normalized weight scores to calculate the GRC for each candidate
network by Equation 19.
Equation 19
where means the weight of criteria ―j‖.
The calculation result is shown in Table 13:
Table 13 GRC of candidate networks by GRA
Candidate
Network
WLAN UMTS GPRS
GRC (case 1)
0.5466 0.5083 0.5029
GRC (case
2)
1 0.8789 0.8628
As a result, we should select WLAN again for it has the highest GRC in both cases.
41
Multiplicative Exponent Weighting (MEW)
In this method, the score for each candidate network is calculated with Equation 20:
=
Equation 20
Where is the weight of candidate network ―i‖ specific to criteria ―j‖; means the weight
of criteria ―j‖. Usually, this score will be also normalized by the ideal solution with Equation 21:
Equation 21
Where means the best value among candidate networks for criteria ‗j‘. The candidate
network with the largest will be selected as ―best‖ and the calculation result is shown in Table
14:
Table 14 of candidate networks by MEW
Candidate
Network
WLAN UMTS GPRS
1 0.7901 0.6908
Note that WLAN is selected as ―best‖ candidate.
In [59], these four methods are evaluated, where the used selection criteria are bandwidth, delay,
jitter and BER, concluded that GRA provides a slightly higher bandwidth and lower delay for
interactive and background traffic classes. Moreover, results showed that the performance of all
four methods depend on the way of how the importance weights are assigned to the selection
criteria.
So far, we have introduced three steps of using AHP to make a multi-criteria decision: (1) initial
scoring for criteria and candidate networks, (2) weights calculation for criteria and candidate
networks and (3) final score calculation for candidate networks. AHP is the most widely-used
algorithm method in multi-criteria decision on communication network/interface selection.
3.3.2 Cost Function-based method
Vertical handover decision cost function is a measurement of the benefit obtained by handover
to a particular network [53]. It is evaluated for each candidate network available with respect to
a user service. It is a sum of weighted functions of specific parameters. The general form of the
cost function in [68], is:
= Equation 22
where represents the cost in the criteria ―i‖ to carry out service ―s‖ on network n, and
represents the weight assigned to criteria ‗i‘ for service ―s. For different services, a criterion
might have different weights. Suppose a user would like to make his vertical handover decision
42
based on criteria: monetary cost and bandwidth of available candidate networks. Another cost
function is described in [69], see Equation 23
= ln(
)+ ln( ) Equation 23
where represents the bandwidth that candidate network n can offer and represents the
monetary cost of candidate network n. and are the weights assigned to criteria of
bandwidth and monetary cost respectively. And the summation of all the weights assigned to
different criteria should equal to 1. The communication network that has the lowest cost is
chosen as the target network. Therefore, dynamic network conditions should be estimated and a
waiting period before handover should be included to ensure that a handover is worthwhile for
each mobile station, e.g. traffic load for the target network deemed by mobile stations before
handover may be obviously different after multiple stations handover to the same target network
at the same time. With a period of waiting time, ―ping-pong‖ effect can be avoided. And with
different waiting time, mobile stations are able to sense the traffic load changes timely. In [69],
the Equation 24 is used, which not only gives priority to the mobile station benefiting more by
handover, but also differentiates the handover waiting period for all mobile stations:
Equation 24
Where is the handoff latency, is the cost function evaluated for the target
network, and is the cost function evaluated for the current network.
Besides the weight factors, W and QoS factors, Q as shown in Equation 25 used to calculate cost
of candidate networks, a network elimination factor, E, was introduced in [69] as optimization,
which is used to eliminate the candidate network not able to guarantee certain constraints for
specific services. The cost function is shown in Equation 25:
Equation 25
where is the normalized QoS parameter,
, representing the cost with respect to
criteria ―j‖ for service ―s‖ on network ―n‖, is the weighting function for criteria ―j‖ for
service s and is the network elimination factor for candidate network ―n‖ with respect to
criteria ―i‖ for service ―s‖. can be one or infinity. If one certain constraint cannot be
guaranteed, the value for the cost function will be infinity and corresponding candidate network
―n‖ will be excluded.
This eliminator factor, , performs the function of checking the availability of networks, while
in above section of AHP, all considered candidate networks are assumed to be available (all
constraints of considered criteria can be guaranteed).
In [69], the method utilizing eliminating factor is evaluated in a specific scenario, presenting its
performance‘s slight better than that without utilizing eliminating factor.
43
In [68], [69] and [70], the authors consider the handover for a station with multiple sessions
(services) and to be implemented by Mobile IP. In [68], [69], the ―collective session handoff‖ is
considered where all services should be handover to a same target network and the cost function
should take all services into account, while in [70], the ―prioritized session handoff‖ is
introduced, where cost function of different services are calculated independently in the
sequence from the service of the highest priority to the service of the lowest priority so that each
service will be handover to its own ―best‖ target network.
3.3.3 Utility Function-based method Vertical handover decision utility function is also a measurement of the benefit obtained by
handover to a particular network, which is similar to cost function. The difference between cost
function and utility function is that from the view of running applications on mobile station cost
function calculates the cost of each candidate network, while utility function calculates QoS
provided by each candidate network. There, the ―best‖ candidate network should supply to the
user application with highest value of utility function. The general form of a utility function can
be seen in equation Equation 26 [71]:
Equation 26
As shown in Equation 26 the utility function of wireless network ―j‖ from the view of mobile
users is composed of several normalized QoS factors (QoS value of network ―j‖ for criteria
―i‖) that are multiplied with their weights (importance). Unreachable wireless network always
has a utility of zero. Different applications may assign different weight values to a specific
criterion. Calculation of normalized QoS factors can be seen in Equation 27:
)
,
) 0,
) 1
Equation 27
and are the maximum requirement and the minimum requirement of criteria ―i‖ and
is the real value of criteria ―i‖ in wireless network ―j‖. From above equation, if is
between UBi and LBi, it will be normalized, while if it is less than , it will be set to 0 and if it
is more than it will be set to 1, which means even if the performance of a specific network
on a specific criteria is not able to meet an application‘s minimum requirement, it won‘t be
eliminated as what the cost function with elimination factor does. Here, a handover waiting
period can be used to guarantee a selected target network‘s being consistently (during the
waiting time) better than the current one. Equation 28 is used to calculate the handover waiting
time, which is based on the cost function based method.
, r=
Equation 28
44
By using the cost function-based method, a mobile station can benefit by experiencing a shorter
handover time. A detailed example can be found in [46].
3.3.4 Fuzzy logic and neural networks based method
In this method, Fuzzy Logic (FL) and Neural Networks (NN) concepts are applied to choose
when and over which network to handover among different available access networks. In [72],
both the FL and NN concepts are introduced. The algorithm consists of a Modified Elman
Neural Network (MENN) predicting the number of users after the handover (considered as an
input of the adaptive multi-criteria decision) and a Fuzzy Inference System (FIS) that makes the
analysis of relevant criteria and does the final decision according to the inputs and the IF-THEN
rules. In [72], a scenario with the coverage of UMTS (whole domain), WLAN (partial domain)
and the vertical handover between UMTS and WLAN is considered. The general reason of
handover from WLAN to UMTS are predefined as 1) mobile station has to leave the WLAN
coverage area; 2) the velocity of MS becomes very fast or the number-of-users of WLAN cell
increases to a certain threshold; while the handover from UMTS to WLAN is in order to pursue
high bandwidth and deduce the multi-user interference in UMTS.
In this method, different criteria are not scored but their performance is shown in linguistic
values. The bandwidth required by traffic can be: High (HI), Medium (ME), Low (LO); the
velocity of mobile station can be: Fast (FA), Medium (ME), Few (FE) and the number-of-users
after handover in target network can be: More (MO), Medium (ME), Few (FE). The max-min
inference method is used to calculate the result while it is not clearly stated in the paper about
the details of this max-min inference method. According to [9], the general idea of max-min
inference method: for candidate ― ‖ and criteria , means how much a
candidate ― ‖ suits criteria ― ‖. And how much a candidate ― ‖ suits multiple criteria can be
found in Equation 29.
For all
Equation 29
And the optimal candidate should fulfill Equation 30.
Equation 30
The corresponding fuzzy inference rule (FIS) base generated in [72] is shown in Table 15:
Table 15 Fuzzy Interference Rules (FIS)
45
The output of the FIS for handoff is: Very Fit (VF), Fit (FI), Weak Fit (WF), and Not Fit (NF).
The number of users after handover is predicted by an algorithm using an MENN structure.
More details can be found in [72]. In [73] and [74], an NN algorithm is used to predict the RSS,
where the handover is just triggered by only one criterion. The simulation results showed that for
the WLAN specific simulated scenario this method outperforms the methods (1) handover with
respect to RSS on packet drop ratio, (2) retransmission packets number and delay.
3.3.5 Geometric Speed-based Method
The previously described methods are in the context of vertical handover for typical mobile
stations/devices. For vehicles, which can (1) move with a higher velocity and (2) on a predefined
road, geometry information can be used to help the handover decision process. Compared to
other mobile stations/devices, the battery power of vehicles is not limited and therefore it is not
considered to be a critical issue in the selection making process. However, the influence of
vehicle speed of and the coverage area of the communication network during the decision
making process are considered to be significant. In [75] a geometric speed-based method is
described. In particular, in [75], a handover is defined as ―valid‖ if, and only if, the handover
results in a throughput increase. Furthermore, [75] provides a definition to the following
parameters: cell crossing time and handover latency. In particular a cell crossing time is defined
as the time a vehicle can spend under one specific network‘s coverage. Handover latency is
defined as a period of time during which a vehicle that starts a handover procedure cannot
received any data. The network topology used in [75] is given in Figure 19.
46
Figure 19 Manhattan mobility model for a VANET scenario (copied from [75])
In Figure 19, it is considered that the UMTS network has a global coverage; the WLAN network
just covers part of the area. As shown in the Figure 19: ―v‖ represents the speed of the vehicle;
― ‖ and ― ‖ are respectively the time the vehicle enter and depart the coverage of WLAN;
is the distance that the vehicle passes through; is the angle to the access point of WLAN.
The relationship between ― ‖and ― ‖ can be found in Equation 31.
Equation 31
And the calculation of cell crossing time and the throughput that a vehicle would
experience by remaining connected to the Service Network (SN), during the cell crossing time
can be found in Equation 32 and Equation 33:
] Equation 32
= Equation 33
where ( , ) and ( , ) are the coordinates of the point where the vehicle enter the
coverage of the SN and where the vehicle leave the coverage of the SN. is the bandwidth
offered by SN. Correspondingly, is the bandwidth offered by Candidate Network (CN), and
with a handover latency of ―L‖. The throughput experienced by a vehicle if it handover to the
CN for the same period of time is shown in Equation 34:
( Equation 34
Where is a hysteresis factor introduced to avoid vertical handover occurrence when both the
SN and CN have negligible bandwidth difference. The geometric information can be collected
by GPS. Therefore, the handover will be initiated only when:
Equation 35
As this method shows, geometric information and vehicle‘s speed can be used to prevent
unnecessary handover. Similar mechanisms can be found in [76], [57]. The result in [75] showed
that vehicles are required to maintain a given speed limitation to maintain acceptable levels of
throughput, delay and jitter and better performance compared to similar mechanism in [76].
47
3.4 Conclusions In this chapter, five general methods are introduced: (1) AHP; (2) Cost Function-based method;
(3) Utility Function-based method; (4) Fuzzy logic and neural networks based method and (5)
Geometric Speed-based Method. Among these methods, AHP is the most widely used one,
which can efficiently support the multiple criteria selection procedure. The Cost Function-based
and Utility Function-based methods use intuitive algorithms. The fuzzy logic and neural
networks based method scores the candidate networks with linguistic variables (e.g. high or low)
instead of quantitative values; In particular, they predict the traffic load after handover using the
neural network algorithm and make the decision based on a max-min inference method. This
decision making method is different from the methods used for AHP‘s final scoring. The
Geometric Speed-based method adopts the geometric coverage of a specific network. Moreover,
the position of the vehicle and the speed of the vehicle are used to estimate whether a handover
can benefit from the point of view of available throughput increase.
48
49
Chapter 4: Handover Mechanisms
In this chapter, the vertical handover mechanisms defined in IEEE (IEEE 802.21) and 3GPP
(3GPP TS 23402-a21) are introduced. Furthermore, multiple IP-based mobility management
mechanisms specified by the IETF are described, such as Mobile IP, Proxy Mobile IP, Network
Mobility (NEMO) [77].
4.1 IEEE 802.21-Media-Independent Handover IEEE 802.21 is developing standards to enable handover and interoperability between
heterogeneous network types including both 802 and non 802 networks [78]. The scope of
802.21 can be seen in Figure 20.
Figure 20 The scope of IEEE 802.21 (copied from [79])
IEEE 802.21 is responsible for the Handover Initiation and Handover Preparation procedures,
see Figure 20, which are to be realized in a media-independent handover (MIH) framework
defined in IEEE 802.21 standard [80]. While the IEEE 802.21 helps with the discovery of the
available networks, the selection of used network, the handover negotiation, the Layer 2 and IP
Connectivity, it does not attempt to standardize the actual handover execution mechanism.
However, the MIH framework is equally applicable to systems that employ mobile IP at the IP
layer as to systems that employ Session Initiation Protocol (SIP) at the application layer [81],
which help with the handover execution part.
MIH framework
The MIH framework is specified in [80] and it comprises three main elements: (1) MIH function
(MIHF), (2) Service Access Points (SAPs) and (3) MIH users. They will be introduced below:
MIHF shown in Figure 21 is a logical entity whose primary role is to facilitate handovers and
provide intelligence to the network selector entity (the network selector is outside the scope of
IEEE 802.21 but considered in Chapter 3).
50
Figure 21 General MIHF reference model and SAPs (copied from [80])
In Figure 21, MIHF provides abstract services to the higher layers through a media independent
interface (MIH_SAP) and obtains information from the lower layers (different access
technologies) through media specific interfaces (MIH_LINK_SAP). Three kinds of services of
MIHF are defined, including: (1) media independent event service (MIES), (2) media
independent command service (MICS) and (3) media independent information service (MIIS),
which have different requirements for the transport protocol and are generally referred to as
Mobility Services (MoS) and in IETF RFCs [82-85].
MIH Event Service (MIES)
Events may indicate changes in state and transmission behavior of the physical, data link and
logical link layers, or predict state changes of these layers. The Event Services may also be used
to indicate management actions or command status on the part of the network or some
management entity. Table 16 introduces several proposed link layer events:
51
Table 16 Proposed Link Layer Events (copied from [79])
MIH Command Service (MICS)
The command service enables higher layers to control the physical, data link, and logical link
layers. The higher layers may control the reconfiguration or selection of an appropriate link
through a set of handover commands.
MIH Information Service (MIIS)
Information Service provide a unified framework to the higher-layer entities across the
heterogeneous network environment to facilitate discovery and selection of multiple types of
networks existing within a geographical area, with the objective to help the higher-layer mobility
protocols to acquire a global view of the heterogeneous networks and perform seamless
handover across these networks.
MIH services may be either local or remote, with local operation occurring within a protocol
stack and remote operation occurring between two MIHF entities. For example, remote
communication can occur between an MIHF entity in a mobile node (MN) and another MIHF
entity located in the network. Different scenarios can be found in [83].
MIH SAPs (Service Access Points) defined in IEEE 802.21 include:
MIH_SAP, a media independent interface between the MIHF and upper layers of the
mobility management protocol stack. The upper layers need to subscribe with the MIHF
as users to receive MIHF-generated events and also for link-layer events that originate at
layers below the MIHF but are passed on to MIHF users through the MIHF. MIHF users
directly send commands to the local MIHF using the service primitives of the MIH_SAP.
The MIH_LINK_SAP, an abstract media dependent interface between the MIHF and
lower layers media-specific protocol stacks of technologies such as IEEE 802.3, IEEE
802.11, IEEE 802.16, 3GPP, and 3GPP2. For different link-layer technologies, media-specific SAPs provide the functionality of MIH_LINK_SAP. Amendments are
suggested to the respective media-specific SAPs to provide all the functionality as
described by MIH_LINK_SAP (e.g. IEEE 802.11u [86] and 802.16g [87]).
The MIH_NET_SAP, an abstract media dependent interface of the MIHF that provides
transport services over the data plane on the local node, supporting the exchange of MIH information and messages with remote MIHFs.
52
MIH users are abstractions of the functional entities that employ MIH services, that is,
consumers of MIH services. A typical user of MIH services could be a mobility management
application that would use these services to optimize handovers [81]. For example, MIH users
can subscribe with the MIES to be notified when specific events important to the handover
decision and process occur. While MIH Protocol is defined in IEEE 802.21, transport for MIH
Protocol is defined in IETF (MIPSHOP: Mobility for IP: Performance, Signalling and Handoff
Optimization [88]) and details can be found in [82-85].
In [81], an example which uses media-independent pre-authentication (MPA) [89] client acting
as the mobility management entity to demonstrate how MIH services work is given. Here we
will briefly describe the example. The handover scenario is shown in Figure 22 Handover
scenario example for MIH (copied from [78]).
Figure 22 Handover scenario example for MIH (copied from [78])
In Figure 22 Handover scenario example for MIH (copied from [78]), a multi-interface MN
equipped with Wi-Fi and EV-DO (Evolution-Data designed for Optimized CDMA2000)
interfaces, which has an on-going VoIP session and runs an MPA client, is going to roam from a
Wi-Fi network to a cellular (CDMA 2000 and EV-DO interface used) network. In this scenario,
the corresponding node (CN) is located in another ―Enterprise network with WLAN access‖.
Besides, the MPA server and Information Server which provides the MIIS to MN via tunnelled
traffic both reside at the ―Enterprise network with WLAN access‖.
53
During the handover, whereas the MPA client is responsible for executing the inter-technology
handover, the MIH services can be used to provide valuable information to assist in handover
preparation and initiation.
The MPA client first subscribes to two MIH events on the Wi-Fi interface. One event
(MIH_Link_Param_Report event) is used to provide link parameter reports. The other
(MIH_Link_Down) is used to trigger the handover. Then the MPA client uses command
MIH_Link_Configure_Threshold to establish a set of Wi-Fi signal strength levels that trigger
notifications.
As MN moves far from AP of its current-involved Wi-Fi network, the first link indication
reporting the weakened Wi-Fi signal would trigger the MPA client to query the Information
Server for available neighboring networks using its own current location. Then, the Information
Server reports the availability of the cellular network, which enables the MPA client to be aware
of the cellular network without turning on the EV-DO interface.
After signal strength of Wi-Fi weakens further, a second threshold is crossed, which trigger that
the MPA client starts setting up the cellular connection (pre-authentication, pre-configuration,
and start proactive handover (HO) tunnel procedures through the serving Wi-Fi interface). Then
the EV-DO interface is brought up by the command Link_UP MIH command.
When MN leaves the coverage of Wi-Fi, a Link Down indication is received and the handover
operation is completed. Finally, the MPA client uses MICS to deactivate the Wi-Fi interface and
delete the MPA HO tunnel between the original Wi-Fi network and the Information server.
In this example, IEEE 802.21 services supply the MPA client with knowledge of available
networks, allowing the device to avoid active scanning and to power off interface when no
appropriate networks are available. Though in this example, only RSS is used as the indication,
other metrics can also be used to trigger the Information Service query.
4.2 3GPP-defined vertical handover mechanisms The LTE Evolved Packet System (EPS) is an evolution of the 3GPP system architecture with the
vision of an all-IP network finally realized. EPS consists of the Evolved UTRAN (E-UTRAN)
and Evolved Packet Core (EPC). EPC supports mobility with the existing 3GPP and non-3GPP
wireless networks to facilitate smooth migration, interworking, and service continuity across
these networks.
In [90] 3GPP specifies the ―Architecture enhancements for non-3GPP accesses‖. In [90] the EPS
does not only support the use of non-3GPP IP access networks to access the EPC, but it also
supports network-based mobility management mechanism based on PMIP or GTP and host-
based mobility management mechanism (e.g., MIP).
The selection between network-based Mobility (NBM) and host-based mobility (HMB) is part of
the IP Mobility management Selection (IPMS), which also makes decision on IP address
preservation if NBM is selected. The IPMS can be initiated upon various events. These events
can be: (1) UE‘s initial attach to a trusted non-3GPP access or evolved packet data gateway
54
(ePDG), (2) upon UE‘s handover without optimization from a 3GPP access to a non-3GPP
access, (3) or upon UE‘s change of access between a non-3GPP access and a 3GPP accesses or
between two non-3GPP accesses. How IPMS makes the decision on mobility management is
described in Sections 4.1.3.2.1 & 4.1.3.2.3 of [90]. The final decision on the mobility
management mechanism is made by the HSS/AAA upon UE authentication in the trusted non-
3GPP access system or ePDG, based on the information it has regarding the UE, local/home
network capabilities and local/home network policies.
In [90], three kinds of mobility management are mentioned: PMIP, GTP-based mechanisms and
MIP (e.g. DSMIPv6 and MIPv4). PMIP and MIP are both IP-based mechanisms defined by
IETF and they will be introduced in section 4.3, while GTP is standardized in 3GPP.
In 3GPP-defined vertical handovers, GTP provides the tunneling method at the reference point
S5/S8, which will be introduced below. An example [90] of handover from a trusted/untrusted
non-3GPP IP access to UTRAN/GERAN connected to EPC will be described here as
demonstration of how 3GPP-defined vertical handover works. Figure 23 shows us architecture
for EPS using PMP-based S8, S2a, and S2b:
Figure 23 Roaming Architecture for EPS using PMIP-based S8, S2a, S2b (copied from [90])
Before describing the handover process, the entities used in the architecture shown in Figure
23will be briefly introduced:
HPLMN denotes the Home Public Land Mobile Network (PLMN), which is the PLMN the
customer belongs to.
VPLMN denotes the Visitor PLMN (the PLMN the customer is roaming in).
55
In HPLMN:
HSS denotes the Home Subscriber Server, which the master database for a given user. It
is the entity containing the subscription-related information.
PDN Gateway denotes the Packet Data Network Gateway, whose functionality is
described in [91] for both 3GPP and non-3GPP accesses connected to the EPC via GTP-
based and PMIP-based S5/S8 interface. It is also the user plane anchor for mobility
between 3GPP access and non-3GPP access: A LMA according to the PMIPv6 specification, [92], if PMIP-based S5 or S8, or if
S2a or PMIP based S2b is used.
A DSMIPv6 Home Agent, as described in [93], if S2c is used.
Allocation of uplink Generic Routing Encapsulation (GRE) key for each PDN connection within the PDN GW, which is used to encapsulate uplink traffic to the
PDN GW on the PMIP-based S5/S8, or S2a or PMIP based S2b interface.
A MIPv4 Home Agent, if S2a with MIPv4 FA CoA mode is used. GTP for the control plane and the user plane to provide PDN connectivity to UEs
using non-3GPP accesses, if GTP based S2b is used.
HPCRF denotes the Home Policy Charging and Rules Function, while the PCRF
aggregates information to and from the network, operational support systems, and other sources (such as portals) in real time, supporting the creation of rules and then
automatically making intelligent policy decisions for each subscriber active on the
network [94].
3GPP AAA server denotes the entity performing the authentication, authorization and
accounting (AAA) functions for the network.
In VPLMN:
Serving Gateway, whose functionality is described in [91]. In addition, the Serving GW
includes the following functionality: A local non-3GPP anchor for the case of roaming when the non-3GPP IP accesses
connected to the VPLMN.
Event reporting to the PCRF. Uplink and downlink bearer binding towards 3GPP accesses as defined in [95]
Uplink bearer binding verification with packet dropping of "misbehaving UL
traffic". Mobile Access Gateway (MAG) according to PMIPv6 specification, if PMIP-based
S5 or S8 is used. The MAG function shall be able to send UL packets before
sending the PBU or before receiving the PBA
DHCPv4 (relay agent) and DHCPv6 (relay agent) functions if PMIP-based S5 or S8 is used. Other functions can be found in clause 4.3.3.2 [90]
vPCRF denotes the Visited PCRF with functions defined in [91]
ePDG denotes Evolved Packet Data Gateway, which is responsible for interworking
between the EPC and untrusted non-3GPP networks that require secure access. Its
functionalities are defined in clause 4.3.4 of [90].
3GPP AAA Proxy denotes a AAA proxy server in VPLMN
Only few reference points [90] that can be applied in our example are introduced below:
S2a It provides the user plane with related control and mobility support between trusted
non 3GPP IP access and the Gateway.
S2b It provides the user plane with related control and mobility support between ePDG
and the Gateway.
56
S2c It provides the user plane with related control and mobility support between UE and
the Gateway. This reference point is implemented over trusted and/or untrusted non-
3GPP Access and/or 3GPP access.
S5 It provides user plane tunnelling and tunnel management between Serving GW and
PDN GW. It is used for Serving GW relocation due to UE mobility and in case the
Serving GW needs to connect to a non- collocated PDN GW for the required PDN
connectivity.
PMIP-based S8 it is the roaming interface in case of roaming with home routed traffic.
It provides the user plane with related control between Gateways in the VPLMN and HPLMN.
In Figure 24, the steps involved in the handover from a trusted/untrusted non-3GPP IP access to
UTRAN/GERAN connected to EPC are depicted. In this example it is assumed that while the
UE is served by the trusted/untrusted non-3GPP IP access, a PMIPv6 tunnel is established
between the non-3GPP access network and the PDN GW in the EPC:
57
Figure 24 Handover from Trusted/untrusted Non-3GPP IP Access to UTRAN/GERAN with
PMIP (copied from [90])
The steps shown in Figure 24 are described below:
1. The UE uses a trusted/untrusted non-3GPP access system and is being served by PDN GW (as
PMIPv6 LMA).
2. The UE discovers the 3GPP Access system (UTRAN or GERAN) and determines to handover
from the currently used non-3GPP access system to the discovered 3GPP Access system.
3. The UE sends an Attach Request to the SGSN.
4. The SGSN may contact the HSS and authenticate the UE.
58
5. The SGSN may perform location update procedure and subscriber data retrieval from the
HSS. PDN GW identity information is part of the subscriber data.
6. The SGSN sends the Attach Accept request to the UE to indicate the completion of the attach
procedure.
7. The UE initiate at this stage this establishment of the primary PDP context, which consists of
all the required information for establishing an end-to-end connection.
8. The SGSN selects a Serving GW and sends Create Session Request message to the selected
Serving GW.
9. The Serving GW sends a Create Session Request message to the PDN-GW. The PDN GW
should not switch the tunnel from non-3GPP IP access to 3GPP access system at this point.
10. The PDN GW executes a PCEF (Policy and Charging Enforcement Function)-Initiated IP
CAN Session Modification Procedure with the PCRF to obtain the rules required for the PDN
GW to function as the PCEF for all the active sessions.
11. The PDN GW responds with a Create Session Response message to the Serving GW. The
Create Session Response contains the IP address or the prefix that was assigned to the UE while
it was connected to the non-3GPP IP access.
12. The Serving GW returns a Create Session Response message to the SGSN. This message
also includes the IP address of the UE. This message also serves as an indication to the SGSN
that the S5 bearer setup and update has been successful.
13. The rest of the PDP context establishment is completed here.
14.The Serving GW sends a Modify Bearer Request message to the PDN GW in the VPLMN or
the HPLMN including the Handover Indication flag that prompts the PDN GW to tunnel packets
from non 3GPP IP access to 3GPP access system and immediately start routing packets to the
Serving GW for the default and any dedicated EPS bearers established. In this step, The PDN
GW removes the old Policy and charging control (PCC) Rules for the Trusted or Untrusted Non-
3GPP IP access and applies the new Rules for UTRAN/GERAN access for charging.
15. The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.
16. The UE sends and receives data at this point via the 3GPP access system.
17. The PDN GW shall initiate resource allocation deactivation procedure in the
trusted/untrusted non-3GPP IP access.
It is important to emphasize that vertical handovers defined in 3GPP can adopt multiple mobility
management mechanisms belonging to both network-based mobility and host-based mobility.
Multiple handovers scenarios are taken into consideration by 3GPP (e.g. from 3GPP access to
trusted non-3GPP IP access, from a trusted/untrusted non-3GPP IP access to UTRAN/GERAN )
and here one example of a handover from non-3GPP access network to 3GPP access network
59
has been given, which is a typical scenario considered for vertical handover in vehicular
network.
4.3 IP-based mobility management mechanisms In this subsection, several representative IP-based mobility management mechanisms will be
introduced that is based on [96]. Though most of them were designed when horizontal handovers
were widely used, their ideas still apply to vertical handover, like Mobile IP‘s considered in the
3GPP-defined vertical handover.
4.3.1 Mobile IP (both IPv4 &IPv6)
Mobile IPv4 (MIPv4) [97] Mobile IPv6 (MIPv6) [98] were published by IETF respectively in
2002 and 2004. Although these two mobility management mechanisms differ in details,
conceptually they are quite similar. Since it is expected that IPv6 will be widely deployed in the
future, in order to solve the address limitations of IPv4, we provide an example of MIPv6 brief
operation in Figure 25.
Figure 25 Mobile IPv6 without Route Optimization (copied from [96])
Each mobile node (MN) has a Home Agent, from which it acquires its Home Address (HoA),
the identifier. The mobile node also obtains its locator, a Care-of Address (CoA) through
conventional IPv6 mechanisms, such as stateless or stateful auto-configuration [98]. MIPv6 can
only have its HoA and CoA co-located at the MN, while MIPv4 can also use the address of its
Foreign Agent (FA) located at the foreign network (visited network) as its CoA where HoA and
CoA are located at different entities.
Whenever the mobile node gets a new CoA, it sends a Binding Update message to notify the
Home Agent. This ―Binding‖ is an association between a mobile node's HoA and CoA. The
corresponding node (CN) uses the mobile‘s HoA as the destination IP address when sending data
to a MN. The packets are forwarded to the Home Agent, which then encapsulates the packets
60
and tunnelled them to mobile node‘s CoA according to the binding. The MN can send data to
CN directly.
Triangle routing problem happens when the CN and MN are located quite near while the data
from CN still needs to be sent to the MN‘s Home Agent and tunnelled to MN. By ―Route
Optimization‖, CN can learn MN‘s CoA and the binding should also be kept by the CN so that
CN itself can encapsulate packets to the MN directly. Note that in this case, the mobile needs to
update its CoA to CNs as well. The MN may also accept packets from several care-of addresses,
such as when it is moving but still reachable at the previous link.
4.3.2 Hierarchical Mobile IP (HMIP) HMIP [99] is a simple extension to MIP, whose architecture can be seen Figure 26 below.
Figure 26 Hierarchical Mobile IP (copied from [99])
In HMIP, a Mobility Anchor Point (MAP) is responsible for handling the movements of a
mobile in a local region, which can be seems as local Home Agent for the MN. A MN
supporting HMIP can obtain a Regional CoA (RCoA) and register it with its Home Agent as its
current CoA. Meanwhile, the MN obtains Local CoA (LCoA) from the subnet it attaches to.
RCoA not only represents the MN‘s locator in Mobile IP but also represents the MN‘s identifier
in the regional network, therefore, the MAP maintain the binding between RCoA and LCoA. As
MN roams within the region, it only updates the MAP‘s with binding between RCoA and LCoA.
In this way, the frequency of sending updates to Home Agents are reduced and updating between
MAP and MN has shorter round-trip time than that between HA and MN. For handover which is
between different MAPs, updating of binding between HoA and RCoA, and between RCoA and
LCoA are both necessary.
4.3.3 Fast Handover for Mobile IPv6 (FMIP) FMIP [100] is another extension to Mobile IP, whose architecture can be seen in Figure 27:
61
Figure 27 Fast Mobile IP(copied from [100])
As shown in Figure 27 MN is still connected to the PAR, it is able to detect that it has moved to
the NAR. Moreover, the MN can formulate a prospective new care-of address (NCoA) when it is
still on the previous link so that this NCoA can be used immediately after it attaches to the NAR.
In this way, the binding update latency is reduced. Besides, in order to reduce the Binding
Update interruption, FMIP specifies a tunnel between the previous care-of address (PCoA) and
the NCoA (between PAR and NAR in Figure 27). After the handover, the MN would send a Fast
Binding Update to the PAR then the PAR begins to tunnel packets for PCoA to NCoA while in
reverse direction, the MN also tunnels packets to PAR until it finishes the Binding Update
process. Without such a tunnel, the packets sent to PAR from CN after MN‘s handover to the
NAR and before the Binding Update process finishes will be lost.
4.3.4 Network Mobility (NEMO) In Network Mobility (NEMO) [77], supports the mobility of a communication network, e.g., a
train, instead of supporting the mobility of each MN individually. In NEMO, a new entity called
Mobile Router is introduced, which is similar to a MN but instead of having a single HoA, it has
one or more IP prefixes (namely Mobile Prefixes) as the identifier and also the CoA as the
locator. The Mobile Router would establish a tunnel to Home Agent and distribute its Mobile
Prefixes to the HA. The Mobile Prefixes is not leaked to its access router i.e. the access router
never knows that it can reach the Mobile Prefixes via the Mobile Router. The Home Agent then
announces the reachability to the Mobile Prefixes. Packets to mobile network would be first
encapsulated by HA and tunnelled to the Mobile Router with its CoA as destination address and
then forwarded to node after decapsulation by the Mobile Router. Packets from mobile network
would be tunnelled to home agent and then sent to CN. This encapsulation is required to avoid
problems with ingress filtering, because many routers implement security policies that do not
allow the forwarding of packets that have a source address that appears topologically incorrect.
Note that mobility is transparent to the nodes in the moving network [101].
4.3.5 Proxy Mobile IP (PMIP) PMIP [92] was proposed in 2006 to meet the interest of mobile network operators who desire to
support legacy mobile devices and to have tighter control on mobility support. Two new types of
62
network nodes are introduced in PMIP, Local Mobility Anchor (LMA) and Mobile Access
Gateway (MAG) (see Figure 28), which together can support mobility within an operator's
network without any action taken by the mobile node, in other words, PMIP is network-based.
Compared to MIP which is a global mobility management mechanism, PMIP is a Localized
Mobility management mechanism. LMA serves as a local Home Agent and assigns a local
Home Network Prefix for each mobile node. This prefix is the identifier for the MN within the
PMIP domain. MAGs monitor the attaching and detaching events of mobile node, and generate
Proxy Binding Update to LMA on behalf of mobile node during handoff, which is different from
HMIP where it is the MN generating the Binding Update to MAP. After the success of binding,
LMA updates mobile node's Proxy-CoA (locator in PMIP domain) with the IP address of the
MAG that is currently serving mobile node. The MAG then emulates mobile node's local Home
Link by advertising mobile node's local Home Network Prefix in Router Advertisement. When
roaming in the PMIP domain, mobile node always obtains its local Home Prefix, and believes
that it is on local Home Link, so mobility is transparent to the MN within the PMIP domain.
Within the domain, the mobile node is reached by the identifier (local Home Network Prefix)
and LMA tunnels packets to the mobile node according to the mapping.
Figure 28 Proxy Mobile IP
Dual Stack Mobile IPv6 (DSMIPv6) [93], considered as one of the mobility mechanisms used in
3GPP EPC and as a standard was proposed in 2009. The current Mobile IPv6 and Network
Mobility (NEMO) specifications support IPv6 only. This specification extends those standards
to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both
IPv4 and IPv6 packets over the tunnel to the home agent and allow IPv4 and IPv6 HoAs to bind
to an IPv4 or IPv6 CoA. This specification also allows the mobile node to roam over both IPv6
and IPv4, including the case where Network Address Translation is present on the path between
the mobile node and its home agent. Details can be found [93].
A brief overview of other IP- based mobility management protocols can be found in [96].
63
4.3.6 An example about implementation of mobility management mechanisms in vehicular network
Basic concepts and ideas of mobility management mechanisms have already been described
above within this chapter. In real world, the implementation process can make modifications to
the original mechanism in order to achieve better performance. Here we briefly give an example
about how a mobility management mechanism is implemented in a vehicular network.
In [102], a modified mobility management mechanism is used, which combines NEMO and
FMIP. For a bus with passengers as mobile nodes, the bus itself at least has a mobile router and
by pre-configuration idea of FMIP, the bus can reduce the latency and packet loss ratio. The pre-
configuration is achieved from several aspects:
First, one bus is equipped with two mobile routers--front mobile router (FMR) and rear mobile
router (RMR) as shown in Figure 29, while two neighboring vehicles in the same direction
which has at least one mobile router can form a ―virtual bus‖ with FMR and RMR equipped on
different vehicles, or more neighboring vehicles form a ―virtual bus‖ with intermediate vehicles‘
mobile routers as relay nodes between FMR and RMR. The mobile nodes in the bus would
communicate to Internet through the RMR. In this way, the FMR which is able to get access to a
new subnet earlier than RMR would assist RMR to do the pre-configuration.
Figure 29 Network mobility scenario: (a) NEMO on a real Bus (b) NEMO on a Virtual Bus with
two vehicles (c) NEMO on a Virtual Bus with three vehicles (copied form [102])
Second, an FMR is able to get its new IP address from a vehicle in the opposite direction or
vehicles in the same direction but being about to leave the FMR‘s target subnet, respectively,
like the exchange of IP address between BMR1 and BMR‘1 shown in Figure 29 and the IP
address of BMR1 gained from CMR1 shown in. If the FMR cannot get its new IP address
through these two methods, it will try to acquire the IP address from the DHCP Server, which is
slower than acquire IP address from vehicles.
64
Figure 30(a) Acquire IP address from the lanes of the opposite direction. (b) Acquire IP address
from the lanes of the same direction (copied from [102]).
After the IP address to be used in new subnet is received, the standard NEMO is used for the
binding update procedure.
65
Several solutions can be found, for example: (1) in [103] MIPv6 is considered to be the solution
for mobility management, in [104, 105] the interoperability between IPv4 and IPv6 is considered
in the implementation of MIP, in [103] an example is given of implementing a vertical handover
mechanism based on IEEE 802.21.
4.4 Conclusions and supplemented issues regarding to vertical
handover In traditional handover, the handover execution is triggered only by RSS (either by mobile
station or network part) or traffic overload (only by network part). For vertical handover this is
different, since many other metrics have to be considered for the handover decision procedure.
The handover can for example be triggered by the combination of metrics such as RSS, initial
delay, throughput, jitter, monetary cost and user preferences. How to make the selection between
candidate networks based on multiple metrics have already been dealt with in Chapter 3. IEEE
802.21 provides services to trigger handover (by MIES), gather metrics values necessary for
selection (by MIIS) and command service (MICS), see Section 4.1. 3GPP supplies the way of
making non-3GPP networks able to get access to the EPC (Evolved Packet Core). Different
mobility management mechanisms and handovers between different access networks (either
3GPP-based or non 3GPP-based) are also feasible as defined in [90], see Section 4.2. Moreover,
as discussed in Section 4.3, IETF specified several IP-based mobility management mechanisms.
An example of implementing one IP based mobility management mechanism is described in
Section 4.3.6. Moreover, several issues specific to vertical handover applied to our V2I scenario
are introduced, which are listed below:
Who is in control of the handover, network side or vehicle (mobile station) side?
The handover can be initiated in either network side or vehicle side for traditional horizontal
handover. However, additional issues should be considered for the realization of a vertical
handover. In [106], it is mentioned that for vertical handover, a multi-criteria selection procedure
should be performed. In particular, it is more efficient if these calculations are performed by the
mobile stations, instead of performing these calculations centrally at the network side. In order to
select the ―best‖ candidate network, users‘ should specify their preference on the different
selection criteria. These values should then be considered as private and therefore, they should
not be transferred to the network side. Moreover, the mobile station-initiated handover can
choose a candidate network with lower price which would not be influenced by the network
operator. Last but not least, it is quite difficult for the network side to execute the handover,
because different candidate access networks do probably not belong to the same operator while it
is easy for the mobile station to execute the handover because it has multiple interfaces.
Therefore, in our research, we assumed that the vehicle is in control of the handover.
For mobility management, PMIP might be considered only if the proxy domain is assumed to
belong to the same operator.
Address compatibility
The candidate access networks may have different kinds of addressing mechanisms. In our
research work, we just simply assume they are all using IPv6.
66
Metric compatibility
In order to maintain a connection, different RSS thresholds should apply to different access
mechanisms. Therefore, we consider the availability of different candidate networks based on
different predefined RSS thresholds.
Besides for monetary cost, multiple accounting models are used like time-based, volume-based
and flat rates with contract. Initially we consider that every user uses flat rates for different
networks.
Tight or loose coupling?
For the vertical handover between non-3GPP access networks and 3GPP access networks, there
are two main interworking architectures: (1) tightly coupling: the data transfers from non-3GPP
access networks to a Corresponding Node on the internet must go through the Core Network of
UMTS or (2) loosely coupling: the case when the WLAN is not operated by a cellular operator
but by private users, where data transmitted through WLAN will not go through Cellular
Networks. An example of the ―tightly coupling‖ has already been shown in section 4.2. For
vehicular networks, non-3GPP access networks can be used outdoor, where most of them are
operated by network operators, therefore, a tightly coupling can apply.
67
Chapter 5: Architecture Specification and Design
This chapter presents the derived architecture specification and design. In particular, based on
the conclusions presented in Chapter 2 to Chapter 4, the following topics are derived and
presented in this chapter: (1) the vehicular network scenario wherein the intelligent scheduler
will be deployed, (2) requirements on the selection-making and handover mechanisms, (3) the
communication architecture and mechanisms used by the intelligent scheduler, (4) the intelligent
scheduler functional entities and architecture.
5.1 Requirements and Choices
In this section, we will discuss the requirements on designing (or selecting) the decision-making
(selection-making) and handover mechanisms. Furthermore, present our choices on the used
communication architecture, .selection-making and handover mechanisms.
5.1.1 Requirements on designing Decision-making Mechanism
During horizontal handover, the decision making is only required to select an access wireless
network with enough RSS to maintain the connection. More criteria are taken under
consideration during vertical handover for V2I communication. Therefore, more requirements on
the decision-making mechanism are desired:
First, it is required that the decision-making mechanism is capable of dealing with
multiple criteria, which means that the decision-making mechanism can be used to make a decision with respect to multiple criteria. For the users, the decision-making
mechanism should target to suit the user needs than just maintaining good connectivity.
Second, the decision-making mechanism should be adaptive for different application
types. This is because a criterion may have a different importance for different
application types. Therefore, the criteria weights used by the decision mechanism should be easily adapted.
Third, the decision-making mechanism should be scalable from the point of the number
of the supported criteria. The user does not have to refer to the same set of criteria for a
certain application all the time. Taking monetary cost as example, the user may not consider this criterion any longer, if this user signed for a flat-rate contract.
Fourth, since this assignment focuses on V2I communication, vehicular networking
characteristics should be taken into consideration. Important selection criteria associated
with the vehicular networking characteristics are the speed of the vehicle, the coverage area of each wireless technology, the vehicle density and the required bandwidth
associated with the applications that run on vehicles. For example, consider that a
vehicle uses UMTS technology for its V2I communication and is moving with a high
speed. In particular, when the vehicle moves with such a high speed that it can pass through the coverage area of a WiMAX base station within a very short time, the
handover from the UMTS technology to the WiMAX technology could be unnecessary
if the benefit gained from a larger bandwidth is less than the benefit gained from the signalling and processing cost. Moreover, due to the Doppler Effect, the higher speed
the vehicle has the lower throughput it can achieve.
Therefore, speed of the vehicle and other geometric information (e.g. coverage of the
candidate networks) should be taken into consideration for decision making (e.g. to
prevent unnecessary handover).
68
Fifth, there might be multiple sessions inside one vehicle, like watching videos on line
and answering telephone by two passengers at the same time, so it is required that the
decision-making mechanism is able to deal with the simultaneous multiple-sessions case. Decision making for different simultaneous sessions can be treated independently
or aggregated depending on whether the vehicle supports communicating with multiple
interfaces.
Sixth, the decision-making mechanism should comply with the selected communication
architecture, e.g. it should consider the communication interfaces supported by the communication architecture; it should be able to use the information provided by the
communication entities supported by the communication architecture, etc. Furthermore,
the decision mechanism (1) should be simple, i.e., does not require large processing power, and (2) should be easy to be implemented.
5.1.2 Requirements on designing Handover Mechanism This section describes the requirements needed for the design of the handover mechanism.
First, the handover mechanism should be able to maintain the connection (or minimize
packet loss) during vertical handover, i.e. ―(quasi-) seamless‖. In a horizontal handover,
this is achieved using the concept of ―make before break‖. For a vertical handover, the
seamless handover can be achieved when the vehicle communicates with both the previous and the target (new) access technologies at the same time. This is only possible
if (1) the vehicle can communicate with two communication interfaces simultaneously
and (2) both access technologies are available at the same time. A handover mechanism
that can be used to provide a seamless vertical handover (and minimize packet loss) is a Mobile IP based mobility management mechanism.
Second, the handover processing complexity cost should be minimized, i.e. the
handover signalling and handover processing times should be minimized. Large
handover signalling and/or handover processing times influence the vehicle data throughput that can become lower within the coverage of the target (new) access
network.
Third, the handover mechanism should also support handovers of multiple sessions
(multiple applications). Multiple sessions might always handover to the same target (new) access network or independently handover to different target (new) access
networks.
Fourth, the handover mechanism should comply with the requirements imposed by the
communication architecture.
5.1.3 Selection of the V2I Communication Architecture In Chapter 2, we introduced different V2V and V2I communication architectures proposed by
different organizations or standardization bodies: communication architecture proposed by C2C-
CC; WAVE proposed by IEEE; ETSI ITS communication architecture; and ISO CALM
communication architecture.
In addition to the communication architecture proposed by C2C-CC, which is a non-profit
organization initiated by European vehicle manufacturers, three other communication
architectures are proposed by standardization bodies. This means these three communication
architectures are being standardized or have already been standardized. Among these three
communication architectures, the WAVE architecture just considers the communication
69
interface defined in IEEE 802.11p, so it is not suitable for our intelligent scheduler which is
designed to work in communication architecture with multiple communication interfaces.
Actually, the communication architectures proposed by ETSI and ISO are quite similar. The
main difference is that the previous one is standardized by ETSI TC ITS on a regional level
while the latter one is standardized by ISO TC204 on an international level.
We select the CALM communication architecture to implement our intelligent scheduler
because it supports:
multiple communication interfaces (access technologies);
a communication interface for selection management (clearly specified in ISO 24102
[32]).
The above make the CALM architecture suitable for implementing our intelligent scheduler. In
addition, the ISO CALM architecture is standardized by the International Standardization
Organization, which is a standardization body, where its participants are ITS operators,
automobile manufacturers and ITS users located worldwide. This means that there is a high
chance that the ISO CALM standard will be deployed worldwide.
5.1.4 Selection of the Decision-Making Method and the Handover Mechanism This section discusses the selection of the decision-making method and the handover mechanism
to be used in our intelligent scheduler. This selection process uses the requirements stated in
Section 5.1 and the solutions introduced in Chapter 3 and Chapter 4.
Selection of the Decision-Making Method
In Chapter 3, the decision-making mechanisms based on AHP, cost/utility functions, neural
networks and geometric information are discussed. These mechanisms focus on common and as
well as different aspects of decision making.
In particular, the different aspects are:
AHP focuses on scoring the candidate networks for a specific criteria and scoring the
multiple criteria.
Cost/utility functions provide a way of utilizing criteria‘s score and the candidate
networks‘ performances to calculate the candidate networks‘ final score.
Neural networks-based method helps to predict the traffic load of a candidate network
after handover when it is selected as a target (new) access network.
Geometric information can help preventing the unnecessary handovers.
However, if used individually, none of these methods provide us a satisfactory solution:
AHP itself cannot preclude the consideration of an access network during selection-
making process if this network cannot meet the requirement(s) on one or more criteria parameters, e.g., minimum delay value, as a candidate access network. Considering
unavailable network (which cannot meet one or more of the minimal requirements) as
candidate networks, may result in an unnecessary handover execution especially when it
is just utilizing geometric information.
70
Cost/utility function can utilize the elimination factor as stated in section 3.3.2 to
exclude unavailable networks so that they will not be considered in calculating the
candidate networks‘ final score. However, it does not use a well-defined criteria scoring method. Specifying weights of different criteria directly is more difficult for the user
than comparing different criteria pairwise and specifying weights directly is not scalable.
It means that each time the number of criteria changes, the user has to reassign weights
to all the criteria, while for AHP, the user just needs to compare additional criteria with the existent criteria pairwise.
The neural networks-based method used to predict the traffic load of candidate networks
after handover seems useful. However, this prediction method is complicated and in a
vehicular networking environment with higher mobility, the prediction method might be even more complicated.
Simply calculating the benefit of throughput by handover based on the coverage and speed of
vehicle may neglect the influence of other criteria, e.g., cost and dynamic capabilities of the
candidate networks.
Since AHP supports multi-criteria decisions, and is efficient and scalable on changing the
criteria number and weights, it is considered as being suitable as the starting point on designing
the decision making method required for this assignment. The information required by the AHP
mechanism can be supplied by the IME and NME entities (see section 2.4.2). Though some
other requirements cannot be fulfilled by just using the original AHP mechanism, improvements
or additional functionalities can be defined in the implementation of the intelligent scheduler
(see section 5.3).
Selection of the Handover Mechanism
In Chapter 4, we have already discussed different standardization bodies and organizations‘
efforts on supporting vertical handover: IEEE 802.21 defined three kinds of services-MIES,
MICS and MIIS for indicating link events, setting higher layer commands and providing the
higher layer information of the heterogeneous network environment (see section 4.1); 3GPP
provides Architecture enhancements for non-3GPP accesses; IETF provides multiple network-
layer mobility management mechanism.
Since we have selected the CALM communication architecture, we should select the handover
mechanism complying with the requirements of CALM. It is mentioned in [39] that during
vertical handover, the IP address must be changed because an IP address has two parts: Network
ID and Host ID, and the Network ID is dependent on network to which it is attached. Therefore,
we need a layer-3 mobility management mechanism to maintain our session continuity. As
emphasized in [37], the IPv6 session continuity shall be achieved in accordance with the NEMO
'Basic Support' protocol [77] Therefore, the mobility management mechanism selected for this
assignment is the NEMO ‗Basic Support‘ protocol. Furthermore, NEMO is backwards
compatible with Mobile IPv6 and the NEMO Basic Support ensures session continuity for all the
nodes in the Mobile Network. This is achieved even when the Mobile Router changes its point
of attachment to the Internet. In vehicular networks, a vehicle can operate as a Mobile Router,
that supports roaming and routing support for all devices incorporated within the vehicle.
71
5.2 Deployment Scenario and Used Entities This section specifies the deployment scenario where the intelligent scheduler will be applied.
Moreover, this section introduces the new network entities needed to support the intelligent
scheduler functionalities.
5.2.1 Deployment Scenario In an urban area, there is usually coverage of various heterogeneous wireless communication
technologies, like GPRS, UMTS, WLAN, and WiMAX. On their way of going across the city,
vehicle passengers are eligible to enjoy the benefits of getting access to the internet. The
intelligent scheduler will help the vehicle passengers travelling in an urban area to select the
access wireless technologies that satisfy their needs in the best possible way. Our basic
deployment scenario is a single road crossing the coverage areas of different wireless
technologies, see Figure 31.
Figure 31Deployment Scenario of our Intelligent Communication Medium Scheduler
As shown in Figure 31, we can see a vehicle is driving on a road which can be seen as the route
that a driver takes to reach his/her destination. Generally, we consider that four wireless
technologies can be used: UMTS, GPRS, WiMAX and WLAN. Since we assume WiMAX and
WLAN cannot offer ubiquitous coverage area in our deployment scenario as GPRS and UMTS
do, as the vehicle‘s position changes, the set of available technologies is also changing. For
example, as shown in Figure 31, the vehicle is going to enter the coverage area of a WLAN
access point, so its set of available technology changes from UMTS and GPRS to UMTS, GPRS
and WLAN. This means that the vehicle user of the intelligent scheduler will have an additional
wireless technology choice which might suit his/her need better than the one he/she is currently
72
using. Therefore, it is required that our scheduler should reconsider which wireless technology to
be used as the vehicle‘s position changing.
In order to make selections, our intelligent scheduler has to consider different criteria including
static (or slow changing) criteria like initial delay (access delay), monetary cost, and also
dynamic criteria like the offered bandwidth, delay and jitter. Normally, when a vehicle‘s driving
in the area covered by the same set of wireless technologies, or even by the same set of access
points and base stations, their performance (dynamic criteria) can also change as time goes by,
e.g. the traffic load for the access points and base stations can change. Therefore, it is required
that our intelligent scheduler should reconsider which wireless technology to be used as time
goes by.
The intelligent scheduler can either be implemented/applied in the vehicle or at the infrastructure
part. Here, we consider that the intelligent scheduler is implemented/applied in the vehicle, see
Figure 31. The reasons of why we only consider this case are:
so far, only the in-vehicle implementation of CALM is considered [40]
implementation at the infrastructure part could make the collection of the performance
values corresponding to the different criteria even more difficult. This is because
measuring performance values with respect to the various heterogeneous wireless technologies involves the cooperation between these wireless technologies and the
infrastructure, which is more complex than measuring the required performance values,
directly by the vehicle.
even when a centralized infrastructure node can be used to make the wireless
technology selection, the execution of the selection will be delayed once the handover
part is mobile-controlled
making the handover network-controlled, requires all the operators cooperation, which
might not be possible in the near future
implementing the intelligent scheduler at the vehicle part it might increase user privacy.
In the proposed deployment scenario, in addition to the intelligent communication medium
scheduler that is embedded into the vehicle, several new network entities are needed, see Figure
31. These network entities are:
Access Technology Agents (ATAs), which are represented by all types of base stations
and access points belonging to different access wireless technologies.
Information Server, which is a centralized entity that collects the (by the vehicle)
measured performance values of the different access wireless technologies providing coverage in the urban road area.
5.2.2 Used Network Entities This section introduces the intelligent scheduler, the Access Technology Agent (ATA) and the
Information Server. As shown in Figure 32, the intelligent scheduler, which is embedded into a
vehicle, communicates with the ATA using either the IEEE 80211p or a cellular wireless
technology. ATA is communicating with IS could either use a wired TCP/IP based
communication link or a cellular based wireless technology.
73
Figure 32Communication of Used Entities in Deployment Scenario
5.2.2.1 Assumptions on Intelligent Scheduler use
This section describes the assumptions that apply on where and how the intelligent scheduler is
used. These assumptions are:
the intelligent scheduler can be applied in different environments, but is optimised to be
used in urban environments;
the mobility and speed of vehicles is depending on the environment wherein the vehicle
is roaming. For example, in an urban environment, the vehicle will not move with a
speed higher than 50 km/hour.
the decision making mechanism associated with the intelligent scheduler is available in a
vehicle;
the decision making mechanism is among others initiated by vertical handovers.
Horizontal handovers are not triggering the decision making mechanism
the decision making mechanism is initiated when the vehicle is approaching the border
of a coverage area supported by the wireless technology that the vehicle during that
moment is using for V2I connectivity;
the decision making mechanism is using the metrics associated with Internet-based
applications, e.g., video streaming, monetary costs, characteristics of the environment
that the vehicle is moving in, vehicle traffic and dynamics, such as vehicle speed, data
traffic background at the moment that a vertical handover needs to be made and be
executed;
Assumptions made on the used entities are given in the following sections.
5.2.2.1.1 Vehicle
For a proper operation of the intelligent scheduler, several assumptions on the vehicle operation
are considered.
the vehicle should be equipped with the communication interfaces of all technologies
considered by us, i.e. GPRS, UMTS, WiMAX, and WLAN, which provide to the vehicle the basic functionality of connecting to heterogeneous wireless technologies.
the vehicle should store an up-to-date map and/or GPS, which means that the vehicle
should be able to know its position. This is because, see section 5.2.1, as the vehicle‘s
position changes, the available set of wireless technologies can also change.
we assume that the vehicle knows the coverage areas belonging to the different Access
Technology Agents. Together with the second assumption, listed above, the vehicle
knows where it is going to and which set of available access wireless technologies can
use. This can be done instead of continuously monitoring the available access networks,
which can help to reduce the battery consumption of the vehicle.
74
the vehicle, where the intelligent scheduler is embedded in, would measure the
performance parameters periodically and/or retrieve them from the different Access
Technology Agents. These performance parameter values are used as dynamic selection criteria, section 5.2.1. At the same time, the vehicle also measures other type of
characteristics, like the RSS, in order to monitor the communication link quality
when the vehicle is approaching an upcoming coverage area border of any Access
Technology Agent, it would retrieve the network performance parameters values from
the Information Server before it: (1) either enters the coverage area of a new Access Technology Agent (2) or leaves the coverage area of the Access Technology Area that
was communicating with.
once the intelligent scheduler makes a selection on using an access network which
differs from the currently used one, the vehicle will handover to this selected access network once the coverage area quality of the selected access network is satisfactory.
Note that when the currently used access network is selected as the target (new) access
network, then no handover execution procedure is necessary.
5.2.2.1.2 Access Technology Agent
For all the Access Technology Agents, the following assumptions held:
all the Access Technology Agents can collect up-to-date values of all the considered
performance parameters (dynamic criteria) regarding to the communication between
themselves and the vehicles within their coverage areas.
Second, the Access Technology Agents are assumed to be able to update those collected
performance values as stated in the above assumption to the Information Server by using
either wired TCP/IP based technology or a cellular technology. This updating procedure
can also be accomplished periodically.
the vehicle‘s currently connected Access Technology Agent need, in addition to the
features described above, to also support basic functions for the processing and
forwarding of information from/to the vehicle and from/to Information Server. This
information can include the information request ―Req‖ (see Figure 31) sent from the
vehicle to the Information Server and the information reply ―Rep‖ (see Figure 31) sent from the Information Server to the vehicle.
5.2.2.1.3 Information Server
The Information Server is a new entity which is not used in common cellular or other similar
mobile communication-supporting systems. The main functionality of this Information Server is
to collect the performance values of all Access Technology Agents within a specific area. It can
communicate with those Access Technology Agents directly and the vehicle through the
vehicle‘s connected Access Technology Agent. The periodically-updated information from those
Access Technology Agents will be sent to the Information Server, while only the latest-updated
values will be stored. Basically, the Information Server will maintain a table to store these
periodically-updated value and for each Access Technology Agent, the Information Server
maintains an entry in the table, as shown in Table 17:
75
Table 17Performance value maintenance in Information Server
ATA\Criteria Offered
bandwidth
Delay Jitter …
ATA 1
ATA 2
ATA 3
…
Table 17, shows the performance parameters that are maintained by the Access Technology
Agent (ATA).
Involving the Information Server, besides periodically measuring the performance values of the
available access networks, i.e., vehicle roaming in the coverage areas of these access networks,
the vehicle can also be aware of the performance values of the access networks that are not
available in its current position (i.e., vehicle is not currently roaming in the coverage area of this
access networks).
When a vehicle is using an access technology like UMTS, see Figure 31, and is approaching the
border of a WLAN coverage area, it does not know which access networks are available after it
enters this coverage area border. So it would do scanning on all communication interfaces to
identify all the available set of access networks. Using the third vehicle assumption given in
Section 5.2.2.1.1, it is able to know the access networks. However, it does not know the values
of the performance parameters associated with these access networks. So it has to do
measurements and exchange information from each of the available access networks in order to
make the selection of the target (new) access network. Typically this could cause more power
consumption and can probably delay the handover. Especially if a vehicle is going out from the
coverage area of its currently used access network, this delay can increase the probability of
losing the connection. This is also the reason of including and using the Information Server in
the proposed design.
In particular, with the help of the third assumption given in Section 5.2.2.1.1, , the vehicle knows
the available set of access networks at the upcoming coverage area border and it will send an
information request including the IDs of those Access Technology Agents corresponding to
those available access networks at the upcoming border to the Information Server. Its currently
connected Access Technology Agent is responsible of forwarding this information request to the
Information Server. Once the Information Server receives the information request, it will check
the performance of values of which access networks are requested and look up the table as
shown in Table 17. The received value will be carried by an Information Reply and will be sent
to the Vehicle which sent the request through its currently connected Access Technology Agent.
With the retrieved value, the vehicle is able to select which access network will be used after it
enters the upcoming coverage area or gets out of its current coverage area. In this way, the
vehicle does not have to scan all its communication interfaces and at the same time it will be
able prepare for potential handover procedures like pre-authentication so that the handover
latency is decreased and the probability of losing its connection is decreased.
76
5.3 Intelligent Scheduler and its requirements In the previous sections, we have already discussed the deployment scenario of our intelligent
scheduler and the necessary entities that are needed to implement the proposed intelligent
scheduler. Furthermore, the intelligent scheduler has been briefly introduced in Section 5.2.2.1.3. This section describes the requirements and the operation of the mechanisms used in the
Intelligent Scheduler in more detail, including how the Intelligent Scheduler is making the
selection and how the handover is executed.
In order to design our intelligent scheduler, we have to define which performance parameters
and user policy parameters will be considered in our intelligent scheduler, i.e., the selection
making process:
For the performance parameters, we have to first take the Received Signal Strength
(RSS) into account. This value will be measured and monitored by the vehicle to
identify whether an ongoing connection to an access network can be kept or another
target (new) access network should be found. Only the access networks whose RSS is larger than the sensitivity required by the vehicle will be treated as available/candidate
access networks. Then the bandwidth offered by different networks, delay and jitter
performance values will be considered. These three performance parameters are treated as dynamic criteria, because they can change as time goes by. Note that the initial delay
(access delay) is treated as static or slow-changing parameter, which differs for different
access wireless technologies.
For the user policy parameters, i.e. parameters related to user‘s preference, only the
financial/monetary cost is chosen.
Therefore, here we choose five network performance parameters and one policy parameter. The
way of how they are used by the decision making mechanism is explained below. Even though a
specific set of criteria is considered, the end users should be able to adjust which performance
parameters they would like to be used by the intelligent scheduler. We require that the proposed
Intelligent Scheduler should select accurately the target (new) access wireless technology. The
target (new) access wireless technology/access network is the one that is used by the vehicle
before going out of the current serving Access Technology Agent‘s coverage area or entering the
upcoming coverage area of a target (new) Access Technology Agent.
In Figure 33, we give an structured overview the intelligent scheduler operation.
77
Figure 33 Structure of our Intelligent Communication Medium Scheduler
As shown in Figure 33, the first Intelligent Scheduler block is denoted as ―Estimator‖, which
estimates when to trigger the initiation of the selection making process shown in the second
block denoted as ―Selection Making‖.
Inside the ―Estimator‖, three processes operate in parallel:
For the first process: shown in the upper part of the ―Estimator‖ block, see Figure 33, the
scheduler uses the speed, position of the vehicle, and the coverage areas of all Access
Technology Agents as input to calculate when the vehicle will arrive at the upcoming coverage
area border associated with another Access Technology Agent.
We assume that the vehicle is driving with a constant speed or at least is keeping its speed slow
changing. So based on vehicle‘s position and the position of the upcoming coverage area border,
the scheduler can calculate how much distance is left to the upcoming coverage area border
(denoted by ―Db_h‖), assuming that the driver keeps its predefined driving route. Then, the time
required to reach the coverage area border ―tb_h‖ can be calculated using the equation below:
Equation 36
In equation above, v_current denotes the constant speed of the vehicle.
Another parameter that is considered is the minimum time, i.e., ―Tb_h‖, needed for the intelligent
scheduler to finish all operations (i.e. retrieving information from the Information Sever, making
selections, doing pre-authentication) before reaching the new (target) coverage area border.
The ―Estimator‖ block continuously compares the difference (tb_h - Tb_h) to a predefined
threshold t. Once the following (tb_h - Tb_h) ≤ t, is valid then the intelligent scheduler sends an
information request to the Information Server. On receiving the Information reply from the
Information Server, the selection making process is triggered.
78
For the second process shown in the middle part of the ―Estimator‖ block, see Figure 33, the
intelligent scheduler periodically scans all its communication interfaces and exchanges
information with all available networks in its current position. In this case, once the performance
parameters get updated, the selection making process in the ―Selection Making‖ block will be
triggered. Therefore, in this case, it is considered that the selection making process is executed
periodically.
For the third process: shown at the bottom part of the ―Estimator‖ block, see Figure 33, the
intelligent scheduler monitors the RSSI and once the value of RSS is below the required
threshold the selection making process is triggered.
After the estimation process in the ―Estimator‖ block, a candidate access network will be
selected by the ―Selection Making‖ block. If another access network needs to be selected than
the one that the vehicle is using, then a handover will be triggered as shown in the ―Handover‖
block. If the selected candidate access network is at that moment available, then the handover
will be executed immediately. Otherwise the handover will be executed when the selected
candidate access network is available (e.g. entering the cell of the selected network). The
selection making and handover processes will be described in detail in the following two
subsections. in The values used for the estimation parameters will be discussed in Chapter 7.
5.3.1 Selection making procedure This subsection describes the procedures of making a selection of a candidate access network.
Figure 34 Selection Making Structure
Figure 34 the main features of ―Selection Making‖ block. This ―Selection Making‖ block has
four general input blocks.
79
The first one is ―A-SAP‖, which is the Service Access Point between the CALM Service
Layer and the CALM Management Entity (CME), where the intelligent scheduler is
being implemented. From this A-SAP, the intelligent scheduler can retrieve the requirements from different applications. It is considered that in order to make a
decision that the application requirements should at least include: (1) the type of the
application, e.g., streaming service (can be sub-categorized), messaging service, etc.; the
minimal requirement for each considered criterion, e.g., for VoIP, we assume the minimal requirement on offered bandwidth is 32kbit/s; (2) the maximum effective value
for each considered criterion, which means that if the offered performance value of one
criterion is larger than the maximum effective value with respect to this criterion, then its performance value will be treated as equal to the maximum effective value during the
selection calculations.
Different application types have probably different requirements on the considered
criteria like for streaming service, the bandwidth is much more important compared that
of a messaging service. Furthermore, users should also be able to apply their own
preference on the importance of different criteria. Therefore, we define that the weights of importance of the considered criteria are calculated based on the used application type
and the user‘s preference, which will be executed in the ―Criteria Scoring‖ block
utilizing AHP introduced in Chapter 3. One example of implementing this ―Criteria Scoring‖ block I, is that for each type of application, a default importance comparison
matrix used for AHP is pre-configured and the user should have the right to change the
value of this matrix, especially his/her own consideration on monetary/financial costs. Moreover, the Minimal requirements and Maximum effective value of each considered
criterion will be used in the weights calculation procedure.
The second and the third input blocks are ―CI/VCI status list‖ and ―Retrieved
information‖, respectively. These blocks are corresponding to the first two processes in the ―Estimator‖ block processes, see Figure 33. ―CI/VCI status list‖ provides the
performance values of all currently available access networks by periodically scanning
the communication interfaces. The ―Retrieved information‖ block provides the performance values, retrieved from the Information Server, of the access networks
available after the vehicle would move across the upcoming border of another access
network. These performance values can be characterized as ―Static Media data‖, i.e.
initial delay and monetary cost, and ―Dynamic Media data‖, i.e. offered bandwidth, delay and jitter. In the ―CN elimination‖ block (CN means candidate network), these
performance values are compared to the minimal requirements of different criteria. Once
the performance value of a candidate network with respect to any considered criterion does not meet the corresponding minimal requirement, this network will be eliminated
from consideration and the further steps. For example, consider that a table of
performance values of all candidate networks is maintained as shown in Figure 34. In this table, different rows include the performance values for different candidate
networks and different rows denote performance values of the same candidate network
with respect to different criteria. Thus, elimination of one candidate network means
deleting one row from this table.
Then the candidate networks left after the block ―CN elimination‖ will be scored in the
―CN scoring‖ block. In this block, two procedures have to be accomplished. In the first procedure, the performance value of one specific candidate network with respect to each
criterion will be assigned a score ranging from 1 to 9 based on the original performance
80
value, minimal requirement and maximum effective value of each criterion. This score is
calculated with the Equation 2 and Equation 3 (see Chapter 3).
In the second procedure, for each criterion, the score of each candidate network will be
compared in pairwise so that a performance comparison matrix can be obtained for
utilizing AHP to calculate the performance weights of different candidate networks with respect to each criterion. Then, as stated in Section 3.3.1, we can use any one of SAW,
MEW, GRA and TOPSIS to decide which network best suits the user‘s needs. If SAW is
used, in the ―Final scoring and decision made‖ block, the final score of each network will be calculated based on the performance weights and criteria weights. The network
which has the largest final score will be chosen as the most suitable one. The ID of the
Access Technology Agent corresponding to the selected candidate network will be used as the output of the selection making process.
The forth input block is ―low current RSS‖, as mentioned above; this input can trigger
the vehicle handover to a candidate access network technology or try to make a
horizontal handover so that the handover latency can be decreased. Also it is possible to trigger this process early enough so that the selection making mechanism can be finished
before the RSS falls below the minimal requirement to maintain the connection. A
specific implementation of this block is not yet accomplished. The selection result of this ―Selection Making‖ block, i.e. ID of selected Access Technology
Agent, is coupled to the ―Handover‖ block in Figure 33.
5.3.2 Handover procedure The ―Handover‖ block, see in Figure 33, is performing the handover execution procedure. This
procedure is performed when the ―Selection Making‖ selected another candidate access network
than the one that the vehicle was using before the handover execution phase.
As explained in Chapter 4, the IETF NEMO IP based mobility management solution is selected
to be used during the handover execution procedure, see Figure 35.
81
Figure 35 NEMO Handover Process
In Figure 35, the two mobile devices used in the vehicle are representing the Mobile Network
Nodes (MNN) and the On Board Unit (OBU), which is the access gateway used in the vehicle is
represented by the Mobile Router (―MR‖). In Figure 35, it is considered that before the handover
is being initiated, the vehicle is connected with the Visiting Network 1 (VN1), which is denoted
as the home (or source) network for the handover. A bidirectional tunnel (green line shown in
Figure 35.) has been established between the MR and Home Agent (HA) of the vehicle through
VN1 in order to support exchanging encapsulated packets used by the IETF NEMO protocol.
Furthermore, it is assumed that the Visit Network 2 (VN2), denoted as the target network‖, is the
selected access network that the vehicle needs to handover to. Once the handover is initiated, the
vehicle (MR) will continuously transmit Router Solicitations. Once these Router Solicitations
are received by the router behind the access point of VN2, it will reply with Router
Advertisements. Alternatively, these Router Advertisements can be broadcasted periodically.
Subsequently, the MR will send its own Router Advertisements to VN2. Note that also
Authentication and authorization procedures need to be accomplished, by they are not shown in
Figure 35. After the vehicle associates to VN2, it will configure its new Care-of-Address (CoA).
The CoA of the vehicle can be configured using two alternative methods: the first one is self-
configuration, which is based on the prefix of VN2 retrieved from the Router Advertisements of
VN2; the second method is accomplished by external configuration, i.e. configured by an
external entity at the infrastructure part using DHCP.
82
After the CoA is configured, a Binding Update (BU) is sent to the HA carrying the binding of
the vehicle‘s home address of CoA. In order to avoid the triangular routing issue, the BU is also
sent to the Corresponding Node (CN). Then, the HA (or the CN) would reply with an Binding
Acknowledgement (BA) to the vehicle. A new tunnel (blue line shown in Figure 35) between the
MR and HA (or the CN) is established through VN2. After this step, the handover execution
procedure is finished.
If the original tunnel is terminated right after the starting of the handover, and when not all
packets are buffered at the infrastructure part, then packets might get lost. In the situation that
real time applications, such as VoIP, are used, even when packets are buffered, there is a high chance that these buffered packets could become out-dated and could not be used by the
application after the handover execution procedure is completed. Note that this challenge can be
solved by maintaining the tunnel until the handover execution is completed. Investigating this
issue in detail is beyond our scope of this master assignment.
5.4 Summary This chapter lists the requirements needed to design the intelligent communication medium
scheduler. Furthermore, the defined deployment scenario and the used architecture is discussed.
Subsequently, the design of the intelligent communication scheduler is described in detail. The
intelligent communication scheduler comprises three parts: ―Trigger‖, ―Selection Making‖ and
―Handover‖. The ―Estimator‖ part decides when to start making a selection of a candidate access
network; The ―Selection Making‖ part is responsible for selecting the ―best-suited‖ access
network by using the AHP algorithm; The ―Handover‖ part executes the selection result, by
completing the handover execution procedure to the selected access network. The following two
chapters focus on the implementation and evaluation of the designed intelligent scheduler.
83
Chapter 6 Simulation models
Since the intelligent communication medium scheduler and its deployment scenario has already
been designed, the performance of this intelligent scheduler in the selected vehicular network
scenario can be investigated. The method used for this performance evaluation is simulation.
Several studies have focused on the evaluation of selection mechanisms, see [9, 43, 47, 56, 59,
60, 66, 68-70, 107, 108]. However, not many studies focussed on the evaluation of a
combination of the selection mechanism and the handover procedures applied in vehicular
networks.
The performance measure used in these simulation experiments is described in Section 7.2.1.
This chapter describes the simulation models which model the functionalities of the intelligent
scheduler and implement the selected vehicular network scenario. The AHP model implemented
in matlab is used to do calculations in an off-line manner as stated in section 6.1.1. The other
functionalities of the intelligent scheduler and the designed deployment scenario are
implemented in the INET/OMNeT++ and SUMO simulation environments.
First, this chapter describes the Matlab implementation of the AHP algorithm and its correctness
validation. Subsequently, the INET/OMNeT++ and SUMO simulation environments are
introduced, and the simulation models implemented in INET/OMNeT++ and SUMO are
described. Furthermore, the integrated simulation model (architecture) is given (see section
6.2.5).
6.1 AHP implementation and validation model Since it has already been decided to use AHP-based method for the selection making process of
the intelligent scheduler as stated in Section 5.1, the implementation of the AHP algorithm is
preferred for the first step. The Matlab environment is used in this report to model the AHP
algorithm. With the AHP algorithm implemented in Matlab, an AHP model described in [56] is
reproduced to validate its correctness. Furthermore, this section also compares the selection
result of the implemented AHP algorithm with the results presented in [56]. The verification
results and their analysis are given in Chapter 7.
6.1.1 AHP algorithm in Matlab As stated in [109], there are several popular methods identified as alternatives to participate in
AHP synthesis: eigenvector, additive normalization, weighted least-squared, logarithmic least-
squares, logarithmic goal programming and fuzzy preference programming. Among these
alternatives, the two most popular alternatives are considered in our implementation not only in
order to limit our scope, but also that 1) eigenvector is the original and standard AHP alternative
proposed by Saaty [58] 2) the additive normalization method is a simple and quick
approximation to Saaty‘s eigenvector method. Before the implementation of any AHP
alternative, the comparison matrices used for the AHP algorithm have to be calculated.
84
In the selection-making process, it is necessary to calculate (1) the weights for each criterion and
(2) the network performance weights for each candidate network with respect to a specific
criterion. The procedures used to calculate the criteria weights and network performance weights
are shown in Figure 36:
Figure 36.Weights calculation procedures for (a) criteria, (b) network performance
As shown in Figure 36, the calculation of the criteria weights and network performance weights
are done in different procedures. Calculation of the comparison matrix of these two kinds of
weights are different: The comparison matrix of different criteria (see Figure 36(a)), is
calculated by directly comparing the criteria's importance manually. For each application class a
specific comparison matrix is predefined which will be described in detail in Chapter 7. In order
to calculate the comparison matrix of different candidate networks (see Figure 36(b)), the
performance value of each candidate network with a specific criterion has to be scaled (scored)
to a value within the range from 1to 9. Subsequently, the scaled values are compared in pairwise
to generate the comparison matrix. Hence, the comparison matrix of different criteria can be
inconsistent because each pair of comparison is made independent from others. However the
comparison matrix of performance values for different candidate networks is always consistent.
This is due to the fact that each pair of comparison is based on the scaled values of the original
performance values of the candidate network, which are consistent for all comparisons.
In order to clarify the consistency of the comparison matrices intuitively, an example will be
given: there are three criteria considered: offered bandwidth, delay and jitter. For a specific
application, we may recognize the offered bandwidth is strongly more important than the delay,
and weakly more important than the jitter, so:
85
If the importance comparison matrix of these three criteria for this application is consistent, the
importance comparison between the delay and jitter can be derived from above comparisons as:
However, if the importance comparison matrix of these three criteria for this application can be
inconsistent, the user or designer can set the importance comparison between the delay and jitter
without taking their own respect comparison to offered bandwidth, e.g. the user or designer can
recognize these two criteria are equally important:
importance of delay/importance of jitter=1
However, the consistency ratio of each comparison matrix should meet specific requirement as
shown in section 3.3.1.
In addition, two different solutions are introduced to calculate these weights. On the initial stage,
the standardized eigenvector solution is used to calculate both types of weights. Meanwhile,
according to [110], if the comparison matrix is consistent, then the weights calculated by
Additive Normalization (see [109]) are equivalent to those obtained when the original
eigenvector solution is used. Besides, when the comparison matrix is inconsistent, the Additive
Normalization can be used as approximation. Thus, it is valid to (1) use the original eigenvector
solution to calculate the weights for different criteria; (2) the Additive Normalization solution to
calculate the weights for network performances respectively. Implementing the eigenvector
calculations in C++ based OMNeT++ environment (see section 6.2.2), it is much more complex
than implementing the more simple Additive Normalization. This is because the eigenvector
solution requires the use of the necessary eigenvectors calculations. What is more interesting is
that the consistency characteristic of the comparison matrix of network performance makes the
two alternative solutions equivalent, in certain situations. However, for the calculation of criteria
weights the Additive Normalization is not powerful to replace the Eigenvector solution for the
reason of inconsistency of the comparison matrix of criteria weights.
Note that, the Simulink and INET/OMNeT++model introduced in Section 6.2, the calculation of
the criteria weights are done in an off-line manner using Matlab, while the calculation of the
network performance weight values are done in an on-line manner. The specific Matlab code of
the two alternative solutions is given in Appendix A.
6.1.2 AHP validation model in Matlab The AHP algorithm is implemented in the Matlab environment. The correctness of the
implemented AHP algorithm needs to be validated. The validation method is based on verifying
whether the results obtained by the implemented AHP are equivalent to the results obtained by
an existing AHP model. The chosen existing AHP model is the one used in [56]. This is done
since the details given in [56] are clearly presented and analyzed.
In [56], the criteria comparison matrix and its corresponding weights (see Table 18) are
calculated for a streaming service. Only the criteria comparison matrix for a streaming service is
86
given in [56], so in this assignment only the results associated with a streaming service will be
used for the validation process.
Table 18 First level AHP Matrix for deciding relative priority of influencing factors
Mobility
(speed) Bandwidth
Network Traffic
Load
Initial
Delay
Usage
Cost
Priority
Vector
Mobility(speed) 1 3 5 3 7 0.4529
Bandwidth 1/3 1 5 3 5 0.2765
Network
Traffic Load 1/5 1/5 1 1/3 3 0.0742
Initial Delay 1/3 1/3 3 1 5 0.1553
Usage Cost 1/7 1/5 1/3 1/5 1 0.0407
CI= 0.0777467, RI=1.12, CR=CI/RI=0.0694;
In Table 18, not only the criteria comparison matrix is given, but also the calculated criteria
weights named ―Priority Vector‖ are listed. Correspondingly also the consistency index and
consistency ratio are calculated as well. If the consistency ratio (CR) is less than 10%, then the
level of inconsistency is acceptable. It is considered in [56] that the speeds of the vehicle are
more important than the Bandwidth, which is considered to be more important than the other
criteria.
The considered criteria include: the speed of the vehicle (Mobility); Bandwidth; Network Traffic
Load; Initial delay; Usage Cost. With respect to the last four criteria, the performance values are
considered to be static and their performance comparison matrices are also pre-defined as shown
from Table 19 to Table 22:
Table 19 Second level AHP Matrix for deciding relative priority of networks for bandwidth only
WiMAX UMTS WLAN Priority Vector
WiMAX 1 7 1 0.4666
UMTS 1/7 1 1/7 0.0666
WLAN 1 7 1 0.4666
CI= 2.22 ⋅ , RI=0.58, CR=CI/RI=3.82*10^-16;
According to Table 19, according to [56], WiMAX and WLAN can provide similar bandwidth
capacity to the vehicle and this bandwidth capacity can be even larger than the one offered by
UMTS. Even though the calculated CI is 0.9998, which is slightly larger than 0, the comparison
matrix is consistent. In addition, the summation of the priority vector is slightly smaller than 1.
This small difference can be ignored.
87
Table 20 Second level AHP Matrix for deciding relative priority of networks for traffic load only
WiMAX UMTS WLAN Priority Vector
WiMAX 1 1/3 3 0.2431
UMTS 3 1 7 0.6689
WLAN 1/3 1/7 1 0.0882
CI= 0.003515, RI=0.58, CR=CI/RI=0.006061;
According to Table 20, the network traffic load of WLAN is observed to be the largest and that
of UMTS as the lowest. As a result, the highest weight is assigned to UMTS.
Table 21 Second level AHP Matrix for deciding relative priority of networks for initial delay only
WiMAX UMTS WLAN Priority Vector
WiMAX 1 3 1/3 0.2431
UMTS 1/3 1 1/7 0.0882
WLAN 3 7 1 0.6689
CI= 0.003515, RI=0.58, CR=CI/RI=0.006061;
According to Table 21, WLAN has the smallest initial delay for connection establishment, and
the initial delay for connection establishment of WiMAX is smaller than that of UMTS, see [56],
.
Table 22 Second level AHP Matrix for deciding relative priority of networks for usage cost only
WiMAX UMTS WLAN Priority Vector
WiMAX 1 1/3 1/5 0.1061
UMTS 3 1 1/3 0.2604
WLAN 5 3 1 0.6333
CI= 0.019357, RI=0.58, CR=CI/RI=0.033375;
According to Table 22, WiMAX has larger usage costs than UMTS, and WLAN has the lowest
usage costs.
In [56] a different way of calculating the comparison matrix for ―Mobility (speed)‖ is presented.
As stated in [56], WLAN can support mobility up to 30-35kmph, UMTS and WiMAX can do
that up to 90-100kmph and 150kmph respectively. The method of converting the original speed
to mobility scores for each technology is defined as:
88
m_wlan=9- (speed*8)/30;
m_umts=9-(speed*8)/90;
m_wimax=9-(speed*8)/130;
Equation 37
And the comparison matrix for each technology's performance value on mobility is denoted as
―A‖ in [56]. Since in above equations, the scores of mobility for three access technologies have
been calculated, the pairwise comparison of these values are included in ―A‖, shown in Figure
37:
1 m_wimax/m_umts m_wimax/m_wlan
m_umts/m_wimax 1 m_umts/m_wlan
m_wlan/m_wimax m_wlan/m_umts 1 Figure 37 Mobility performance value comparison matrix
With the matrix shown in Figure 37, the weights of different technologies are calculated with
respect to mobility. Since the scored values: m_wlan, m_umts, m_wimax are all consistent in
each pair of comparison of the above matrix, the matrix is also consistent. Based on these criteria
weights and performance value weights, a Simulink model is built to calculate the total weights
of each technology concerning different speed. The model can be seen in Figure 38:
Figure 38 SIMULINK model for AHP based vertical handoff simulation, copied from [56]
As shown in Figure 38, the performance weights of technologies with respect to different criteria
are calculated in different modules: MOB_AHP, DATRATE_AHP, TL-AHP, Delay_AHP,
COS_AHP corresponding to the criteria: mobility, bandwidth, network traffic load, initial delay
and usage cost, respectively. The ―Application‖ type is pre-defined and the criteria weights for
each application type are calculated in the ―AHP‖ module. In [56], only two types of
A=
89
applications are defined, so there are two criteria importance comparison matrices predefined in
―AHP‖ module. In addition, the ―NW-AVL‖ provides the availability of each technology. The
speed of the vehicle is used as the changing/varying input of ―MOP_AHP‖ module and used to
calculate the weights for all available technologies.
6.2 Simulation environment and models By using simulators, we would like to study the performance of the designed intelligent
scheduler with respect to the performance measure defined in section 7.2.1. The used entities
and the selected vehicular networking scenario are implemented in INET/OMNeT++. Together
with the framework of Veins [111], which couples SUMO and INET/OMNeT++, the mobility
model of the vehicle wherein the intelligent scheduler is embedded, is provided. In addition, the
xMIPv6 [112] framework enables the used entities to support layer 3 handovers. Moreover, the
functionalities and the performance value changing model used to generate background traffic
(see section 6.2.4.3) can be implemented directly in the source code of INET/OMNeT++
modules.
In this section, the used Simulation environments and the simulation models are described. First,
the simulation environments are introduced. Then, the simulation topology corresponding to the
selected vehicular networking scenario is given. Afterwards, different simulation models built in
the mentioned simulation environments (see section 6.2.1) are described. In section 6.2.5, the
integrated model representing the whole simulation architecture is described.
6.2.1 Simulation environments This subsection describes the two simulation environments used in this assignment: SUMO and
INET/OMNeT++.
6.2.1.1 Traffic Simulator -SUMO
This section describes the SUMO traffic simulator environment, see [113].
Mobility Models
Vehicular mobility models are usually classified as either microscopic or macroscopic. When
focusing from a macroscopic point of view, motion constraints are considered such as roads,
streets, crossroads, and traffic lights. Furthermore, in this case also the generation of vehicular
traffic such as traffic density, traffic flows, and initial vehicle distributions are defined. The
microscopic approach, focuses on the movement of each individual vehicle and on the vehicle
behavior with respect to others [114] In Figure 39, the vehicular mobility models are in advance
classified, where from left to right the following mobility model types are shown: macroscopic,
microscopic, and sub-microscopic (within the circle: mesoscopic).
90
Figure 39Mobility Models-Macroscopic, Microscopic, Sub-Microscopic from left to right (within
the circle: mesoscopic, copied from [113]
According to [114], several candidates are considered to simulate the VANET related issues. But
they all have obvious deficiencies. For example, MOVE [115] could not provide an interaction
between the network simulator, see Section 6.2.1.2, and the used mobility model. The method of
FDK [116] has the limitation that CORSIM [117] as a traffic simulator has a complex
calibration/configuration and large number of configuration parameters. [118] is unable to
reproduce the non-uniform distribution of positions and speed usually experienced in urban area.
The Simulation of Urban Mobility (SUMO [113]) is an open source, highly portable road traffic
simulation package designed to handle large road networks. It is widely used in research
community. The decision of using SUMO in combination with INET / OMNET++ is due to the
fact that this combination is often used in the research community. Other research activities
accomplished by the UT/DACS [119] group show a well performance.
The development of modern vehicular mobility models may be classified in four different
classes, see [114]:
synthetic Models wrapping all models based on mathematical models;
traffic Simulators-based Models, where the vehicular mobility models are extracted from
a detailed traffic simulator;
survey-based Models extracting mobility patterns from surveys;
trace-based Models, which generate mobility patterns from real mobility traces.
Furthermore, according to [114], the synthetic models may be separated in five classes:
stochastic models wrapping all models containing purely random motions;
traffic stream models looking at vehicular mobility as hydrodynamic phenomenon;
Car Following Models, where the behavior of each driver is modelled according to
vehicles ahead;
Queue Models which models roads as FIFO queues and cars as clients;
behavioral Models where each movement is determined by behavioral rules imposed by
social influences for instance.
91
The SUMO model used in this M.Sc. assignment belongs to the macroscopic and synthetic
model, see Section 6.2.2, but it is much simpler than those five classed stated above.
History of SUMO
The development of SUMO started from 2000 by the German Aerospace Center, in order to
support the traffic research community with a tool into which own algorithms can be
implemented and evaluated without the need to regard all the artefacts needed to obtain a
complete traffic simulation. Such artefacts are related to the implementation and/or setting up
methods for dealing with road networks, demand, and traffic controls [113]. By supplying such
an open source microscopic road traffic simulation tool, the German Aerospace Center wanted to
(1) make the implemented algorithms more comparable, as a common architecture and model
base is used, and (2) gain additional help from other contributors
SUMO allows high-performance simulations of huge networks with roads consisting of single
and multiple lanes, as well as of intra-junction traffic on these roads, either using simple right-
of-way rules or traffic lights. Vehicle types are freely configurable with each vehicle following
statically assigned routes, dynamically generated routes, or driving according to a configured
timetable [120].
Since 2002, one popular use of SUMO is the evaluation of vehicle-to-vehicle and vehicle-to-
infrastructure communication. Two major third-party projects should be mentioned in this
context, the first, TraCI, [113], is an extension of SUMO by the possibility to communicate with
external applications, done at the University of Lübeck by Axel Wegener. The second project
that should be mentioned in this context is "TraNS" [121]. TraNS is a direct coupling between
SUMO and the network simulator ns-2 [122], which uses TraCI for communication and that was
set up by Michal Piorkowski and Maxim Raya at the EPFL Lausanne.
Different from ―TraNS‖, in this assignment, we replace the ns2 by OMNeT++ and use TraCI for
the support of the coupling and communication with SUMO.
Simulation Processes
To set up a simulation for SUMO three steps have to be followed. First the road network on
which the vehicle traffic is moving on is needed. This can be achieved by a) generating an
abstract road network using NETGEN, b) setting up an own description in XML and importing
it using the NETCONVERT tool, c) importing an existing road network using also the
NETCONVERT tool. Second, each vehicle should recognize its route, which is a list of edges
that have to be passed and can be known. This can be accomplished by: a) describing explicit
routes on the road network, b) using predefined routes and activating only a percentage of them,
c) generating random routes, d) importing OD-matrices, or e) importing existing routes. If
necessary it will also be needed to compute the dynamic user assignment and to calibrate the
simulation using the given measures. The final step is to perform the simulation.
In particular:
NETGEN allows building abstract networks. Three types of networks can be built,
92
which are: grid-networks, spider-networks and random-networks. Normally the builder
has to supply the name of the network to generate and the type of network he/she want to create. However, by using the NETCONVERT tool, the builder can build a road
network of any topology freely.
NETCONVERT imports digital road networks generated by other sources and at the
same time generate road networks that can be used by other SUMO tools. It assumes at
least one parameter - the combination of the name of the file type to import as parameter name and the name of the file to import as parameter value. Of course, a user can
specify the output file name and type. In our experiments, an own description in XML is
set up and imported by the NETCONVERT tool to generate a road network. This road network is generated in the form of a grid, where the most-left- and most-bottom node
(vehicle) in the grid is identified by the coordinate (0, 0).
6.2.1.2 Network Simulator—INET/OMNeT++
Network simulation is commonly used to model computer network configurations long before
they are deployed in the real world. In this assignment, the V2I communication is modelled
using a network simulator. Network simulators are able to evaluate the performance of network
protocols and that of the communicated traffic, under dynamic changes of e.g., the traffic
conditions, the communication channel conditions.
In most cases, network protocols are analyzed using discrete event simulations. A large number
of simulation frameworks are available in this area. Examples of such frameworks are open
source tools such as the network simulator ns-2 [122], OMNeT++ [123], J-SIM [124], and JiST
/SWANS [125] and commercial tools like OPNET [126]. The reason of selecting OMNeT++ in
this assignment is due to the fact that it is often used in research community and used within the
DACS group on some research activities. ns-2 and OMNeT++ are considered as candidates in
the assignment to couple with SUMO, but as already mentioned the combination of OMNeT++
and SUMO is selected to be used in this assignment.
OMNeT++
OMNeT++ (Objective Modular Network Tested in C++), see [123], is an extensible and
modular component-based C++ simulation library and framework that is running on different
operating systems such as Linux, Mac OS X, other Unix-like systems and Windows. Primarily,
OMNET++ is developed for building network simulators. The simulator can be used for traffic
modelling of telecommunication networks, protocol modelling, queuing networks modelling,
multiprocessors and other distributed hardware systems modelling, hardware architectures
validating, evaluating performance aspects of complex software systems and modelling any
other systems where the discrete event approaches are suitable.
93
Figure 40 Simple modules, compound module and system module, copied from [127]
OMNeT++ provides a component architecture for models. These components programmed in
C++ are nested hierarchically and simpler components can assemble to compound components
and models using a high-level language—NED (Network Description), see Figure 40. NED lets
the user declare simple modules, and connect and assemble them into compound modules. The
user can label some compound modules as networks. These compound models are self-contained
simulation models. Communication channels can be defined as another component type, whose
instances can also be used in compound modules. The NED language has several features which
let it scale well. Therefore, it can be used to model large communication topologies [127]These
features are:
Hierarchical: The traditional way to deal with complexity is by introducing hierarchies.
Any module which would be too complex as a single entity can be broken down into
smaller modules, and used as a compound module.
Component-Based: Simple modules and compound modules are inherently reusable,
which not only reduces code copying, but more importantly, allows component libraries
to be reused.
Interfaces: Module and channel interfaces can be used as a placeholder where normally
a module or channel type would be used, and the concrete module or channel type is determined at network setup time by a parameter.
Inheritance: Modules and channels can be sub classed.
Packages: The NED language features a Java-like package structure, to reduce the risk
of name clashes between different models.
Inner types: Channel types and module types used locally by a compound module can be
defined within the compound module, aiming at reducing namespace pollution.
Metadata annotations: It is possible to annotate module or channel types, parameters,
gates and sub modules by adding properties.
Re-usability of models makes model building flexible. Also, the depth of module nesting is not
limited, which allows the user to reflect the logical structure of the actual system in the model
structure. Modules communicate with message passing. Messages can contain arbitrarily
complex data structures. Modules can send messages either directly to their destination or along
a predefined path, through gates and connections.
Modules have parameters used for three main purposes: to customize module behavior; to create
flexible model topologies (where parameters can specify the number of modules, connection
structure etc.); and for module communication, as shared variables.
94
Modules at the lowest level of the module hierarchy are to be provided by the user, and they
contain the algorithms in the model. During simulation execution, simple modules appear to run
in parallel, since they are implemented as co-routines (sometimes termed lightweight processes).
To write simple modules, the user does not need to learn a new programming language, but
some knowledge of C++ programming is essentially necessary.
Therefore, an OMNeT++ model is combined by simple modules using the NED language. The
simple modules are programmed in C++. The simulation system provides two components:
simulation kernel containing the code that manages the simulation, the simulation class library
and user interfaces. Graphical, animating user interfaces are highly useful for demonstration,
while command-line user interfaces are best for batch execution.
Thus, the way of how to use OMNeT++is shown as follows. First, the NED files are compiled
into C++ source code using the NEDC compiler which is part of OMNeT++. Then all C++
sources are compiled and linked with the simulation kernel and a user interface to form a
simulation executable.
INET
The INET Framework is an open-source communication networks simulation package for the
OMNeT++ simulation environment. It contains models for several wired and wireless
networking protocols, including UDP, TCP, SCTP, IP, IPv6, Ethernet, PPP, 802.11, MPLS,
OSPF, and many others [128]. These characteristics make INET widely being used for higher-
layer simulations in OMNeT++.
INET supports wireless and mobile communicating nodes within the simulation environment.
For this report‘s simulation, the well-defined Transport and Network layers enable the
communication between vehicle and the Infrastructure of the network part.
Based on the basic INET framework, several extensions have been made [128] to support
various specific requirements on simulations. During these extensions, xMIPv6 framework is
used to enable the vehicle the scheduler the functionality to do layer-3 handovers. What's more,
since mobility support for network simulations of INET is limited to simple mobility patterns,
INET-sommer (Veins [111]) as another extension is used together with SUMO to provide the
mobility model of the vehicle.. More technique details about INET can be found in [129].
6.2.2 Simulation topology In order to build the traffic model with SUMO and the network model with INET/OMNeT++,
the deployment scenario described in Section 5.2 has to be first converted into a specific
simulation topology. This simulation topology should include all the used entities required in
Section 5.2: a vehicle, Access Technology Agents of different technologies, Information Server.
Furthermore, in order to support layer-3 handover mechanism, a Home Agent, a Correspondent
Node and an access point for home network are also necessary. Apart from building modules for
these entities, the positions of the Access Technology Agents and the route and road used by the
vehicle will be defined especially in this subsection.
95
First, the topology of the road used for the simulation experiments is defined. Since no realistic
road topology together with network's coverage area information is available, a simple topology
is preferred to be implemented for investigation. It is started from the topology of a single road,
while in order to increase the simulation time, the length of this road has also to be increased and
many Access Technology Agents have to be manually implemented. Therefore, a rectangular
road network is chosen which allows the vehicle to loop in this road network. In this way, the
number of implemented Access Technology Agents can be limited by the total length of this
road network and at the same time the simulation time can be freely adjusted. The topology of
this road network is shown in Figure 41.
Figure 41Topology of designed road network
As shown in Figure 41, the vehicle enters the rectangular road network from outside, and will
loop in the rectangular road network in a clockwise direction. In this way, the road network
topology and the route used by the vehicle are defined. Then the numbers of entities being used
are defined. And the numbers of entities being used are shown in Table 23:
Table 23 Number of Used Entities
Entity Name Vehicle HA CN AP of HN GPRS ATA UMTS ATA WiMAX ATA WLAN ATA IS
Entity Number 1 1 1 1 1 1 3 3 1
In Table 23, HA, CN, AP of HN, ATA and IS are the abbreviations for Home Agent,
Correspondent Node, Access Point of Home Network, Access Technology Agent and
Information Server, respectively. Since the network model supporting the used handover-
mechanism, does not scale well with increasing number of vehicles, only the behavior of one
vehicle using the intelligent scheduler will be investigated. Thus, one Correspondent Node and
one Home Agent are enough. For the number of Access Technology Agents, at least one Access
Technology Agent for each access technology has to be defined. Furthermore, it is assumed that
GPRS and UMTS have ubiquitous coverage areas and no horizontal handover within either of
these two technologies is considered in our research scope, so using one Access Technology
Agent covering the rectangular road network for GPRS and UMTS respectively is enough. For
WiMAX and WLAN (IEEE 802.11p), three Access Technology Agents for each of them are
defined. All of these 6 Access Technology Agents belonging to WiMAX and WLAN together
are assumed to be able to cover the whole rectangular road network. It is important to mention
that for the vehicle's initial registration, an access point of the vehicle's home network, which
96
should lay outside the rectangular road network so that a unified handover type—handover from
one foreign network to another foreign network-can be investigated. Therefore, there are 8
Access technology Agents in total, and one Information Server collecting information from these
Access Technology Agents. The position of these Access Technology Agents and the access
point of the home network are shown in Figure 42 where the length and width of defined
rectangular road network are also marked:
Figure 42 .The complete simulation topology
As shown in Figure 42, two WLAN ATAs are allocated at the two ends of the upper edge of the
rectangular road network and one in the middle of the lower edge. For WiMAX ATAs, it is the
opposite: two WiMAX ATAs are allocated at the two ends of the lower edge and the third one is
allocated in the middle of the upper edge. The ATAs of GPRS and UMTS are both located at the
geometric center of the rectangular road network. The vehicle will start from the left end of the
road network where it is in the coverage area of its home network. Once it enters the rectangular
part, it will continuously loop on the rectangular road until simulation time reaches. Distance
between ATAs, length and width of the road network are marked with the values used for
simulations and they will be explained in Chapter 7. Other entities in the network infrastructure
part are also depicted in Figure 42. whose position are not considered in our assignment. Note
that the functionalities of these entities have already been described in Section 5.2.
6.2.3 SUMO model As stated above, SUMO is used as the traffic simulator, which provides the mobility model of
the vehicle using the designed intelligent communication medium scheduler. A mobility model
provided by SUMO is restricted by a defined road topology and route used by the vehicle. Here
is an introduction of how the road topology and vehicle route are generated.
There are several ways of building a road network, while for a simple rectangular-like road
network defined in Section 6.2.2, setting up a road network description in XML and importing it
97
using NETCONVERT can be considered to be easy and proper. In order to create a road
containing sections (i.e., edges) and nodes (i.e. start/end points of road sections), three types of
XML files are necessary:
Node based XML: this XML file describes the coordinates of the start/end points of a
road section and if one node is the start/end point of more than three sections, then it is a
junction. As required by SUMO, one road network should at least include three nodes.
With three nodes, at least two road sections (edges) can be built and one is used for
projecting vehicles and the other is used as vehicle's route destinations.
Edge based XML: this XML file describes the edges (i.e., road sections), which have to
be used to connect two nodes defined in the node based XML file.
Link type XML: this file describes the properties of the edges included in the edge based
XML file. When the link type XML file is not used, then SUMO considers that the used
edges are with single lanes. As defined above, only one vehicle in this assignment is simulated, so a single lane road network
comprising five road sections connecting five nodes is enough. Therefore, in this assignment a
node based XML file that includes the coordinates definition of five nodes is used. Furthermore,
an edge based XML file is created that contains five edges interconnecting the five nodes
specified in the node based XML file. Afterwards, by converting the two XML files using the
NETCONVERT tool, a one-single lane road with five edges and five nodes can be constructed.
The generated road network is shown in Figure 43.
Figure 43SUMO Model of Road Network
In Figure 43, the defined five nodes and five road edges are marked, and the edge length can be
found in Figure 42. As designed in Section 6.2.2, the vehicle will take this route: it will be
projected from Edge 1, and once the vehicle passes Node 2 and enters Edge 2, it will loop along
with Edge2, Edge3, Edge 4 and Edge 5 continuously. This route will be defined in a forth XML
file, denoted as route XML file. This route XML file contains the vehicle parameters and the
description of the routes that each vehicle can take on the road network. The vehicle parameters
can be the car length, the route ID, vehicle ID, maximum speed, and maximum acceleration. In
our assignment, only one vehicle is used, and the size of the vehicle will not influence our
investigation, therefore we just set the car length to a value we used for another project [130],
4.46m. The maximum speed and maximum acceleration will give the upper limit of the vehicle's
speed and acceleration. Besides, the vehicle's speed will be influenced by the road topology, e.g.,
the vehicle will decrease when approaching a road junction and after increases to the maximum
98
speed. As stated in Section 5.3, our designed intelligent scheduler estimates how much time is
left for the vehicle to reach an upcoming border based on the distance to the border and its own
speed. To simplify the investigation it is considered that the vehicle's speed is constant. Instead
of specifying this constant speed in the route XML file, it is directly set in the source code of
SUMO.
In order to make this SUMO model work well, an ―.cfg‖ configuration file has also to be defined
where the name of the used road network file and route XML file are specified. In addition, the
begin time, end time of the simulation and the updating frequency of the vehicle's position are
also set in this configuration file. Here, the begin time and end time are set to t=0s, and t=11000s
respectively so that the integrated simulation model will start at t=0s, and can terminate at any
time before t=11000s. And the updating frequency of vehicle position is set to 100Hz, which
means that the simulation time step is 0.01s and the vehicle will change its position every 0.01s
with ―v‖*0.01 m difference if ―v‖ is taken to denote the constant speed of the vehicle. For this
macroscopic simulation, the simulation time step of 0.01s used for the simulation is considered
to be as accurate enough.
6.2.4 INET/OMNeT++ model A model containing all those necessary entities for the network part is built using the
INET/OMNeT++ framework. First the entities required by the designed deployment scenario
(see Section 5.2) are deployed. Some of these entities‘ functionalities are originally provided by
the INET framework and some of them are implemented by us directly in the source code, i.e.,
the functionality of the intelligent scheduler and changing pattern of the ATAs' performance
values. Furthermore, some other functionalities are neither provided by the original INET
framework, nor created by us. They are implemented by merging the functionalities provided by
modified versions of INET frameworks to a single INET framework. Here we use INET-sommer
[131] to provide the functionality of communication between INET/OMNeT++ and SUMO;
xMIPv6 [112] framework to provide the functionality of mobile IPv6 respectively. Note that the
IETF MIPv6 model is used instead of the IETF NEMO, since no IETF NEMO INET/OMNeT++
model could be found.
In this subsection, the complete simulation network will be first descried from a high level, and
then the structures of important entities will be presented. Afterwards, we will introduce the
implemented intelligent scheduler and the changing pattern of the ATA's performance values.
Furthermore, the frameworks of ―xMIPv6‖ and ―INET-sommer‖ will be introduced.
6.2.4.1 The complete simulation network
The whole simulation network implemented using the INET/OMNeT++ framework is composed
by two basic parts: the network infrastructure part and the vehicle (i.e., a mobile node/station).
The network infrastructure part is shown in Figure 44.
99
Figure 44 The INET/OMNeT++ model of network infrastructure
In Figure 44, a snapshot of all the entities implemented at the infrastructure part is shown. The
positions of those ATAs comply with what was shown in Figure 42. In particular, ―AP_1‖,
―AP_3‖ and ―AP_5‖ are the ATAs of WLAN; ―AP_2‖, ―AP_4‖ and ―AP_6‖ are the ATAs of
WiMAX; ―AP_7‖ and ―AP_8‖ are the ATAs of UMTS and GPRS, respectively, and they are co-
located. ―AP_Home‖ is the access point of the vehicle's home network. Each ATA is connected
to the Information Server with two intermediate routers and the ―AP_Home‖ is directly
connected to the ―Home_Agent‖. Between the CN and HA there is only one router and a hub.
Apart from these designed entities, we can also see three other entities in Figure 44. The
―channel control‖ is used commonly in INET framework to determine which nodes are within
the communication or interference distance based on the location and movement of nodes. The
―manager‖ we used here is an INET-sommer entity named ―TraCIScenarioManager‖ which is in
charge of the communication between OMNeT++ and SUMO. The ―Configurator‖ refers to an
INET entity named ―FlatNetworkConfigurator6‖ which configures Ipv6 addresses and routing
tables for a ―flat‖ network. Note that ―flat‖ means that all hosts and routers will have the same
network address and will only differ in the host part. For more information on the
―channelcontrol‖ and ―configurator‖, please refer to [129]
Below, we will introduce several important entities including: Vehicle, Correspondent Node,
Information Server, Home Agent and Access Technology Agents (Access Points).
Vehicle
For the simulated vehicle, a module named ―WirelessHostMod6‖ is chosen, which is modified
from the original ―WirelessHost6‖ provided by xMIPv6. The inside structure of this module is
shown in Figure 45.
100
Figure 45 The structure of "WirelessHostMod6": the INET/OMNeT++ model of the vehicle
The protocol stack implemented in the vehicle is shown in the right side of Figure 45:
―tcpApp‖: TCP application. In our simulation model, no TCP applications are used.
―udpAPP (numUdpApps)‖: UDP applications. ―numUdpApps‖ specifies the number of
applications. In our simulation model, two UDP applications are used for the vehicle.
Both of the two UDP applications are of the same type-- ―UDPVideoStreamCli‖, which
is a basic video streaming client application implemented in original INET framework.
This type of application can send a request to remote connected server and get a stream of video packets back. The working processes of these two applications are shown in
Figure 46.
Figure 46 Working processes of the two applications implemented in the vehicle
As shown in Figure 46, one of two client applications denoted as ―Client 1‖ is used to
emulate the on-going session running on the vehicle. At the beginning of simulation, the
vehicle will request a stream of video from the Correspondent Node. And the stream of video will be replied in the form of a stream of packets with the same size and inter-
packet time. The other client application denoted as ―Client 2‖ is used by the vehicle to
101
retrieve information from the Information Sever and the information server can
encapsulate the required information in one packet and send it back to the vehicle. Note that it is also possible to reply with several duplicate packets. In order to support the
functionalities of these two client applications, the corresponding servers --
―UDPVideoStreamStr‖ applications have to be implemented both at the Correspondent
Node and Information Server.
―tcp‖ and ―udp‖: modules where the TCP and UDP protocols are implemented.
―pingAPP‖: application with functionality of pinging other hosts, which is not used in
our simulation.
―networklayer‖: module which basically supports mobile IPv6 provided by xMIPv6.
―wlan‖: a basic IEEE802.11 wireless interface implemented in INET framework. In this
module, the management function, MAC layer and radio layer are implemented.
Actually, this is the only communication interface implemented by us for a vehicle instead of implementing all interfaces for different wireless access technologies, which
is quite a burden work for this assignment. In order to distinguish the ATAs, we assign
them with different channels.' In left side of Figure 45. we can see modules not implemented in the protocol stack:
―notificationBoard‖: a basic INET module which enables modules notify each other
about ―events‖ such as routing table changes, interface status changes, mobile node position changes and so on.
―interfacetable‖: a basic INET module which maintains the table of network interfaces
―RoutingTable6‖: a module maintaining the IPv6 Routing Table and Neighbor
Discovery data structures.
―buList‖: an xMIPv6 module defined to maintain the Data structure for a Mobile Node
(the vehicle here). In this Data Structure, the binding information of the Mobile Node
(the Vehicle) is maintained [132]. ―mobility‖: a ―tracimobility‖ provided by INET-
sommer is used, which supplies the vehicle's mobility trace from SUMO and the vehicle
in INET/OMNeT++ will update its position based on this trace. And this will be illustrated with more details in Section 6.2.4.
Correspondent Node
For the Correspondent Node, the module named ―CorrespondentNode6‖ is chosen, which is
provided by xMIPv6 model. The inside structure of this module is shown in Figure 47.
102
Figure 47.The structure of "CorrespondentNode6": the INET/OMNeT++ model of the
Correspondent Node
In Figure 47, it can be observed that most of the modules used by the Correspondent Node are
the same as those used by Vehicle and similarly, only the UDP application is used. The different
modules include:
―udpApp[numUdpApps]‖: the Correspondent Node uses a UDP application named
―UDPVideoStreamSvr‖, which is a basic video streaming server application,
corresponding to the client application ― UDPVideoStreamCli‖ used by the Vehicle.
Once a video request's being received, a stream of packets with constant inter-packet
time will be replied. This process is shown in Figure 46.
―eth[sizeof(ethOut)]‖: the Correspondent Node uses this typical INET Ethernet module
as communication interface and the number of interfaces is defined by ―sizeof(ethOut)‖,
i.e., how many entities this Correspondent Node is connected to using Ethernet.
―bindingCache‖: an xMIPv6 Data structure for Correspondent Node and Home Agent,
corresponding to ―buList‖ used by Vehicle. The binding information of the Mobile Node
(the Vehicle) is maintained here in case that route optimization is needed [132].
Information Server
For the Information Server, the same module as in the Correspondent Node is used:
―Correspondent Node‖. Furthermore the same UDP application type is used. The only difference
than the modules used in the Correspondent Node is that the ―UDPVideoStreamSvr‖ application
of Information Sever will only reply the request sent from Vehicle with only one or several
packets instead of replying with a continuous stream of packets. This process is also shown in
Figure 46.
Home Agent
For the Home Agent, a module denoted as ―HomeAgent6‖ is used, and this is provided by the
xMIPv6 framework. The inside structure of this module is shown in Figure 48.
103
Figure 48 The structure of "HomeAgent6": the INET/OMNeT++ model of the Home Agent
As shown in Figure 48, the Home Agent has a router-like protocol structure. The difference
between a home agent module and a router module is that besides normal router functionality,
the ―networklayer‖ module of ―HomeAgent6‖ also supports mobile IPv6 functionality provided
by xMIPv6. The Home Agent can tunnel packets to Vehicle and Correspondent Node by packet encapsulation and decapsulation. Moreover, ―networklayer‖ feature in Home Agent requires also
a ―bindingCache‖ to maintain the binding information of Vehicle‘s home address and care of
address.
Access Technology Agents
For the ATAs, simple INET access points modules ―WirelessAPWithEth‖ are used instead of
implementing all the technologies. The inside structure is shown in Figure 49:
Figure 49 The structure of "WirelessAPWithEth": the INET/OMNeT++ model of the Access
Technology Agents
In Figure 49, two types of communication interfaces are shown: ―wlan‖ and ―eth[sizeof(ethg)]‖
are implemented. The ―wlan‖ module is the same one as the one used for Vehicle: a general
IEEE802.11 wireless interface. This interface is used for communication between Vehicle and
the network infrastructure. By using the Ethernet module ―eth[sizeof(ethg)]‖, the access point is
able to communicate with other entities in the infrastructure network. Different ATAs
differentiate with each other by using different communication channels.
104
In this subsection, the whole simulation network and implemented entities are introduced. The
following subsections, describe how the designed intelligent scheduler is implemented.
Furthermore, the changing pattern of the performance values are discussed and functionality
provided by the xMIPv6 and INET-sommer are described.
6.2.4.2 Intelligent scheduler implementation
In the INET/OMNeT++ model, the designed intelligent communication scheduler is
implemented in the form of an application. As introduced in Section 6.2.3.1, the Vehicle uses a
second application that is in charge of information retrieval. We modified the source code of this
application such that this application not only supports the information retrieval, but also the
other functionalities of required by the intelligent scheduler. In Figure 50, the flow chart of how
the implemented intelligent communication scheduler is depicted:
Figure 50.The flow chart of implemented intelligent scheduler
In this INET/OMNeT++ model, the only access technology that is implemented is the IEEE
802.11. This is because no INET/OMNeT++ models of the other access technologies could be
found. Due to this reason, the estimation based on real-world periodic measurements of
performance values for all access technologies, specified in Section 5.2 cannot be directly
evaluated. As shown in Figure 50, for the evaluation of these parameters, the behavior of the
intelligent scheduler that is applied when the vehicle is approaching an upcoming border and
retrieve information from Information server will be studied.
105
Note that in the INET/OMNeT++, all connectivity support of any access technologies is
emulated by using the IEEE 802.11 technology, but for different emulated access technologies,
specific sets of performance values are used.
In addition, for implementation of IEEE 802.11, one IEEE 802.11p model was considered to be
implemented because this standard is specific to vehicular communication. However, this model
is implemented in the MiXiM/OMNeT++ framework. Even though, Veins has a MiXiM version,
xMIPv6 is not compatible to MiXiM as an INET-based framework. Mixnet [133] is a solution to
make INET and MiXiM work together, however, this solution is still in progress and not
complete. In order to utilize the existent xMIPv6 model, a INET-based general IEEE 802.11
model is used instead of the MiXiM-based IEEE 802.11p model.
The intelligent scheduler monitors the position of the vehicle. Once the distance between the
vehicle and its upcoming border ΔD equals to v*Δt‘, the vehicle will retrieve information of the
access networks available at the upcoming border from the information server. Here, v denotes
the speed of the vehicle and Δt‘ is the predefined time difference between the time of sending
information request and the time of starting the handover. This Δt‘ should be large enough so
that the intelligent communication scheduler can finish information retrieval and selection
making before that the vehicle reaches the upcoming border. It should also not be too large,
otherwise the retrieved information will differ significantly from the real performance values
when the vehicle finishes its handover and becomes outdated. The ―Δt‖ shown in Figure 33
actually equals to (ΔD/v- Δt‘), so when ΔD equals to v*Δt‘, the ―Δt‖ shown in Figure 33 is equal
to zero.
Since that we've already set the position updating frequency in SUMO to 100Hz, i.e., the
vehicle's position changing unit is 0.01*v, the ΔD cannot equal to v*Δt‘ exactly. We
approximate the case: ΔD=V*Δt‘ as (V*(Δt‘-0.005) <ΔD<=V*(Δt‘+0.005)), because 0.005 is
half of the simulation timestep of vehicle in SUMO. Using the replied information and using
selection-making mechanism, an ATA is selected together with its channel index. Subsequently,
the intelligent scheduler continuously monitors the vehicle's position, and once: V-
0.005<ΔD<=V*0.005, i.e., the vehicle is just at the border, the intelligent scheduler will check
whether the channel index of the selected ATA differs from the one that the vehicle is using. If
this is the case, then the vehicle will start to scan the channel used by the selected ATA and to
make a handover. Otherwise, no handover should be performed and the intelligent scheduler
remains monitoring the vehicle's position.
6.2.4.3 Performance Value Changing Pattern
The designed Intelligent Scheduler makes selections based on the dynamically changing
performance values of ATAs of the considered access technologies. As defined in Chapter 5,
three dynamically changing criteria are used: offered bandwidth, delay and jitter are considered.
Several methods are considered to implement the dynamic changing pattern of performance
values:
1) using simple mathematic functions, e.g., the upper limit and the lower limit value with
respect to each criterion can be assigned to each access technology and the performance
106
values can vary between their upper and lower limits in a sinusoidal manner. However,
this method seems to be too simple and far from reality; 2) the second method is using a certain model defined and used by other research activities.
Such a model is described in [59]. This model iterates the performance value for each
access technology with respect to a specific criterion among several typical values based on a transition matrix. However, there are only quite a few typical values for each
criterion and the predefined transition matrix of performance values is also quite
abstracted, which uses uniform transition probabilities with limited states; 3) 3, it will be nice if realistic trace or distribution information of the performance values
based on real-world measurement is available while so far, we have not found such
useful information.
Therefore, it is decided to model the changing pattern of these performance values with a
mathematic model, which is a more realistic model with more performance value states that are
related and implemented for each of the access technologies considered in this model. With
more literature study and discussions, it is decided to model the number of background vehicles
served by each ATA using a queuing model. Furthermore, the performance values associated
with the offered bandwidth, mean delay and jitter are calculated based on the number of vehicles
served by each ATA.
This model is used to calculate the background traffic and the performance values associated
with this traffic in each of the access technologies supported by the simulation model. This is
also the reason of why these vehicles are called ―background vehicles‖, which are not
simulated/modelled in SUMO, but they are used to generate the background traffic and to
influence the performance values related to each access technology that are used during the
selection making procedure of the intelligent scheduler.
The queuing model used for calculating the number of vehicles served by each ATA is an
M/D/m/m queue, which is modified from the M/M/m/B queue [134]. The state transition
diagram for this M/D/m/m queue is shown in Figure 51. If the current number of vehicles within
a cell is lower than ―m‖, which is also the number of servers, a new arrived vehicle can always
be served, while if the current number of vehicle within a cell is equal to ―m‖, a new arrived
vehicle cannot be served and can be seemed as get lost from connection.
Figure 51State transition diagram for this M/D/m/m
In Figure 51, the number of background vehicles changes among the values from 1to m, based
on the arriving rate ―λ‖ and service rate unit ―μ‖. Here, the arrivals of the vehicles are complying
with a Poisson process; therefore, the inter-arrival time is exponential distributed. And it is
assumed that all the background vehicles are using the same velocity which is constant for each
simulation run. So if the inter-vehicle distance is exponential distributed, the inter-arrival time is
also exponential distributed. For implementation, the inter-arrival distance of vehicles is set as
exponential distributed and a constant speed is used for all background vehicles within a specific
107
cell. In urban area with small access technology cell size, it is assumed that the call/application
duration time associated with each background vehicle is longer than the time that a background
vehicle needs to cross over the access technology cell. For large-size cells in suburban and rural
areas, it is more probable the connection of one vehicle can finish within one cell. Since in this
assignment, the intelligent scheduler will be evaluated in urban area as assumed, it is considered
that the duration time that a vehicle uses any application within one cell is equal to the time they
used to go across this access technology cell. Thus, the service time is modelled to be
deterministic and based on the vehicle's speed and the cell size. ―λ‖ and ―μ‖ and are calculated
based on equations given below.
λ=speed of background vehicle/inter-arrival distance Equation 38
μ=speed of background vehicle/diameter of current cell Equation 39
In our simulation topology (see Figure 42.), since the road just crosses the centers of the ATA
cells, the diameter of each access technology cell can be used as the distance needed by each
background vehicle to cross an access technology cell.
Once an vehicle arrival event occurs, the number of the background vehicles increases by one,
while if a background vehicle has departure from the cell, the number of the background
vehicles decreases by one. When the whole cell is fully-loaded (m background vehicles are
supported by the cell), then the number of served vehicles will change only when a background
vehicle has departure from the cell and the new arrived vehicles will not be served. These new
arrived vehicles are considered as losing their connection to the ATA. While once the access
technology cell is empty (0 background vehicle is being served), the number of vehicles will
change only when a new arrival vehicle event occurs.
Based on the current number of vehicles, we calculate the offered bandwidth, delay and jitter
based on those equations, which are specific for M/M/1 queue [134]. The M/M/1 queuing model
is used to model the average traffic intensity for each access technology. Furthermore, we
calculate the delay and jitter based on the average traffic intensity of each server, which is
identical to the traffic intensity of the whole cell. The original equations used are shown below:
Traffic intensity:
Equation 40
Mean response time
Equation 41
Variance of response time =
Equation 42
In our model, it is defined that ―m_current‖ stands for the number of vehicle currently in the cell.
If ―m_current‖ is smaller or equal to ―m‖ (m_current ≤ m), then there will be ―m_current‖
servers serving these vehicles with full load, i.e. the arriving rate of packets for each serving
server ―λp‖ is equal to the service rate for each serving server ―μ‖, i.e. λp=μ. Otherwise, ―m -
m_current‖ servers are idle. In other words, for each individual server, its traffic intensity is
either ―1‖ or ―0‖. Therefore, the calculation of the traffic intensity can be reshaped as:
108
⋅ ⋅ Equation 43
The mean and standard deviation of the response time are used to approximate the delay and
jitter for each technology. However, since in reality, the values of delay and jitter can be much
larger than the mere response time and its standard deviation calculated for a single simple
M/M/1 queue, we need some scale factor ―k1‖ and ―k2‖ to scale these values into a realistic
range:
Delay=(1/(μ⋅k1))/(1-ρ)
Equation 44
Jitter=(1/(μ⋅k2)/(1-ρ)
Equation 45
If ―m_current‖ equals to ―m‖, an infinite value of Delay and Jitter can be obtained.. In order to
avoid this scenario, a small value ― ‖ is used to reshape the calculation of traffic intensity to:
: δ Equation 46
For calculation of the offered bandwidth, suppose that one cell can offer a total bandwidth of
―B_all‖ and each vehicle will utilize a bandwidth unit of ―B_p‖, then:
m = B_all/B_p
Equation 47
Offered bandwidth = B_all-m_current⋅B_p
Equation 48
Here, it is assumed that the maximum number of users supported in one cell is limited by the
total bandwidth and the used bandwidth unit. Note that the offered bandwidth is the rest amount
of available bandwidth of the access technology cell that is not used by the active background
vehicles.
For the simplicity of implementation, these delay, jitter and available bandwidth values are not
implemented in the model at each ATA, see Section 5.2. These values are in the simulation
model directly generated by the Information Server, instead of generating them at each ATA and
disseminating them regularly to the Information Server using TCP/IP based wired
communication, see Section 5.2. Since wired communication can be considered to be reliable,
this approximation is realistic and reasonable.
In this subsection, is described how the changing performance values are generated: the number
of vehicles being served for one specific access technology cell is modelled as an M/D/m/m
queuing model. Based on this number of vehicles being served, the offered bandwidth and the
average traffic intensity can be calculated. A simple M/M/1 queuing model is used to model the
queue of each serving server. With the average traffic intensity being applied, the delay and jitter
can be calculated approximately by utilizing the equation for calculating the mean response time
and variance of response time for the simple M/M/1 queuing model.
Even though using an average traffic intensity may not be strictly justified, this way of
generating performance values can be a more appropriate method at this moment (without
realistic trace and distribution measured from real infrastructure) compared to a simple
109
mathematic model and the one used in [59]. In particular, it bridges the transition among states
to traffic scenario reasonably, and it models more performance value states, depending on the
number of servers.
6.2.4.4 XMIPv6 framework
In Chapter 4, NEMO has been selected as the handover mechanism used by our intelligent
scheduler. Since the in-vehicle network and the handover of multiple devices in the vehicle are
beyond our investigation scope, and since no IETF NEMO INET/OMNET++ models could be
found, the Mobile IPv6 can be used instead. In this way, the vehicle is treated as a single moving
station. xMIPv6 stands for Extensible Mobile Ipv6 Simulation framework developed for
OMNeT++. According to [112], xMIPv6 is a simulation model that has been implemented with
strict conformance to IETF's official specification for the Mobile Ipv6 (MIPv6) protocol that has
been standardized in RFC 3775 [98].It has been developed in the INET20061020 framework for
OMNeT++ 3.2 and the accuracy and reliability of its performance has been validated against a
real Linux based MIPv6 test bed as shown in [132]. What's more important, presently, is that
protocols like FMIPv6, HMIPv6, NEMO have been implemented but are undergoing validation
tests and are planned to be released in the coming months [112]. Since it is decided to use
OMNeT ++ as our simulation environment and use the Veins [111] to provide mobility model
for the vehicle, this xMIPv6 is quite suitable for our simulation framework and this framework is
used to provide us the required handover execution mechanism.
When introducing the whole simulation network and used entities, the modules used from
xMIPv6 to implement Mobile Ipv6 have been discussed: ―networklayer‖ supporting mobile
IPv6, ―buList‖ and ―bindingCache‖. For more details, please refer to [132] where the authors
give a clear description of this framework.
With respect to our work on this module, instead of directly using the existent module, several
modifications had to be made, because the original model does not support our requirements
well. Generally, our work includes two aspects:
a)The original example given by xMIPv6 works well for a handover from the home network of a
mobile station to a foreign network and as well as the handover from the foreign network to the
home network. However, this example does not function properly after being extended to let the
mobile station handover from a foreign network to another foreign network. Therefore, the
source code of the original model has to be modified so that it can support handover between
two foreign networks.
b)The original model introduces some random and constant delays, which makes the handover
latency of this model also a random value with obvious fluctuations. Since the influence of the
handover latency on our observing performance measure is interesting to be monitored, this
handover latency has to be made controllable, i.e., the original model simply introduces some
random delay without specific events or procedures and only the mean handover delay is
meaningful in our simulation model but not the distribution, so these simply introduced delay are
removed. According to [132], the total handover latency comprises: Move Detection Delay,
Home Registration Delay, Return Routability Delay, and Correspondent Registration Delay.
After our modification, the keep Home Registration Delay, Return Routability Delay,
110
Corresponding Registration Delay is still kept more or less constant. The Move Detection Delay
is constituted of Layer 2 handover delay, Router Discovery Delay and Proxy Duplicate Address
Detection Delay . These three delay components remain more or less constant and in order to get
different handover latency value, the value of the Proxy Duplicate Address Detection Delay can
be adjusted. The influence of handover latency on the chosen performance measures is shown in
Chapter 7.
6.2.4.5 INET-sommer
OMNeT++ is an event-based simulator, being able to handle mobility by scheduling node
movements at regular intervals. This suits the approach followed by SUMO, which is a discrete
time simulator. INET-sommer is the INET version of network simulator used for Veins-Vehicles
in Network simulation [111] created by Christopher Sommer and it is just providing a simulation
framework by coupling INET/OMNeT++ and SUMO.
Veins can use two versions of the network simulator: MiXiM-sommer, and INET-sommer.
INET-sommer is chosen instead of MiXiM-sommer as a result of that the INET framework has
well-defined higher layer modules. In addition, Veins is needed to be used together with xMIPv6
and it is difficult to merge two frameworks, where one of them is based on INET and the other is
based on MiXiM. Even though the Mixnet [133] provides one method of bridging INET to
MiXiM, it is not fully functional. Below a description is given on how this INET-sommer
framework operates in combination with the trace of the vehicle given by SUMO.
Figure 52 shows the combined state machines of the INET-sommer framework and SUMO
when they operate together: INET-sommer can send commands to SUMO through a TCP-based
connection and any commands arriving in-between timesteps can be buffered to guarantee
synchronous execution at defined intervals [135]. At each timestep, INET-sommer would send
buffered commands to SUMO and trigger the corresponding timestep of SUMO. Once SUMO
completes its timestep, it will send a trace comprising the vehicle's mobility information back to
INET-sommer, which allows the networks to react to the received mobility trace like introducing
new nodes or deleting nodes that had reached their destination and for our simulation, the
network-simulator just moves the vehicle based the updated position in the vehicle's SUMO
counterpart. After this kind of reaction, INET-sommer will advance its own simulation until the
next scheduled timestep.
The coupling between INET-sommer and SUMO can also be shown in the form of functionality
blocks instead of state machine, see Figure 53.
111
Figure 52.State machines of road traffic and network simulator communication modules, copied
from [135]
Figure 53.Functionality blocks used for coupling between INET-sommer and SUMO
The functionality blocks shown in Figure 53 comprise:
TraCI: is a traffic control interface, which is a TCP based client/server architecture and it
provides access for network simulator to run a road traffic simulation. During simulation
runs, both SUMO and INET-sommer use their communication modules to exchange
commands by using TCP connections. As a TraCI client, INET-sommer uses TraCIScenarioManager to communicate with the TraCI server—SUMO.
TraCIMobility: is a INET-sommer function that is able to move corresponding
communication nodes at the network part based trace sent from SUMO.
TraCIScenarioManager: TraCIScenarioManager connects INET-sommer to a TraCI
server (SUMO) running road traffic simulation. It sets up and controls the simulation
experiments, moving nodes with the help of the TraCIMobility module. The communication between INET-sommer and SUMO is based on exchanging TraCI
112
messages. The TraCIScenarioManager as being the ―Manager‖ can ask SUMO for all
the parameters such as vehicle speed, position and to execute all the commands such as creating an object. This can however be accomplished only if these parameters and
commands are defined in the ―TraCIConstants.h‖. ―TraCIConstants.h‖ is a header file
that defines all parameters allowed to be transmitted between SUMO and INET-
sommer), e..g., acceleration, position, velocity). Moreover, this header file contains all the allowed program commands that can be executed and can use on these parameters,
e.g., ―get‖, ―set‖.
In particular: At the beginning of each timestep, INET-sommer would send buffered commands
to SUMO by using the TraCIScenarioManager (step 1&2 in Figure 53). The simulation timestep
of SUMO is triggered. SUMO sends its trace (i.e., position for our simulation) to INET-sommer
after its timestep completes (step 3 in Figure 53). In INET-sommer, the vehicle moves to the
updated position given by SUMO with TraCIMobility (step 4 in Figure 53). Then the simulation
at the network part is triggered.
6.2.5 Integrated simulation model This subsection describes the integration simulation model, that use the traffic simulator and the
network simulator described in the previous sections. The complete integrated simulation
framework is shown in Figure 54.
Figure 54 Complete/integrated simulation framework of functionalities
In Figure 54, it can be seen that the integrated simulation framework consist of two simulation
environments:: INET/OMNeT++ and SUMO. As discussed in section 6.2.3.5, INET-sommer
operates as the client part of Veins, and SUMO operates as the server part of Veins.
113
The INET-sommer functionality is used to support the communication with SUMO. At the
beginning of each simulation timestep, INET/OMNeT++ sends commands to SUMO and trigger
the simulation run of SUMO. After this simulation timestep finishes, the position of vehicle is
sent back to the vehicle's counterpart in the INET/OMNeT++.
Veins provides a mobility model for the vehicle that needs to be simulated. The main part of the
integrated simulation model is accomplished inside the INET/OMNeT++ environment, where
the communication between the vehicle and Infrastructure (V2I) and the intelligent scheduler is
simulated. The estimation process and the selection-making mechanism are directly
implemented in the application of the Vehicle shown in Figure 33. Furthermore, the handover
execution mechanism is supported by the functionality provided by the xMIPv6 simulation
framework, which provides the (1) vehicle part of the Mobile Node module, (2)the Network
Infrastructure part of the Correspondent Node and (3) the Home Agent.
In addition, in order to generate the dynamically changing performance values at the Network
Infrastructure part used for our intelligent scheduler, a mathematic model is directly
implemented in the source code of the application used by the Information Server.
Using the integrated simulation model, that encompasses the intelligent scheduler, Information
Server and mobility model, it is possible to perform simulations for the following scenario: a
vehicle is moving on the route provided by SUMO and is able to retrieve information from the
Information Server and make selections and handover to a targeted access network(s) that can
use during the simulation.
114
115
Chapter 7: Experiments and Results
In this chapter, the experiments and results associated with this assignment will be described and
discussed. First, the validation process of the used selection-making mechanism is introduced.
Then in section 7.2.1, the performance measure used to evaluate the designed intelligent
scheduler is illustrated. Afterwards, the simulation parameters are defined. Simulations are done
with different background vehicle speed, average inter-arrival distance and handover latency. In
addition, the simulation results are also analyzed.
7.1 Selection-making mechanism validation This section describes the validation of the implemented AHP algorithm, see Section 6.1.1.
7.1.1 Verification of the Simulink model Section 6.1.1, describes how the AHP algorithm is implemented. In particular, for inconsistent
matrices, the eigenvector solution is used, and for consistent matrices the equivalent Additive
Normalization solution is used for simplicity. As described in Section 6.1.2, the model used in
[56] is reproduced to check the correctness of the implemented AHP algorithm. In this
subsection, the performed experiments performed during the validation process and the obtained
results are described.
In [56], the comparison matrix of five different criteria application, four of the five performance
comparison matrices, and the calculated weights of each matrix are clearly given for the
streaming application, Thus, the weights of these five matrices (shown in Section 6.1.2) can be
first calculated by the implemented AHP algorithm. The calculated results will be compared to
those described in [56]. The calculated results in this assignment and the original results given in
[56] corresponding to these five matrices are abstracted in Table 24 to Table 28.
Table 24 Results given by original and reproduced model on criteria weights
Mobility(speed) Bandwidth Network
Traffic
Load
Initial
Delay
Usage
Cost
Consistency
Index
Random
Inconsistency
Consistency
Ratio
Original
Model
0.4529 0.2765 0.0742 0.1553 0.0407 0.0777467 1.12 0.0694
Reproduced
Model
0.4530 0.2766 0.0742 0.1554 0.0408 0.0777467 1.12 0.0694
Bias
(absolute
difference)
0.001 0.001 0 0.001 0.001 0 0 0
116
Table 25 Results given by original and reproduced model on technologies' performance weights
on bandwidth
WiMAX UMTS WLAN Consistency
Index
Random
Inconsistency
Consistency
Ratio
Original
Model
0.4666 0.0666 0.4666 2.2*10^-16 0.58 3.82*10^-16
Reproduced Model
0.4667 0.0667 0.4667 0 0.58 0
Bias (absolute
difference)
0.001 0.001 0.001 2.2*10^-16 0 3.82*10^-16
Table 26 Results given by original and reproduced model on technologies' performance weights
on network traffic load
WiMAX UMTS WLAN Consistency
Index
Random
Inconsistency
Consistency
Ratio
Original
Model
0.2431 0.6689 0.0882 0.003515 0.58 0.006061
Reproduced
Model
0.2426 0.6694 0.0879 0.003511 0.58 0.006053
Bias (absolute difference)
0.005 0.005 0.003 0.000004 0 0.000008
Table 27 Results given by original and reproduced model on technologies' performance weights
on initial delay
WiMAX UMTS WLAN Consistency
Index
Random
Inconsistency
Consistency
Ratio
Original
Model
0.2431 0.0882 0.6689 0.003515 0.58 0.006061
Reproduced
Model
0.2426 0.0879 0.6694 0.003511 0.58 0.006053
Bias (absolute
difference)
0.005 0.003 0.005 0.000004 0 0.000008
Table 28 Results given by original and reproduced model on technologies' performance weights
on unit cost
WiMAX UMTS WLAN Consistency
Index
Random
Inconsistency
Consistency
Ratio
Original
Model
0.1061 0.2604 0.6333 0.019357 0.58 0.03375
Reproduced
Model
0.1047 0.2583 0.6370 0.019256 0.58 0.03320
Bias (absolute
difference)
0.0014 0.0021 0.0037 0.000101 0 0.00055
From Table 24 to Table 28, it can be seen that the difference between the results calculated by
the reproduced model (that will be used in this assignment) and those in the original paper, see
[56] are very small. The maximum difference for calculated weights is ―0.005‖ and the
maximum value for difference divided by original value in percentage is
―0.005/0.2431=2.0568%‖, which is also quite small.
117
The reasons of these observed (relative small) differences can be seen below:
the methods used to calculate the eigenvector used by [56] and our reproduced model
might be different (we use the function ―eigs( )‖ in Matlab)
Different effective number of digits are taken during the calculation process
Furthermore, the way of calculating the performance comparison matrix with respect to the fifth
criterion- ―Mobility‖ is also clearly described. However, no calculated weight with respect to
this criterion is given. Instead, the chart depicting the final weights (synthesizing the criteria
weights and all the performance weights) of three technologies are given in Figure 55. Then a
chart depicted with the final weights calculated by the reproduced model can be compared with
the given chart in [56]. With the information given in [56], only part of the chart can be
reproduced when the vehicle speed is smaller than 20 km/h.
Figure 55Performance weights generated from reproduced model (left) and original model
(right)
The ―Selection Index‖ (final weights) of three technologies used in [56] is given in the right part
of Figure 55 with a speed changing from 0 to 100 Km/h. The results generated by our
reproduced model are depicted in the left part of Figure 55. Compared to the curves in the right
part of Figure 55 from 0 Km/h to 20 Km/h, no clear difference can be seen. And the cross point
of the curves of WLAN and WiMAX appears at 16.3Km/h in [56] and as well in the reproduced
model, it appears at 16.5Km/h, which is slightly different.
The AHP algorithm implemented by us was strictly complying with Saaty's definition of AHP.
And there's no clear difference found between the performance of a certain model using AHP,
see [56], and that of our reproduced model. Based on these validation results we deduce that the
implemented algorithm performs similarly to the algorithm described in [56] and therefore it can
be applied in the following simulation experiments.
118
7.1.2 Verification of the Additive Normalization model in C++ Since the Additive Normalization solution will also be implemented in C++, also a verification
of the C++ based Additive Normalization model should be performed. Here, for different
comparison candidates (no matter for criteria or performances), their scores are shifted from 1 to
9 using integers and the number of comparison candidates is shifted from 1 to 5. The weights
calculated by the Additive Normalization solution that is implemented in C++ are exactly the
same as the ones implemented in Matlab.
For the original eigenvector solution, the weights are just calculated in Matlab and are
predefined to be used in the OMNeT++ model, as specified in Section 6.1.1.
7.2 Evaluation experiments After that the implemented AHP algorithm behavior has been verified, the implemented
intelligent communication medium scheduler model described in Chapter 6 will be evaluated. In
this section, first the performance measures going to evaluate will be introduced. Then, the
simulation parameter values that will be used during the simulation experiments will be listed.
Afterwards, the simulation results and their analysis are given.
7.2.1 Performance measure In Chapter 3, various types of multi-criteria-selection-making methods have been introduced.
The study of the sensitivity and accuracy of these selection-making mechanisms is described in
many research papers. Some research papers evaluate the sensitivity of the selection result by
changing performance values considered in decision making. For example, in [56], the authors
investigate the selection result when changing the vehicle speed; in [69], the authors are
interested in the bandwidth of the selected network corresponding to a changing requested
bandwidth. Some other papers evaluate the difference of the selection result with respect to the
different performance weights combination methods, like in [136] and [59]. However, most of
these research papers just focus on the pure selection-making mechanism's results. However, in
realistic scenarios the selection-making mechanism has to be combined with a handover
execution mechanism. Even if architectures combining the selection-making mechanisms and
handover mechanisms have already been presented in some papers like [53], [137] and [76], the
evaluation related to the influence of this combination is not given.
One apparent side effect of using a handover mechanism is the introduction of the handover
latency. Without perfect seamless handover mechanism being implemented, this latency makes
it less attractive for the vehicle to handover to a different technology, when is not necessary to
maintain an on-going session. The influence of whether executing or not a handover has on the
packet loss has been studied in [75].
Furthermore, as the performance values may change during the handover execution, the vehicle
may have a different selection result compared to the one that is obtained before the handover.
The difference in these values can be quantified using the accuracy performance measure.
119
The definition of the ―accuracy‖ is the following: the ratio of the number of selections made
before handover which have the same results as selections made after the handover execution
procedure to the total number of handovers:
For a specific period of simulation time and fixed vehicle speed, the intelligent scheduler will
make a specific number of selections. Though not every selection will trigger a handover (once
the selected network is the currently using one by the vehicle), in order to have a controllable
number of handovers, we will make the intelligent scheduler to also scan the selected channel
and make the handover when the selected network is currently used by the vehicle. In case that
no access technology is selected, then the handover will be triggered to one available
technology. This is done to check whether there is still no access technology that can be selected
by the selection-making after handover.
7.2.2 Simulation parameters After deciding which performance measure needs to be evaluated, the used simulation
parameters will be specified.
First, the parameters used for the simulation topology are specified. The cell sizes for ATAs of
each access technology are shown in Table 29. As the intelligent scheduler is designed to be
used in an urban area, cells of small size are used for UMTS and WiMAX. For UMTS, the 2km
[138] is taken as its diameter and for WiMAX, 1 km [139, 140] is used for its diameter. For
WLAN, IEEE 802.11p [141] s assumed to be used and a transmission range of 250 meters is
possible, which means that the diameter of the WLAN cell is set to be 500 meters. Since the
simulation topology has already been designed as shown in Section 6.2.2 (simulation topology),
the length and width of the rectangular road network should be smaller than 250*2+1000=1500
meters and 250+500=700 meters respectively in order to make possible that WiMAX and
WLAN together can cover the whole rectangular road network. For the implementation, a length
of 1260 meters is set and the distance between a WiMAX ATA and its neighboring WLAN ATA
is 630 meters. Furthermore, in order to make sure that the road is long enough for the simulated
vehicle to finish its registration in its home network before it enters the rectangular area, the
length of the edge 1 shown in Figure 42 is set to 500 meters. The Access Point of the home
network is located 380 meters away from its neighboring WLAN ATA and its communication
range is the same as a WLAN ATA. Compared to the cell size of UMTS, WiMAX, WLAN, the
cell size of GSM/GPRS can be quite large. If only the size of GSM/GPRS is able to cover the
whole rectangular area, it can be considered to be large enough for our simulation experiments
and its cell size can be set the same as the UMTS cell size. However, in our simulation
experiments the diameter of a GPRS cell is set to be 35 km. Since the cell size of GPRS is large
compared to cells belonging to other technologies, the call/application duration time can be
lower than the time that a vehicle needs to cross the GPRS cell. Therefore, the serving duration
time of an application used by a vehicle moving in the GPRS cell is assumed to have an
exponential distribution with an average value of four minutes.
120
Table 29 Cell sizes for different access technologies
Access Technology GPRS UMTS WiMAX WLAN
Cell Size 35km (implemented
as 2km)
2 km 1 km 500 m
Secondly, we specify the application traffic parameters used to generate the used performance
values, which are shown in Table 30.
Table 30Parameters to generate performance values
Access Technology GPRS UMTS WiMAX WLAN Total Bandwidth 150 kbps 14 Mbps 25Mbps 11Mbps
Background
Bandwidth Unit
10 kbps 64 kbps 256 kbps 256 kbps
Maximum Supported
User Number
15 224 100 44
It is assumed that GPRS can support a maximum data rate of 150 kbps and each background
vehicle that uses GPRS will consume 10kbps, therefore, GPRS can support at maximum
150/10=15 vehicles as shown in Table 30. For UMTS, HSDPA [142] is assumed to be used and
a total bandwidth of 14Mbps can be supplied. Background traffic using the UMTS consumes 64
kbps for each vehicle, as a result, the UMTS ATA can support 224 users simultaneously at
maximum. For WiMAX, the used bandwidth is 25 Mbps (approximated from 24.94 Mbps,
corresponding to the assumption when 16QAM, ¾ FEC and 10MHz Channel Bandwidth are
used [143]). For WLAN, the used bandwidth is 11Mbps. For both WiMAX and WLAN, each
background vehicle will use 256 kbps, therefore, these two technologies support 100 and 44
users at most respectively.
For the equations (Equation 44 and Equation 45) used to generate the delay and the jitter, and in
order to prevent an infinity value of delay, when calculating the traffic intensity, the maximum
supported user number is set a bit larger. In this way, the largest possible traffic intensity is
calculated to be
and uniform for all four access
technologies. Furthermore, for the equation (Equation 44 and Equation 45), μ⋅k1=0.21 and
μ⋅k2=2.1 are used as scaling factor so that most of our values can be within the range of 1ms to
11ms for jitter and 10ms to 110ms for delay, which is comparable to the values used in [59].
Here, a further assumption is made, that the background traffic situation for each cell in the
simulation uses the same value for the average vehicle inter-arrival distance and vehicle speed.
Furthermore, the background traffic of one cell is independent from that of any other cell. In
urban area, we assume that the upper limit for vehicle is 50km/h=13.889m/s. For simulations,
the value of 14 m/s is used instead, for sake of equal-spaced speed. The minimal average vehicle
inter-arrival distance taken is 2 meters, which means 50 vehicles/100 meters for one road. The
vehicle inter-arrival distance used is defined as the distance between two neighboring vehicles in
the direction of the road, no matter whether these two vehicles are in the same lane as shown in
Figure 56.
121
Figure 56 Inter-arrival Distance definition
From Figure 56, it can be seen that the inter-arrival distance for Vehicle A and Vehicle B is
taken in the direction of the road and equal to 5 meters. Also, length of the road section shown in
Figure 56 is 40 meters and there are 8 vehicles in this road section's different lanes, so its
average vehicle inter-arrival distance is 40/8=5 meters. Similarly, with more lanes assumed for
background traffic, even smaller inter-arrival distance is possible.
Thirdly, the simulation parameters for the intelligent scheduler and vehicle are specified. In the
simulation, two continuous applications will be considered: video watching and VoIP. These
applications have different requirements on the used selection criteria, e.g., video watching cares
more on offered bandwidth than VoIP does.
For video watching (see Table 31), the offered bandwidth is more important than the delay and
initial delay, strongly more important than the monetary cost, weakly more important than the
jitter. Jitter and monetary cost are both strongly more important than the Delay and Initial Delay.
Jitter is weakly more important than monetary cost.
Table 31 Criteria comparison for video watching
Offered
Bandwidth Delay Jitter
Initial
Delay Monetary
Cost Weights
Offered Bandwidth 1 7 3 7 5 0.5036
Delay 1/7 1 1/5 1 1/5 0.0464 Jitter 1/3 5 1 5 3 0.2526
Initial Delay 1/7 1 1/5 1 1/5 0.0464 Monetary Cost 1/5 5 1/3 5 1 0.1511
CI= 0.0733, RI=1.12, CR=CI/RI=0.0655;
For VoIP (see Table 32), Delay and Jitter are strongly more important than the initial delay and
the offered bandwidth. And the initial delay and offered bandwidth is weakly more important
than the monetary cost.
Table 32 Criteria comparison for VoIP
122
Offered
Bandwidth Delay Jitter
Initial
Delay Monetary
Cost Weights
Offered Bandwidth 1 1/5 1/5 3 1 0.0908
Delay 5 1 1 7 5 0.3883 Jitter 5 1 1 7 5 0.3883
Initial Delay 1/3 1/7 1/7 1 1/3 0.0419 Monetary Cost 1 1/5 1/5 3 1 0.0908
CI= 0.0235, RI=1.12, CR=CI/RI=0.0210;
The above comparison matrices used for the criteria importance can be adjusted by the users
according to their preference. The above matrices will be used for simulation.
In order to scale the performance values with respect to the offered bandwidth, delay and jitter,
the upper and lower limits of these criteria for the two applications have to be set (see Table 33).
Table 33 Performance value limits for video watching and VoIP
Offered
Bandwidth
Delay Jitter
Video Watching maximum (minimal) effective
value
2Mbps N/A 1ms
Video Watching minimal (maximum) required
value
256kbps N/A 11ms
VoIP maximum (minimal) effective value 384kbps 10ms 1ms
VoIP minimal (maximum) required value 32kbps 200ms 11ms
For video watching, the maximum effective value for offered bandwidth is assumed to be 2Mbps
and the minimal requirement is 256kbps. For VoIP, it requires less bandwidth and its maximum
effective value is 384kbps and 32kbps for the minimal requirement. For video watching, it is
assumed that there's no limit on the delay while for VoIP, the delay is important and at most it
should be fewer than 200ms. It makes no difference if the Delay is lower than 10ms. For the
jitter, the upper limit and lower limit for two applications are the same: 11ms and 1ms
respectively.
For the network's static capabilities: initial delay and monetary cost, they are the same for the
two different applications and the performance comparison matrices are predefined as shown in
Table 34and Table 35, respectively.
Table 34 Initial delay comparison matrix
GPRS UMTS WiMAX WLAN Weights
GPRS 1 1/3 1/5 1/9 0.0485 UMTS 3 1 1/3 1/7 0.1015
WiMAX 5 3 1 1/3 0.2427 WLAN 9 7 3 1 0.6073
CI= 0.0292, RI=0.9, CR=CI/RI=0.0325<10%;
The initial delay of WLAN is assumed to be weakly smaller than that of WiMAX and strongly
smaller than that of UMTS and extremely smaller than that of GPRS.
123
Table 35 Monetary cost comparison matrix
GPRS UMTS WiMAX WLAN Weights
GPRS 1 3 5 1/3 0.2554 UMTS 1/3 1 3 1/5 0.1141
WiMAX 1/5 1/3 1 1/9 0.0499 WLAN 3 5 9 1 0.5806
CI= 0.0254, RI=0.9, CR=CI/RI=0.0283<10%;
WLAN is treated as free of monetary costs and WiMAX is the most expensive one. UMTS costs
more than GPRS. Moreover, compared to WLAN, the WiMAX is extremely more expensive.
Finally, for all the following experiments, the speed of the vehicle modelled in SUMO is
maintained at 10m/s, which is reasonable in urban area and in our simulation framework. In
addition, each simulation is run from 0s to 9000s and the selection results from 2000s to 9000s
will be collected for analysis. In the following subsections, the simulation results and their
analysis are given.
7.2.3 Accuracy investigation for video watching In this section, the accuracy of our designed intelligent schedule is going to be investigated once
it is applied for video watching. For this application, the criteria weights specified in Table 31.,
are used. The static performance weights are derived from Table 34 and Table 35. The upper and
lower limits with respect to the dynamic capabilities of video watching have been specified in
Section 7.2.2.
In the first set of experiments the influence of the average inter-arrival distance of the
background vehicles on the accuracy is investigated. This value is varied among 100m, 50m,
30m, 20m, 10m, 5m and 2m, which corresponds to the vehicle density: 10 vehicles/km, 20
vehicles/km, 33.33 vehicles/km, 50 vehicles/km, 100 vehicles/km, 200 vehicles/km, 500
vehicles/km. For this simulation, the speed of the background vehicles is set to constant as
10m/s. The handover latency is set to about 2.5 seconds. The computed accuracy results are
shown in Figure 57.:
124
Figure 57 Total accuracy of different average inter-arrival distance for video watching
From Figure 57., we can see that when the inter-arrival distance is large (which means that the
traffic density is low), the intelligent scheduler can have quite high accuracy equal or close to
100%. The reason is that, when there are not many users, the UMTS, WLAN, WiMAX can offer
a bandwidth that is larger than the maximum effective value of video watching. Similarly, the
performance value of delay and jitter for these three access technologies are also better than the
maximum effective value. Meanwhile, the performance values for GPRS are even below the
minimal required value. In this case, the weights of three access technologies with respect to
dynamic criteria are equal, so the static performance weights dominate. Because WLAN has the
smallest initial delay and is free of cost, therefore WLAN will be selected if it is available; when
it is not available, UMTS is preferred than WiMAX taking both initial delay and
monetary/financial cost into consideration.
As the inter-arrival distance decreases, which means that the traffic density increases, the
accuracy is decreasing rapidly. This is because that with more background vehicles, the
performance values with respect to dynamic criteria cannot fulfill the maximum effective values
anymore and the dynamic performance weights begin to dominate.
Simultaneously, as the speed for background vehicles is constant, a larger vehicle density
indicates a larger vehicle arriving rate, while the service rate is constant. Thus, during the
handover execution procedure, the dynamic performance values update more frequently, which
results in a higher possibility of making a different selection before the handover from that after
the handover.
However, as the inter-arrival distance continues decreasing from 5m to 2m, it can be found that
the accuracy increases. This is due to the fact that with such a small inter-arrival distance, the
access technologies have already been almost fully loaded. For this situation, there is a larger
possibility that the scheduler has the same decision result of not finding an available technology
both before and after the handover execution.
125
The maximum 95% two-sided confidence intervals for all the figures in this chapter are below
3% of their mean values.
Generally, the selections made by our intelligent scheduler can be classified in two types.
The first type refers to the selection made from four candidate networks. When the vehicle is
approaching the border of a new cell rather than leaving from its currently located cell. These
four candidate networks are UMTS, GPRS, the currently located technology with partial
coverage (WiMAX or WLAN) and an upcoming new technology with partial coverage are
available (WLAN or WiMAX).
The second type refers to the selection made from three candidate networks, i.e. when the
vehicle is going to cross the border of its currently located cell. Here, only the UMTS, GPRS,
and an upcoming new technology with partial coverage (WiMAX or WLAN) will be available
after it crosses the border.
The accuracy for these two selection types is shown in Figure 58, where 4 CN refers to the first
selection type and 3 CN refers to the second one.
Figure 58 Classified accuracy of different average inter-arrival distance for video watching
From Figure 58, similar results can be found compared to those of Figure 57. for both types of
selections: the accuracy decreases as the inter-arrival distance decreases and increases as the
inter-arrival distance continues decreasing.
Furthermore, it can also be observed that the accuracy of selections made from 3 candidate
networks is larger from the accuracy of selections made from 4 candidate networks.
Furthermore, we can see that as the inter-arrival distance decreases, the difference of accuracy
126
for these two selections is increasing. These results indicate that with fewer candidate networks,
the selection result is less sensible to performance values updates during handover execution.
In the second set of simulation experiments, the influence of the speed of the background
vehicles on the accuracy is investigated. This value of speed is varied from 2.5m/s to 14m/s
spaced with 0.5m/s. For this simulation, the average inter-arrival distance of background vehicle
is set to a constant value equal to 15m. The handover latency is set to about 2.5 seconds. The
obtained simulation results are shown in Figure 59.
Figure 59 Total accuracy of different background vehicle speed for video watching
In Figure 59, as the speed of background vehicles increases, the accuracy of our intelligent
scheduler decreases in a general trend with some fluctuations. In this scenario, the increasing
vehicle speed gives a higher arriving rate of background vehicles and service rate at the same
time, which indicates more updates during handover latency. The influence of more updates
during handover latency on the accuracy of our intelligent scheduler can be classified into two
stages:
For the first stage, the speed of the background vehicles is not high (the average vehicle arrival
time interval and/or service time is larger than or equal to the handover latency more or less),
which corresponds to the case that there will be no or only 1 update (an arrival or served event)
during the handover execution for most handovers of each simulation run. In this section, a
higher speed indicates a lower vehicle arrival time interval and service time, so a higher
probability of occurrence for one update during handover execution. In particular, a higher
probability of occurrence for one update during handover latency results in (1) a higher
possibility of the changing of performance values during handover execution, (2) a higher
possibility of making a different selection before the handover from the selection after the
handover execution.
127
The second stage corresponds to a high vehicle speed (the average vehicle arrival time interval
and/or service time is smaller than the handover latency more or less), when the average number
of updates during handover latency is larger than 1. In this section, a higher speed indicates a
higher probability of more performance updates during the handover latency. More performance
updates may result in a larger probability of changing of the performance values during
handover execution. For example, the influence of an arrival event can be cancelled by a
following served (departure) event. Thus, when the vehicle‘s speed is high, the accuracy does
not decrease apparently as the speed increases.
The accuracy results corresponding to different number of candidate networks are shown in
Figure 60.
Figure 60 Classified accuracy of different background vehicle speed for video watching
In Figure 60, the same result can be derived compared to those of Figure 59: generally, as the
background vehicle speed increases, the accuracy of our intelligent scheduler decreases. Similar
to Figure 58., it can be found with fewer candidate networks, the selection result corresponding
to the largest total weights is less sensible to performance values updates during handover
latency. It can also be seen that for more candidate networks, the fluctuations of accuracy are
more significant.
In the third set of simulation experiments, the influence of the handover latency on the accuracy
is investigated. The accuracy corresponding to different handover latency time can be found in
Figure 61:
128
Figure 61 Total accuracy of different handover latency for video watching
From Figure 61, a general decreasing trend accompanying with the increasing handover latency
can be seen but not really significant. With larger handover latency values, there should be more
updates during this period of time. In addition, the smallest handover latency in Figure 61 is not
smaller than the average vehicle arriving interval (15/10=1.5s) and larger than service time
(about 1s). So there will be at least one update during the handover execution for most of the
handovers of each simulation run. Thus, the influence of the increasing handover latency
corresponds to the second stage of the influence of more updates as stated above for Figure 59.
For different number of candidate networks, the accuracy for different handover latency values
is shown in Figure 62:
129
Figure 62 Classified accuracy of different handover latency for video watching
From Figure 62, it can be seen that the decreasing of the accuracy for selections made from three
candidate networks is more significant than that of four candidate networks. Similar results can
be seen as the ones shown in Figure 58 and Figure 60.
7.2.4 Accuracy investigation for VoIP In this section, the accuracy of the intelligent communication scheduler is studied assuming that
the vehicles are using VoIP applications. For this type of application, the criteria weights
specified in Table 32 are used. The static performance weights shown in Table 34and Table 35
are listing the upper and lower limits with respect to the dynamic capabilities of VoIP that have
been specified in Section 7.2.2. The other simulation parameters are the same as the ones used
for video watching. Thus, the results of the accuracy corresponding to the varied average inter-
arrival distance, background vehicle speed, handover latency are shown in Figure 63 and Figure
64, Figure 65 and Figure 66, Figure 67 and Figure 68, respectively.
130
Figure 63 Total accuracy of different average inter-arrival distance for VoIP
Figure 64 Classified accuracy of different average inter-arrival distance for VoIP
131
Figure 65 Total accuracy of different background vehicle speed for VoIP
Figure 66 Classified accuracy of different background vehicle speed for VoIP
132
Figure 67 Total accuracy of different handover latency for VoIP
Figure 68 Classified accuracy of different handover latency for video watching
From Figure 63 to Figure 68, similar results can be seen as the ones shown from Figure 57 to
Figure 62. The following observations can be made: (1) the accuracy of designed intelligent
scheduler decreases as the average inter-arrival distance decreases and increases as this value
continues to decrease, when a specified constant handover latency and background vehicle speed
are used; (2) the accuracy of the intelligent scheduler also decreases as the background vehicle
speed increases, when a specified constant average inter-arrival distance and handover latency
values are used; (3) the decreasing trend of the accuracy corresponding to a increasing handover
133
latency can be noticed but it is not obvious; (4) the accuracy of selections made from the four
candidate networks is lower than the accuracy of selections made from three candidate networks.
Furthermore, the accuracy results for video watching are slightly higher than the accuracy results
obtained for VoIP. The main difference between these two applications is that they have
different requirements on various selection criteria. According to [43], [56] and [59], different
combinations of criteria weights will influence the selection results,. Moreover, it can be seen
that the different combinations of criteria weights can also influence the accuracy of the
intelligent scheduler.
Moreover, from all the simulation results it can be concluded that the accuracy of the intelligent
scheduler is quite low when (1) the handover latency is large, (2) the background vehicle speed
is high and (3) especially when the inter-arrival distance of the vehicles that are generating the
background traffic is low. Thus, if a prediction mechanism is used to accurately estimate the
values of the performance characteristics at the moment that the handover execution takes place,
the accuracy of the intelligent scheduler could significantly be improved.
7.2.5 Summary In this section, the behavior of the implemented AHP algorithm is first verified by reproducing a
certain AHP model used by a research paper. Then the accuracy of the designed intelligent
scheduler is selected as the performance measure. This performance measure is investigated with
respect to two different applications: video watching and VoIP. For each of these applications,
the influence of the average inter-arrival distance (traffic density), background vehicle speed and
handover latency on the accuracy are investigated.
134
135
Chapter 8: Conclusions and Future work
This chapter concludes this master thesis and presents recommendations for future work. In
particular, first the conclusions specific to this M.Sc. assignment are listed. Afterwards, some
issues related to the performance of the intelligent communication medium scheduler are
discussed. Finally, the recommendations for future activities are given.
8.1 Conclusions Several studies have focused on the evaluation of selection mechanisms, see [9, 43, 47, 56, 59,
60, 66, 68-70, 107, 108]. However, not many studies focussed on the evaluation of a
combination of the selection mechanism and the handover procedures applied in vehicular
networks. Furthermore, the vertical handover and access technology mechanisms that are
developed in typical beyond 3G networks [11] cannot directly be applied in vehicular
environments. This is due to the fact that these existing mechanisms are not taking into account
the characteristics of vehicular environments, such as (1) high mobility of communicating nodes,
i.e., vehicles, (2) the fact that the road topology is known, (3) rapidly changing network topology
as a result of the high-mobility communicating nodes, (4) potentially unbounded communication
network size. Therefore, other types of vertical handover and access technology mechanisms are
needed to satisfy these vehicular environment characteristics.
The main contributions of this M.Sc. assignment include:
investigation and selection of the environment wherein the intelligent communication
medium scheduler is implemented. This includes the vehicular networking architecture,
the used selection making mechanism and the vertical handover protocol.
design of the intelligent communication medium scheduler.
implementation of the intelligent communication medium scheduler simulation model
using matlab, and the SUMO and INET/OMNeT++ simulation environments.
performance evaluation of the intelligent communication medium scheduler from the
point of view of accuracy.
The main goal of this M. Sc. assignment, is to design and evaluate an intelligent communication
medium scheduler used for vehicular to infrastructure communication. This goal is achieved by
answering the research questions listed in Section 1.4. Specifically, various communication
architectures used for vehicular communication, multiple selection-making mechanisms and
different vertical handover mechanisms are investigated through literature study as described
from Chapter 2 to Chapter 4. Afterwards, the requirements on the intelligent scheduler are listed
in Section 5.1 and based on these requirements, the communication architecture, selection-
making mechanism, handover mechanism used by our intelligent scheduler are chosen, which
defines the design of the intelligent scheduler. Furthermore, the deployment scenario (selected
vehicular networking scenario) of the intelligent scheduler is defined and the working
procedures of the intelligent scheduler are specified in detail.
136
In order to evaluate the intelligent scheduler, the scheduler and a designed simulation topology
are implemented using the INET/OMNeT++ as network simulator and SUMO as the traffic
simulator.
The background traffic and the performance values associated with this traffic in each of the
studied access technologies supported by the simulation model, is generated by using among
others a M/D/m/m queuing model.
The performance measure used to evaluate the performance of the intelligent communication
medium scheduler is the accuracy. Accuracy is defined as: the ratio of the number of selections
made before handover which have the same results as selections made after the handover
execution procedure to the total number of handovers:
Based on the simulation results it can be concluded that:
Accuracy is decreasing when the handover latency is increasing. If the handover latency
increases then the background traffic values can vary in such a way that the probability
of making different selections before and after the handover increases, which can result
in a lower accuracy.
Accuracy is decreasing when the speed of the vehicles that are generating the
background traffic is increasing. With a specified average inter-vehicle arrival distance
and handover latency, the increase of the vehicles‘ speed influences significantly the
fluctuations of the background traffic during the handover, which can result in a lower
accuracy.
Accuracy is decreasing when the inter-arrival distance of the vehicles that are generating
the background traffic is decreasing. This means that the number of users that are
generating the background traffic is increasing. Once the number of users is so large that
the network cannot always fulfil the upper limit of the user‘s requirement, the background traffic begin to influence and decrease the accuracy of the used intelligent
scheduler.
Accuracy corresponding to selections made from 3 candidate networks is less sensitive
to the background traffic fluctuations during handover than that of 4 candidate networks.
Different applications have different requirements on the considered criteria set, and different criteria weights can influence the accuracy of the intelligent scheduler.
8.2 Discussions This section describes a number of additional issues that can be considered for the design and
evaluation of an intelligent communication medium scheduler.
Seamless handover
For real time applications, e.g. VoIP, seamless handover should be applied in order to prevent
loss of packets during handover.
Address compatibility
The candidate access networks may use different types of addressing schemes..
137
Metric compatibility
Metric compatibility is needed in the situation that the intelligent medium scheduler is applied in
communication environments that are administrated by different operators. In this case different
performance metrics and values might be used by the different operators for intelligent
communication medium schedulers.
Multiple-device handover
In order to support the handover of all devices embedded in a vehicle to a specific wireless
technology, the selection-making mechanism can be more complex, especially when these
devices are serving different applications. [70] has already taken this issue into consideration.
8.3 Future work The work accomplished in this M.Sc. assignment provides an initial design of an intelligent
communication medium scheduler. Therefore, the future work associate with this intelligent
communication medium scheduler is to enhance its design, evaluate it more realistically and
improve its performance.
First, as specified in section 5.2, the functionality of periodically scanning the communication
interfaces should be implemented to monitor the performance value changes of the available
access technologies. Moreover, the performance values should be monitored regularly by the
access technology agents, which will inform the Information Server.
Second, in order to get realistic changing performance values, either realistic models of different
access technologies should be built or trace of performance values of real access technologies
should be measured.
Third, a prediction mechanism can be used to accurately estimate the values of the performance
characteristics at the moment that the handover execution takes place, in order to improve the
accuracy of the intelligent scheduler.
Furthermore, the influence of the frequency of the updates from the access technology agents to
the information server and the frequency of scanning the communication interfaces by the
intelligent scheduler on the accuracy, is interesting to be investigated.
Finally, the issues discussed in section 8.2 should also be considered as part of the future work
recommendations.
138
139
Reference
[1] CAR_2_CAR_Communication_Consortium, "CAR 2 CAR Communication Consortium Manifesto Overview of the C2C-CC System," 28th August 2007.
[2] IEEE802.11p, "IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless Access in Vehicular Environments," ed, 2010.
[3] IEEE802.11a, "Supplement to IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: High-Speed Physical Layer in the 5 GHz Band," ed, 1999.
[4] IEEE802.16, "IEEE Draft Amendment Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Broadband Wireless Access Systems - Advanced Air Interface," 2011.
[5] E. Strom, H. Hartenstein, P. Santi, and W. Wiesbeck, "Vehicular Communications: Ubiquitous Networks for Sustainable Mobility," Proceedings of the Ieee, vol. 98, pp. 1111-1112, Jul, 2010.
[6] M. Emmelmann, S. Wiethoelter, A. Koepsel, C. Kappler, and A. Wolisz, "Moving toward seamless mobility: state of the art and emerging aspects in standardization bodies," Wireless Personal Communications, vol. 43, pp. 803-816, Nov, 2007.
[7] M. Stemm and R. H. Katz, "Vertical handoffs in wireless overlay networks," Mobile Networks and Applications, pp. 335-350, 1998.
[8] E. Gustafsson and A. Jonsson, "Always best connected," IEEE Wireless Communications, vol. 10, pp. 49-55, Feb, 2003.
[9] R. A. Ribeiro, "Fuzzy multiple attribute decision making: A review and new preference elicitation techniques," Fuzzy Sets and Systems, vol. 78, pp. 155-181, Mar 11, 1996.
[10] S. Tabbane, Handbook of mobile radio networks: Artech House, 2000 [11] E. Stevens-Navarro, U. Pineda-Rico, and J. Jesus Acosta-Elias, "Vertical Handover in
beyond Third Generation (B3G) Wireless Networks" International Journal of Future Generation Communication and Networking, pp. 51-58, 2008.
[12] IEEE802.11e, "IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements," ed, 2005.
[13] IEEE1609.1, "IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) - Resource Manager," ed, 2006.
[14] IEEE1609.2, "IEEE Trial-Use Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management Messages," 2006.
[15] IEEE1609.3, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services," ed, 2010.
[16] IEEE1609.4, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE)--Multi-channel Operation," ed, 2010.
140
[17] R. A. Uzcategui and G. Acosta-Marum, "Wave: A Tutorial," IEEE Communications Magazine, vol. 47, pp. 126-133, May, 2009.
[18] M. Weigle. Standards:WAVE / DSRC / 802.11p [Online]. Available: http://www.cs.odu.edu/~mweigle/courses/cs795-s08/lectures/5c-DSRC.pdf
[19] ETSI_EN_302_665, "Intelligent Transport Systems (ITS); Communications Architecture," ed, 2010.
[20] ETSI_TS_102_723-3, "Intelligent Transport Systems; OSI cross-layer topics; Part 3: Interface between management entity and access layer," ed, 2009 (start of work).
[21] ETSI_TS_102_723-4, "Intelligent Transport Systems; OSI cross-layer topics; Part 4: Interface between management entity and network and transport layer," ed, 2009 (start of work).
[22] ETSI_TS_102_723-5, "Intelligent Transport Systems; OSI cross-layer topics; Part 5: Interface between management entity and facilities layer," ed, 2009 (start of work).
[23] ETSI_TS_102_723-6, "Intelligent Transport Systems; OSI cross-layer topics; Part 6: Interface between management entity and security entity," ed, 2009 (start of work).
[24] ETSI_TS_102_723-7, "Intelligent Transport Systems; OSI cross-layer topics; Part 7: Interface between security entity and access layer," ed, 2009 (start of work).
[25] ETSI_TS_102_723-8, "Intelligent Transport Systems; OSI cross-layer topics; Part 8: Interface between security entity and network and transport layers," ed, 2009 (start of work).
[26] ETSI_TS_102_723-9, "Intelligent Transport Systems; OSI cross-layer topics; Part 9: Interface between security entity and facilities layer," ed, 2009 (start of work).
[27] ETSI_TS_102_723-10, "Intelligent Transport Systems; OSI cross-layer topics; Part 10: Interface between access layer and network and transport layers," ed, 2009 (start of work).
[28] ETSI_TS_102_723-11, "Intelligent Transport Systems; OSI cross-layer topics; Part 11: Interface between network and transport layers and facilities layer," ed, 2009 (start of work).
[29] ETSI_TS_102_636, "Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking," ed, 2008 (start of work).
[30] ETSI_TS_102_636-6-1, "Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 6: Internet Integration; Sub-part1: Transmission of IPv6 Packets over GeoNetworking Protocols," ed, 2011.
[31] ISO/WD_29281, "Intelligent Transport Systems — Communications access for land mobiles (CALM) — CALM non-IP networking," ed, 2008.
[32] ISO/CD_24102, "Intelligent Transport Systems — Communications access for land mobiles (CALM) — CALM management," ed, 2008.
[33] (April 18th). What is CALM? Communications Architecture for land Mobile environment. Available: http://calm.its-standards.eu/Public/CALMintro.html
[34] ISO/DIS_21217, "Intelligent transport systems — Communications access for and mobiles (CALM) — Architecture," ed, 2008.
[35] (April 18th). What is Working Group 16: CALM Concept. Available: http://www.isotc204wg16.org/concept
[36] R. Roy. CALM Architecture Details [Online]. Available: http://img.slidefinder.net/imagegethandler.axd?id=13587114&size=1
[37] ISO/DIS_21210, "Intelligent transport systems — Communications access for land mobiles (CALM) — IPv6 networking," ed, 2008.
141
[38] ISO_15628, "Road transport and traffic telematics -- Dedicated short range communication (DSRC) -- DSRC application layer," 2007.
[39] ISO_TC204_:_ETSI_ERM_TG37, "The CALM Handbook," ed, 2006. [40] ISO_21218, "Intelligent transport systems —Communications access for land mobiles
(CALM) — Medium service access points," 2008. [41] I. Chantaksinopas, P. Oothongsap, and A. Prayote, "Framework for network selection
transparency on vehicular networks," in International Conference on Electrical Engineering/Electronics Computer Telecommunications and Information Technology (ECTI-CON), 2010, pp. 593-597.
[42] L. Isaksson, "seamless communication," PhD, Department of Telecommunication Systems School of Engineering, Blekinge Institute of Technology, 2007.
[43] L. Isaksson and M. Fiedler, "Seamless connectivity in WLAN and cellular networks with multi criteria decision making," 2007 Next Generation Internet Networks, pp. 56-63, 2007.
[44] T. L. Willke, P. Tientrakool, and N. F. Maxemchuk, "A Survey of Inter-Vehicle Communication Protocols and Their Applications," IEEE Communications Surveys and Tutorials, vol. 11, pp. 3-20, 2009.
[45] F. Bai, T. Elbatt, G. Hollan, H. Krishnan, and V. Sadekar, "Towards characterizing and classifying communication-based automotive applications from a wireless networking perspective," in IEEE Workshop on Automotive Networking and Applications (AutoNet), 2006.
[46] H. J. Wang, R. H. Katz, and J. Giese, "Policy-enabled handoffs across heterogeneous wireless networks," Wmcsa '99, Second IEEE Workshop on Mobile Computing Systems and Applications, Proceedings, pp. 51-60,123, 1999.
[47] W. H. Zhang, J. Jaehnert, and K. Dolzer, "Design and evaluation of a handover decision strategy for 4th generation mobile networks," in 57th IEEE Vehicular Technology Conference, 2003, pp. 1969-1973.
[48] S. Balasubramaniam and J. Indulska, "Vertical handover supporting pervasive computing in future wireless networks," Computer Communications, vol. 27, pp. 708-719, May 20, 2004.
[49] A. Calvagna and G. D. Modica, "A user-centric analysis of vertical handovers," in the Second ACM International Workshop on Wireless Mobile Applications and Services on WLAN Hotspots, 2004, pp. 137–146.
[50] Q. Wei, K. Farkas, C. Prehofer, P. Mendes, and B. Plattner, "Context-aware handover using active network technology," Computer Networks, vol. 50, pp. 2855-2872, Oct 18, 2006.
[51] T. Ahmed, K. Kyamakya, and M. Ludwig, "A Context-Aware Vertical Handover Decision Algorithm for Multimode Mobile Terminals and Its Performance," in the IEEE/ACM Euro American Conference on Telematics and Information Systems (EATIS 2006), 2007, pp. 19-28.
[52] M. Kassar, B. Kervella, and G. Pujolle, "Architecture of an intelligent inter-system handover management scheme," Proceedings of Future Generation Communication and Networking, Main Conference Papers, Vol 1, pp. 331-336, 585, 2007.
[53] M. Kassar, B. Kervella, and G. Pujolle, "An overview of vertical handover decision strategies in heterogeneous wireless networks," Computer Communications, vol. 31, pp. 2607-2620, Jun 25, 2008.
142
[54] M. Kassar, B. Kervella, and G. Pujolle, "An Intelligent Handover Management System for Future Generation Wireless Networks," Eurasip Journal on Wireless Communications and Networking, 2008.
[55] T. Ernst, V. Nebehaj, and R. Sorasen, "CVIS: CALM Proof of Concept Preliminary Results," ITST: 2009 9th International Conference on Intelligent Transport Systems Telecommunications, pp. 80-85, 684, 2009.
[56] S. Dhar, A. Ray, and R. Bera, "Design and Simulation of Vertical Handover Algorithm For Vehicular Communication," International Journal of Engineering Science and Technolog, vol. Vol. 2, 2010.
[57] C. Ma, E. Fallon, Y. Qiao, and B. Lee, "Optimizing Media Independent Handover Using Predictive Geographical Information for Vehicular Based Systems," presented at the 2010 Fourth UKSim European Symposium on Computer Modeling and Simulation, 2010.
[58] T. L. Saaty, "How to Make a Decision - the Analytic Hierarchy Process," European Journal of Operational Research, vol. 48, pp. 9-26, Sep 5, 1990.
[59] E. Stevens-Navarro and V. W. S. Wong, "Comparison between Vertical Handoff Decision Algorithms for Heterogeneous Wireless Networks," 2006 Ieee 63rd Vehicular Technology Conference, vol. 1-6, pp. 947-951, 3030, 2006.
[60] P. M. L. Chan, Y. F. Hu, and R. E. Sheriff, "Implementation of fuzzy multiple objective decision making algorithm in a heterogeneous mobile environment," WCNC 2002: IEEE Wireless Communications and Networking Conference Record, vol. 1-2, pp. 332-336, 936, 2002.
[61] M. Dagdeviren and I. Yuksel, "Developing a fuzzy analytic hierarchy process (AHP) model for behavior-based safety management," Information Sciences, vol. 178, pp. 1717-1733, Mar 15, 2008.
[62] T. Ertay, D. Ruan, and U. R. Tuzkaya, "Integrating data envelopment analysis and analytic hierarchy for the facility layout design in manufacturing systems," Information Sciences, vol. 176, pp. 237-262, Feb 6, 2005.
[63] M. S. Ozdemir, "Validity and inconsistency in the analytic hierarchy process," Applied Mathematics and Computation, vol. 161, pp. 707-720, Feb 25, 2005.
[64] A. Brünner. (2003). Calculator for Eigenvalues and Eigenvectors. Available: http://www.arndtbruenner.de/mathe/scripts/engl_eigenwert.htm
[65] W. H. Zhang, "Handover decision using fuzzy MADM in heterogeneous networks," 2004 Ieee Wireless Communications and Networking Conference, vol. 1-4, pp. 653-658, 2600, 2004.
[66] Q. Y. Song and A. Jamalipour, "A network selection mechanism for next generation networks," Icc 2005: Ieee International Conference on Communications, vol. 1-5, pp. 1418-1422, 3646, 2005.
[67] P. Koele, "Multiple attribute decision making: An introduction - Yoon,KP, Hwang,CL," Journal of Behavioral Decision Making, vol. 10, pp. 151-151, Jun, 1997.
[68] F. Zhu and J. McNair, "Optimizations for vertical handoff decision algorithms," 2004 Ieee Wireless Communications and Networking Conference, vol. 1-4, pp. 867-872, 2600, 2004.
[69] J. McNair and F. Zhu, "Vertical handoffs in fourth-generation multinetwork environments," Ieee Wireless Communications, vol. 11, pp. 8-15, Jun, 2004.
[70] F. Zhu and J. McNair, "Multiservice vertical handoff decision algorithms," Eurasip Journal on Wireless Communications and Networking, 2006.
143
[71] W. T. Chen, J. C. Liu, and H. K. Huang, "An adaptive scheme for vertical handoff in wireless overlay networks," Tenth International Conference on Parallel and Distributed Systems, Proceedings, pp. 541-548, 729, 2004.
[72] Q. Guo, J. Zhu, and X. H. Xu, "An adaptive multi-criteria vertical handoff decision algorithm for radio heterogeneous network," Icc 2005: Ieee International Conference on Communications, vol. 1-5, pp. 2769-2773, 3646, 2005.
[73] K. Pahlavan, et al., "Handoff in hybrid mobile data networks," Ieee Personal Communications, vol. 7, pp. 34-47, Apr, 2000.
[74] J. Makela, M. Ylianttila, and K. Pahlavan, "Handoff decision in multi-service networks," in PIMRC 2000: 11th Ieee International Symposium on Personal, Indoor and Mobile Radio Communications, 2000, pp. 655-659, 1603.
[75] F. Esposito, A. M. Vegni, I. Matta, and A. Neri, "On modeling speed-based vertical handovers in vehicular networks “Dad, slow down, I am watching the movie”," in the Annual IEEE Global Telecommunications Conference (GLOBECOM’10), Miami, Fla, USA, 2010.
[76] Z. Yan, H. Zhou, H. Zhang, and S. Zhang, "Speed-based Probability-driven Seamless Handover Scheme between WLAN and UMTS," presented at the The 4th International Conference on Mobile Ad-hoc and Sensor Networks, Wuhan, China, 2008.
[77] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol," IETF_RFC3963, Ed., ed, 2005.
[78] (April 22nd). IEEE 802.21 official site. Available: http://www.ieee802.org/21/index.html [79] V. Gupta. (2006). IEEE P802.21 Tutorial. Available:
http://www.ieee802.org/21/Tutorials/802%2021-IEEE-Tutorial.ppt [80] IEEE802.21, "IEEE Standard for Local and Metropolitan Area Networks- Part 21: Media
Independent Handover," ed, 2008. [81] K. Taniuchi, et al., "IEEE 802.21: Media Independent Handover: Features, Applicability,
and Realization," Ieee Communications Magazine, vol. 47, pp. 112-120, Jan, 2009. [82] T. Melia, "Mobility Services Transport: Problem Statement," IETF_RFC5164, Ed., ed,
2008. [83] T.Melia, G.Bajko, S.Das, N.Golmie, and JC.Zuniga, "IEEE 802.21 Mobility Services
Framework Design (MSFD)," IETF_RFC5677, Ed., ed, 2009. [84] G. Bajko and S.Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6)
Options for IEEE 802.21 Mobility Services (MoS) Discovery," IETF_RFC5678, Ed., ed, 2009.
[85] G. Bajko, "Locating IEEE 802.21 Mobility Services Using DNS," IETF_RFC5679, Ed., ed, 2009.
[86] IEEE802.11u, "Draft STANDARD for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 7: Interworking with External Networks," ed, 2009.
[87] IEEE802.16g, "IEEE Standards for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems - Amendment 3: Management PLANe Procedure and Services," 2007.
[88] (2011, April 22nd). Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop). Available: http://datatracker.ietf.org/wg/mipshop/charter/
[89] IEEE802.21/D14, "IEEE Draft Standard for Local and Metropolitan Area Networks: Media Independent Handover Services," ed, 2008.
144
[90] 3GPP_TS_23402-a21, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses (Release 10)," ed, 2011.
[91] 3GPP_TS_23.401_V9.3.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 9)," ed, 2009.
[92] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil, "Proxy Mobile IPv6," IETF_RFC5213, Ed., ed, 2008.
[93] H. Solima, "Mobile IPv6 Support for Dual Stack Hosts and Routers," IETF_RFC5555, Ed., ed, 2009.
[94] C. M. Daid. (June 15th). Overview and Comparison of QoS Control in Next Generation Networks. Available: http://www.palowireless.com/3g/qos.asp
[95] 3GPP_TS_23.203_V8.9.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 8)," ed, 2010.
[96] Z.Zhu, R.Wakikawa, and L.Zhang. (2011, April 22nd). A Survey of Mobility Support In the Internet. Available: http://tools.ietf.org/pdf/draft-zhu-mobility-survey-04.txt
[97] C.Perkins, "IP Mobility Support for IPv4," IETF_RFC3344, Ed., ed, 2002. [98] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6," IETF_RFC3775, Ed., ed,
2004. [99] H. Soliman, C. Castelluccia, K. ElMalki, and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6)
Mobility Management," IETF_RFC5380, Ed., ed, 2008. [100] R. Kooldi, "Mobile IPv6 Fast Handovers," IETF_RFC5568, Ed., ed, 2009. [101] C. J. Bernardos, I. Soto, and M. Calderón, "IPv6 Network Mobility," The Internet
Protocol Journal, vol. 10, 2007. [102] Y.-S. Chen, C.-H. Cheng, C.-S. Hsu, and G.-M. Chiu, "Network Mobility Protocol for
Vehicular Ad Hoc Networks," in IEEE Wireless Communications and Networking Conference (WCNC 2009, Budapest, Hungary, 2009.
[103] P. M. L. Chan, R. E. Sheriff, Y. F. Hu, P. Conforto, and C. Tocci, "Mobility management incorporating fuzzy logic for a heterogeneous IP environment," Ieee Communications Magazine, vol. 39, pp. 42-51, Dec, 2001.
[104] M. Bernaschi, F. Cacace, A. Pescape, and S. Za, "Analysis and experimentation over heterogeneous wireless networks," First International Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities, Proceedings, pp. 182-191, 311, 2004.
[105] A. Widhiasi, V. Mohanan, M. F. Pasha, and R. Budiarto, "Vertical Handover Scheme for Car-to-Car Communication Based on IEEE 802.21 Standard," presented at the 2010 Second International Conference on Computer Engineering and Applications, 2010.
[106] F. A. Zdarsky and J. B. Schmitt, "Handover in mobile communication networks: Who is in control anyway?," Proceedings of the 30th Euromicro Conference, pp. 205-212, 639, 2004.
[107] O. Ormond, J. Murphy, and G. M. Muntean, "Utility-based Intelligent Network Selection in Beyond 3G Systems," 2006 Ieee International Conference on Communications, Vols 1-12, pp. 1831-1836, 2006.
[108] A. Prayote, P. Oothongsap, and S. Kanda, "Fast Network Selection Mechanism for Seamless Connectivity on Vehicular Networks," presented at the Computer Sciences
145
and Convergence Information Technology (ICCIT), 2010 5th International Conference on 2011.
[109] B. Srdjevic, "Combining different prioritization methods in the analytic hierarchy process synthesis," Computers & Operations Research, vol. 32, pp. 1897-1919, Jul, 2005.
[110] T. L. Saaty, "A Scaling Method for Priorities in Hierarchical Structures," Journal of Mathematical Psychology, vol. 15, pp. 234-281, 1977.
[111] (January 2011). Veins official website. Available: http://veins.car2x.org [112] (May 2011). xMIPv6 official website. Available: http://www.kn.e-technik.tu-
dortmund.de/index.php [113] SUMO introduction in the sourceforge website. Available:
http://sourceforge.net/apps/mediawiki/sumo/ [114] J. Harri, F. Filali, and C. Bonnet, "Mobility Models for Vehicular Ad Hoc Networks: A
Survey and Taxonomy," Ieee Communications Surveys and Tutorials, vol. 11, pp. 19-41, 2009.
[115] F. K. Karnadi, Z. H. Mo, and K. C. Lan, "Rapid generation of realistic mobility models for VANET," 2007 Ieee Wireless Communications & Networking Conference, Vols 1-9, pp. 2508-2513, 2007.
[116] (January 2011). The Federated Simulations Development Kit (FDK). Available: http://www-static.cc.gatech.edu/computing/pads/fdk.html
[117] (January 2011). CORSIM: Microscopic Traffi c Simulation Model. Available: http://www-mctrans.ce.ufl.edu/featured/TSIS/Version5/corsim.htm
[118] R. Vuyyuru, K. Oguchi, C. Collier, and E. Koch, "Automesh: Flexible simulation framework for vehicular communication.," 2006 Third Annual International Conference on Mobile and Ubiquitous Systems: Networking & Services, pp. 371-376, 2006.
[119] (February 2011). UT-DACS (Design and Analysis of Communication Systems) official web site. Available: http://www.utwente.nl/ewi/dacs/
[120] C. Sommer, Z. Yao, R. German, and F. Dressler, "On the Need for Bidirectional Coupling of Road Traffic Microsimulation and Network Simulation," presented at the 9th ACM International Symposium on Mobile Ad Hoc Networking and Computing (ACM Mobihoc 2008): 1st ACM SIGMOBILE International Workshop on Mobility Models for Networking Research (MobilityModels'08), Hong Kong, China, 2008.
[121] (January 2011). TraNS official website. Available: http://lca.epfl.ch/projects/trans [122] (February 2011). NS2 (Network Simulator -2) official website. Available:
http://www.isi.edu/nsnam/ns/ [123] (January 2011). OMNeT++ official website. Available: http://www.omnetpp.org [124] A. Sobeih, et al., "J-Sim: A simulation and emulation environment for wireless sensor
networks," Ieee Wireless Communications, vol. 13, pp. 104-119, Aug, 2006. [125] (January 2011). Scalable Wireless Ad-hoc Network Simulator (SWANS). Available:
http://jist.ece.cornell.edu/ [126] (January 2011). OPNET official website. Available:
http://www.opnet.com/solutions/network_rd/modeler.html [127] (January 2011). OMNeT++ User Manual. Available:
http://www.omnetpp.org/doc/omnetpp41/manual/usman.html [128] (May 2011). INET official website. Available: http://inet.omnetpp.org/ [129] (June 2011). INET manual. Available: http://inet.omnetpp.org/doc/inet-manual-
DRAFT.pdf
146
[130] C. Lei. (2011, May 2011). Cooperative Adaptive Cruise Control model study based on traffic & network simulation. Available: http://www.utwente.nl/ewi/dacs/assignments/completed/bachelor/reports/2011_lei_chenxi.pdf
[131] (May 2011). INET sommer framework. Available: https://github.com/sommer/inet-sommer
[132] F. Z. Yousaf, C. Bauer, and C. Wietfeld, "An accurate and extensible mobile IPv6 (xMIPV6) simulation model for OMNeT++," in Simutools '08 Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems & workshops, Brussels, Belgium, 2008.
[133] (July 2011). Mixnet official website. Available: http://sourceforge.net/apps/trac/mixim/wiki/mixnet
[134] "The Art of Computer-Systems Performance Analysis, Techniques for Experimental-Design, Measurement, Simulation and Modeling - Jain,R," Interfaces, vol. 22, pp. 113-115, Jul-Aug, 1992.
[135] C. Sommer, R. German, and F. Dressler, "Bidirectionally Coupled Network and Road Traffic Simulation for Improved IVC Analysis," Ieee Transactions on Mobile Computing, vol. 10, pp. 3-15, Jan, 2011.
[136] Q. Song and A. Jamalipour, "An adaptive quality-of-service network selection mechanism for heterogeneous mobile networks," Wireless Communications & Mobile Computing, vol. 5, pp. 697-708, Sep, 2005.
[137] D. Kwak, J. Mo, and M. Kang, "Investigation of Handoffs for IEEE 802.11 Networks in Vehicular Environment," 2009 First International Conference on Ubiquitous and Future Networks, pp. 89-94, 245, 2009.
[138] H. Holma and A. Toskala, WCDMA for UMTS: HSPA Evolution and LTE, 5 ed.: John Wiley and Sons, 2010.
[139] A. Kumar, Mobile broadcasting with WiMAX: principles, technology, and applications: Focal Press, 2008.
[140] (September 2011). WiMAX Transimission Power. Available: http://www.wimaxcom.net/2008/11/wimax-transmit-power.html
[141] IEEE802.11p, in IEEE Standard for Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless Access in Vehicular Environments, ed, June, 2010.
[142] S. A. Ahson, HSDPA/HSUPA Handbook: CRC Press, 2010. [143] (August 2011). Mobile WiMAX: The 4G Revolution Has Begun. Available:
http://www.wimax.com/whitepapers/sprint-mobile-wimax.pdf
147
Appendix A:
This appendix includes the matlab code of two alternative solutions that are implementing AHP.
% an example of predefined comparison matrix b1=[1 5 9 5; 1/5 1 9/5 1; 1/9 5/9 1 5/9; 1/5 1 9/5 1];
%Additive normalization solution
%normalize each row of b1
b2=zeros(4,4);
for i=1:4 for j=1:4
b2(i,j)=b1(i,j)/sum(b1(:,j));
end
end
%normalize each column of b2
%weights of each candidate all stored in b3 b3=zeros(4,1);
for i=1:4
b3(i)=sum(b2(i,:))/4;
end
%Eigenvector-based solution
[Vei,Dei] = eigs(b1); %calculate eigenvectors and eigenvalues Vei=abs(Vei);%absolute values for all eigen vectors
Dei=abs(Dei);%absolute values for all eigenvalues
%find the index of the largest eigenvalue and eigenvector
Dei=sum(Dei);
[MAx,Ind]=max(Dei);
%normalize the eigenvector corresponding to largest eigenvalue
%the weights are stored in Ewei
Ewei=Vei(:,Ind)/sum(Vei(:,Ind));
%for consistency ratio calculation
%calculate the dimension of weights vector
d=size(Ewei);
n=d(1);
CI=(MAx-n)/(n-1);%calculate the consistency index
RI=[0 0 0.58 0.90 1.12 1.24 1.32 1.41];%random inconsistency for different candidates numbers r=RI(n);%random inconsistency when "n" candidates are compared
CR=CI/r;%calculated consistency ratio
148
149
Appendix B:
In this appendix, some notes will be given with respect to the method of building our simulation
framework in INET/OMNeT++. Most of the notes are related to the framework of xMIPv6.
Since this framework is still in developing progress and with many ―TODO‖ left, we think that it
will be helpful to provide the log on how we solve problems when we build the simulation
framework.
Using TCP
During the initial stage of implementation, TCP applications were tried.
For simulation of TCP, two basic queue classes can be used:
1. ―TCPMsgBasedSendQueue/TCPMsgBasedRcvQueue‖
2 .―TCPVirtualDataSendQueue/TCPVirtualDataRcvQueue‖
The first queue class manages the simulation of messages, while the second class just manages
the simulation of the message size, which means it just consider the length of each message but
ignore the information inside the messages. In our simulations, the information exchanged
between the intelligent scheduler and the Information Server cannot be ignored. Therefore, the
first queue class should be used if TCP protocol is included in the simulation.
Support Handover between Foreign Networks
The original xMIPv6 framework does not function well when handovers are made between
foreign networks. However, according to this announcement:
(http://www.omnetpp.org/listarchive/msg11853.php)
―The problem has been rectified‖. Unfortunately, even though we download the source file after
this announcement, there is still one problem left when we want to build a simulation framework
supporting handover between foreign networks with an error (using OMNeT++-4.1):
―Duplicate Address Detected! Manual attention required‖
With threads from the author of xMIPv6 and OMNeT++ google group, we can still not figure
out the problem. And from graphical interface, we did not find duplicate address at all.
Finally, we found this error should be caused by the process of ―setting tentative address‖
corresponding code is in the file ―Ipv6NeighbourDiscovery.cc‖ below the notes:
// TODO improve this code so that only addresses are set to tentative which are
// formed based on the link-local address from above
According to [RFC 2462], ―tentative address‖ is defined as:
an address whose uniqueness on a link is being verified, prior to its assignment to an interface.
A tentative address is not considered assigned to an interface in the usual sense. An interface
discards received packets addressed to a tentative address, but accepts Neighbor Discovery
150
packets related to Duplicate Address Detection for the tentative address.
In the example given in xMIPv6, the link-local address of the mobile node assigned at its home
network will be set to tentative and verified its uniqueness. And, when the mobile node roams
from the home network to the foreign network, this link-local address is not set to tentative
anymore. And according to above notes and the author's paper [], only the CoA is designed to set
as tentative address for Duplicate Address Detection.
However, we found for the handovers from one foreign network to another, even the link-local
address of the mobile node is also set to tentative address. Specific to this model and below the
notes in ―Ipv6NeighbourDiscovery.cc‖, we rectified the code so that only the newly generated
CoA will be set to tentative but not the link-local address. In addition, since a
―FlatNetworkConfigurator6‖ is used, there won't have duplicate link-local address in this model.
By this solution, this specific error does not appear any more.
Using UDP application
Directly using some UDP application (like ―UDPVideoStreamCli‖) together with the xMIPv6
framework introduces an additional problem: in this application, the client does not ―par‖ its
own address at the initialization process, so there's no home address (HoA) embedded in the
packets sent from the vehicle to the correspondent node (CN) and information server (IS). In
advance, the CN and IS cannot reply to the requests sent from the vehicle without knowing its
home address when the vehicle is in foreign networks. In home network, there's only one home
address embedded as using normal IPv6 without mobility support and in foreign network the
CoA is still correctly encapsulated but without specific external HoA.
Our solution: at the initialization process of ―UDPVideoStreamCli‖, we add some code to ―par‖
the address of the vehicle:
const char *HoA=par("localAddress");
hoaAddr=IPAddressResolver().resolve(HoA);
And we rewrite the function ―sendToUDP‖ to let it also specify the ―hoaAddr‖ as the source
address in the control information of the packet. At the same time we keep the original
―sendToUDP‖ in case the source address is not used in other applications. The source code of
original ―sendToUDP‖ and rewrite one are given below.
void UDPAppBase::sendToUDP(cPacket *msg, int srcPort, const IPvXAddress& destAddr,
int destPort)
{
// send message to UDP, with the appropriate control info attached
msg->setKind(UDP_C_DATA);
UDPControlInfo *ctrl = new UDPControlInfo();
ctrl->setSrcPort(srcPort);
ctrl->setDestAddr(destAddr);
ctrl->setDestPort(destPort);
msg->setControlInfo(ctrl);
151
EV << "Sending packet: ";
printPacket(msg);
send(msg, "udpOut");
}
void UDPAppBase::sendToUDPP(cPacket *msg, int srcPort, const IPvXAddress& destAddr,
int destPort, const IPvXAddress& srcAddr)//lcx add set srcAddr
{
// send message to UDP, with the appropriate control info attached
msg->setKind(UDP_C_DATA);
UDPControlInfo *ctrl = new UDPControlInfo();
ctrl->setSrcPort(srcPort);
ctrl->setDestAddr(destAddr);
ctrl->setDestPort(destPort);
ctrl->setSrcAddr(srcAddr);
msg->setControlInfo(ctrl);
EV << "Sending packet: ";
printPacket(msg);
send(msg, "udpOut");
}
In this way, the network layer will know the home address of the vehicle, and encapsulate the
packet sent from the upper layer with CoA and HoA.
Relate geographical information to the application
From the main body of this master thesis, we can find that our intelligent scheduler sends the
request to the information server based on the distance between the vehicle and its upcoming
border. Since the simulation timestep of SUMO is 0.01s and the mobility trace will be sent to the
network simulator also once every 0.01s. Initially, in the application layer, we let the vehicle
checks the position of the vehicle once every 0.01s by using self messages.
However, we found in this way that the reaction (i.e., switching channel) of the application layer
is delayed by 0.01s. During this 0.01s, the vehicle actually has already left from the coverage
area of previous ―ATA‖ and should have already closed the channel used to communicate to
previous ―ATA‖. However, due to the delay, the intelligent scheduler still recognizes the vehicle
is still in the coverage area of previous ―ATA‖ so it still leave corresponding channel open.
During that delay, if the vehicle receives any packet from previous ―ATA‖ with power lower
than the sensitivity, it will be recognized as noise. But if the power of this received packet is still
below the sensitivity but not too low, and plus to ―thermal noise‖ in the model, the noise level
can be larger than the sensitivity, then the radio state of of the vehicle will switch to ―RECEIVE‖
state for previous channel. Thus, after the channel being changed by the aplication layer, the
vehicle cannot send probe request or other packets to the new ―ATA‖.
The delay is caused by that the application layer is not reacting quickly enough to the position
changing. In order to solve this problem, we propose three solutions.
152
Solution 1: change the channel 0.01s early.
Solution 2: the Application layer should update the position with higher frequency. (so that the
delay won't cause additional packets being received).
Solution 3: event-based method
The first solution is dirty, which makes the application layer react to position changing before
the position really changes and the second method does not solve the problem completely.
With the third method, we rectify the code in ―TraCIMobility‖ so that once the mobility trace
sent from the sumo being received, the mobility module will trigger that the application layer to
check whether position update. Revised code can be found below:
void TraCIMobility::nextPosition(const Coord& position, std::string road_id, double speed,
double angle)
{
if (debug) EV << "nextPosition " << position.x << " " << position.y << " " << road_id
<< " " << speed << " " << angle << std::endl;
isPreInitialized = false;
nextPos = position;
this->road_id = road_id;
this->speed = speed;
this->angle = angle;
changePosition();
myUDPVideoStreamCli->posx=position.x;
myUDPVideoStreamCli->posy=position.y;
myUDPVideoStreamCli->positionUpdate();
}
With this solution, the application layer check the position of the vehicle immediately after it is
updated so that the problem can be solve completely.
Random Handover Latency
In Chapter 6, we have mentioned that we need to vary the value of handover latency. In order to
control this value, we have to remove some simple random part so that the handover latency for
the handovers of each simulation configuration won't differ too much.
In ―Ipv6NeighbourDiscovery‖, these lines of code can be found:
// update: added uniform(0,1) to account for joining the solicited-node multicast
// group which is delay up to one 1 second (RFC 4862, 5.4.2) - 16.01.08, CB
scheduleAt(simTime()+ie->ipv6Data()->getRetransTimer()+uniform(0,1), msg);
Even the random part ―uniform(0,1)‖ is used to ―account for joining the solicited-node multicast
group which is delay up to one second‖, there are no corresponding events being simulated at the
same time, which means this is just a simple artificially added delay. Therefore, we change the
code into:
153
scheduleAt(simTime()+ie->ipv6Data()->getRetransTimer()+additionaltime,msg);
Therefore the value of this added delay is adjustable and we can evaluate the accuracy with
different handover latency.
Dynamic Communication Range in INET/OMNeT++
Because the vehicle simulated by us is roaming among the coverage areas of different
technologies with different transmission ranges, the vehicle is required to dynamically changing
its transmission power so that communication range during the simulation to save power. Even
though the power efficiency of the vehicle is not considered in this assignment, it will be
interesting to see how to implement a dynamic changing communication range in INET.
In INET, the maximum interference range of all Access Points will be determined by the single
parameter ―pmax‖ in ―channelcontrol.cc‖ so that every Access Point will use the same maximum
interference range (maximum interference range). Since we are using different Access Points to
emulate the base stations/access points of different access technologies, it's not realistic to use
the same value for the maximum interference range. In order to implement different maximum
interference ranges for different access technologies and let the vehicle dynamically change its
maximum interference range, two steps need to be done:
1, Set the maximum interference range graphically
This can be achieved by modify the "void BasicMobility::updatePosition()" in
"BasicMobility.cc". Here the maximum interference range of the infrastructure and the vehicle
can be set to any value specified by the designer or the value determined by ―pmax‖. And we set
different values to the vehicle if it communicates with different channels (corresponding to
different access technologies). Here the maximum interference ranges are only changed
graphically but won't have any effect on the simulations.
2, Set the real maximum interference range
The real maximum interference range is used to judge whether a packet it sent from a node
within this determined range, which needs modification in "void
ChannelControl::updateConnections" of ―ChannelControl.cc‖. Here the squared maximum
interference range named ―maxDistSquared‖ can be set to different values for different access
technologies.
The second step really sets the range while the first step provides a graphical range complying
with the second step. Normally, the value of maximum interference range used for two steps
should be the consistent. For the vehicle, in order to adjust the communication range, the
transmission range (transmission power) of the vehicle should also be set to adjustable, which is
implemented in the function named ―AirFrame *AbstractRadio::encapsulatePacket(cPacket
*frame)‖ in ―AbstractRadio.cc‖. In this way, when the vehicle is sending packet using different
channels, different transmissiopowers are used.
Other bugs and Naive Solutions
1) in ―Ieee80211Mac::scheduleDataTimeoutPeriod‖ of ―Ieee80211Mac.cc‖, the timeout
period is calculated as
154
computeFrameDuration(frameToSend) + getSIFS() + computeFrameDuration(LENGTH_ACK,
basicBitrate) + MAX_PROPAGATION_DELAY * 2
However, during our simulations, this value may be a little bitter small so that it can be
recognized as time out continuously just when the waited packet is received, so we just add
0.001s to this value and the problem is solved.
2) As the simulation time's being increased, the life time of the ―Return Routability‖
binding at the CN module can expire, this time is defined in the ―IPv6InterfaceData.h‖
as MIPv6_MAX_RR_BINDING_LIFETIME and equals to 420s, so it can be increased
to prevent such kind of problem.
155
Acronyms
Acronym Definition
AAA Authentication Authorization and Accounting
ABC Always Best Connected
AHP Analytic Hierachical Process
AP Access Point
API Application Programming Interface
ATA Access Technology Agent
AU Application Unit
B3G Beyond 3rd Generation
BA Binding Acknowledgement
BER Bit Error Rate
BMR Bus Mobile Router
BS Base Station
BSS Basic Service Set
BU Binding Update
C2C CAR 2 CAR
C2C-CC CAR 2 CAR Communication Consortium
CAL Communication Application Layer
CALM Communications Access for Land Mobiles
CCH Control Channel
CCK CALM Communications Kernel
CDMA Code Division Multiple Access
CI Communication Interface
CIMAE Communication Interface Management Adaptation Entity
156
Acronym Definition
CIME Communication Interface Management Entity
CIPL Communication Interface Protocol Layers
CM Communication Modules
CME CALM Management Entity
CMME Communication Module Management Entity
CMPL Communication Module Protocol Layer
CN Corresponding Node
CoA Care-of Address
CORSIM Microscopic Traffic Simulation Model
CR Consistency Ratio
CSMA-
CA
Collision Sense Multiple Access with Collision Collision Avoidance
DAB Digital Audio Broadcasting
DACS Design and Analysis of Communication Systems
DHCP Dynamic Host Configuration Protocol
DLL Data Link Layer
DSMIPv6 Dual-Stack Mobile IPv6
DSRC Dedicated Short Range Communications
EPC Evolved Packet Core
ePDG evolved Packet Data gateway
EPS Evolved Packet System
ETSI European Telecommunications Standards Institute
E-UTRAN Evolved Universal Terrestrial Radio Access Network
EV-DO Evolution Data Only/Evolution Data Optimized
FDK The Federated Simulations Development Kit
157
Acronym Definition
FEC Forward Error Correction
FIFO First In First Out
FIS Fuzzy Inference System
FMIP Fast Mobile IP
FMR Front Mobile Router
GERAN GSM EDGE Radio Access Network
GPRS General Packet Radio Service
GPS Global Positioning System
GRA Grey Relational Analysis
GRC Grey Relational Coefficient
GRE Generic Routing Encapsulation
GSM Global System for Mobile Communications
GTP GPRS Tunneling Protocol
GW Gateway
HA Home Agent
HMB Host-based Mobility
HMI Human Machine Interface
HMIP Hierarchical Mobile IP
HN Home Network
HoA Home Address
HPCRF Home Policy Charging and Rules Rules Function
HPLMN Home Public Land Mobile Network
HSDPA High-Speed Downlink Packet Access
HSS Home Subscriber Server
IBSS Independent Basic Service Set
158
Acronym Definition
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IME Interface Management Entity
IP Internet Protocol
IP-CAN IP Connectivity Access Network
IPD Inter Packet Delay
IPMS IP Mobility management Selection
IS Information Server
ISO International Standardization Organization
ITS Intelligent Transport Systems
LCoA Local CoA
LLC Logic Link Control
LMA Local Mobility Anchor
LTE Long Term Evolution
MAC Medium Access Control
MADM Multiple Attribute Decision Making
MAE Management Adaptation Entity
MAG Mobile Access Gateway
MAP Mobility Anchor Point
MENN Modified Elman Neural Network
MEW Multiplicative Exponent Weighting
MICS Media Independent Command Service
MIES Media Independent Entity Service
MIH Media Independent Handover
MIHF Media Independent Handover Function
159
Acronym Definition
MIIS Media Independent Information Service
MIPSHOP Mobility for IP: Performance, Signaling and Handoff Optimization
MiXiM Mixed Simulator
MLME MAC Layer Management Entity
MMI Man Machine Interface
MN Mobile Node
MNN Mobile Network Node
MPA Media-independent Pre-authentication
MPLS Multiprotocol Label Switching
MR Mobile Router
M-SAP Medium Service Access Point
NBM Network-based Mobility
NEMO Network Mobility
NME Network Management Entity
OBU On Board Unit
OSI Open Systems Interconnection mode
OSPF Open Shortest Path First
PBA Proxy Binding Acknowledgement
PBU Proxy Binding Update
PCC Policy and Charging Control
PCEF Policy and Charging Enforcement Function
PCRF Policy Charging and Rules Function
PDN Packet Data Network
PDP Packet Data Protoco
PDS Personal Download Service
160
Acronym Definition
PIS Personal Interactive Service
PLME Physical Layer Management Entity
PLMN Public Land Mobile Network
PMIP Proxy Mobile IP
PPP Point-to-Point Protocol
PSS Public Streaming Service
QoS Quality of Service
RCoA Reginal CoA
RMR Rear Mobile Router
RSS Received Signal Strength
RSSI Received Signal Strength Indication
RSU Road Side Unit
RTT Round Trip Time
SAE Security Adaptation Entity
SAP Service Access Point
SAW Simple Additive Weighting
SCTP Stream Control Transmission Protocol
SGSN Serving GPRS Support Node
SIP Session Initiation Protocol
SMS Short Message Service
SSS Selective Streaming Service
SUMO Simulation of Urban Mobility
SWANS Scalable Wireless Ad-hoc Network Simulator
TCP Transmission Control Protocol
TOPSIS Technique for Order Preference by Similarity to Ideal Solution
161
Acronym Definition
TraCI Traffic Control Interface
UDP User Datagram Protocol
UE User Entity
UMTS Universal Mobile Telecommunications System
UTRAN Universal Terrestrial Radio Access Network
V2I Vehicle to Infrastructure
V2V Vehicle to Vehicle
VANET Vehicle Adhoc Network
VCI Virtual Communication Interface
VCI Virtual Communication Interfaces
VoIP Voice over IP
vPCRF Visited PCRF
VPLMN Visitor PLMN
Veins Vehicles in network simulations
WAVE Wireless Access in Vehicular Environments
WBSS WAVE Basic Service Sets
WCDMA Wideband CMA
WME WAVE Management Entity
WSM WAVE Short Message
WSMP WAVE Short-Message Protocol
xMIPv6 Extensible Mobile Ipv6 Simulation framework