SIP-CONF-PULVER-2001 Telcordia Technologies Proprietary - Internal use only. See proprietary...

SIP-CONF-PULVER-2001Telcordia Technologies Proprietary - Internal use only. See proprietary restrictions on title page.

SIP-based Mobility Management Scheme for Wireless Internet

Presenter: Ashutosh Dutta

Research Scientist,Telcordia Technologies, NJ

[email protected]

(Joint work with Toshiba America Research Inc.,

Toyota Info Technologies.,

Columbia University)


Motivation

Mobility and wireless are rapidly becoming the rule rather than exception.

SIP is gaining acceptance as the signaling protocol for multimedia conferences and Internet telephony.

It is essential to support wireless mobile users in a SIP signaling and control environment.

Current Wireless Standard efforts using SIP– IETF– 3GPP (Third Generation Partnership Project)– MWIF (Mobile Wireless Internet Forum)– 3GPP2


Outline

–Objective–Mobility Management Requirement–Existing mobility solutions–SIP based mobility–Performance–Wireless Internet Testbed Implementation–Issues and Summary–SIP Mobility demo


Why is Mobility Management Difficult ?

Goals of mobility support in Internet:–allow a mobile device to move between different subnets

and domains –preserve an ongoing session between the mobile device

and its counterpart alive while moving–Ability to provide same service irrespective of network

attachment Several protocols and mechanisms have been developed Broadly divided into

– Network Layer Mobility MIP, CIP, HAWAII, TeleMIP, MIP-LR, MIPV6

– Application Layer Mobility SIP based Mobility Management Scheme


Multimedia Protocol Stack

Media Transport

App

lica

tion

Dae

mon

Ker

nel

Phy

sica

lN

etw

ork

H.323 SIP RTSP RSVP RTCPRTP

TCP UDP

IPv4, IPv6, IP Multicast

PPP AAL3/4 AAL5 PPP

SONET ATM Ethernet V.34

Signaling Quality of Service media encaps(H.261. MPEG)

ICMP IGMP

MGCP

802.11

DNSLDAP

MIP MIP variant

CIP

CDMA


Service Profile for all IP wireless network user

ServicesRequirements

Multimedia Voice Data

Delay Stringent Stringent TolerantLoss/error Tolerant - Stringent Tolerant StringentBit rate (outdoor) Pedestrian 384 kb/s

Vehicular 144 kb/s

64 kb/s Pedestrian 384 kb/sVehicular 144 kb/s

Bit rate (indoor) 2 Mb/s 64kb/s 2Mb/sExampleapplications

Video streaming, videoconferencing

Mobile telephony File Transfer (e.g., ftp)to mobile


State of the Art: Related Work

CellularIP

Uses host based routing Uses Mobile IP for global mobility. For macro-mobility it uses rules similar to HAWAII as far

as border router is concerned. It uses two parallel cache system , routing and paging, for

location update. Handoff is initiated by the mobile host

Hawaii

Proposes a 2-layer method for binding protocol. UsesMobile IP for global mobility.

For macro-mobility it assigns the mobile node an addressassociated with border router.

When moving within the foreign domain, MH retains itscare-of-address.

Base stations are capable of decapsulating packets andforwarding it to the mobile host.

Base station also determines whether to redirect theregistration to special routers in the domain or to the HA.


State of the Art: Related Work

Tele-MIP

TeleMIP is an intra-domain mobility solution– It uses two layers of scoping within a

domain Reduce the latency of intra-domain location

updates Reduce the frequency of global update

messages Reduce the requirement of public addresses

(IPv4)

MIP-LR

HLR can be anywhere (geographicallydistributed)

No tunneling If a VLR runs out of COAs temporarily, it

issues its own IP address as COA tunnelspackets temporarily

Lazy caching, eager caching and tunnelingfrom old foreign agent to the new one

Direct update to CH


Related Work:

Mobile IP

