Sie sind auf Seite 1von 116

Mobile Networks

Module E

Mobile Network Layer

J.-P. Hubaux, N. Vratonjic, M. Poturalski

http://mobnet.epfl.ch

1
Some slides addapted from Jochen H. Schiller (www.jochenschiller.de)
Outline

 Mobility in the Internet

 Routing in mobile ad hoc networks

2
Enablers of IP mobility

 Mobile end systems


Laptops
PDAs
Smart-phones
…

 Wireless technologies
Wireless LANs (IEEE 802.11)
Bluetooth (www.bluetooth.com)

 Improved batteries (longer lifetime)

3
Problem with IP mobility

IP1

mail.epfl.ch

WLAN 802.11
IP2
Need to establish a new TCP
connection, old connection broken

Assign a new IP address via DHCP

4
IP mobility and cellular networks

• Assign IP address
GPRS (or EDGE) tunnel • Tunnel IP packets
IP link • Always in the path

IP1
IP1

mail.epfl.ch
IP1
WLAN 802.11

IP2
• Assign a new IP address via DHCP

5
Courtesy E. Corthay, Swisscom
TCP/IP was not designed for mobility

 Change of IP address means disconnection of the application


 TCP interprets dropped packets (channel errors,
disconnections) as congestion
More in Module F
 Limitations due to a fundamental design problem

The IP address (network layer) has a dual role


 Network locator (topological point of attachment) for
routing purposes
 Host identifier (unique for a host and TCP/IP stack)

6
Routing in the Internet

 Routing is based on the destination IP address


Network prefix (e.g. 129.13.42) determines physical subnet

 Change of physical subnet implies change of IP address


(standard IP)
The new IP address needs to be topologically correct (belong to
the new subnet) to be routable

 Changing the IP address according to the current location


DHCP provides plug-and-play address update
Number of drawbacks:
Almost impossible to locate a mobile system; long delays for
DNS updates
TCP connections break
Security problems

7
Update routing tables?

 Quick ‘solution’
Keep IP address constant
Update routing tables to forward packets to the right location

 Not feasible
Does not scale with number of mobile hosts and frequent
changes in location
Routers are designed for fast forwarding, not fast
updates
Routers have limited memory (cannot store separate
entry for every mobile host)
Route updates consume network throughput
Security problems

8
Case-study of two solutions

 Mobile IP
Support mobility transparently to TCP and applications
Rely on existing protocols

 Host Identity Protocol (HIP)


A new layer between IP and transport layers
Architectural change to TCP/IP structure

9
Mobile IP
Requirements to Mobile IP
 Transparency
Mobile end-systems (hosts) keep their IP address
Maintain communication in spite of link breakage
Enable change of point of connection to the fixed network
 Compatibility
Support the same Layer 2 protocols as IP
No changes to current end-systems and routers
Mobile end-systems can communicate with fixed systems
 Security
Authentication of all registration messages
 Efficiency and scalability
Only little additional messages to the mobile system required
(connection may be over a low-bandwidth radio link)
World-wide support of a large number of mobile systems

11
Terminology
 Mobile Node (MN)
 Entity (node) that can change its point of connection
to the network without changing its IP address
 Home Agent (HA)
 Entity in the home network of the MN, typically a router
 Registers the MN location, encapsulates and tunnels IP packets to the COA
 Foreign Agent (FA)
 System in the current foreign network of the MN, typically a router
 Decapsulates and forwards the tunneled packets to the MN
 Care-of Address (COA)
 Address of the current tunnel end-point for the MN
Foreign Agent COA or
Co-located COA (no FA, MN performs decapsulation)
 Actual location of the MN from an IP point of view
 Co-located COA typically acquired via DHCP
 Correspondent Node (CN)
 Communication partner

12
Data transfer to the mobile node:

HA
2
MN

home network 3 receiver


Internet

FA foreign
network

1. Sender sends to the IP address of MN,


HA intercepts packet (proxy ARP)
1 2. HA tunnels packet to COA, here FA,
CN
by encapsulation
3. FA forwards the packet
sender to the MN
13
Data transfer with co-located COA

HA 2
MN

Internet
home network receiver

3 foreign
network

1. Sender sends to the IP address of MN,


HA intercepts packet (proxy ARP)
1 2. HA tunnels packet to co-located COA
CN
(MN) by encapsulation
3. MN decapsulates and (internally)
sender delivers packet to home address
14
Data transfer from the mobile node

HA
4 MN

home network sender


Internet

FA foreign
network

4. Sender sends to the IP address


of the receiver as usual,
CN
FA works as default router

receiver
15
Mobile IP mechanisms

 Agent Discovery
MN discovers its location (home network, foreign network)
MN learns a COA

 Registration
MN securely signals the COA to the HA (via the FA)

 Tunneling
MN encapsulates IP packets from CN and sends them to the
COA
FA (or MN) decapsulates these packets and sends them to
the MN

16
Agent discovery

 Agent Advertisement
