Wireless Networks III: advanced conceptskom.aau.dk/~hps/Courses/Fall06/WNIII/Fall06_MM1_mobility.pdf · Wireless Networks III: advanced concepts ... TCP, UDP, RTP/UDP Application

Page 1 Hans Peter SchwefelWireless Networks III, Fall 2006: MM1, IP Mobility Support

Wireless Networks III: advanced conceptsHans-Peter Schwefel, Joao Figueiras, and Tatiana K. Madsen

[email protected]

http://www.kom.auc.dk/~hps

• Mm1 IP Mobility Support (HPS)

• Mm2 IP-based Multimedia Subsystem (hps)

• Mm3 tbd (maybe wireless applications and cross-layer aspects??)

• Mm4 Localisation & location-based services (jf)

• Mm5 Advanced ad-hoc networking (tkm)

Note: Slide-set contains more material than covered in the lecture!


Extended layered communication model• Ultimate goal of (wireless)

service provisioning: user satisfaction

• Focus in this course: network aspects, i.e. Layers 2-5

Functionalities, that are difficult to assign to single layers:

• Mobility support• Quality of service support• Security (authentication, etc.)• Dependability/Resilience... More later in this session/course[see also WNII]

L3: Network Layer: IP

L2: MAC/LLC

L4: Transport: TCP, UDP, RTP/UDP

Application

(L5) Session Control, e.g. SIP

Middleware

User Interface

User

L1: PHYS

User Environment

Netw

ork QoS

Application Q

oS

User perceived Q

oS


Content 1. Background • Mobility & Handover Types

2. Link-Layer Hand-over• Example: WLAN 802.11

3. Network Layer Mobility Support: MIP• Motivation, Principles, Messages• Performance Enhancements: HMIP• MIPv6

4. Higher-Layer Mobility Support• Transport Layer Mobility, e.g. mobile SCTP• Host Identity Protocol, HIP

5. Additional Hand-over aspects• Multi-homing & flow mobility

• Reminder: Mobility in GPRS/UMTS

• TCP in hand-over situations

6. Summary & Outlook

Appendix: Experimental Measurements

Goal: Make students familiar with • underlying problems• solution approaches • Overview on key technologiesrequired to support mobility in IP-

based networks


Background II: Mobility types

Assumption in this lecture: Infrastructure networks (only first hop wireless)

Different Levels of Mobility:• Pico (e.g. within same radio cell)• Micro (e.g. within same subnet)• Macro (e.g. across subnets but within same administrative domain)• Global (e.g. across different administrative domains)

D Internet

GPRS

NetworkCellular access(GPRS)

RouterSwitchWLAN AP

WLAN AP

WLAN AP

WLAN AP

Router

Router

Router

Router

’Alternative’ classification:

• vertical mobility: changing access technology

Mobile Host


Background III: Handover & more mobility typesHand-over classification:• Mobile initiated or network-initiated• Backward or forward• mobile controlled or network controlled• Mobile-assisted or network assisted or unassisted• Proactive or reactive• Make-before-break or break-before make• Soft or hard• fast (without ‚noticable‘ delay)• smooth (no loss of data) • seamless = fast + smooth

More mobility types ...• Host Mobility • User Mobility • Application Mobility• Network Mobility

... and related identifiers• IP address, hostname (DNS)• User-name (e.g. SIP URL)• ---• address prefix / subnetmask






5. Hand-over extensions• Multi-homing & flow mobility






Link-Layer Hand-over: Measurements 802.11b

Scenario• Hard Handover in 802.11b• Both APs use same SSID • HO initiated by pulling cable

from AP1 (’Istanbul’)

Source: Master Thesis, Rui Martins


Measurements II: Hard Hand-over


Measurements III: Soft Hand-over Scenario


Measurements IV: Soft Handover Results











Revision (for some of you...)


Problem: IP address identifies host as well as topological locationReason: IP Routing:

– Routes selected based on IP destination address– network prefix (e.g. 129.13.42) determines physical subnet– change of physical subnet change of IP address to have a topological correct address

• Solution? Host-based routing: Specific routes to each host– Handover change of all routing table entries in each (!) router– Scalability & performance problem

• Solution? Obtain new IP-address at hand-over– Problem: how to identify host after handover? DNS update performance/scalability problem– Higher protocol layers (TCP/UDP/application) need to ‘handle’ changing IP address

Development of mobile IP