Simple and scalable global mobility solution. Needs support for fast handoff control, real-time location

tracking, authentication and distributed policymanagement.

Its triangular routing may adversely affect performance ofreal-time services.

Registration and configuration are tied with the mobilityarchitecture.

There are different proposals for using mobile IP in a SIPenvironment.

- SIP based mobility for real-time services and mobileIP for TCP applications (Wedlund, Schulzrinne).

- SIP for location service and Mobile IP for addressbinding (Calhoun, Kempf).


Qualitative comparison with Mobilityapproaches

QUALITATIVE COMPARISON OF DIFFERENT APPROACHESIntra-domainencapsulation

Inter-domainencapsulation

Changesto end-systems

Trianglerouting

Infrastructurechange

Fasthandoff

MIP Yes Yes No Yes No NoMIP-RO Yes Yes Yes No No NoMIP-RR Yes Yes No Yes No YesMIP-FF Yes Yes No Yes Yes Yes

CIP No Yes No Yes Yes YesHAWAII No Yes No Yes Yes YesMIP-LR No No Yes No No YesTeleMIP Yes Yes No Yes Yes Yes

SIP No No No No No Yes


Objective

To develop a mobility management scheme for wireless IP networks based on SIP signaling scheme

–Support for all types of mobility–Support global roaming–Independent of underlying wireless technology–Support for real-time and non-real-time multimedia applications (both TCP and UDP/RTP based applications)

–Inter-work with today’s 1G/2G telephony smoothly


Technical Issues for SIP Mobility

Functions Requirements

Hand-off Should support cell, subnet (intra-domain) anddomain hand-off.

Should utilize the soft hand-off feature of CDMAtechnology, or virtual hand-off

Should be wireless “technology independent”.

Registration Should be completed in less than a fewseconds.

Support Hierarchical Registration

Configuration Should be done in fractions of a second forroaming users (e.g., IP address, DNS server.)

Address Binding Should allow a user to maintain a universalidentifier regardless of its point of attachment tothe network.

Location Management Should be up to date, accurate, and confidential.


SIP Mobility Advantages

– Easier Interaction with associated standard IETF protocols DNS, HTTP, LDAP for location management SLP for service discovery AAA protocol (e.g.;Diameter) for inter-domain mobility DHCP/DRCP for IP address configuration tftp for firware upload SDP for providing session parameters (e.g., change mid-call parameters) RTP/UDP for transport, RTSP for stream control application (e.g., IP Telephony, voice mail, streaming)

– Elimination of triangular routing and IP-IP encapsulation associated with other mobility approaches such as MIP Reduces delay Saves network overhead

End hosts should be equipped with SIP-UA Suitable for real-time multimedia traffic such as voice over IP and/or video

streaming

– Can be used for RTP/UDP based application as is

– SIP extensions for Non-real-time application Complements IPV6 mobility Can co-exist with MIP, Cellular IP and other Micro-mobility approaches


SIP Mobility Basics

Supports end-to-end mobility by means of application layer signaling

meant for multi-media/multi-party sessions

SIP based mobility can also be termed as Application Layer mobility More than just hand-off

– supports various types of mobility

– provides flexible services

Compensate for lack of Mobile IP deployment Less reliance on underlying transport network of the ISPs Supports application-layer equivalent of Mobile IP registration Fast-handoff Paging


Types of Mobility supported by SIP

Terminal Mobility– Pre-session mobility (Micro/Macro/Domain)

pre-session mobility by means of unique URI (ability for a user to

be within reach under the same identifier

while using different terminals) use of SIP proxy, redirect, registrar Hierarchical registration for faster registration update

Mid-session mobility Move between cells, subnets, domains, supports handoffs Real-Time (RTP/UDP)

–SIP Re-invite, RTP SSRC/IP address–Hierarchical proxy and RTP translator for fast hand-off within a

domain–Duration limited multicast between subnet handoff–use of RTSP to control multi-media stream