HA and FA periodically send advertisement messages into their
physical subnets
MN listens to these messages and detects, if it is in the home or a
foreign network (standard case for home network)
MN reads a COA from the FA advertisement messages
 Agent Solicitation
MN can request an Agent Advertisement message with a Agent
Solicatation message
Helps decrease disconnection time
 Simple extension of ICMP Router Discovery (RFC 1256)

 Other mechanisms can be used to discover the network


and the COA (e.g. DHCP)
17
Agent advertisement

0 7 8 15 16 23 24 31
type code checksum
#addresses addr. size lifetime
router address 1
RFC 1256 preference level 1
router address 2
preference level 2
...
type = 16
length = 6 + 4 * #COAs type = 16 length sequence number
R: registration required registration lifetime R B H F M G r T reserved
B: busy, no more registrations COA 1
H: home agent COA 2
F: foreign agent ...
M: minimal encapsulation
G: GRE encapsulation
r: =0, ignored (former Van Jacobson compression)
T: FA supports reverse tunneling
reserved: =0, ignored

18
Registration

Mobility Binding Home address COA Registration lifetime

Note: with co-located COA, MN sends


registation request directly to HA

Foreign 2. Registration request Home


Agent Agent
4. Registration reply
3. If OK, sets up the binding

1. Registration
5. Registration reply Note: HA can allow for multiple
request
simultanous mobilty bindings.
In that case, a packet from CN is
forwarded to all active COAs
Mobile Node
(COA)
19
Mobile IP registration request

0 7 8 15 16 23 24 31
type = 1 S B DMG r T x lifetime
home address
home agent
UDP
COA
message
identification

extensions . . .

S: simultaneous bindings identification:


B: broadcast datagrams generated by MN, used for matching requests with
D: decapsulation by MN replies and preventing replay attacks (must contain
M: mininal encapsulation a timestame and/or a nonce)
G: GRE encapsulation
r: =0, ignored extensions:
T: reverse tunneling requested mobile-home authentication extension (mandatory)
x: =0, ignored mobile-foreign authentication extension (optional)
foreign-home authentication extension (optional)
20
Mobile IP registration reply
0 7 8 15 16 31
type = 3 code lifetime
home address
UDP
home agent
message
identification
Example codes: extensions . . .
registration successful
0 registration accepted
1 registration accepted, but simultaneous mobility bindings unsupported
registration denied by FA
65 administratively prohibited
66 insufficient resources
67 mobile node failed authentication
68 home agent failed authentication
69 requested Lifetime too long
registration denied by HA
129 administratively prohibited
131 mobile node failed authentication
133 registration Identification mismatch
135 too many simultaneous mobility bindings

21
Security associations and registration keys
Foreign Home
Agent Agent

Mobile Node

 Usually, there is a security association (SA) between the home agent


(HA) and the mobile node (MN)
 Possible techniques to establish a registration key between the mobile
node and the foreign agent (FA):
 Make use of Internet Key Exchange (IKE), if available
 If HA and FA share a SA, the HA can provide the registration
 Make use of the public key of the FA or of the MN
 Diffie-Hellman key exchange protocol between FA and MN

22
Tunneling
Correspondent
Node Src Dest Payload
CN MN abcdefghij
1
Binding

Foreign 2
Home
Agent Agent
Src Dest Src Dest Payload
HA COA CN MN abcdefghij

Encapsulated datagram
3
Src Dest Payload
CN MN abcdefghij

Mobile Node
23
IP-in-IP encapsulation

 IP-in-IP-encapsulation (mandatory, RFC 2003)

ver. IHL DS (TOS) length


IP identification flags fragment offset
TTL IP-in-IP IP checksum
IP address of HA
Care-of address COA
ver. IHL DS (TOS) length
IP identification flags fragment offset
TTL lay. 4 prot. IP checksum
IP address of CN
IP address of MN
TCP/UDP/ ... payload

24
Minimal encapsulation

 Minimal encapsulation (optional)


avoids repetition of identical fields
e.g. TTL, IHL, version, DS (RFC 2474, old: TOS)
only applicable for non fragmented packets, no space left for
fragment identification
ver. IHL DS (TOS) length
IP identification flags fragment offset
TTL min. encap. IP checksum
IP address of HA
care-of address COA
lay. 4 protoc. S reserved IP checksum
IP address of MN
original sender IP address (if S=1)
TCP/UDP/ ... payload

25
Generic Routing Encapsulation
original
original data
header

GRE original
outer header original data
header header

RFC 1701 new header new data

ver. IHL DS (TOS) length


IP identification flags fragment offset
TTL GRE IP checksum
IP address of HA RFC 2784 (updated by 2890)
Care-of address COA
C R K S s rec. rsv. ver. protocol C reserved0 ver. protocol
checksum (optional) offset (optional) checksum (optional) reserved1 (=0)
key (optional)
sequence number (optional)
routing (optional)
ver. IHL DS (TOS) length
IP identification flags fragment offset
TTL lay. 4 prot. IP checksum
IP address of CN
IP address of MN