Mobile IP Motivation: Host mobility & Routing

Subnet A

Subnet BIP networkMobile Node


Mobile IP: Requirements (RFC 3344)• Transparency

– mobile end-systems keep their IP address– point of attachment to the fixed network can be changed– continuation of communication after handover possible (transparent to

transport layer in mobile node as well as to correspondent node)• Compatibility

– support of the same layer 2 protocols as IP– no changes to correspondent nodes and routers required

• Security– authentication of all registration messages

• Efficiency and scalability– only small data volume for additional messages to/from the mobile node

(connection typically via a low bandwidth radio link)– world-wide support of a large number of mobile nodes (via the whole Internet)


Mobile IP: Principles & Terminology

Underlying Approach: separate host identifier and location identifier maintain multiple IP addresses for mobile host

Terminology:• Mobile Node (MN) with fixed IP address IP1 (home address)• Home Network: subnet that contains IP1 • Home Agent (HA): node in home network, responsible for packet forwarding to MN• Visited Network: new subnet after roaming / handover• Care-of Address (CoA): temporary IP address within visited network• Foreign Agent (FA): node in visited network, responsible for packet forwarding to CoA

Home network

Visited network

IP networkMobile Node

Home Address IP1

HA

FA Home Address IP1

Care of Address: CoA1Correspondent Node


Home Network

Mobile IP: Tunneling &Triangle Routing

CN sends packets to the MN using its Home Address IP1 HA tunnels them to FA, using CoA1; FA forwards them to MNMN sends packets back to the CN using IP2 (without any tunneling)Home Agent needs to contain mapping of care-of address to home address (location register)

Mobile NodeIP1, CoA1

Home Agent Subnet

Correspondent Node (CN)IP2

Visited Network

FA

←IP1

CoA1→

IP2 →

Source: Mobile IPv4 illustrated


Mobile IP: TunnelingDefault encapsulation:

• IP-within-IP (RFC2003)

Other Approaches:

• Minimal encapsulation (RFC2004)

• Generic Routing Encapsulation (GRE) (RFC1702)

IP-within-IP encapsulation


Tunneling: IP in IP Encapsulation• IP-in-IP-encapsulation (support in MIP mandatory, RFC 2003)

– tunnel between HA and COA

Care-of address COAIP address of HA

TTLIP identification

IP-in-IP IP checksumflags fragment offset

lengthDS (TOS)ver. IHL

IP address of MNIP address of CN


lay. 4 prot. IP checksumflags fragment offset


TCP/UDP/ ... payload

• Drawback of tunneling– Possibly long routes between CN and MN (many hops)– Increase of data volume increase (additional 20 bytes IP header)

possibly fragmentation


Tunneling: Minimal Encapsulation• Minimal encapsulation (optional)

– avoids repetition of identical fields (e.g.TTL, IHL, version, DS/TOS)

– only applicable for un-fragmented packets (no space left for fragment identification)

care-of address COAIP address of HA


min. encap. IP checksumflags fragment offset


IP address of MNoriginal sender IP address (if S=1)

Slay. 4 protoc. IP checksum

TCP/UDP/ ... payload

reserved


Mobile IP: Agent Discovery & Registration

• Mobile Node finds out about FA through Agent Advertisements– FAs broadcast Advertisements in periodic intervals– Advertisements can be triggered by an Agent Solicitation from the MN

• Care of Address of the MN is determined, either– Dynamically, e.g. using Dynamic Host Configuration Protocol (DHCP)– Or: use IP address of FA as CoA

• MN registers at FA and HA: Registration Request & Reply– MN signals COA to the HA via the FA– HA acknowledges via FA to MN

• Registration with old FA simply expires (limited life-time, soft-state)

FAHA MN

[Agent Solicitation] (opt.)Agent Advertisement

Registration Request

Registration Reply Time

Obtain c/o address


type = 16R: registration requiredB: busy, no more registrationsH: home agentF: foreign agentM: minimal encapsulationG: GRE encapsulationr: =0, ignored (former Van Jacobson compression)T: FA supports reverse tunnelingreserved: =0, ignored

MIP messages:Agent advertisement

preference level 1router address 1

#addressestype

addr. size lifetimechecksum

COA 1COA 2

type = 16 sequence numberlength

0 7 8 15 16 312423code

preference level 2router address 2

. . .

registration lifetime

. . .

R B H F M G r reservedT

Procedure:

• HA and FA periodically broadcast advertisement messages into their subnets

• MN listens to these messages and detects, if it is in the home or a (new?) foreign network

• when new foreign network: MN reads a COA from the advertisement (opt.)

ICMP Router Discovery extension:


MIP messages: registration request & reply

home agenthome address

type = 1 lifetime0 7 8 15 16 312423

T x

identification

COA

extensions . . .

S B D MG rS: simultaneous bindingsB: broadcast datagramsD: decapsulation by MNM mininal encapsulationG: GRE encapsulationr: =0, ignoredT: reverse tunneling requestedx: =0, ignored

Registration Request (via UDP)

home agenthome address

type = 3 lifetime0 7 8 15 16 31

code

identification

extensions . . .

Registration Reply (UDP)

Example codes:registration successful• 0 registration accepted• 1 registration accepted, but simultaneous mobility bindings unsupportedregistration denied by FA•65 administratively prohibited•66 insufficient resources•67 mobile node failed authentication

•68 home agent failed authentication•69 requested Lifetime too longregistration denied by HA•129 administratively prohibited•131 mobile node failed authentication•133 registration Identification mismatch•135 too many simultaneous mobility bindings


MIP: Care-of addressesMN obtains local care-of address either• from FA Advertisement (see before)• Or via Dynamic Host Configuration Protocol (DHCP)

– supplies systems with all necessary information, such as IP address, DNS server address, domain name, subnet mask, default router etc.

– Client/Server-Model: client sends request via L2 broadcast

time

server(not selected)

client server(selected)

initialization

collection of replies

selection of configuration

initialization completed

confirmation ofconfiguration

determine the configurationDHCPDISCOVER

DHCPOFFER

DHCPREQUEST(reject)

DHCPACK

DHCPDISCOVER

DHCPOFFER

DHCPREQUEST(options)

determine the configuration


Hierarchical Approaches• Optimization for:

• long registration delay• inefficient routing paths• Frequent re-registration at HA (even though

mostly ‘local’ mobility

• Example (Hierarchical Mobile IPv4):– Hierarchy of Foreign Agents – Every FA re-tunnels the packets to the next

FA until it reaches the MN

– When a handoff occurs, the MN sends a regional registration request to the lowest level FA

– FAs can also re-direct up-stream packets, if the destination (home-address) is registered within their domain

Similar Approach using ‘local Home Agents’ (called Mobility Anchor Points) in HMIPv6draft-ietf-mobileip-hmipv6-08.txt (June2003)


Hybrid Approaches: Cellular IP• Solutions to the local management of micro-mobility events • Mobile IP is used for global mobility• A gateway (GW) acts as foreign agent for each domain (all MNs use GW address as c/o)

• Within the domain: host-based routing• routing cache entries using soft-state• routing cache updated by upstream packets• separate paging cache for in-active nodesrouters within domain have to be CIP aware

• Similar approach: Hand-off Aware Wireless Access Internet Infrastructure (HAWAII)

CIP Gateway

Internet

BS

MN1

data/controlpackets

from MN 1

Mobile IP

BSBS

MN2

packets fromMN2 to MN 1


Hand-over prediction using localization

• Different methods to obtain device positions•Triangulation (signal strength, time of arrival), e.g. GPS•Database Correlation

• Hand-over optimization• predict future location based on estimated past trajectory• use prediction to start hand-over procedure in advance

•Problems• Accuracy of localization

•Adequate filtering techniques (see example)•Include knowledge of building geometry•Include knowledge of mobility patterns

• Timeliness of location information•E.g., Bluetooth localization with several AP 4-10 seconds


MIP Security Aspects I: Basics (optional)• General security requirements (Security Architecture for the Internet Protocol, RFC

1825)– Authentication

the origin of the data can be determined– Integrity

messages cannot be modified by a third party– Confidentiality

only authorized partners (e.g. sender & receiver) can read the data– Non-Repudiation

sender cannot deny sending of data– Prevention of Traffic Analysis

creation of traffic and user profiles should not be possible– Replay Protection

replay of earlier messages by an attacker can be detected• Additionally: Availability (Prevent Denial of Service Attacks)


• Security Association (SA) for registrations– extended authentication of registration

registration reply

registration requestregistration request

MIP security aspects II: Security associations(optional)

MH FA HAregistration reply

MH-HA authenticationMH-FA authentication FA-HA authentication

– SA contains the following parameters– Destination IP address– Cryptographic method for encryption/authentication– Encryption/authentication key– Lifetime of key– Specific parameters depending on cryptographic method


Registration Request

MIP security aspects III: Registration (optional)Registration Reply

Identification Reg. Request

1 0 1 0 1 1 0 1 1 1 0 1 1 0 1 1Identification Reg. Reply

1 0 1 0 1 1 0 1 1 1 0 1 1 0 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1Identification Reg. Reply Identification next Reg. Request

64

Identification field: protection against replay attacks

• time stamps: 32 bit time-stamp + 32 bit random number

• Nonces: 32bit random number (MH) + 32 bit random number (HA)


MIP security aspects IV: Authentication extension (optional)

• Part of Registration Messages: MN <->HA, MN<->Fa, FA<->HA

•Computation of Autenticator: cryptographic keyed Hash function (e.g. HMAC-MD5 Algorithm) covering

•UDP payload•All earlier extensions•Type, length and SPI of authentication extension

Using the shared, secret key

• SPI (security parameter index) - determines algorithm, mode, and key


MIP security aspects V: Firewall traversalIngress Filtering

Problem: MN sends packets to CN with source address = Home Address (and not c/o address)

Firewalls at domain boundaries suspect IP –Spoofing discard packets

Solution: Reverse Tunneling HACH

MH

Firewall


IP Version 6 (IPv6)IPv6• Basic Header 40 Bytes• 128-bit Network Addresses• Flow label (QoS)• No fragmentation in the network• ‘Built-in’ Security• Neighbor Discovery• Extension Headers:

Routing, Fragmentation, Authentication, Encryption

IPv4• Basic Header 20 Bytes• 32-bit Network Addresses• Type of Service field• Router may fragment packets• IPsec as an enhancement• ARP (Address Resolution Protocol)• Options

Version Priority Flow LabelPayload Length Type of Next Hdr. Hop Limit

Source Address

Destination Address

Offset0812162024283236

4

40

0 1 2 3

Next Header


IPv6 in mobile settings• Large number of IP addresses (each device needs at

least two addresses!)• Stateless autoconfiguration (can replace DHCP)• Route Optimisation via binding updates to CN

– Return Routability Procedure• Validate ownership of addresses• Exchange Authentication Information

– Binding update with check of authentication info– Soft-state approach: automatic expiry

• IPv6 Extension Header: Mobility Header (Next Header Value=135)

– Binding Refresh Request (MH Type=0)– Home Test Init (1), Care-of Test Init (2)– Home Test (3), Care-of Test (4)– Binding Update (5), BU ACK (6), BU Error (7)












Transport Layer ProtocolsGoal: data transfer between application (processes) in end-systems

• support of multiplexing/de-multiplexing e.g. socket API

data stream/connection identified by:two IP addresses, protocol number, two port numbers


Overview: Transport Protocols

• User Datagram Protocol UDP (RFC 768)– Connectionless– Unreliable– No flow/congestion control

• Transmission Control Protocol TCP (RFC 793, 1122, 1323, 2018, 2581)– Connection-oriented (full duplex)– Reliable, in-order byte-stream delivery– Flow/congestion control

• Stream Control Transport Protocol SCTP (see later)• Real-Time Transport Protocol RTP

– Uses UDP– Provides: Time-stamps, sequence numbers– Supports: codecs, codec translation, mixing of multi-media streams


Streaming Control Transmission Protocol (SCTP)

• Defined in RFC2960 (see also RFC 3257, 3286)• Purpose initially: Signalling Transport• Features

– Reliable, full-duplex unicast transport (performs retransmissions)– TCP-friendly flow control (+ many other features of TCP)– Multi-streaming, in sequence delivery within streams

Avoid head of line blocking (performance issue)– Multi-homing: hosts with multiple IP addresses, path monitoring (heart-beat mechanism),

transparent failover to secondary paths• Useful for provisioning of network reliability

Host A Host BIPa1

IPa2 IPb2

IPb1

Separate Networks

SCTP Association


Transport Layer Handover in SCTP

1. MN communicates with CN via established SCTP association (From IP1 to IP CN)

2. When MN comes in Range of AP B• MN obtains new IP address IP2• MN adds IP2 to the existing SCTP association

Address configuration Change (ASCONF) Chunk

3. When connection should be transferred to new AP B• MN sets primary address to IP2• MN deletes old IP1 from SCTP association (ASCONF

chunk)

IP1

IP 2

Correspondent Node

AP A

AP B


SCTP Mobility support: Discussion• SCTP Handover transparent for network

– No additional network infrastructure needed– Possible use-case: switch to peer-to-peer mode without network support

• avoids tunneling and tri-angular routing

• Endpoints need to support SCTP (with dynamic control of IP addresses)• Signalling to every correspondent node necessary (for every established SCTP

association) for high number of parallel connections, large signalling volume over air interface

• Dynamic Naming Service for connection set-up from CN required (to establish the initial SCTP association)– Dynamic DNS– Other location mechanisms (e.g. based on SIP URLs)

• Only usable for traffic without real-time requirements (due to SCTP flow/congestion control)– but similar approaches, e.g. for RTP, possible

• Simultaneous Handover (Mobile Node and Correspondent Node) can lead to loss of connection


Host Identity Protocol (HIP)• IETF drafts, see http://www.ietf.org/html.charters/hip-charter.html• Underlying ideas for mobility support

– Separate host identifier (HI, ‘name’) and locator (‘IP address’)– Dynamic name service or rendezvous server for pre-session mobility– Update of mapping of host identifier locator at handovers– Mechanism works between transport

and network layer• In combination with security

– Host Identity Name space based on public keys

– Hash of HI 128bit Host Identity Tag attached to packets

– 4-packet basic exchange (cookies, Diffie-Hellman Key Exchange)

Source: Semester Project, Roost/Toft/Haraldson


Host Identity / Host identifier

• Host Identity in HIP is a public asymmetric key pair.– RSA– DSA– Possible others

• Host Identifier (HI) is the public key which is used to refer the Host Identity.– Statically globally unique.– Used for host authentication.– Variable length (Depending on cryptographic algorithm).

• Host Identity Tag (HIT)– is a fixed length (128 or 64 bit) representation of a Host Identifier– Can be used as IPv6 address– Goal: low collision probability


HIP Base exchange

• Beginning of a HIP connection• Consists of a 4-way handshake.• Involves :

– Host authentication– IPsec encryption key exchange

(Diffie-Hellman)– DoS prevention via first handshake

• After Base exchange: only ‘normal’ IPsec packets

• Mobility support via ‘re-direction of Ipsec associations’












Multi-homing and flow mobility• Multi-homing: Host supports multiple interfaces with potentially different

IP addresses – E.g. for redundancy purposes (e.g. SCTP)– Simultaneous, multiple wireless access techniques

• Goal: redirect different data-streams via ‚appropriate‘ interfaces– only one home address (as host identificator)– multiple c/o addresses (one per interface)

Flow Mobility, e.g. extension of mobile IP (IETF draft):

• HA contains mapping [home address, flow identifier]

c/o address• Flows identified by (ranges of)

• Source IP addresses (CNs)• Protocol type (TCP, UDP, etc.)• Port Numbers, DSCPs, etc.

UMTS

Access NW

WLAN

Access NW

IP1 (UMTS)

IP2 (WLAN)

IP Transport(Multimedia) Application

Server

Flow 1Flow 2


Reminder: Mobility in GPRS/UMTS

G G SNSG SN

D HC P

R ADIU S

IM S D o m ain

H SS

H L R/AuC

RNC

Node B

Node B

N etw ork Services

SS7, G r

SS 7, G c

G RX Netw o rk

D N SG n-SEC

DN S G n-PRI

G n N etw ork

D N S E xt

B G

G i N etw ork

D M Z

D NSExt

E -m ail

HT T Pproxy

D N S NS

D N S IM S

P-C S C F

I/S -C S CF

MN O 1`s B ackbone

AS N etw o rk

M essages

FT P

V ideo

DN SAS

C orp. Network

VPN -G W Y

AS

B G

IDS

ID S

M N O 1`s N etw ork

B G

1 2 3 4 5 6 7 8 9 * 0 # U E1

BG

In ternetAS

M N O 3

UE3

M N O 2

UE2

IMS

Roaming Support: • UE attaches with SGSN in visited network• PDP context is set-up to GGSN in home network (via Gp interface, GRX network)


Transport of IP packets

ApplicationServerGGSNTerminal SGSNUTRAN

GTP-UGTP-U

User IP (v4 or v6)

Radio Bearer

IP tackets are tunnelled through the UMTS/GPRS network(GTP – GPRS tunneling protocol)

L1

RLC

PDCP

MAC

IPv4 or v6

Application

L1

RLC

PDCP

MAC

ATM

UDP/IPv4 or v6

GTP-U

AAL5

Relay

L1

UDP/IPv4 or v6

L2

GTP-U

IPv4 or v6

Iu-PSUu Gn Gi

ATM

UDP/IPv4 or v6

GTP-U

AAL5

L1

UDP/IPv4 or v6

GTP-U

L2

Relay

L1

L2

IPv4 or v6

[Source: 3GPP]


TCP-mechanisms in wireless settings

• TCP assumes congestion when packets are dropped– possibly wrong in wireless networks: here we often have packet loss due to

transmission errors– furthermore, mobility itself can cause packet loss (handover losses)

or temporary connection disruptions (timeouts or even broken TCPconnections)

performance of an unchanged TCP degrades severely– however, TCP cannot be changed fundamentally due to the large base of

installation in the fixed network, TCP for mobility has to remain compatible– the basic TCP mechanisms are needed to for congestion control in the wired

network parts


TCP Performance Degradation

At right end of graph: About 30% packets lost due to wireless link but approx. 95% TCP throughput reduction!!

Example using Bursty Loss Model:• While current state i: packets

corrupted with probability εi

• After each packet: state transition with probability pik

Average Packet Loss Probability:


TCP over WLAN 802.11b

0

100000

200000

300000

400000

500000

600000

700000

800000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Th

rou

gh

pu

t (B

yte

s/se

c)

Time

Influence of Distance and Obstacles in Wireless LAN (Downstream)

Direct Line of Sight ConectionLine of Sight 5mOut-of-Sight 5m

Out-of_sight 20m

• Strongly reduced throughput in scenario with poor channel conditions

• No TCP retransmissions observedWLAN link-layer retransmissions (together with rate adaptation) effective in these scenarios

Source: Master Thesis, D. Dungs


TCP over Bluetooth• Long-term throughput

smaller than achieved maximum in some measurements

• No TCP level retransmissions



TCP over Bluetooth: detailed analysis

0

20000

40000

60000

80000

100000

120000

140000

160000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

/s)