server


Mid-session mobility for TCP based application

Mobility problem with TCP applications– TCP socket - bound to source and destination address– One of these addresses change => connection breaks

TCP applications: ftp, telnet, web Application Layer restart and recovery capabilities

– connection: close header into HTTP request– FTP variants (e.g., bullet-proof ftp)

Multi-homing feature of SCTP (IETF) TCP-Migrate Option SIP-eye enabled in the end-hosts - keeps track of the TCP end-points

of SIP

SIP Mobility Proxy (Columbia U.)– an interceptor to forward data


Basics of SIP Mobility

Personal Mobility

– Use of one logical address to address a single user located at different terminal One address to many potential terminals

– Many addresses reaching one terminal– Use of forking Proxy, a user can be reached at any of the devices

Service Mobility– Allows users to maintain access to their services while moving or changing devices and network service

providers– Maintain speed dial list, address books, buddy lists, incoming call handling (e.g, CPL)– As part of registration message (on a routine basis or upon network change) it conveys

current network address Properties of the device (media supported, call priority etc.) Other configuration elements

Session Mobility– Allow a user to maintain an on going media session even while changing terminals– Use of MGCP/Megaco– Third-party Call control– Refer Mechanism


SIP Mobility - Mobile IP

CH

HA

FA

Home Network

MN

Tunnelled data

data

data

CH

SIPServer

Home Network

MN

1

2

3

4

5

Plain Mobile IP

CH

SIPServer

Home Network

MNmoves MN

Foreign Network

SIP Pre-session Mobility

SIP Mid-session mobility

1

2

3

4

1. SIP INVITE 2. 302 client

moved3. SIP INVITE

4. SIP OK5. Data

1. MN moves2. MN re-invites

3. SIP OK4. Data

CH

SIPServer

Home Network

MNmoves MN

Foreign Network

SIPServer

CH

When both move


Evaluation Model for SIP and Mobile IP

Caller’sNetwork

Callee’s Home Network

Callee’s Foreign Network

MHHA

M hops

MHFA

High-speed link

Low-speed link

N hops

CH

P hops

MIP

SIP


SIP-Mobile IP Transport Delay vs. Packet size

SIP/MIP Latency vs. Packet size

0

10

20

30

40

50

60

70

80

90

100

0 300 600 900 1200 1500

Packet Size in bytes

La

ten

cy

in

ms

ec

MIP-SD

SIP-SD

MIP-D

SIP-D


Bandwidth Efficiency Gain

SIP/MIP bandwidth gain

0

0.1

0.2

0.3

0.4

0.5

0.6

0 100 200 300 400 500 600

Packet size in bytes

Ban

dw

idth

Eff

icie

nc

y G

ain

SIP b/w efficiencygain


SIP-Based Mobilityin Military Environment

CorrespondentHost

SIPServer

LDAPDNS

StreamServer

ACN 1

SIPServer

LDAPDNS

StreamServer

ACN 2

1. Register2. Invite

3. Client moved

5. INVITE Proxy message

7. Re-invite

ServerRe-directServer

ServerServer

On-going MediaSession (RTP)

DRCPDNS

192.4.8.18

MobileNode Pre-session

Move

MN

192.6.10.18

SIP

Domain 1Domain 2

6. Proxy

1B1A

Proxying Registration4. Invite

192.6.11.20MN

Mid-sessionMove

192.4.8.20

Server

CH moves


SIP mobility for Appliances

UPnPUPnPControllerController

UPnPUPnPControllerController

JiniJiniControllerController

JiniJiniControllerController

LDAP LDAP StoreStore

Location Registries(User & Location)

Web Browser& SIP UA

PocketPC

Webphone

Web serverSIP User AgentMobile Service LogicSIP Proxy

Web serverSIP User AgentMobile Service LogicSIP Proxy

SIP ProxySIP User AgentWatcher