TCP/UDP/ ... payload

26
“Triangle” routing

Correspondent
Node

Home
Agent

Mobile
Node Foreign
Agent

 Drawbacks
Inefficiency
MN sends IP packets with topologically incorrect source
For security reasons, router can be configured to drop
topologically incorrect packets (ingress filtering) 27
Route Optimization in Mobile IP

 Route optimization
HA provides the CN with the current location of MN (FA)
CN sends tunneled traffic directly to FA
 Optimization of FA handover
Packets on-the-fly during FA change can be lost
New FA informs old FA to avoid packet loss, old FA now
forwards remaining packets to new FA
This information also enables the old FA to release
resources for the MN
 Extension: not part of the core Mobile IP (RFC 3344)
Violates compatibility (CN needs to be Mobile-IP-aware)
Security problems
28
Route and FA handover optimizations

CN HA FA FAnew MN
Request
Update
ACK
Data
Data
MN changes
location
Registration
Update
ACK
Data
Data Data
Warning
Request
Update
ACK
Data
Data
t
29
Reverse tunneling

HA
2
MN

home network sender


1
Internet

FA foreign
network

1. MN sends to FA
3 2. FA tunnels packets to HA
CN by encapsulation
3. HA forwards the packet to the
receiver receiver (standard case)
30
Mobile IP with reverse tunneling

 Reverse tunneling solves ingress filtering problem


A packet from the MN encapsulated by the FA is now topological
correct
Can cope with mobile routers
Protects MN location privacy
Multicast and TTL problems solved
 Reverse tunneling does not solve
Optimization of data paths
Double triangular routing
Problems with firewalls
The reverse tunnel can be abused to circumvent security
mechanisms (tunnel hijacking)

31
Firewalls
Correspondent Filtering of incoming packets:
Domain Discard packets that seem to emanate
from an address internal to the domain
Correspondent (even if they are tunneled)
Node

FW
Home Domain
Global FW
Internet Home
Agent

FW
Foreign
Domain
Filtering of outgoing packets: discard packets that seem
Foreign to emanate from an address external to the domain
Agent (even if they are tunneled)

Possible solutions:
Mobile • Manual configuration
Node • Isolation of Mobile Nodes 32
(pockets)
Mobile IP and IPsec

 Security in Mobile IP
Authentication in registration messages
No protection of data transmission (tunneling)

 IPsec provides general IP layer security


Can be used to protect data transmission
Can also be used in addition/in place of default registration
messages authentication

33
IPsec: Brief reminder

Application Application

TCP or UDP TCP or UDP


Security Association

IP IP IP

Data link Data link Data link Data link

IPsec Router
mechanisms

 Provides confidentiality, authentication and integrity


 IPsec support is optional in IPv4, mandatory in IPv6
 Security Association (SA) consists of a suite of
cryprographic algorithms and keys
Security Parameter Index (SPI) is used for indexing SAs 34
IPsec: Authentication Header

Input IP packet:
... src IP dst IP payload - authenticated
with auth
IP header
AH transport mode:
src IP dst IP ... SPI seq auth payload
IP header AH
AH tunnel mode:
src IP’ dst IP’ ... SPI seq auth IP header payload

new IP header AH input IP packet

 Provides authentication and integrity


 Cannot traverse NATs
IP addresses authenticated 35
IPsec: Encapsulating Security Payload

Input IP packet: - encrypted


... src IP dst IP payload
IP header - authenticated
with auth
ESP transport mode:
... src IP dst IP SPI seq payload auth
IP header ESP
ESP tunnel mode:
... src IP’ dst IP’ SPI seq input IP packet auth
IP header ESP

 Provides confidentiality, authentication and integrity


 Outer IP header not authenticated
36
Mobile IPv6

 Mobile IPv6 introduces several modifications based


on new IPv6 functionality and experiences with
Mobile IPv4
No FA, COA is always co-located
Two modes of operation:
Bidirectional tunnel (between HA and COA)
Route optimization (MN informs CN about the COA)
Security integrated with IPsec (mandatory support in IPv6)
“Soft“ hand-over, i.e. without packet loss, between two
subnets is supported
MN sends the new COA to its old router
The old router encapsulates all incoming packets for the
MN and forwards them to the new COA

37
IP Micro-mobility support

 Micro-mobility support:
Efficient local handover inside a foreign domain
without involving a home agent
Reduces control traffic on backbone
Especially needed in case of route optimization

 Example:
Hierarchical Mobile IP (HMIP)

 Important criteria:
Security Efficiency, Scalability, Transparency,
Manageability
38
Hierarchical Mobile IPv6

 Operation:
Network contains mobility anchor point (MAP)
mapping of regional COA (RCOA) to link COA
(LCOA)
Internet
Upon handover, MN informs HA
MAP only
gets new LCOA, keeps RCOA RCOA
HA is only contacted if MAP MAP
changes