Time

UDP Throughput over time (Downstream)

Instantaneous ThroughputInstantaneous Averaged Throughput

Transmission Throughput

• Additional performance metric: throughput average over 10 packets

• Throughput drop-down by approx. 33% after ca. 15 sec. in that experiment

• Possible explanation– BT Packet scheduler / link

symmetry– [interference]



Measurement Setup: MIP Handover (Topology I)

Tokyo Delft

Legend:

Aalborg

Fixed Host

Mobile Host

Router

Mobile Node

Toronto

Foreign Agent 210.10.3.254

Switch

WLAN Access Point

8 MBit/s 8 MBit/s

100 MBit/s100 MBit/s

100 MBit/s

Shanghai

100 MBit/sForeign Agent 110.10.1.254

Frankfurt

Server

10.10.2.254Shanghai

10.10.3.X10.10.1.XDownstreamTCP data & UDP probing

Home Agent

• WLAN APs configured with different SSIDs

• HO triggered by change of SSID in mobile node


MIP hand-over delays• Long HO delays due to

DHCP configuration (standard Windows XP)

• Also realistic in some future scenarios

– Vertical hand-overs– Interface

reconfigurations at Handover (SDR)

• TCP timeout mechanism can in worst case approximately double hand-over delays



TCP Proxy