SIP ProxySIP User AgentWatcher

WML

SIP

http

http

SIP

ProvisioningProvisioningSystemSystem

OSGiOSGiGWGW

SIP for AppliancesSIP for Appliances

TalismanTalisman

Wide-area wireless v/dShort-range LAN I/f

Location-sensitive servicesPersonalized services


SIP Mobility - Handoff -

BS

Correspondent Host (CH)

BS

2. re-INVITE

3. Send Data to New Address

By sending SIP re-INVITE message from new location, CH starts sending its voice packet to the new location and Communication continues seamlessly


SIP Mobility - Handoff

Corresponding Host at Mobile Host at

IP0SIP signaling

RTP

Invite user@domain

Contact user@IP2

IP1

-> IP2

Mobile Host

SIP UA

RAT

IP2

RTP

SIP signaling


Hotmail.comServer

Columbia.edu

[email protected]

Mobile Phone

Fixed Phone

Host

[email protected]

[email protected]

[email protected]

SIP Personal Mobility


Session Mobility using Call transfer

Bob@mobile

Bob@fixed

Alice@wonderland

Ongoing session

1. REFER Bob@fixed Referred-By: B1

2. INVITE Bob@fixed Referred-By: B1

3. BYE Alice@Wonderland

Session Transferred

1

2

34

INVITEwith no SDP

200OK

Bob@fixed

INVITEfrom 2

200

5ACKSDP(4)

6ACK

Bob@mobile Alice@wonderland

Third party control

Session Mobility

RTP


Registration with local SIP RegistrarRegistration with local SIP Registrar

From:Alice@NY (1) Contact: 193.1.1.1

(3) CA From:Alice@NY (2) NY

Registrar Contact: Alice%NY@CA Registrar

From:Alice@NY (4) Contact: 193.1.2.3

Visited Network Registrar needs to map Alice’s URI to a canonical name

Only first registration in CA needs to go all the way to NY All SIP messages to Alice need to go through SIP server/registrar

for address translation.


Use of multicast for hierarchical SIP servers for paging

SIP server

SIP server

SIP server

TTL = 1

TTL = 64

TTL = 256

Caller

INVITE

Forwardsupstream

INVITE withmulticast addr.

Callee has movedhere

searches

failure

INVITEwith wider scope

INVITE withTTL =256

failure


The ITSUMO Network Architecture

MS: Mobile Station

BS: Base Station

ERC: Edge Router & Controller

Control messages (i.e..., signaling)

Domain Control Agent

Visited Network

Domain Control Agent

Wireline IP backbone network

Home Network

ERC

Internet

Regional IP network Regional IP

network

ERC

Inter-Domain Control Agent

Radio Access Network(RAN)

Radio Access Network(RAN)

BS

BSBS

BS

DCADCA

IDCA

MS

IP


Network Signaling and Control Architecture

Signaling:

Wireline IP backbone network

Internet

Visiting Registrar

3GAccess

SIP

3GAccess

SIP Server

MAAAQ SIP

VR

Regional IP network

Visiting Network

MS

DCA

Home Network

3GAccess

SIP

3GAccess

Regional IP network

SIP Server

MAAAQSIP

HR

Home Registrar

DCA

Inter-Domain Registrar

SIP Server

MAAAQ

IDR

IDCA

SIP UA in mobiles and hosts.


Internet Roaming (RTP Application)

SIP Server

AAAQ

SIP

HR

SIP Server

MAAAQ

VR

Internet

Visiting Network Home Network

BSC 1 BS

BS

ERC 1

BSC 2

BS

ERC 2

ERC 3

BS

BS BSC 3

A

C

B D

Home RegistrarVisiting Registrar

Corresponding HostSIP

DRCPDRCP

INVITE128.59.10.6

IPch

207.3.232.10

207.3.232.10207.3.240.10

SLA/SA

128.59.11.6

RTPTranslator

• SIP UA in mobiles and hosts.