binding AR AR
 Security provisions:
update
No HMIP-specific
security provisions LCOAnew LCOAold
Binding updates should be MN MN
authenticated
39
Hierarchical Mobile IP: Security

 Advantages:
Local COAs can be hidden,
which provides at least some location privacy
Direct routing between CNs sharing the same link is
possible (but might be dangerous)
 Potential problems:
Decentralized security-critical functionality
(handover processing) in mobility anchor points
MNs can (must!) directly influence routing entries via binding
updates (authentication necessary)

40
Hierarchical Mobile IP: Other issues

 Advantages:
Handover requires minimum number
of overall changes to routing tables
Integration with firewalls / private address support possible
 Potential problems:
Not transparent to MNs
Handover efficiency in wireless mobile scenarios:
Complex MN operations
All routing reconfiguration messages
sent over wireless link

41
Mobile IP summary

 A mobile network layer compatible with the current


deployed Internet protocol stack
 Issues with Mobile IP
Security
Authentication with FA problematic, for the FA typically
belongs to another organization
Firewalls
Typically mobile IP cannot be used together with
firewalls, special set-ups are needed
QoS
Tunneling makes it hard to give a flow of packets a
special treatment needed for the QoS

42
Host Identity Protocol (HIP)

43
Architectural background

 Two global name spaces in the current Internet:


Domain names
IP addresses
 Recall: IP addresses have a dual role
1. Identifiers
2. Locators

 Duality makes many things difficult

44
New requirements to Internet addressing

 Mobile Hosts
Need to change IP address dynamically
 Multi-interface hosts
Have multiple independent addresses

 Challenge: Mobile and multi-interface hosts


Multiple dynamically changing addresses

45
HIP: A new global Internet name space

 Decouples the name and locator roles of IP


addresses
 Architectural change to TCP/IP structure
 A new layer between IP and transport layers
 Introduces cryptographic Host Identifiers
 Integrates security, mobility and multi-homing
Opportunistic host-to-host IPsec ESP
End-host mobility, across IPv4 and IPv6
End-host multi-address multi-homing, IPv4/v6
 IPv4/v6 interoperability for applications

46
HIP: A new layer

Process

<IP addr, port>  Sockets bound to Host


Transport
<Host ID, port> Identities (HIs), not to IP
addresses
Host Identity Host ID

IP layer IP address

Link Layer
47
HIP bindings

48
HIP overview

 HIP identifiers
 Establishing a shared context between two host
HIP base exchange
 Data communication
By default protected with IPsec ESP
 Mobility during data communication
HIP locator update
 Finding a host
HIP DNS extensions
HIP Rendezvous extension
 Multihoming
49
HIP identifiers

 Host Identifiers (HIs)


A host holds a key pair (private and public key)
Host Identifier (HI) = public key
 HI representation: Host Identity Tag (HIT)
HIT = h(HI) (h – cryptographic hash function, 128bits)
Advantages:
Fixed length makes for easier protocol coding and better
manages the packet size cost
Independent of cryptographic protocols used for public
private keys
Collision probability (birthday paradox)
With 1012 hosts P(collision) < 1.5·10-15

50
HIP base exchange
Initiator (I) Responder (R)
I1: IPI, IPR, HITI, HITR
R1: IPI, IPR, HITI, HITR, DHR, HIR, sig, ESPtransform, puzzle
I2: IPI, IPR, HITI, HITR, DHI, HII, sig, ESPtransform, ESPinfo, solution
R2: IPI, IPR, HITI, HITR, sig, ESPinfo

 Establishes HIP association (addressing part)


HII ↔ IPI ↔ IPR ↔ HIR
 Used by the HIP layer to map between HIs and IPs

51
HIP base exchange
Initiator (I) Responder (R)
I1: IPI, IPR, HITI, HITR
R1: IPI, IPR, HITI, HITR, DHR, HIR, sig, ESPtransform, puzzle
I2: IPI, IPR, HITI, HITR, DHI, HII, sig, ESPtransform, ESPinfo, solution
R2: IPI, IPR, HITI, HITR, sig, ESPinfo

DHI/R – Diffie-Hellman key material


sig – signature generated with private key of HII/R
 Diffie-Hellman generates a shared secret
 Signatures
protect message integrity
prove that hosts possess private keys corresponding to their
declared HIs 52
HIP base exchange
Initiator (I) Responder (R)
I1: IPI, IPR, HITI, HITR
R1: IPI, IPR, HITI, HITR, DHR, HIR, sig, ESPtransform, puzzle
I2: IPI, IPR, HITI, HITR, DHI, HII, sig, ESPtransform, ESPinfo, solution
R2: IPI, IPR, HITI, HITR, sig, ESPinfo

ESPtransform – supported cryptographic suites


ESPinfo – contains the Security Parameter Index (SPI)
 ESP keys are generated from the Diffie-Hellman secret
 Full HIP association (basic case):