Mobile Node

Foreign Agent 2



Foreign Agent 1

TCP Proxy Home Agent

Correspondent Node (Server)

Linux Router

100 MBit/s

100 MBit/s

Access Point 1 Access Point 2

Proxy location: Home Agent subnet

• Receives MIP messages and TCP fragments via policy-based routing at HA and Linux Router

• Reverse Tunneling activated – TCP Proxy also processes

upstream ACK packets

Proxy Functionality:• Split-connection approach (TCP

RENO)• After disconnection

– CN is frozen by Zero Window Advertisment

• Upon successful MIP registration:– TCP data transfer is

immediately resumed (when MIP response sent)

• [Additional performance enhancing features]

– not HO related not activated here!


TCP: Improvements using Proxy







• TCP in hand-over situations6. Summary & Outlook



PAN

CAN

BBT

BT

BT

BT

You

Br

VD

aT

VD

aT

YouYouMe

aT

B aTBr

BRo/Br

aT

B aTBr

BThird Party

Ro/Br

aT

Br : BridgeRo : Router

Network Architectures beyond cellular networks

Personal Area Networks (PANs)• Devices attached to or in vicinity of person

group mobility models• Wireless communication

• Between devices within PAN• To infrastructure networks• Between two PANs

Wireless multi-hop communication

