Embed Size (px)
Citation preview
Heterogenous mobility managementTaking advantages from technology diversity orToward fully networked carsSmart mobility management framework
Jean-Marie Bonnin Professor, (Institut Telecom / Telecom Bretagne / RSM)
ANR - JST workshopNovember, 19-20, 2009, Paris
IT/TB/RSM/GERME/JMB
Summary
Introduction / Context Standardization A mobility management framework Works in progress Projects
2
IT/TB/RSM/GERME/JMB
IntroductionVarious diversities
3
1.2. CONTEXT 7
Access
Networks
Network
Devices
Services /
Applications
Figure 1.4: Heterogeneity in ITS
This heterogeneity of service requirements implies a significant flexibility of the
transmission network to be used.
1.2.2 Network Heterogeneity
For a long time, ITS related works made the assumption that a universal communica-
tion technology will be used for all ITS-related usages. With the evolution of wireless
networks, researchers realized that it was illusory. If a lot of efforts have been spent on
IEEE 802.11-based standards (IEEE 802.11p [70] and M5 [30]) this type of media will
never be deployed worldwide because the current deployment costs are too high and
regulation issues too complex to fully cover all countries.
By now, there is no communication technology that fulfills all the requirements in
terms of performance, cost, response time, availability and reliability. Instead, almost
all needs can be covered using available public data networks.
Nowadays, it is expected that various technologies will coexist allowing mobile de-
vices equipped with multiple wireless communication interfaces to roam seamlessly
between multiple heterogeneous access networks.
The use of heterogeneous wireless networks such as 3G, WLANs and WWANs has
been the focus of numerous researches. These works attempt to satisfy the variety of
emerging applications that require different levels of QoS. In fact, the complementary
Internet of things
3.3. STANDARDIZATION 43
48 CHAPITRE 5. GESTION DE LA MOBILITÉ DANS LES RÉSEAUX MOBILES
déjà décrits sur les terminaux multi-interfaces. Nous montrerons en quoi ils permettent derépondre à une partie des besoins apparus lors de la définition de l’architecture de gestionde CALM. Enfin, nous présentons un certain nombre de problématiques de recherche et deperspectives ouvertes par ce nouveau domaine d’application.
5.2 Context
Lorsqu’il a été clair que les véhicules automobiles (et les autres) devaient pouvoir com-muniquer avec l’extérieur, la première approche des organismes de standardisation a étéde développer des standards spécifiques (par exemple Wave [141] / M5 [46]) ayant chacunl’ambition de devenir le standard de communication unique dans le domaine des transportsintelligents. Mais du fait d’un grand nombre d’acteurs (organismes de standardisation inter-nationaux, équipementiers, utilisateurs, organismes de régulation) et d’une grande variété debesoins, aucun standard ne s’impose. Quelles que soient les raisons administrativo-politico-économiques, il reste que les applications et les environnements sont variés et qu’il est tech-niquement très difficile de proposer une technologie de communication qui convienne à tousles usages dans tous les contextes géographiques et démographiques. Et même si un tel choixdevait être fait, comment prendre une décision qui serait nécessairement contraignante sansattendre en quelque sorte le verdict du marché.
RSE
5.8GHzDSRC
vehicle-to-vehicle *
(CALM 5 or 60 GHz)portable-to-
vehicle
RSE
RSE-to-RSE *
Hot-Spot(WiFi)
RSE
Satellite
Broadcast
GPS/GALILEO
TerrestrialBroadcast
2G/3G 2G/3GWiMAXWiMAX
CALM M5
WAVE *
RSE
CALMIR *
RSERSE
5.8GHzDSRC
vehicle-to-vehicle *
(CALM 5 or 60 GHz)portable-to-
vehicle
RSE
RSE-to-RSE *
Hot-Spot(WiFi)
RSE
Satellite
Broadcast
GPS/GALILEO
TerrestrialBroadcast
2G/3G 2G/3GWiMAXWiMAX
CALM M5
WAVE *
RSE
CALMIR *
CALM Handbook, ISO TC 204 WG16.1, December 2005
Figure 5.1 – Environnement réseau de l’architecture CALM [144]Figure 3.4: Overview of the CALM Communication Capabilities [73]
networking allowing integrating multiple access technologies through dedicated conver-
gence layers.
CALM is designed to be split in several entities in the on-board network. The
CALM Router (the MR) is responsible for interfaces management and connectivity
continuity. All other on-board equipements only have to support IPv6 networking and
implement a simple version of the CALM management plan [31] as shown in fig.3.6. It
makes it easy to integrate simple IPv6 devices as they are allowed to communicate as
if they are on the fixed Internet.
A first take of the architecture is currently being developed by the CVIS (Cooper-
ative Vehicle-to-Infrastructure Systems) European project2.
2http://www.cvisproject.org/
Operator - access network
(ISP)
- Internet
Mobility
Mobile Network
Administrator - car makers
- car owner
Users
/
Applications
Usage
Policies
IT/TB/RSM/GERME/JMB
IntroductionA scalability issue?
Yes, for adress space concerns• Number of devices
- 2.5 billions of mobile phone over the world- much more non-mobile devices
– temperature sensor, wireless tyre gauge, security camera, heart rate monitor, ...
• Number of vehicles- 600 millions of cars today, 3 billions forecast in 2050 (IMF)
Yes, for service deployability• Middle-box approaches
➡Difficult to evolve toward an open service architecture➡Need to configure all the transmission chain
(MR, HA, ISP network) for new services/applications
• Transparent seamless connectivity (network or link level)- Could be an ecosystem enabler
4
3G RAN
Multiple Simultaneous
Handovers
Each mobile
manages its
own mobility
(MIP)
Each mobile
has to reach the
infrastructure
using only its
own ressources
Spectrum and network
ressources are not used
efficiently
Each mobile has
few wireless
interfaces
Some devices
should not have
to manage
mobility
3G RAN
Each mobile does
not manage
mobility, it is just
an IP terminal
Only the router
has to reach the
infrastructure
Low power (short range)
transmission between
devices and mobile router
Each mobile
needs only one
wireless interface
Devices could
not manage
mobility
WiFi
Access
Network Router could manage
several interfaces and
performs load sharing
IT/TB/RSM/GERME/JMB
Mobility managements
Host mobility (MIP on teminal)
5
Network mobility (on a router)
IT/TB/RSM/GERME/JMB
Multihoming and NEMO
6
HA
RA
CR
RA
MR
CoA(VMN)=MNP:if(VMN)HoA(VMN)
WiFi:CoA(MR-ef1)HoA(MR-ef1)
Binding cache: HoA(MR-ef1):CoA(MR-ef1), lifetime HoA(MR-ef2):CoA(MR-ef2), lifetimePrefix Table / routing table : HoA(MR-ef1):MNP, lifetime
GPRS/3G:CoA(MR-ef2)HoA(MR-ef2)
MNP::/64MNP::1
Several interfaces: ‣ Several tunnels toward the
HA and only one prefix
‣ Allow load sharing and redundancy
‣ Require routing policy at MR and HA- HA and MR has to exchange
this routing policies➡ Flow binding, XML based
policy description
IT/TB/RSM/GERME/JMB
Summary
Introduction Standardization, an example A mobility management framework Works in progress Projects
7
IT/TB/RSM/GERME/JMB
CALM architectureISO TC204 WG16
8
Communications Access for
Land Mobiles
Source [CALM ISO 21217]
Couche réseauRoutage IPv6 et sélection du
média
Application
TCP/IP
Network
Management
Entity
(NME)
Interface
Management
Entity
(IME)
CALM
Management
Entity
(CME)
CALM
media2
Autres
Médias
FAST ITSApplications
Pla
n d
e g
estion
Média
GP
RS
Média
ED
GE
CALM
media2
Média
WiM
AX
Média
UM
TS
CALM
media2
Média
M5
Média
WiF
i
2G 3G WLAN
CALM FASTGéocasting
CA
LM
FA
ST
Managm
ent
IPv6MIPv6NEMO(FMIPv6)
IT/TB/RSM/GERME/JMB
CALM Implementations
9
(a) Standalone (b) CALM on-board unit and CALM enabled device
(c) A full CALM implementation, with isolated OEM network
CALM RoutingIPV6
Internet
Application
NME
IME
CME
IVN
Socket
TCP/UDP
Traffic Mgt
Socket
UDP
CALM RoutingIPv6, NEMO, MCoA
NME
IME
CME
IVNCALM
M5 GPS
Convergence
Antenna Pod
CALM RoutingIPv6, NEMO, MCoA
NME
IME
CME
IVN
Antenna Pod
GPRS
Convergence
DSRC
Convergence
CALM
Routing
Internet
Application
NME
IME
CME
IVN
Socket
TCP/UDP
IVN IVN
Firewall
Sensors
IVNIVN
In-Vehicle
ApplicationSensor
Display/Calculator
OEMCALM
IW
Directory
Services
OEM NetworkIn-Vehicle CALM Network
Backseat screen
CALM MR
Navigation System
Supplementary CALM MR
CALM RoutingNEMO, MCoA, IPv6
NME
IME
CME
IVNCALM
M5 GPS
Convergence
Antenna Pod
CALM MR
CALM Routing
IPv6
Internet
Application
NME
IME
CME
In-Vehicle Network
Socket
TCP/UDP
Traffic Mgt
Socket
UDP
Navigation System
CALM RoutingNEMO, MCoA, IPv6
NME
IME
CME
CALM MR
In-Vehicle CALM Network
IVN M5GPRS DSRC GPS
Convergence Convergence Convergence
Antenna Pod
IT/TB/RSM/GERME/JMB
What is missing in CALM? Route optimization QoS (planed for next CALM specifications) Specialized interface management➡ Modification of the CALM architecture to
introduce CALM FAST Multiple MR management • Connectivity maintenance and distributed
flow binding decision Distributed/Centralized ressource allocation• Fully centralized architecture a good solution?• What about nested network?
Support for adaptive applications
10
82CHAPTER 6. ENVIRONMENT MONITORING & CONTEXT
MANAGEMENT
GPS
GPS
GPS
GPS
Figure 6.3: Sensor Hot Plugging in Multiple MR and Nested NEMO Scenarios
6.6 Context Management Systems
In the current implementation, the sensors needed to retrieve the information are eitherinstalled on the MR or easily accessible through scripting. this can be a hurdle for morecomplex cases involving hot sensor plugging capabilities such as Multiple MR or NestedNEMO (see fig.6.3 ).
Another more developed approach, consists in using the sensors installed on theMNNs. When a new MNN connects to the mobile network, it declares its capabilitiesto the MR which can use it either to complete missing context information or toconsolidate an already established context (sensor redundancy).
Of course, there should be mechanisms to manage the freshness of the informationand its quality (i.e., accuracy of the sensors). In addition, there should be filtering andtriggering mechanisms responsible of alerting the decision process only if “significant”changes occur.
All these mechanisms are inherent in many CMS available in literature. By def-inition, CMS are responsible for exchanging, maintaining and processing contextualinformation. They are used in many domains spanning from healthcare monitoring tohome automation and it is interesting to apply them to the mobility context manage-ment.
Other aspects of the framework can also profit from a CMS. For example, the processof flow declaration and application adaptability through the applications policy. The
82CHAPTER 6. ENVIRONMENT MONITORING & CONTEXT
MANAGEMENT
GPS
GPS
GPS
GPS
Figure 6.3: Sensor Hot Plugging in Multiple MR and Nested NEMO Scenarios
6.6 Context Management Systems
In the current implementation, the sensors needed to retrieve the information are eitherinstalled on the MR or easily accessible through scripting. this can be a hurdle for morecomplex cases involving hot sensor plugging capabilities such as Multiple MR or NestedNEMO (see fig.6.3 ).
Another more developed approach, consists in using the sensors installed on theMNNs. When a new MNN connects to the mobile network, it declares its capabilitiesto the MR which can use it either to complete missing context information or toconsolidate an already established context (sensor redundancy).
Of course, there should be mechanisms to manage the freshness of the informationand its quality (i.e., accuracy of the sensors). In addition, there should be filtering andtriggering mechanisms responsible of alerting the decision process only if “significant”changes occur.
All these mechanisms are inherent in many CMS available in literature. By def-inition, CMS are responsible for exchanging, maintaining and processing contextualinformation. They are used in many domains spanning from healthcare monitoring tohome automation and it is interesting to apply them to the mobility context manage-ment.
Other aspects of the framework can also profit from a CMS. For example, the processof flow declaration and application adaptability through the applications policy. The
66
CHAPTER 4. RECOMMENDED FEATURE SET FOR A MOBILITYMANAGEMENT FRAMEWORK
AdaptiveMobility-AwareApplications
Declarative Mobility-Aware
ApplicationsSynchronous
Adaptive & Declarative Mobility-Aware Applications
Adaptive & Declarative Mobility-Aware Applications
Figure 4.3: Classification of Mobility Aware Applications
the framework. The framework keeps a state for each SRADA. It receives the requests
separately, treats them differently depending on high level parameters and sends back
a custom response to each application.
In real systems, different kinds of MAwAs will co-exist with unaware appli-
cations. This could lead to several fairness issues that have to be dealt with. Traffic
shaping mechanisms have to be set to prevent standard applications to consume the
bandwidth freed by adaptive applications.
In NEMO based systems, applications are on the MR and applications are
on MNNs. This outlines the need for communication protocols between these devices.
CALM foresees such interactions between application and a management plan, which
has to be present in MNNs and in MRs. In [7] we show that a simple middle-ware
present in MNNs can free applications from implementing complex adaptation policies
while allowing advanced management of mobile network resources. This behavior will
be detailed in 9.4.
4.7 Context Awareness & Context ManagementSystems
Context monitoring modules are necessary to conceive an intelligent mobility frame-
work with high level policy support. The sensing features allow the framework to be
aware of the environment. Up-to-date context information makes it more reactive and
allows it to provide more accurate decisions.
An essential information to be monitored is the list of available wireless
networks. A knowledge of the surrounding networks is mandatory to select the best
network. Obtaining this list is not easy in the current state of ICT. In 802.11 for ex-
ample, the scan mode interrupts the communication and cannot be used too frequently
IT/TB/RSM/GERME/JMB
Summary
Introduction / Context Standardization A mobility management framework Works in progress Projects
11
IT/TB/RSM/GERME/JMB
Toward a mobility management framework
12
Mobility Framework
AdministratorEnd User
Applications
Decision
3rd Party (Operator
or Car Manufacturer)
Flow Routing PolicyInterface ManagementPolicy
Application AdaptationPolicy
Enforcement
Flow Declaration
Context
Management
System
EventHigh-level Policy
Enforcement Rule
IT/TB/RSM/GERME/JMB
Decision mechanism
13
Policy Management
MonitoringDecision
Operator Mobility Framework Administrator
End User
Applications
ContextManagement
System NetworkMonitor
Interface <=> Networkmapping
EnvironmentMonitor
Interface Management
Event
Network Database
Network <=> Flowmapping
High-level Policy
Enforcement Rule
2. Decision Algorithm
Flow Database
Policy Matrix
1. Score Computation
Graph of Solutions
Best Solution
Flow <=> Flow Modemapping
Enforcement _
Flow Monitor
Fast Recovery Solutions
Flow Routing Application
Adaptation
IT/TB/RSM/GERME/JMB
Implantations
14
5.3. MODULE DEPLOYMENT VIEW 75
Mobile Node
Mobile Node
Home Agent
Correspondant Node
Tunnel 1 Tunnel 2 Tunnel 3
Correspondant Node
Home Agent
Da
taD
ata
Applications
Operator
End User
Policy Management
Applications
End User
Monitoring
Decision
Mobility Framework Administrator
Interface Management
Flow Routing
Application Adaptation
Routing
Routing
Mobile IPv6 - MCoA
Mobile IPv6 - MCoAMobile Router
Mobile Network
Node
Mobile Network Node
Mobile Router
Home Agent
Correspondant Node
Tunnel 1 Tunnel 2 Tunnel 3
Correspondant Node
Home Agent
Da
taD
ata
Applications
Operator
End User
Policy Management
Applications
End User
Monitoring
Decision
Mobility Framework Administrator
Interface Management
Flow Routing
Application Adaptation
Routing
Routing
NEMO - MCoA
NEMO - MCoA
Figure 5.2: SmartMob6 Deployed in a Mobile IPv6 Architecture and in a NEMO
Architecture
In the case of a NEMO deployment, the policy management, and the decision are
mainly implemented in the MR. the MR is the only device in direct contact with
access network, thus, it is the only device able to sense and react to mobility. In 9.4,
we explore alternatives where decision is distributed between the MR and the MNNs.
Context sensing is concentrated in the MR but as explained in chapter 6, it can
be part of a larger system when context is managed between MNNs with, eventually,
sensor hot plugging capabilities.
The tunnel establishment and flow routing can be implemented using MCOA de-
scribed in 2.5.5. It allows to dispatch the flows on the different tunnels according to
the best solution given by the decision algorithms.
In the figure, applications are installed on the MNNs, however, nothing prevents
from having applications on the MR.
The case of a Mobile IPv6 deployment is simpler as all the modules of the MNNs
and the MR are both implemented into the MN as shown in fig. 5.2.
In a Terminal
5.3. MODULE DEPLOYMENT VIEW 75
Mobile Node
Mobile Node
Home Agent
Correspondant Node
Tunnel 1 Tunnel 2 Tunnel 3
Correspondant Node
Home Agent
Da
taD
ata
Applications
Operator
End User
Policy Management
Applications
End User
Monitoring
Decision
Mobility Framework Administrator
Interface Management
Flow Routing
Application Adaptation
Routing
Routing
Mobile IPv6 - MCoA
Mobile IPv6 - MCoAMobile Router
Mobile Network
Node
Mobile Network Node
Mobile Router
Home Agent
Correspondant Node
Tunnel 1 Tunnel 2 Tunnel 3
Correspondant Node
Home Agent
Da
taD
ata
Applications
Operator
End User
Policy Management
Applications
End User
Monitoring
Decision
Mobility Framework Administrator
Interface Management
Flow Routing
Application Adaptation
Routing
Routing
NEMO - MCoA
NEMO - MCoA
Figure 5.2: SmartMob6 Deployed in a Mobile IPv6 Architecture and in a NEMO
Architecture
In the case of a NEMO deployment, the policy management, and the decision are
mainly implemented in the MR. the MR is the only device in direct contact with
access network, thus, it is the only device able to sense and react to mobility. In 9.4,
we explore alternatives where decision is distributed between the MR and the MNNs.
Context sensing is concentrated in the MR but as explained in chapter 6, it can
be part of a larger system when context is managed between MNNs with, eventually,
sensor hot plugging capabilities.
The tunnel establishment and flow routing can be implemented using MCOA de-
scribed in 2.5.5. It allows to dispatch the flows on the different tunnels according to
the best solution given by the decision algorithms.
In the figure, applications are installed on the MNNs, however, nothing prevents
from having applications on the MR.
The case of a Mobile IPv6 deployment is simpler as all the modules of the MNNs
and the MR are both implemented into the MN as shown in fig. 5.2.
In a Mobile Router
IT/TB/RSM/GERME/JMB
Summary
Introduction / Context Standardization A mobility management framework Works in progress, and possible collaborations Projects
15
IT/TB/RSM/GERME/JMB
Open problems related to our workAnd possible collaborations
16
Home
Network 3
Internet
Home
Network 1
Home
Network 2
?
Home
Network 3
??
Route optimization and NEMO• Addressing• Geocasting and Vanet• Multihoming issue
- routing decision
• Nested NEMO as Mesh network
NEMO and MANET• Energie efficiency concern• Electromagnetic pollution reduction• Adhoc network vs. nested NEMO
IT/TB/RSM/GERME/JMB
Evolve our Smart Mobility management
Link with CMS (Context Management System)
Link with link level mechanisms• eg. MIH (IEEE 802.21)
Use other multihoming support • End to end multihoming (shim6)
Tools • We develop a simulation/emulation
environment
17
130 CHAPTER 10. EVALUATION
Figure 10.3: NetPyLab Screenshot
OpenGL Graphical User Interface
One of the most exciting features of NetPyLab is its graphical user interface (GUI). It
is also written in Python/OpenGL using the pyglet library. The GUI allows the user
to follow the movement of the nodes and see when an interface connects to an access
point, for example (see fig.10.3).
The GUI is very useful to help preparing and debugging simulation scripts. But, it
can also be used in demonstrations or as a learning tool.
Within the simulation scripts, the user can specify the different widgets that he
wants to be displayed on the GUI during the experimentation. These widgets can be
a simple interface status or even a real-time plot for any of the monitored parameters.
These instructions are simply ignored when NetPyLab is launched in command-line
mode.
Map Management
NetPyLab displays street maps behind the simulated items. The map images are
streamed in real-time from the OpenStreetMap servers. A cache system allows to keep
these images in the local hard drive to reuse them during the following simulation runs.
134 CHAPTER 10. EVALUATION
0
50
100
150
200
250
300
0 100 200 300 400 500 600
0
50
100
150
200
250
300
0 100 200 300 400 500 600
AP 1 AP 2 AP 13G 3G
Email retrievaldelayed
Reduced streaming bitrate
Normal streaming bitrate
Streaming
(a)
(b)
time (s)
thro
ug
hp
ut
(Kb
ps)
Email retrieval
Figure 10.5: Scenario 1: Adaptive versus Static Application Management
0
50
100
150
200
250
0 20 40 60 80 100
AP 1 AP 2 AP 13G 3G
Streaming
WiFi interface is deactivated during high mobility
Email retrieval
time (s)
thro
ughput (K
bps)
Figure 10.6: Scenario 2: Effect of the Node Velocity on the Decision
IT/TB/RSM/GERME/JMB
Summary
Introduction / Context Standardization A mobility management framework Work in progress Projects
18
IT/TB/RSM/GERME/JMB
Research projectsduring 5 last years
2 European projects • ANEMONE (STREP 27 months)• CVIS (IP 36 months)
3 French ANR projects• Cyberté (RNRT), TrainIPSat (Predit)• REMORA (ANR/RNRT)
4 Regional projects• Labo4G (laboratory)• LoCoSS (PRIR), Moshi (PhD)• LocoMotive (I&R PME), NextTv4All (I&R), IPExtrem (Mer)
3 Projets with private companies • UBIQUE (CRE FT R&D), 6ComMob (SFR), • WiFi - WiMAX (CRE FT R&D)
1 project with ADEME
19
Questions or comments ?