SPIIR SPIIR
HII IPI IPR HIR
SPIRI SPIRI
53
HIP base exchange
Initiator (I) Responder (R)
I1: IPI, IPR, HITI, HITR
R1: IPI, IPR, HITI, HITR, DHR, HIR, sig, ESPtransform, puzzle
I2: IPI, IPR, HITI, HITR, DHI, HII, sig, ESPtransform, ESPinfo, solution
R2: IPI, IPR, HITI, HITR, sig, ESPinfo

 Cryptographic puzzle mitigates DoS against R


Makes HIP base exchange more costly for I than for R
R remains stateless until correct I2 arrives
R1: R chooses puzzle from a pre-computed pool
I computes solution based on puzzle challenge and HITs
I2: R verifies solution and only then allocates state for I

54
Mobile Host
Mobility with HIP
IP Address 1

Correspondent
Host

Mobile Host UPDATE(ESP_INFO, LOCATOR, SEQ)


IP Address 2
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
UPDATE(ACK, ECHO_RESPONSE)

 LOCATOR indicates the new IP address and its lifetime


 ESP_INFO contains old and new SPIs (can be the same)
 HIP accociation is updated accordingly:
new
SPIMC SPIMC
HIM IP1 ... HIM new IP2 ...
SPICM SPICM
55
Mobile Host
Mobility with HIP
IP Address 1

Correspondent
Host

Mobile Host UPDATE(ESP_INFO, LOCATOR, SEQ)


IP Address 2
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
UPDATE(ACK, ECHO_RESPONSE)

 UPDATE is protected by HMAC and HIP_SIGNATURE


 UPDATE is explicitly acknowledged (SEQ and ACK numbers)
 ECHO_REQUEST and ECHO_RESPONSE verify that MH is
reachable at the new address
No data is sent to new IP if this verification fails
Mitigates DoS attacks against new IP
56
HIP DNS extensions

 Traditionally DNS maps domain names to IP


addresses

 HIP-enabled DNS in addition can map a domain


name to:
Host Identifier (HI)
Host Identifier Tag (HIT)
Rendezvous Server (RVS)

57
HIP and DNS: static case

DNS

FQDNSH HISH, HITSH, IPSH

I1: IPCH, IPSH, HITCH, HITSH


R1: IPCH, IPSH, HITCH, HITSH
I2: IPCH, IPSH, HITCH, HITSH
Correspondent Static
Host R2: IPCH, IPSH, HITCH, HITSH
Host
58
FQDN: Fully Qualified Domain Name
HIP and DNS: mobile case

DNS

RVS
(details in RFC 5203)
UPDATE IP
Mobile Host
FQDNMH HIMH, HITMH, IPRVS new IP address

I1: IPRVS, IPMH, HITCH, HITMH


I1: IPCH, IPRVS, HITCH, HITMH

R1: IPCH, IPMH, HITCH, HITMH


I2: IPCH, IPMH, HITCH, HITMH
Correspondent Mobile
Host R2: IPCH, IPMH, HITCH, HITMH
Host
59
FQDN: Fully Qualified Domain Name
Multihoming with HIP

 Multihoming: a host has multiple IP interfaces


Increases reliability
 HIP locator update mechanism enables multihoming
Multihomed host provides Correspondent with multiple IP
adresses (can also idicate a prefered one)
 More complex HIP associations
RFC recommends separate SPI per physical interface
SPI pairA IPA (preferred)

HI SPI pairB IPB

SPI pairC IPC


IPD 60
HIP summary

 New namespace for the Internet


between IP and domain names
 Integrates security, mobility, and multihoming
 Main disadvantage:
Requires update of the transport layer stack on all end hosts
 Transparent and scalable
 Applications for HIP
Mobile VPN user
VoIP (notably handover)
Search in peer-to-peer systems
Faster WLAN access control
Device peering
61
References

 C. Perkins. Mobility support for IPv4. RFC 3344, August 2002


 C. Perkins. IP encapsulation within IP. RFC 2003, October 1996
 C. Perkins. Minimal encapsulation within IP. RFC 2004, October 1996
 S. Hanks et al. Generic Routing Encapsulation (GRE). RFC 1701,
October 1994
 G. Montenegro. Reverse Tunneling for Mobile IP (revised). RFC 3024,
January 2001
 C. Perkins, D. Johnson. Route Optimization for Mobile IP. Cluster
Computing vol. 1, 1998
 S. Kent, R. Atkinson. IP Authentication Header (AH). RFC 2402,
November 1998
 S. Kent, R. Atkinson. IP Encapsulating Security Payload (ESP). RFC
2406, November 1998
 D. Johnson, C. Perkins. Mobility Support in IPv6. RFC 3775, June
2004

62
References

 R. Moskowitz, P. Nikander. Host Identity Protocol (HIP) Architecture.


RFC 4423, May 2006
 R. Moskowitz, P. Nikander, P. Jokela, T. Henderson. Host Identity