Impact of wireless multi-hop• Mutual interference• MAC protocol deficiencies• Need for modified routing (ad-hoc domain)• For PANs: Group Mobility!

[see http:/www.ist-magnet.org]


Outlook: Future wireless networksServices andapplications

IP based core network

IMT-2000UMTS

WLANtype

cellularGSM

short rangeconnectivity

WirelinexDSL

otherentities

DABDVB

New radiointerface

Properties of future networks (‘4G’):• Heterogeneous access

technologies – 802.11, Bluetooth, cellular, etc.

• IP-based core network– Mobility support on IP layer

(complemented by higher-layer methods)• Mobile IP one major candidate

• wireless multi-hop connections• Personalization (Personal Area Networks,

Personal Networks)• Reconfigurability (Software Defined Radio)• Context Sensitivity


References

• C. Perkins: ’Mobile IP: Design Principles and Practices.’ Addison-Wesley, 1998. • IETF Working groups (see also for RFCs and drafts):

– Mobile IP: http://www.ietf.org/html.charters/mobileip-charter.html– IPsec: http://www.ietf.org/html.charters/ipsec-charter.html– IPv6: http://www.ietf.org/html.charters/ipv6-charter.html– Others: nemo, mip4, dhcp, seamoby

• J. Schiller: ’Mobile Communications’. Addison-Wesley, 2000.• A. Festag, ‘Mobile Internet II, Overview of current mobility approaches’ (lecture material).

TU Berlin, 2002.• Seok Joo Koh, ‘mSCTP: Use of SCTP for IP Mobility Support’, Presentation, IT Forum,

Korea, 2003• H. Schulzrinne, E. Wedlund, ‘Application-Layer Mobility Using SIP’. Mobile Computing and

Communications Review, Vol. 1, No. 2


Acknowledgements

• Lecture notes: Mobile Communciations, Jochen Schiller, www.jochenschiller.de

• Student work (TU Munich, AAU)– Stefan Rank (Master Thesis)– Rui Martins (Master Thesis)– Thorbjørn H. Jørgensen and Lars B. Pedersen (Semester project)– Lars Roost, Per Toft, Gustav Haraldson (Semester project)– Dennis Dungs (Master Thesis)

• Lecture notes: Wireless communication protocols (R. Prasad, TKM)


Exercises

1. Hand-over optimization via location information: Assume an infrastructure WLAN network with multiple subnets and MIPv4 for mobility support. The network infrastructure itself now provides another component, called ’location server’, that can upon request provide geographic coordinates as well as estimation of movement vectors of mobile devices.– Develop an approach to shorten the MIP hand-over delays using hand-over prediction. Show a

message flow for your improved solution (if necessary, feel free to introduce additional entities in your network, or additional functionalities on the Mobile Node)

2. Vertical hand-over between heterogeneous access networks: – Discuss the steps that are necessary to perform a mid-session hand-over from a WLAN hotspot

network to a UMTS access network (hint: MM1 from last semester).– Discuss how mobile IP can be used to support such a hand-over. Where would the home-agent

need to be placed? What possible problems can arise? Consider the structure of the headers at the GGSN in this setting (and be reminded of TFTs, see MM1 last semester)?


Additional Material


Performance Analysis of Hand-over Mechanisms:

Experimental Analysis

Based on semester project by Thorbjørn H. Jørgensen and Lars B. Pedersen,

Aalborg University, Spring 2004


Content1. Scenarios and Mobility

Support Schemes• Migrating IP address• Mobile IPv4• (Mobile) SCTP

2. Measurement Methodology• Approach• Parameter definitions

4. Results and Discussion• Migrating IP address• Mobile IPv4• Mobile SCTP• Comparison of schemes


Migrating IP address (I): setup

• Hand-over only within same subnet• Transparent to transport layer• Hand-over script based on Linux standard bash script commands

10.10.3.169

BT

WLAN

10.10.1.58

BTWLAN

UDP Packet StreamerPacket monitorHandover script

Subnet 10.10.1.X Subnet 10.10.3.X