Supporting TCP Applications

SIP Server

MAAAQ

SIP

HR

SIP Server

MAAAQ

VR

Internet

Visiting Network Home Network

BSC 1 BS

BS

ERC 1

BSC 2

BS

ERC 2

ERC 3

BS

BSC 3

A

C

B D

Home RegistrarVisiting Registrar

Corresponding HostSIP

DHCPDHCP

SIP_EYE

Ongoing TCPConnections

INFO

INFO

INFO

• Equip MS with SIP_EYE.

IPch

207.3.232.10

207.3.232.10

207.3.240.10

128.59.10.6

IPch1

MobilityProxy

128.59.11.6

Register


ITSUMO test-bed Architecture

Backbone

VLAN Switch

3600 3600

tari.toshiba.com Research.telcordia.com

R1

LocalServer

LocalServer

VLAN Switch

R2

LocalServer

R3

LocalServer

VLAN Switch VLAN Switch

SIPServer/Call Agent

SIPServer

Border Router Border Router

QOS QOSHA/DRCPServer

DRCPServer

MulticastProxy

DRCPServer

DRCPServer

AAAServer

AAAServer

External OmniAntenna

Micro Macro DomainExternal Demo

SIP UA/Mini_RGW

QOSQOS

BURPBURP BURP

SIPServer/Call Agent

Ad

Media Server


Wireless Internet Telephony Test-bed Protocols

Functionality Protocols Details

Signaling SIP Set up/tear-down multimedia call

Configuration DRCP (Dynamic RegistrationConfiguration Protocol)

Faster registration protocol forthe wireless roaming users,variation of DHCP

Local Authentication(Intra-domain)

BURP (Basic User RegistrationProtocol)

Takes care of movement within adomain.

Inter-domain (AAA) Diameter When mobile moves between thedomainsSIP-AAA interaction duringdomain handoff

Location Management SIP based registration scheme Re-registration upon subnethandoff

QoS DSNP Dynamically allocates the QoS

Binding SIP based mobility for real-time applicationMIP for TCP based applicationSIP Eye and Mobility ProxyWork in progress

Supports audio/video/whiteboardapplication as part of mobility


Backbone

DiameterServer

Home AAA

Diameter Server,

visited AAAHome SIPServer

Diameter Client

BURP Server

DRCP

Server

tari.toshiba.com

Diameter Client

BURP Server

DRCP

Server

Diameter Client

BURP Server

DRCP

Server

Research.telcordia.com

12

Local SIPServer


NGN Application Server Environment

IP

SCE

WebServer

Rapid creation of new services

Telcordia™ NGN Application Server

End-user devices

SIP

Softswitch

PSTN phone SIP phone

Service Execution

Services

MediaServer

Gateway

3rd PartyApplication Servers

API

SIP

3rd Party SIPApplication Servers

Customer Self-Service


Services

Java

Java

IP Service Network

Service Enabling Tier

Middle Tier

Application Tier

External

B/OSS and IT

Backend

Infrastructure

InformationContent Tier

SCE

JAIN / Parlay / OSA APIs

Internet Services Gateway

Internet Services Gateway

Open IDL Interface(CORBA)

ISG APIs (Java, CORBA, XML)

ISG APIs

NGN Application Server Architecture

Location & PresenceApplications

Web PortalApplications

EnterpriseApplications

MediaServer

SIP

Open Services Gateway

Open Services Gateway

(CORBA, Java,XML)

LDAP, DIAMETER,MGCP


Initial/Example SIP-Based Voice Services

Call Distribution / TOD routing Unattended transfer Call forward unconditional Call forward on Busy Call forward on No Answer Single line extension Find-me Call screening Simultaneous ringing Secondary number – In/Out Do not disturb Call waiting Call Hold Consultation hold


Issues & Discussion

SIP can partially replace or complement existing mobility solutions

Survivability under dynamic network condition–When SIP server/proxy dies