Protocol. RFC 5201, April 2008
 P. Jokela, R. Moskowitz, P. Nikander. Using the Encapsulating Security
Payload (ESP) Transport Format with the Host Identity Protocol (HIP) .
RFC 5202, April 2008.
 P. Nikander, T. Henderson, C. Vogt, J. Arkko. End-Host Mobility and
Multihoming with the Host Identity Protocol. RFC 5206, April 2008
 P. Nikander, J. Laganier. Host Identity Protocol (HIP) Domain Name
System (DNS) Extension. RFC 5202, April 2008
 J. Laganier, L. Eggert. Host Identity Protocol (HIP) Rendezvous
Extension. RFC 5204, April 2008
 J. Laganier, T. Koponen, L. Eggert. Host Identity Protocol (HIP)
Registration Extension. RFC 5203, April 2008

63
Routing in
mobile ad hoc networks
The classic solution for mobile networks

 Cellular networks: 2G (GSM, IS-41,…) and 3G


(UMTS,CDMA2000…), 3.5G (HSDPA, ...) deployed; 4G (LTE) soon
to be deployed
 Huge, expensive fixed infrastructure
 License for a share of the spectrum (duration 10 to 20 years)
 Operational responsibility: network operators (telcos, ISPs)
65
The new paradigm: ad hoc networks

 Terminal and node merge


 Everything is potentially mobile
 Initial applications: communication in the battlefield (Packet Radio
Networks, in the 70’s)
 The network is self-organized when it is run by the users themselves
 Similar trend at the application layer: peer-to-peer
(e.g., Napster  Gnutella)
66
Application examples of ad hoc networks

 Wireless sensor networks (WSN)


 Hybrid cellular / ad hoc networks (multi-hop cellular
networks)
 Vehicular networks
Assisted driving (adaptive cruise control,…)
Collision avoidance
Optimization of traffic flows
…
 Crisis networks (e.g., rescue operations after major
disaster)
 Military networks

67
WSN: Earthquake detection

 The occurrence of an earthquake can be detected automatically


by accelerometers.
 Earthquake speed: around 5-10km/s
 If the epicenter of an earthquake is in an unpopulated area
200km from a city center, an instantaneous detection system
can give a warning up to 30 seconds before the shockwave hits
the city.
 If a proper municipal actuation network is in place:
Sirens go off
Traffic lights go to red
Elevators open at the nearest floor
Pipeline valves are shut
 Even with a warning of a few seconds,
the effects of the earthquake can be
mitigated.
 Similar concept can be applied to
Forest fire
Landslides
Etc.
68
C.S. Raghavendra, K.M. Sivalinguam and T. Znati Editors. Wireless Sensor Networks. Springer, 2006
WSN: Cold Chain Management

 Supermarket chains need to track the storage temperature of


perishable goods in their warehouses and stores.
 Tens if not hundreds of fridges should be monitored in real-time
 Whenever the temperature of a monitored item goes above a
threshold
An alarm is raised and an attendant is warned (pager, SMS)
The refrigeration system is turned on
 History of data is kept in the system for
legal purpose

 Similar concept can be applied to


pressure and temperature monitoring in
Production chains
Containers
Pipelines
69
www.ip01.com
WSN: Home automation

 Temperature management
Monitor heating and cooling of a building in an integrated way
Temperature in different rooms is monitored centrally
A power consumption profile is to be drawn in order to save energy
in the future

 Lighting management:
Detect human presence in a
room to automatically switch
lights on and off
Responds to manual activation/
deactivation of switches
Tracks movement to anticipate
the activation of light-switches
on the path of a person

 Similar concept can be applied to


Intrusion detection

70
WSN: Precision Agriculture management

 Farming decisions depend on environmental data (typically photo-synthesis):


 Solar radiation
 Temperature
 Humidity
 Soil moisture

 These data evolve continu-


ously over time and space
 A farmer’s means of action
to influence crop yield :
 Irrigation
 Fertilization
 Pest treatment
 To be optimal, these actions
should be highly localized
(homogenous parcels can be
as small as one hectare or less)
 Environmental impact is also to be taken into account
 Salinization of soils
 Groundwater depletion
 Well contamination
71
Upper bound for the throughput of ad hoc networks

If we have:
- n identical randomly located nodes
- each capable of transmitting W bits/s
Then the throughput  ( n ) obtainable by each node
for a randomly chosen destination is
 W 
 (n )    
 n log n 

Ref: P. Gupta, P. Kumar, The Capacity of Wireless Networks


IEEE Transactions on Information Theory, March 2000
72
Intuition behind the upper bound

N nodes (users)

O(N) transmissions from left to right


over
O( N) transmission links
mean
O( 1 ) capacity per attempted transmission
N

O(N) users O(N) users Ways to improve scalability:


Cut set ~ N
• Directional antennas
• Locality of the traffic
• Hybrid system 73
Routing in ad hoc networks

 Peculiarities