Migrating IP address (II): Gratuitous ARP

10.10.1.42(00-E0-2D-59-4A-7C)

10.10.1.80(00-E0-2D-59-3D-7B)

ARP cache (Layer 2)IP address MAC address

10.10.1.80 00-E0-2D-59-3D-7B

ARP cache (Layer 2)IP address MAC address

10.10.1.80 00-E0-2D-59-3D-7B

ARP cache (Layer 2)IP address MAC address10.10.1.1 00-E0-2D-39-54-9C

10.10.1.42 00-E0-2D-59-4A-7A

10.10.1.1(00-E0-2D-39-54-9C)

10.10.1.42 00-E0-2D-59-4A-7A10.10.1.1 00-E0-2D-39-54-9C

Gratuitous ARP RequestProtocol Type Request

Sender Protocol Address 10.10.1.42

Target Protocol Address 10.10.1.42

Sender Hardware Address 00-E0-2D-59-4A-7C


MIP: setup

UDP Packet streamer

10.10.3.169BT

WLANMobile NodeHADDR: 10.10.1.80

BTWLAN

Subnet 10.10.1.X Subnet 10.10.3.X

HA10.10.1.254

FA10.10.3.254

WLAN

• HUT Dynamic MIP–FA or MN decapsulation

• Mobile Node–Handover scripts for forcing handover


SCTP: setup

SCTPPacket streamer

10.10.3.169BT

WLAN

Mobile Node

BTWLAN

Subnet 10.10.1.X Subnet 10.10.3.XWLAN

• SCTPlib (from sctp.de)– Partial support for Mobile extension– no dynamic modification of IP addresses of association in current implementation

• Mobile node–Handover script for forcing handover


Measurement Methodology: Packet streamers

SCTP Packet Streamer:• Client/Server application

–Maintain association• Reliable transport protocol

–Flow control mechanisms !

INIT

INIT ACK

COOKIE ECHO

COOKIE ACK

STREAM PACKET

STREAM PACKET

STREAM PACKET

STREAM PACKET

ASCONF

ASCONF ACK

STREAM PACKET

STREAM PACKET

STREAM PACKET

STREAM PACKET

SHUTDOWN

SHUTDOWN ACK

Client Server

Association created

Association initiated

Handover initiated

Shutdown initiated

• Handover determined from packet stream– With deterministic inter packet time– UDP and SCTP packet streamer

• Packet stream captured on mobile node (Ethereal)


Definition of handover delay

1: 10

0Ha

ndov

er in

itiat

ed

Last

pac

ket o

n NI

C 1

Firs

t pac

ket o

n N

IC 2

Hand

over

end

ed

[s]

Han

dove

r sta

rted

Handover delay(Soft handover )

Total handover delay(Hard handover )

1:11: 21: 31 :41:51: 61: 71: 81 :9

1: 111:121:1 31: 161: 141 :151: 161:1 71: 181: 191: 211:20

2:2 82: 291: 222 :302: 312:3 22: 332: 342: 352:362:3 72: 382: 392 :40


Migrating IP address: Results• Precision

–Inter-packet time 5ms•Results (w. 95% conf. interv.)

–Bluetooth WLAN•18.8ms±3.2 (Soft)•31.5ms±2.8 (Hard)

–WLAN Bluetooth•25.9ms±3.2 (Soft)•60.4ms±2.1 (Hard)


MIP: handover delay distribution

Home BT Foreign WLAN, MN decapsulation

• problems with packet forwarding FA MN cause long delays in many measurements


SCTP: handover delay distribution

• BT WLAN in different subnets• Problem with long total handover delay (>3s), but not for WLAN BT handover

– possibly due to ‘inter-working’ problems between SCTP library and WLAN device driver




Reference

• Lars B. Pedersen, Thorbjørn H. Jørgensen: ’Experimental Analysis of Mobility Support Schemes for vertical Handover’, Project Report, 6th semester communication networks, Aalborg University, June 2004.

For additional experimental investigations:• Lars J. Roost, Per N. Toft, Gustav Haraldson: ’The Host Identity Protocol – An

experimental evaluation’, Project Report, 6th semester communication networks, Aalborg University, June 2005.

Documents

Wireless Networks III: advanced conceptskom.aau.dk/~hps/Courses/Fall06/WNIII/Fall06_MM1_mobility.pdf · Wireless Networks III: advanced concepts ... TCP, UDP, RTP/UDP Application