Registration with Local registrar vs. home registrar Both the end hosts moving SIP for Adhoc networking Fast handoff mechanism


Q/A


References

www.research.telcordia.com/sip-mobile Application Layer Mobility Using SIP, MC2R

Henning Schulzrinne, Elin Wedlund

Application Layer Mobility Management Scheme for Wireless

Internet, 3G Wireless Conference

Dutta,Vakil, Baba, Chen,Tauil, Schulzrinne


SIP Mobility Demo for real-time audio


Morristown, NJ, U.S.A.

TARI & Telcordia

ITSUMO Outdoor Experiment



Purpose: Under the quasi-real environment

-Mobility Test

-Total system feasibility check



Base Station-Emulating cdma2000 by using WaveLAN

-Mobility test by using the eight radio cells


ITSUMO Outdoor ExperimentDriving route

300 m



Driving Experiment-Evaluation of the IP mobility

in terms of Micro, Macro and Global Mobility


Mobile IP

Mechanism developed for the network layer to support mobility Originally intended for travelers with laptops over wired

networks Later adopted by the wireless community Maintains active TCP connections and UDP port bindings A mobile host is associated with a fixed IP address (home IP

address) When a mobile host connects to a different network other than

the one its IP address belongs, the home network forwards packets to it

A router (home agent) on the user’s home network delivers the packets to the mobile host


Mobile IP

HomeHomeAgentAgent

ForeignForeignAgentAgent

CorrespondentHost

Home Network

Foreign Network

MobileHost


Optimizations and Extensions to Base Mobile IP

Triangular routing causes additional delays and wastes bandwidth If the correspondent host knows where the mobile host is, it can send

packets directly to the care-of address of the mobile host Route optimization:

– binding updates sent from a home agent upon request, or – sent upon receiving a warning from a foreign agent if the mobile host

changes location during a communication session Smooth handoff:

– former foreign agent will keep forwarding packets to the new one until the correspondent host updates its mobility binding cache

Theoretically triangular routing avoided, but correspondent host must be able to encapsulate packets - not possible without changing the operating system of the correspondent host


Optimizations and Extensions to Base Mobile IP (contd.)