Node mobility
High rate of link failure
 Traditional routing approaches are not well suited
 Assumptions
Multihop communication
Symmetric links (in most cases)
Omnidirectional antennas (in most cases)
All nodes have equal capabilities and responsibilities
 Figures of merit
Latency of route discovery
Overhead (bandwidth, energy, processing power)
Security
 Current status of research:
Many, many proposals
Optimal solution depends on deployment scenario: mobility
patterns, radio model, traffic characteristics,…
74
Brief reminder : Link-state protocols

 Example: OSPF
 May consume a lot of resources to update the routes
 Techniques to alleviate the problem: limit the
propagation of information
 Does not seem to be well suited to cope with mobility

75
Distance vector routing (1/2)
B
A B C D Distance
vector 3
A 0 1 5 ¥ 1 1
A D
B 1 0 1 3 5 7

C 5 1 0 7 C

D ¥ 3 7 0

(1 row stored in each node) Distance


1 0 1 3
vector of B
Take the min + Distance from A to B =

2 1 2 4 Cost to dest.
via B
0 1 2,B 4,B

76
Distance vector routing (2/2)

 Even if the updates are asynchronous, the routing


tables converge
 The algorithm is often called Bellman-Ford
 Problem: undesirable behaviour when links go up
and down (e.g., count to infinity problem)

77
Routing protocols for wireless ad hoc
networks

Mobile ad hoc networks Sensor networks

Response time,
Energy
bandwidth

Proactive Reactive
protocols protocols

Dynamic
Optimized Link- Ad Hoc On-Demand
Destination-Sequenced Source Geography- Cluster-based
State Routing Distance-Vector
Distance-Vector (DSDV) Routing based routing (or hierarchical)
(OLSR) (AODV)
(DSR) routing

Geodesic
packet 78
forwarding
Dynamic source routing (DSR)

 Reactive routing protocol


 2 phases, operating both on demand:
Route discovery
Used only when source S attempts to to send a packet to
destination D
Based on flooding of Route Requests (RREQ)
Route maintenance
makes S able to detect, while using a source route to D, if it
can no longer use its route (because a link along that route no
longer works)

79
DSR: Route discovery (1)

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

80
DSR: Route discovery (2)

F K
H
Q A

S E G D P
(S)
J

B M
R
I
L
C
N

81
DSR: Route discovery (3)

(S,A) K
F H
Q A

(S,E)
S E G D P
J

B M
R
I
L
C
N

82
DSR: Route discovery (4)

F K
H
Q A

S E G (S,E,G) D P
J

B M
R
I
L
C
(S,B,C) N

83
DSR: Route discovery (5)

(S,A,F,H)
F K
H
Q A

S E G (S,E,G,J)D P
J

B M
R
I
L
C
N

84
DSR: Route discovery (6)

F K
H (S,A,F,H,K)
Q A

S E G D P
J

B M
R
I
L
C
N

85
DSR: Route discovery (7)

F K
H
Q A

S E G D P
J (S,A,F,H,K,P)

B M
R
I
L
C
N

86
DSR: Route discovery (8)

F K
H
Q A

S E G D P
J RREP(S,E,G,J,D)

B M
R
I
L
C
N

87
DSR: Route Discovery (9)

 Route reply by reversing the route (as illustrated)


works only if all the links along the route are
bidirectional
 If unidirectional links are allowed, then RREP may
need a route discovery from D to S
 Note: IEEE 802.11 assumes that links are
bidirectional

88
DSR: Data delivery

F K
H
Q A

DATA(S,E,G,J,D)
S E G D P
J

B M
R
I
L
C
N

89
DSR: Route maintenance (1)

F K
H
Q A

DATA(S,E,G,J,D)
E P
X
S G D
J

B M
R
I
L
C
N

90
DSR: Route maintenance (2)

F K
H
Q A

RERR(G-J)
E P
X
S G D
J

B M
R
I
L
C
N When receiving the Route Error message (RERR),
S removes the broken link from its cache.
It then tries another route stored in its cache; if none,
91
it initializes a new route discovery
DSR: Optimization of route discovery:
route caching
 Principle: each node caches a new route it learns by
any means
 Examples
When node S finds route (S, E, G, J, D) to D, it also learns
route (S, E, G) to node G
In the same way, node E learns the route to D
Same phenomenon when transmitting route replies
 Moreover, routes can be overheard by nodes in the
neighbourhood
 However, route caching has its downside: stale
caches can severely hamper the performance of the
network

92
DSR: Strengths

 Routes are set up and maintained only between


nodes who need to communicate
 Route caching can further reduce the effort of route
discovery
 A single route discovery may provide several routes
to the destination

93
DSR: Weaknesses

 Route requests tend to flood the network and


generally reach all the nodes of the network
 Because of source routing, the packet header size
grows with the route lengh
 Risk of many collisions between route requests by
neighboring nodes  need for random delays before
forwarding RREQ
 Similar problem for the RREP (Route Reply storm
problem), in case links are not bidirectional

Note: Location-aided routing may help reducing the


number of useless control messages

94
Ad Hoc On-Demand Distance Vector
Routing (AODV)
 As it is based on source routing, DSR includes
source routes in data packet headers
 Large packet headers in DSR  risk of poor
performance if the number of hops is high
 AODV uses a route discovery mechanism similar to
DSR, but it maintains routing tables at the nodes
 AODV ages the routes and maintains a hop count
 AODV assumes that all links are bi-directional

95
AODV : Route discovery (1)

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

96
AODV : Route discovery (2)

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

: Route Request (RREQ) Note: if one of the intermediate nodes (e.g., A)


97
knows a route to D, it responds immediately to S
AODV : Route discovery (3)

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

: represents a link on the reverse path 98


AODV : Route discovery (4)

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

99
AODV : Route discovery (5)

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

100
AODV : Route discovery (6)

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

101
AODV : Route discovery (7)

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

102
AODV : Route reply and setup of the
forward path

F K
H
Q A

S E G D P
J

B M
R
I
L
C
N

: Link over which the RREP is transmitted


103
: Forward path
Route reply in AODV

 In case it knows a path more recent than the one


previously known to sender S, an intermediate node
may also send a route reply (RREP)
 The freshness of a path is assessed by means of
destination sequence numbers
 Both reverse and forward paths are purged at the
expiration of appropriately chosen timeout intervals

104
AODV : Data delivery

F K
H
Q A

Data
S E G D P
J

B M
R
I
L
C
N

The route is not included in the packet header 105


AODV : Route maintenance (1)

F K
H
Q A

Data
E P
S G
X J
D

B M
R
I
L
C
N

106
AODV : Route maintenance (2)

F K
H
Q A

RERR(G-J)
E P
S G
X J
D

B M
R
I
L
C
N

When receiving the Route Error message (RERR),


S removes the broken link from its cache.
It then initializes a new route discovery. 107
AODV: Destination sequence numbers

 If the destination responds to RREP, it places its


current sequence number in the packet
 If an intermediate node responds, it places its record
of the destination’s sequence number in the packet
 Purpose of sequence numbers:
Avoid using stale information about routes
Avoid loops (no source routing!)

108
AODV : Avoiding the usage of stale
1. S A
routing
… D
tables …
2. S A
DSN(D) = 5
DSN(D) = 5

B B

DSN(D) = 8
: Forward path D

3.
S A … 4.
S A …
RREQ DSN(D) = 5 RREP DSN(D) = 5

B B
DSN(D) = 8 DSN(D) = 8

109
D D
AODV : Avoiding loops

A B S X D

C
: Forward path

• Assume there is a route between A and D; link S-D breaks; assume A is not aware of this, e.g. because
RERR sent by S is lost
• Assume now S wants to send to D. It performs a RREQ, which can be received by A via path S-C-A
• Node A will reply since it knows a route to D via node B
• This would result in a loop (S-C-A-B-S)
• The presence of sequence numbers will let S discover that the routing information from A is outdated
• Principle: when S discovers that link S-D is broken, it increments its local value of DSN(D). In this way,
the new local value will be greater than the one stored by A.

110
AODV (unicast) : Conclusion

 Nodes maintain routing information only for routes


that are in active use
 Unused routes expire even when the topology does
not change
 Each node maintains at most one next-hop per
destination
 Many comparisons with DSR (via simulation) have
been performed  no clear conclusion so far

111
A proposal from EPFL

 Last Encounter Routing (2006)


Principle: Nodes exchange information about their previous
encounters
No explicit location service, no transmission overhead to update
the state

M. Grossglauser and M. Vetterli


Locating Mobile Nodes with EASE: Learning Efficient Routes
from Encounter Histories Alone,
IEEE/ACM Trans. on Networking, vol 14, no 3, June 2006.

112
NIC (Nokia)

 (confidential slide show)


FlashLinQ (Qualcomm)

 Vision: extend users’ sensing capabilities


 Operates in licensed spectrum
 All devices globally synchronized to a common
external timing source (e.g., GPS or cellular base
stations)
 All devices operate in OFDMA (Orthogonal
Frequency-Division Multiple Access)
Conclusion on wireless ad hoc
networks

 Extensive research activity over the last decade


 Scalability is still an open issue
 NIC and FlashLinQ show that vendors are
considering this seriously

115
References on wireless ad hoc
networks
Overview of ad hoc network routing protocols: see the references
mentioned at:
http://en.wikipedia.org/wiki/Ad_hoc_networking

Research conference: ACM MobiHoc (was at EPFL in 2002)

For NIC/AwareNet (Nokia):


https://lausanne.nokiaresearch.com/trial/

For FlashLinQ (Qualcomm):


M. Scorson et al., Toward Proximity-Aware Internetwoking,
IEEE Wireless Comm., Dec. 2010

116

Das könnte Ihnen auch gefallen