Firewalls reject to forward packets coming from topologically incorrect addresses (host’s IP address does not match the network

Reverse tunneling: all packets from a mobile host go through the home agent– triangular routing again !

A mobile host registers with home agent each time it changes care-of address signaling delay for long distances

Regional registration: locally register within a visited domain– hierarchical structure of foreign agents– local foreign agents under a gateway foreign agent (GFA)– home agent registers the GFA’s address as the care-of address


Optimizations and Extensions to Base Mobile IP (contd.)

Network Assisted, Mobile and Network Controlled (NAMONC) handoff:– Faster handoff for real-time applications– Network informs mobile host that a layer 2 handoff is anticipated– Uses simultaneous bindings (multiple registrations at a time),

sends multiple copies of the traffic to potential movement locations

Network Initiated, Mobile Terminated (NIMOT) handoff:– Foreign agents use layer 2 triggers to initiate a pre-registration

prior to receiving a formal registration request from the mobile host

Both methods assume considerable involvement of information from layer 2


Limitations and Inefficiencies of Mobile IP

Encapsulation of packets adds between 8 or 12 bytes and 20 bytes of overhead

Although triangular routing is avoided with route optimization, with reverse tunneling it becomes a fact again

With route optimization, changes are necessary in the operating systems of the correspondent hosts

With regional registration, reliability an important issue (failure of a GFA will bring the whole hierarchy down

Processing time needed to encapsulate and decapsulate packets each time they traverse a home agent/foreign agent is not negligible especially for real-time sessions


Cellular IP (Columbia University, Ericsson)

HomeHomeAgentAgent

CorrespondentHost

Internet(with Mobile IP)

BS

BS

BS

BS

GatewayGateway


Cellular IP

Base stations snoop actual data packets from mobile hosts to gateway to cache the path taken by them

To route packets from the gateway to the mobile host, base stations use the reverse of this path

Hosts that have not transmitted packets for a while are removed from the routing cache of the base stations

Idle hosts send infrequent paging-update packets to the gateway– coarsely maintaining the position of idle hosts (passive connectivity)

Active hosts’ exact locations are known If an active mobile host moves to another base station during a call

– it sends a route-update packet back to the gateway– new base station(s) record this path accordingly


HAWAII (Bell Labs)

Internet

Domain Root Domain Root RouterRouter

Domain Root Domain Root RouterRouter

BSBS

R R

R R R

BS

R R

R R

Domain 1Domain 2


HAWAII

The path (route) between the mobile host and the domain root router is specific to that host– established (during power-up) and updated (during movement) for that

mobile host in the domain root router and intermediate routers This information is refreshed periodically by the mobile host Different path setup schemes possible to re-establish path states during

handoff– forward packets from the old base station to the new base station for a

short period (until the relevant routers update their entries for the specific host)

– do not forward packets; either bi-cast them to two base stations or unicast them for hosts that can simultaneously listen to two base stations.

HAWAII requires all routers in a domain to be augmented with mobility support so that they are able to handle host-specific path setup messages


TeleMIP (Telcordia)

TeleMIP is an intra-domain mobility solution– It uses two layers of scoping within a domain

Reduce the latency of intra-domain location updates by specifying an intra-domain termination point (Mobility Agent or MA). – Intra-domain updates only up to the MA, which provides a

globally valid COA to mobile host. Reduce the frequency of global update messages

– Since the MA is located at a higher hierarchy than that of subnets, global updates (to HA, CHs etc.) only occur for inter-domain mobility.

Reduce the requirement of public addresses (IPv4)– By promoting a two-level addressing scheme, it promotes the

use of private (locally-scoped) addresses for handling intra-domain mobility.


TeleMIP’s Architecture Layout


Mobile IP with Location Registers (MIP-LR) (Telcordia, US Army)

Foreign Network: j.k.l

VLR

Mobile Host: a.b.c.d

1: Registration:COA=j.k.l.m

2: Query3: COA

4: Bindingcache (COA)

5:Un-Encapsulateddata packets sentdirectly to COA

HLR

CH

Home Network: a.b.c


MIP-LR

HLR can be anywhere (geographically distributed) No tunneling After a mobile host moves:

– if it was registered at some other foreign VLR, the new VLR deregisters it at the old VLR.

If a VLR runs out of COAs temporarily, it issues its own IP address as COA tunnels packets temporarily

After a mobile host moves:– correspondent host will have an outdated mobility binding– a mechanism is required to update the cache on the

correspondent host: Lazy caching, eager caching and tunneling from old foreign

agent to the new one


DHCP Enhancements for Mobile Wireless

Requirement:– Rapid client configuration(milliseconds rather than seconds)

– Automatic client reconfiguration (independent of lease time)

– Efficient use of scarce wireless bandwidth

– Allowing clients to be routers

– Enhanced registration (e.g., user identification and security)

– Flexible proxies that can act both as relay/server

– Message exchange without broadcast

How to achieve:– Shrink message size

– Minimize messages in transactions

– Minimize use of broadcast


DRCP

DRCPDISCOVER

DRCP ADVERTISEMENT(?)

DRCPOFFER

DRCPACCEPT

ServerClientClient Server

DISCOVER

OFFER

REQUEST

ACK

ARP CHECK

ARP REPLY

15 Sec.

DHCP


DRCP Message Flow

Client Server

ADVERTISEMENT

DISCOVER

OFFER

ACCEPT/DECLINE

Time axis

ServerClient

REQUEST/RELEASE

ACK

Client moves to a new Domain Extending the lease


DRCP vs DHCP Messages

0

50

100

150

200

250

DHCP DRCP

Mes

sag

e S

ize

(in

byt

es)

DHCP - 236 bytes DRCP - 16 bytes 93.2 % improvement


QoS scheme for the Mobile Testbed

MS w/Mobile IP

QGS QLN

QLN

802.11b802.11b

802.11b

CH(Correspondent Host)

Initial SLSnegotiation Handoff(1) Handoff(2)

Handoff(3)Handoff(4) SLS change

Packet shaping for Real-Time Traffic (with pre-reservation)

QLN

*ITSUMO: Internet Technologies Supporting Universal Mobile Operation


AAA Functional Model

AAAF AAAH

A

C

Local Domain Home Domain

AAAH: Home AAA ServerAAAF: Foreign AAA ServerA: Attendant(MIP FA, SIP server, …)C: Client

Pre-established SA


Re-registration (SIP)

03/10/2001 09:52:40:236188Sent to: 207.3.232.90:5060REGISTER sip:research.telcordia.com SIP/2.0Via: SIP/2.0/UDP 10.1.1.130:5060CSeq: 1 REGISTERExpires: 0Contact: sip:[email protected]:5060; expires="Sat, 10 Mar 2001 15:41:48 GMT"; action=proxy; q=0.00From: sip:[email protected]: Basic bWlyaWFtOkJvb3N0ZXJzAMDwCall-ID: [email protected]: Sat, 10 Mar 2001 14:52:40 GMTTo: sip:[email protected]: 0

03/10/2001 09:52:40:237866 Sent to: 207.3.232.90:5060 REGISTER sip:research.telcordia.com SIP/2.0Via: SIP/2.0/UDP 10.1.1.130:5060CSeq: 1 REGISTER Expires: 3600Contact: sip:[email protected]:5060;q=0.00 From: sip:[email protected]: Basic bWlyaWFtOkJvb3N0ZXJzAPAYCall-ID: [email protected] Date: Sat, 10 Mar 2001 14:52:40 GMTTo: sip:[email protected]: 0


Sample INVITE and Re-Invite

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 10.1.4.131:5060CSeq: 1 INVITEContact: sip:[email protected]:5060Expires: 3600From: sip:dutta@dutta-lt4Call-ID: [email protected]: application/sdpPriority: normalDate: Fri, 09 Mar 2001 02:25:39 GMTTo: sip:[email protected]: 121v=0o=dutta 482467205023 984104739 IN IP4 10.1.4.131s=Untitledc=IN IP4 10.1.4.131t=0 0m=audio 10000 RTP/AVP 0

03/08/2001 21:27:56:924728Sent to: 10.1.4.51:5060INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 10.1.1.130:5060Contact: sip:[email protected]:5060CSeq: 2 INVITEFrom: sip:dutta@dutta-lt4Content-Type: application/sdpDate: Fri, 09 Mar 2001 02:27:56 GMTCall-ID: [email protected]: sip:[email protected]; tag=388643458667.10.1.4.51Content-Length: 121v=0o=dutta 661157196696 984104876 IN IP4 10.1.1.130s=Untitledc=IN IP4 10.1.1.130t=0 0

m=audio 10000 RTP/AVP 0


Performance snapshot in 802.11 Environment

INVITE - 455 bytes 100 msec processing time between msgs (OS dependent)

Ringing - 223 bytes 5 msec for Invite to traverse OK - 381 bytes 70 msec for Re-Invite to traverse

(mostly queuing delays) ACK - 261 bytes 150 msec for complete re-registration Bye - 150 bytes 100 msec for address acquisition De-Register - 370 bytes Re-Invite - 450 bytes Re-register - 425 bytes

SIP-CONF-PULVER-2001 Telcordia Technologies Proprietary - Internal use only. See proprietary...

Documents

Transcript of SIP-CONF-PULVER-2001 Telcordia Technologies Proprietary - Internal use only. See proprietary...