Your SlideShare is downloading. ×
0
SIP-based Mobility Management Scheme for Wireless Internet <ul><li>Presenter: Ashutosh Dutta </li></ul><ul><li>  Research ...
Motivation <ul><li>Mobility and wireless are rapidly becoming the rule rather than exception. </li></ul><ul><li>SIP is gai...
Outline <ul><ul><li>Objective </li></ul></ul><ul><ul><li>Mobility Management Requirement </li></ul></ul><ul><ul><li>Existi...
Why is Mobility Management Difficult ? <ul><li>Goals of mobility support in Internet: </li></ul><ul><ul><li>allow a mobile...
Multimedia Protocol  Stack Media Transport Application Daemon Kernel Physical Network H.323 SIP RTSP RSVP RTCP RTP TCP UDP...
Service Profile for all IP wireless network user
State of the Art:  Related Work
State of the Art:  Related Work
Related Work:
Qualitative comparison with Mobility approaches
Objective <ul><li>To develop a mobility management scheme for wireless IP networks  based on SIP signaling scheme </li></u...
Technical Issues for SIP Mobility
SIP Mobility Advantages <ul><ul><li>Easier Interaction with associated standard IETF protocols </li></ul></ul><ul><ul><ul>...
SIP Mobility Basics <ul><li>Supports end-to-end mobility by means of application layer signaling  </li></ul><ul><li>meant ...
Types of Mobility supported by SIP <ul><li>Terminal Mobility </li></ul><ul><ul><li>Pre-session mobility (Micro/Macro/Domai...
Mid-session mobility for TCP based application <ul><li>Mobility problem with TCP applications </li></ul><ul><ul><li>TCP so...
Basics of SIP Mobility <ul><li>Personal Mobility </li></ul><ul><ul><li>Use of one logical address to address a single user...
SIP Mobility - Mobile IP Plain Mobile IP SIP Pre-session Mobility SIP Mid-session mobility 1 2 3 4 1. SIP INVITE 2. 302 cl...
Evaluation Model for SIP and Mobile IP Caller’s Network Callee’s Home Network Callee’s Foreign Network MH HA M hops MH FA ...
SIP-Mobile IP Transport Delay vs. Packet size
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 ...
SIP-Based Mobility in Military Environment Correspondent Host Server Re-direct Server Server Server On-going Media Session...
SIP mobility for Appliances  UPnP Controller Jini Controller LDAP  Store Location Registries (User & Location) Web Browser...
SIP Mobility - Handoff - Correspondent Host (CH) 2. re-INVITE 3. Send Data to New Address By sending SIP re-INVITE message...
SIP Mobility - Handoff Corresponding Host at Mobile Host at IP0 SIP signaling RTP Invite user@domain Contact user@IP2 IP1 ...
Hotmail.com Server Columbia.edu [email_address] Mobile Phone Fixed Phone Host [email_address] [email_address] [email_addre...
Session Mobility using Call transfer [email_address] [email_address] [email_address] Ongoing session 1. REFER Bob@fixed Re...
Registration with  local SIP Registrar <ul><li>From:Alice@NY  (1) </li></ul><ul><li>Contact: 193.1.1.1 </li></ul><ul><li> ...
Use of multicast for hierarchical SIP servers for paging SIP server SIP server SIP server TTL = 1 TTL = 64 TTL = 256 Calle...
The ITSUMO Network Architecture MS: Mobile Station  BS: Base Station  ERC: Edge Router & Controller Control messages ( i.e...
Network Signaling and Control Architecture Signaling:  Wireline IP backbone network Internet Visiting Registrar 3G Access ...
Internet Roaming (RTP Application) SIP Internet Visiting Network Home Network BSC 1 BS BS ERC 1 BSC 2 BS ERC 2 ERC 3 BS BS...
Supporting TCP Applications SIP Server MAAAQ SIP HR SIP Server MAAAQ VR Internet Visiting Network Home Network BSC 1 BS BS...
ITSUMO test-bed Architecture Backbone VLAN Switch 3600 3600 tari.toshiba.com Research.telcordia.com R1 Local Server Local ...
Wireless Internet Telephony Test-bed Protocols
Backbone Diameter Server Home AAA Diameter  Server, visited AAA Home SIP Server tari.toshiba.com Research.telcordia.com 1 ...
NGN Application Server Environment IP SCE Web Server Rapid creation of new services Telcordia ™  NGN Application Server En...
NGN Application Server Architecture Services IP Service Network Service Enabling Tier Middle Tier Application Tier Externa...
Initial/Example SIP-Based Voice Services <ul><li>Call Distribution / TOD routing </li></ul><ul><li>Unattended transfer </l...
Issues & Discussion <ul><li>SIP can partially replace or complement existing mobility solutions </li></ul><ul><li>Survivab...
Q/A
References <ul><li>www.research.telcordia.com/sip-mobile </li></ul><ul><li>Application Layer Mobility Using SIP, MC2R </li...
SIP Mobility Demo for real-time audio
Morristown, NJ, U.S.A. TARI & Telcordia ITSUMO Outdoor Experiment
ITSUMO Outdoor Experiment Purpose: Under the quasi-real environment - Mobility Test - Total system feasibility check
ITSUMO Outdoor Experiment Base Station -Emulating cdma2000 by using WaveLAN -Mobility test by using the eight radio cells
ITSUMO Outdoor Experiment Driving route 300 m
ITSUMO Outdoor Experiment Driving Experiment <ul><li>-Evaluation of the IP mobility </li></ul><ul><ul><li>in terms of Micr...
Mobile IP <ul><li>Mechanism developed for the network layer to support mobility </li></ul><ul><li>Originally intended for ...
Mobile IP Home Agent Foreign Agent Correspondent Host Home Network Foreign Network Mobile Host
Optimizations and Extensions to Base Mobile IP <ul><li>Triangular routing causes additional delays and wastes bandwidth </...
Optimizations and Extensions to Base Mobile IP (contd.) <ul><li>Firewalls reject to forward packets coming from topologica...
Optimizations and Extensions to Base Mobile IP (contd.) <ul><li>Network Assisted, Mobile and Network Controlled (NAMONC) h...
Limitations and Inefficiencies of Mobile IP <ul><li>Encapsulation of packets adds between 8 or 12 bytes and 20 bytes of ov...
Cellular IP (Columbia University, Ericsson) Home Agent Correspondent Host Internet (with Mobile IP) BS BS BS BS Gateway
Cellular IP <ul><li>Base stations snoop actual data packets from mobile hosts to gateway to cache the path taken by them  ...
HAWAII (Bell Labs) Internet Domain Root  Router Domain Root  Router BS BS R R R R R BS R R R R Domain 1 Domain 2
HAWAII <ul><li>The path (route) between the mobile host and the domain root router is specific to that host </li></ul><ul>...
TeleMIP (Telcordia) <ul><li>TeleMIP is an intra-domain mobility solution </li></ul><ul><ul><li>It uses two layers of scopi...
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: Regis...
MIP-LR <ul><li>HLR can be anywhere (geographically distributed) </li></ul><ul><li>No tunneling </li></ul><ul><li>After a m...
DHCP Enhancements for Mobile Wireless <ul><li>Requirement: </li></ul><ul><ul><li>Rapid client configuration(milliseconds r...
DRCP DRCPDISCOVER DRCP ADVERTISEMENT(?) DRCPOFFER DRCPACCEPT Server Client DHCP Client Server DISCOVER OFFER REQUEST ACK A...
DRCP Message Flow Client Server ADVERTISEMENT DISCOVER OFFER ACCEPT/DECLINE Time axis Server Client REQUEST/RELEASE ACK Cl...
DRCP vs DHCP Messages <ul><li>DHCP - 236 bytes </li></ul><ul><li>DRCP - 16 bytes </li></ul><ul><li>93.2 %  improvement </l...
QoS scheme for the Mobile Testbed MS w/Mobile IP QGS QLN QLN CH(Correspondent Host) Initial SLS negotiation Handoff(1) Han...
AAA Functional Model AAAF AAAH A C Local Domain Home Domain AAAH: Home AAA Server AAAF: Foreign AAA Server A: Attendant(MI...
Re-registration (SIP) 03/10/2001 09:52:40:236188 Sent to: 207.3.232.90:5060 REGISTER sip:research.telcordia.com SIP/2.0 Vi...
Sample INVITE and Re-Invite INVITE sip:dutta@10.1.4.51 SIP/2.0 Via: SIP/2.0/UDP 10.1.4.131:5060 CSeq: 1 INVITE Contact: si...
Performance snapshot in 802.11 Environment <ul><li>INVITE - 455 bytes 100 msec processing time between  msgs (OS dependent...
Upcoming SlideShare
Loading in...5
×

DRCP

752

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
752
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Supporting mobility in the Internet is allowing a mobile device to move between different subnets and domains while preserving a possibly ongoing session between the mobile device and its counterpart alive. This is not a trivial requirement to fulfill because IP addresses simply do not work outside the specific networks they belong to. Several protocols and mechanisms have been developed to support mobility in the Internet, and several others are likely to follow, as this is an active research area. This section of the deliverable sorts out and compares several different approaches for micro and macro-mobility.
  • Multiple Data Links: The IP traffic whose source and destination are both on the IP subnet of the ACN network need not pass through any ATM subnet, and avoids the ATM segmentation and reassembly (SAR) processing and overhead. The ATM SAR function introduces some processing delay as well as transmission overhead of about ten percent of total throughput ( i.e., 5/48 = 0.104). Thus, with the multiple data links approach, the IP subnet traffic avoids up to about ten percent loss of link utilization. Note that when the source of a communication is on IP subnet and its destination is on the ATM subnet of ACN network (which may not occur in reality), the SAR can not be avoided. In addition, the multiple data links alternative dictates a static partitioning of the cross link bandwidth between the “IP -bearing” and ATM data links. This static resource sharing is usually less efficient, particularly, when the load of either the IP subnet or the ATM subnet is light while the other link is saturated. Single ATM Data Link: The advantages of this alternative are that: It allows the traffic of the IP and ATM subnets to use the signaling and traffic management features of a single data link mechanism ( i.e., ATM in this case) to dynamically utilize the bandwidth of the cross-link as necessary. It can utilize the control and management capabilities of ATM to facilitate QoS support for IP and native ATM applications of ACN subscribers. For instance, it can use the signaling and QoS features of ATM to determine and allocate the necessary capacity for the IP subnet traffic. The disadvantages of this alternative are that i) all traffic of the IP subnet, regardless of the destination, will experience additional SAR delay and transmission overhead, and ii) ATM cell loss have a more drastic impact on the performance of the IP traffic because loss of a single cell in an IP packet triggers its retransmission.
  • Multiple Data Links: The IP traffic whose source and destination are both on the IP subnet of the ACN network need not pass through any ATM subnet, and avoids the ATM segmentation and reassembly (SAR) processing and overhead. The ATM SAR function introduces some processing delay as well as transmission overhead of about ten percent of total throughput ( i.e., 5/48 = 0.104). Thus, with the multiple data links approach, the IP subnet traffic avoids up to about ten percent loss of link utilization. Note that when the source of a communication is on IP subnet and its destination is on the ATM subnet of ACN network (which may not occur in reality), the SAR can not be avoided. In addition, the multiple data links alternative dictates a static partitioning of the cross link bandwidth between the “IP -bearing” and ATM data links. This static resource sharing is usually less efficient, particularly, when the load of either the IP subnet or the ATM subnet is light while the other link is saturated. Single ATM Data Link: The advantages of this alternative are that: It allows the traffic of the IP and ATM subnets to use the signaling and traffic management features of a single data link mechanism ( i.e., ATM in this case) to dynamically utilize the bandwidth of the cross-link as necessary. It can utilize the control and management capabilities of ATM to facilitate QoS support for IP and native ATM applications of ACN subscribers. For instance, it can use the signaling and QoS features of ATM to determine and allocate the necessary capacity for the IP subnet traffic. The disadvantages of this alternative are that i) all traffic of the IP subnet, regardless of the destination, will experience additional SAR delay and transmission overhead, and ii) ATM cell loss have a more drastic impact on the performance of the IP traffic because loss of a single cell in an IP packet triggers its retransmission.
  • Multiple Data Links: The IP traffic whose source and destination are both on the IP subnet of the ACN network need not pass through any ATM subnet, and avoids the ATM segmentation and reassembly (SAR) processing and overhead. The ATM SAR function introduces some processing delay as well as transmission overhead of about ten percent of total throughput ( i.e., 5/48 = 0.104). Thus, with the multiple data links approach, the IP subnet traffic avoids up to about ten percent loss of link utilization. Note that when the source of a communication is on IP subnet and its destination is on the ATM subnet of ACN network (which may not occur in reality), the SAR can not be avoided. In addition, the multiple data links alternative dictates a static partitioning of the cross link bandwidth between the “IP -bearing” and ATM data links. This static resource sharing is usually less efficient, particularly, when the load of either the IP subnet or the ATM subnet is light while the other link is saturated. Single ATM Data Link: The advantages of this alternative are that: It allows the traffic of the IP and ATM subnets to use the signaling and traffic management features of a single data link mechanism ( i.e., ATM in this case) to dynamically utilize the bandwidth of the cross-link as necessary. It can utilize the control and management capabilities of ATM to facilitate QoS support for IP and native ATM applications of ACN subscribers. For instance, it can use the signaling and QoS features of ATM to determine and allocate the necessary capacity for the IP subnet traffic. The disadvantages of this alternative are that i) all traffic of the IP subnet, regardless of the destination, will experience additional SAR delay and transmission overhead, and ii) ATM cell loss have a more drastic impact on the performance of the IP traffic because loss of a single cell in an IP packet triggers its retransmission.
  • Explain/give examples to the different types of mobility: personal session terminal service. Will not talk about service mobility and interconnection with the current phone system
  • Multiple Data Links: The IP traffic whose source and destination are both on the IP subnet of the ACN network need not pass through any ATM subnet, and avoids the ATM segmentation and reassembly (SAR) processing and overhead. The ATM SAR function introduces some processing delay as well as transmission overhead of about ten percent of total throughput ( i.e., 5/48 = 0.104). Thus, with the multiple data links approach, the IP subnet traffic avoids up to about ten percent loss of link utilization. Note that when the source of a communication is on IP subnet and its destination is on the ATM subnet of ACN network (which may not occur in reality), the SAR can not be avoided. In addition, the multiple data links alternative dictates a static partitioning of the cross link bandwidth between the “IP -bearing” and ATM data links. This static resource sharing is usually less efficient, particularly, when the load of either the IP subnet or the ATM subnet is light while the other link is saturated. Single ATM Data Link: The advantages of this alternative are that: It allows the traffic of the IP and ATM subnets to use the signaling and traffic management features of a single data link mechanism ( i.e., ATM in this case) to dynamically utilize the bandwidth of the cross-link as necessary. It can utilize the control and management capabilities of ATM to facilitate QoS support for IP and native ATM applications of ACN subscribers. For instance, it can use the signaling and QoS features of ATM to determine and allocate the necessary capacity for the IP subnet traffic. The disadvantages of this alternative are that i) all traffic of the IP subnet, regardless of the destination, will experience additional SAR delay and transmission overhead, and ii) ATM cell loss have a more drastic impact on the performance of the IP traffic because loss of a single cell in an IP packet triggers its retransmission.
  • SIP can easily interact with other IETF protocols such as DNS, HTTP, LDAP, SQL. Supports different flavors of Intra-domain and Inter-domain mobility Personal Mobility - Ability for a user to be within reach under the same identifier while using different terminals Service Mobility - Ability to obtain same services regardless of where a user may be roaming Pre-call terminal mobility - Terminal can remain reachable under the same application layer identifier Mid-session terminal mobility for real-time streaming application (RTP/UDP based) Can Co-exist with Mobile IP/Cellular IP for Non-Real-time application (TCP/IP)
  • SIP provides application layer mobility solution in three different ways: pre-session mobility, often known as personal mobility; mid-session mobility, often known as terminal mobility, and service (session) mobility. Personal mobility is the ability for a user to be within reach under the same identifier while using different terminals. Service mobility is the ability to obtain same services regardless of where a user may be roaming. Mid-session terminal mobility or terminal mobility is the ability to keep continuous connectivity while moving between subnets, domains. In other words, SIP supports different flavors of inter-domain and intra-domain mobility. SIP is gaining momentum as the signaling protocol for real-time multimedia calls and it makes sense to use SIP to take care of mobility management because of its server-based approach. Both personal mobility and terminal mobility can be achieved by SIP for real-time communication (real-time traffic is mostly RTP/UDP based).
  • SIP provides application layer mobility solution in three different ways: pre-session mobility, often known as personal mobility; mid-session mobility, often known as terminal mobility, and service (session) mobility. Personal mobility is the ability for a user to be within reach under the same identifier while using different terminals. Service mobility is the ability to obtain same services regardless of where a user may be roaming. Mid-session terminal mobility or terminal mobility is the ability to keep continuous connectivity while moving between subnets, domains. In other words, SIP supports different flavors of inter-domain and intra-domain mobility. SIP is gaining momentum as the signaling protocol for real-time multimedia calls and it makes sense to use SIP to take care of mobility management because of its server-based approach. Both personal mobility and terminal mobility can be achieved by SIP for real-time communication (real-time traffic is mostly RTP/UDP based).
  • SIP provides application layer mobility solution in three different ways: pre-session mobility, often known as personal mobility; mid-session mobility, often known as terminal mobility, and service (session) mobility. Personal mobility is the ability for a user to be within reach under the same identifier while using different terminals. Service mobility is the ability to obtain same services regardless of where a user may be roaming. Mid-session terminal mobility or terminal mobility is the ability to keep continuous connectivity while moving between subnets, domains. In other words, SIP supports different flavors of inter-domain and intra-domain mobility. SIP is gaining momentum as the signaling protocol for real-time multimedia calls and it makes sense to use SIP to take care of mobility management because of its server-based approach. Both personal mobility and terminal mobility can be achieved by SIP for real-time communication (real-time traffic is mostly RTP/UDP based).
  • SIP provides application layer mobility solution in three different ways: pre-session mobility, often known as personal mobility; mid-session mobility, often known as terminal mobility, and service (session) mobility. Personal mobility is the ability for a user to be within reach under the same identifier while using different terminals. Service mobility is the ability to obtain same services regardless of where a user may be roaming. Mid-session terminal mobility or terminal mobility is the ability to keep continuous connectivity while moving between subnets, domains. In other words, SIP supports different flavors of inter-domain and intra-domain mobility. SIP is gaining momentum as the signaling protocol for real-time multimedia calls and it makes sense to use SIP to take care of mobility management because of its server-based approach. Both personal mobility and terminal mobility can be achieved by SIP for real-time communication (real-time traffic is mostly RTP/UDP based).
  • This slide illustrates the basic Mobile IP, and SIP based mobility (both personal and terminal). As evident SIP mobility takes care of triangular routing associated with Mobile-IP and tunneling overhead. SIP’s unique URI scheme and registration mechanism helps to obtain personal mobility using one address irrespective of the mobile node’s location. Terminal mobility is obtained by using Re-INVITE mechanism, both for when CH is static and mobile. It is quite evident from the above diagrams that SIP mobility would take care of tunneling problem associated with Mobile IP and network overhead.
  • This slide shows the simulation model used in a recent study in Telcordia to evaluate SIP and Mobile IP mobility. By varying different parameters such as number of hops, link speed and packet size, several comparisons have been made between Mobile IP and SIP based mobility management. For example the comparison would look different for a ring based network than a mesh or partial mesh based network. Following slides illustrate results of some of the simulations. Here the wireless links are assumed as 2 Mbps, and the wired links are assumed as 10 Mbps. Note that only the last hop is the wireless link.
  • This slide shows the latency in msec for different packet sizes. In this simulation, number of hops between MH and CH are kept constant and the packet sizes were varied. SIP-SD and MIP-SD take both signaling and data factors into the consideration, for giving the average delay, while SIP-D and MIP-D involve just the data factor. As evident latency gap becomes wider as the packet size increases.
  • This graph shows fractional advantage in bandwidth efficiency from using SIP instead of MIP (Mobile IP) as a function of packet size. As evident, the bandwidth efficiency gain is perceived more when packet sizes are small. This curve is based on data packet size only.
  • In this particular example two foot-prints of the two ACNs belong to two different domains. In this case a domain can be a DNS domain or a domain under one ACN gateway. There can be multiple ACN gateways within a DNS domain. The ACN SIP server helps to locate the users on the ground and provides personal mobility by interacting with other SIP servers and SIP user agents on the ground. ACN provides both primary and backup server functionality such as SIP/DNS by advertising its presence to clients and other servers. In the case of a break in the terrestrial communication link between the servers on the ground, the ACN provides all the server functionality. Personal Mobility refers to the ability of end users to originate and receive calls and access subscribed network services on any terminal in any location in a transparent manner, and the ability of the network to identify end users as they move across administrative domains. Personal Mobility: MH acquires IP address via DHCP/DRCP MH finds the SIP server via DHCP/DRCP, SRV Record, Multicast based Pre-provision MH updates home SIP server or nearest SIP server Caller calls the unique URI which gets proxied or redirected Terminal Mobility refers to an end user’s ability to use her/his own terminal in any location and the ability of the network to maintain the user’s ongoing communication as she/he roams across radio cells within the same subnet, subnets within the same administrative and or different administrative domains. MH acquires IP address via DHCP/DRCP The DHCP updates the domain name system (DNS) simultaneously for the new inbound connections MH finds the SIP server via DHCP, SRV MH re-registers with home SIP server or nearest SIP server Sends a Re-Invite to Caller with new contact address in it SDP parameters. SIP session passes this address parameters to upper layer Use of SSRC for RTP application should not be affected by underlying IP changes. It goes through SIP proxy when both end-points (CH and MH) move Session Mobility refers to the end user’s ability to maintain sessions while changing between terminal devices. For example, the user of a mobile terminal should be able to move a specific session to a laptop/DSL terminal without losing the session. End user can obtain services in a transparent manner regardless of visiting network or device. Since most of the networks currently do not support mobile IP, besides Mobile IP has triangle routing and other overhead problems, and basic kernel stack has to be modified on the end-points, it is not suitable for deployment in ACN environment which is so much delay sensitive. On the other hand SIP is gaining momentum as the signaling protocol for real-time multimedia calls. So it is proposed to use SIP to take care of mobility management. Both personal mobility and terminal mobility can be achieved by SIP for real-time communication. Real-time traffic is mostly RTP/UDP based, and thus higher layer error recovery can be taken advantage of if we use SIP as the signaling entity. In this particular example two foot-prints of the two ACNs belong to two different domains. Mobile host registers with a SIP server in the home domain, although it can be better optimized if the mobile host registers with the SIP register in the visited domain. When the correspondent host sends an INVITE to the mobile host, the redirect server has the current information about the mobile host’s location and redirects the INVITE there. Thus personal mobility can be achieved by using unique URI. If the mobile host moves during a session, it sends a new INVITE to the correspondent host using the same call identifier as in the original call setup, and puts the new IP address in the “contact” field of the SIP message’s SDP parameters. At the same time it should also make a new registration at the SIP server with its unique URI for the incoming calls. It would need to update the DNS if the terminal is a mobile server, so that DNS database gets updated dynamically. The scenario above shows both the cases i.e., when CH is static and when CH also moves. When both CH and MH move, Re-invite is sent through the SIP server, since the SIP server would keep track of CH’s location.
  • Let’s examine another scenario/message flow for registration: Alice home network is NY, but Alice is visiting in CA. Alice in the MS in the CA network gets IP address 193.1.1.1, she sends a registration message to the local Registrar CA registrar transforms her contact address to a canonical name where the host is it’s own host name, keep a record of the translation (IP address and canonical name), and forward the registration to Alice home registrar. Then Alice roams, still in CA network, gets a new IP address and sends a SIP registration again to the local(CA) registrar., with new Contact IP address. The registrar updates it’s record mapping the IP address to the canonical name. There is no need to forward the registration to the home registrar. The canonical name, which became Alice’s address out of the visited network has not been changed.
  • SIP provides application layer mobility solution in three different ways: pre-session mobility, often known as personal mobility; mid-session mobility, often known as terminal mobility, and service (session) mobility. Personal mobility is the ability for a user to be within reach under the same identifier while using different terminals. Service mobility is the ability to obtain same services regardless of where a user may be roaming. Mid-session terminal mobility or terminal mobility is the ability to keep continuous connectivity while moving between subnets, domains. In other words, SIP supports different flavors of inter-domain and intra-domain mobility. SIP is gaining momentum as the signaling protocol for real-time multimedia calls and it makes sense to use SIP to take care of mobility management because of its server-based approach. Both personal mobility and terminal mobility can be achieved by SIP for real-time communication (real-time traffic is mostly RTP/UDP based).
  • The most well known protocol in this area is Mobile IP [1], [2] which was first published in 1996. Originally it was intended for travelers with laptops over wired networks, and later has been adopted by the wireless community. Mobile IP is a mechanism developed for the network layer to support mobility. It supports transparency above the IP layer, including the maintenance of active TCP connections and UDP port bindings. According to the Mobile IP specification, a mobile host is associated with a fixed IP address, called its home IP address. When a mobile host connects to a different network other than the one its IP address belongs, the home network of this mobile host forwards packets to it. Specifically, a router, which is usually known as the home agent, on the user’s home network traps the packets destined for the mobile host and forwards it to the new location of the mobile node.
  • Basically, there are two different methods to deliver the packets to a mobile host when it is on a foreign network. With the first method, the mobile host adopts a second (temporary) IP address known as the care-of address and registers it with its home agent. Then, when the home agent receives a packet for this user, it encapsulates the packet in another IP packet ([3], [4]) with the care-of address as the destination address and sends it to the foreign network. The care-of address in this method is said to be co-located and it can be acquired via services like DHCP (Dynamic Host Configuration Protocol) [5]. With the second method, the mobile host first registers with a foreign agent, which is a router on the network the user is visiting. The foreign agent sends (registers) its address to the mobile host’s home agent as the care-of address of the mobile host. Packets that are intended for the mobile host are sent to the foreign agent after the home agent encapsulates them with the IP address of the foreign agent. After decapsulating these packets, the foreign agent delivers them to the mobile host. Encapsulating a packet within another packet until it reaches the care-of address is known as tunneling. Note that, it is not necessary for a home agent and a foreign agent to be a router; they can be implemented on arbitrary nodes on the corresponding networks. Packets from the mobile host do not have to traverse the home agent, the mobile host sends them as usual with its home IP address as the source address. This behavior of base Mobile IP is known as triangular routing . For the methods outlined above to be able to work, a mobile host should be able to know that it has moved from its home network to a foreign network. For this purpose, home agents and foreign agents advertise their presence periodically. A mobile host can also solicit for agent advertisements in case these advertisements are absent.
  • Mobile IP’s routing of all incoming packets via the home network may cause additional delays and waste bandwidth capacity. However if the correspondent host has an idea of where the mobile host is, it can send packets directly to the care-of address of the mobile host. This is achieved by route optimization [6], which is basically providing mobility binding updates to the corresponding host. Binding updates are sent from a home agent upon request, or can be sent upon receiving a warning from a foreign agent if the mobile host changes location during a communication session. In the second case, the former foreign agent will keep forwarding packets to the new one until the correspondent host updates its mobility binding cache and starts sending packets to the new foreign agent. This is also known as smooth handoff . Although theoretically triangular routing could be avoided by letting the correspondent host know where the mobile host is, this requires the correspondent host to be able to encapsulate packets – which is not achievable without changes in the operating system of the correspondent host including authentication mechanisms.
  • Basically outgoing packets from the mobile host to a correspondent host do not have to be routed via the user’s home network. However, if sender’s home IP address contained in the outgoing packets does not match the network the user is actually in (i.e., a topologically incorrect address), then firewalls reject to forward such packets. To avoid this and due to some other considerations, reverse tunneling is defined as an extension to Mobile IP [7]. With reverse tunneling, all packets from a mobile host go through the home agent before reaching the correspondent host. Obviously, triangular routing, which was avoided for packets from the correspondent host to the mobile host by route optimization, is now created for packets emanating from the mobile host. Another optimization proposed to the basic Mobile IP protocol is regional registration [8], which suggests locally registering within a visited domain. A mobile host is required to register with its home agent each time it changes care-of address. However if the distance between the mobile host’s physical location and the home network is large, the signaling delay for these registrations may be long. Regional registration attempts to decrease the number of registrations by keeping a hierarchical structure of foreign agents. As long as a mobile host’s foreign agent is hierarchically under a so-called gateway foreign agent (GFA), it is unnecessary to relay registration messages back to the home agent since the home agent has already registered the GFA’s address as the care-of address.  
  • The base Mobile IP requires that a mobile host register with a foreign agent, and subsequently with its home agent. To make Mobile IP handoffs (i.e., the registration process) friendlier for real-time and delay-sensitive applications, two additional methods are proposed in [9]. With the first of these methods, called the Network Assisted, Mobile and Network Controlled (NAMONC) handoff method, the mobile host is informed (assisted) by the network that a layer 2 handoff is anticipated. It proposes to use simultaneous bindings (multiple registrations at a time) in order to send multiple copies of the traffic to potential movement locations before the actual movement. The other method, called the Network Initiated, Mobile Terminated (NIMOT) handoff method proposes extensions to the base Mobile IP so that foreign agents can utilize information from layer 2. Specifically, 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.
  • There are several limitations and inefficiencies of Mobile IP especially when used for real-time and delay-sensitive applications. Encapsulation of packets adds between 8 and 20 bytes [3], [4] of overhead which is certainly not good for small real-time voice packets. 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 becomes an important issue. That is, failure of a GFA will bring the whole hierarchy down  The 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 approach [10], [11] separates local and wide area mobility (i.e. adopts a domain-based approach). It uses Mobile IP for inter-domain (wide area) mobility. The basic requirements for Cellular IP to be able to function are to isolate the wireless access network from the core of the Internet via a gateway that acts like a foreign agent and to deploy network elements (base stations) specialized for mobility management. Isolating the wireless access from the core is necessary since Cellular IP itself is the layer three routing protocol replacing IP in the wireless access network. Packets from a correspondent host are first sent to the mobile host’s home agent and then tunneled to the gateway where they are decapsulated. Hosts are identified by their home addresses inside the Cellular IP cloud. Packets generated by mobile hosts are sent to the gateway and later to the correspondent host.
  • Cellular IP base stations snoop actual data packets sent from mobile hosts to the gateway to cache the path taken by them (actually, base stations record only the host IP number and the neighboring base station from which the packet was received). 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. In Cellular IP, location-tracking method of mobile hosts depends on whether the hosts are active or idle. An idle host is one that has not received or transmitted a packet for a specific time. The assumption is that, coarsely maintaining the position of idle hosts as a distributed paging cache is enough. To achieve this, a technique known as passive connectivity in cellular telephone systems is mimicked in the Cellular IP layer. Base stations are geographically grouped into paging areas (a paging area may include more than one base stations). Idle hosts send infrequent paging-update packets to the gateway. By doing so, the signaling load is reduced. Note that, for active hosts, a distributed routing cache maintains the exact location of each host. Once a 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.
  • Handoff-Aware Wireless Access Internet Infrastructure (HAWAII) is another effort to complement for Mobile IP’s inefficiency in supporting micro-mobility [12], [13]. In that sense it is similar to the logic behind Cellular IP. The basic assumption is that most user mobility occurs within a domain, therefore optimizing routing and forwarding for efficient support of intra-domain mobility will complement Mobile IP’s macro-mobility support. Another assumption is that base stations are capable of IP routing. HAWAII segregates the network into a hierarchy of domains. For each domain, on the top of the hierarchy, there is a so-called domain root router. Packets addressed for a mobile host in a specific domain first reaches to the domain root router and are then sent to the mobile host. As long as the mobile host moves within a domain, it retains its IP address. Once the mobile host moves into another domain it is assigned a co-located care-of address, and the home agent in the home domain tunnels packets to this address.
  • The path (route) between the mobile host and the domain root router is specific to that host. It is 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, which allows the routers to maintain path state. Principally, the idea is similar to Cellular IP and the regional registration in Mobile IP: a physically distant home agent involvement is not desirable each time the mobile host moves. Four path setup schemes that can be used to re-establish path states when the mobile host moves within a domain are proposed. Two of them forward packets from the old base station to the new base station for a short period (i.e., until the relevant routers update their entries for the specific host). The other two methods do not forward packets during a handoff. Rather, they either bi-cast the packets to two base stations or unicast them for hosts that can simultaneously listen to two base stations. Obviously, 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 (Telecommunications-Enhanced Mobile IP), is an intra-domain mobility solution which uses two layers of scoping within a domain [14], [15]. It reduces the latency of intra-domain location updates by specifying an intra-domain termination point called mobility agent (MA). Intra-domain updates are sent only up to the MA, which provides a globally valid care-of address (COA) to the mobile host. TeleMIP reduces the frequency of global update messages since the MA is located at a higher hierarchy than that of subnets, global updates (to home agent, correspondent hosts, etc.) only occur for inter-domain mobility. It also reduces the requirement of public addresses (IPv4) by adopting a two-level addressing scheme. It promotes the use of private (locally-scoped) addresses for handling intra-domain mobility. In TeleMIP network is divided into domains and one of these domains can be a private domain. Domain identifiers are broadcast in agent advertisement / discovery messages. Network retains control of MA assignment. When a mobile host first moves into a domain, it obtains a global care-of address (mobility agent’s address), as well as a local care-of address. MA’s global COA is sent in the registration message to HA. In IPv4 optimized mode, home agent transmits this global COA to correspondent hosts in its binding updates; in IPv6, mobile host sends the global COA directly to correspondent hosts in binding updates. Mobile host also registers itself (with its local COA) with its MA.
  • This slide shows the architectural layout of TeleMIP and the following describes the functional details. There are foreign agents/ DHCP (DRCP) servers at the subnet level which provide the mobile host with a locally-scoped address which identifies mobile location within the domain. Mobility agent provides mobile host with a global care-of address that stays constant within the domain . Mobility agents are distributed within the domain. Multiple MAs can be provisioned for load-balancing and redundancy within the domain. Mobile host’s location is globally known only up to the MA-level granularity. Mobile host retains the same MA (global care-of address) within the same domain. All packets from the global Internet are tunneled to the MA, which acts as a single point of enforcement/accounting. MA forwards packets to mobile host, using regular IP routing, by using the local COA (co-located or FA) as the destination. On subsequent movement within the domain, mobile host only obtains a new local COA. At that point there is no need to update the home agent or correspondent hosts. However, mobile host updates its MA with its new local COA.
  • Mobile IP with Location Registers (MIP-LR) is a scheme developed to avoid encapsulation of packets [16], [17]. In MIP-LR, each subnet may contain a host that functions as a visitor location register (VLR) and/or a host that functions as a home location register (HLR). Each mobile host can be served by multiple HLRs. Each VLR advertises its presence on its local subnet using agent advertisement messages similar to the ones used for Mobile IP. When a mobile host is located at its local subnet, it is not registered at either the HLR or the VLR. When the mobile host moves to a foreign network it obtains a care-of address (COA). Each VLR owns a pool of IP addresses, which it can assign to visiting mobile hosts as COAs. The mobile host registers with the foreign VLR using the COA it has obtained, which in turn relays the registration to the mobile host’s HLR. The HLR returns a registration reply containing the allowed lifetime for this registration (similar to MIP); the VLR records the mobile host’s COA and the lifetime and forwards the reply to the mobile host. A correspondent host, wishing to send a packet to the mobile host for the first time, issues a query to the HLR, which returns the mobile host’s COA as well as the remaining registration lifetime. The correspondent host then directly sends the packet to the mobile host’s COA. The correspondent host caches a binding for the mobile host’s COA and uses this binding for subsequent packets destined to the mobile host. The correspondent host must refresh its binding cache by querying the HLR again before the mobile host’s remaining registration lifetime expires.
  • In MIP-LR, unlike Mobile IP, HLR can be anywhere (geographically distributed). Also, the tunneling function is eliminated. After a mobile host moves, if the mobile host was previously registered at some other foreign VLR, the new VLR deregisters the mobile host at the old VLR. The deregistration is required so that the mobile host’s old COA can eventually be released for use by some other mobile host. If the old VLR manages COAs, it deallocates the COA that was used by the mobile host and can reuse the COA for some other mobile host. If a VLR runs out of COAs temporarily, it can still issue its own IP address as a COA, and, when a mobile host registers using this COA, inform the HLR accordingly. The HLR in turn informs any correspondent host which queries for the mobile host’s COA; the correspondent host then uses tunneling to send packets to the mobile host, and the foreign VLR must decapsulate such packets before delivering them to the mobile host. After a mobile host moves, the correspondent host will have an outdated mobility binding until the remaining registration lifetime expires and the correspondent host queries the HLR again. Since the remaining lifetime could be long, a mechanism is required to update the cache on the correspondent host. Three schemes are used for this: lazy caching, eager caching and tunneling from old foreign agent to the new one. In lazy caching the mobile host informs the old VLR which sends a warning message to the HLR. HLR, in turn, sends a binding update to the corresponding host. In eager caching, the mobile host issues a binding update to each correspondent host it has active sessions. With the third scheme, the old VLR can relay packets to the new VLR after a request by the mobile host.
  • SIP provides application layer mobility solution in three different ways: pre-session mobility, often known as personal mobility; mid-session mobility, often known as terminal mobility, and service (session) mobility. Personal mobility is the ability for a user to be within reach under the same identifier while using different terminals. Service mobility is the ability to obtain same services regardless of where a user may be roaming. Mid-session terminal mobility or terminal mobility is the ability to keep continuous connectivity while moving between subnets, domains. In other words, SIP supports different flavors of inter-domain and intra-domain mobility. SIP is gaining momentum as the signaling protocol for real-time multimedia calls and it makes sense to use SIP to take care of mobility management because of its server-based approach. Both personal mobility and terminal mobility can be achieved by SIP for real-time communication (real-time traffic is mostly RTP/UDP based).
  • Transcript of "DRCP"

    1. 1. SIP-based Mobility Management Scheme for Wireless Internet <ul><li>Presenter: Ashutosh Dutta </li></ul><ul><li> Research Scientist, Telcordia Technologies, NJ </li></ul><ul><li>[email_address] </li></ul><ul><li>(Joint work with Toshiba America Research Inc., </li></ul><ul><li> Toyota Info Technologies., </li></ul><ul><li> Columbia University) </li></ul>
    2. 2. Motivation <ul><li>Mobility and wireless are rapidly becoming the rule rather than exception. </li></ul><ul><li>SIP is gaining acceptance as the signaling protocol for multimedia conferences and Internet telephony. </li></ul><ul><li>It is essential to support wireless mobile users in a SIP signaling and control environment. </li></ul><ul><li>Current Wireless Standard efforts using SIP </li></ul><ul><ul><li>IETF </li></ul></ul><ul><ul><li>3GPP (Third Generation Partnership Project) </li></ul></ul><ul><ul><li>MWIF (Mobile Wireless Internet Forum) </li></ul></ul><ul><ul><li>3GPP2 </li></ul></ul>
    3. 3. Outline <ul><ul><li>Objective </li></ul></ul><ul><ul><li>Mobility Management Requirement </li></ul></ul><ul><ul><li>Existing mobility solutions </li></ul></ul><ul><ul><li>SIP based mobility </li></ul></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Wireless Internet Testbed Implementation </li></ul></ul><ul><ul><li>Issues and Summary </li></ul></ul><ul><ul><li>SIP Mobility demo </li></ul></ul>
    4. 4. Why is Mobility Management Difficult ? <ul><li>Goals of mobility support in Internet: </li></ul><ul><ul><li>allow a mobile device to move between different subnets and domains </li></ul></ul><ul><ul><li>preserve an ongoing session between the mobile device and its counterpart alive while moving </li></ul></ul><ul><ul><li>Ability to provide same service irrespective of network </li></ul></ul><ul><ul><li>attachment </li></ul></ul><ul><li>Several protocols and mechanisms have been developed </li></ul><ul><li>Broadly divided into </li></ul><ul><ul><li>Network Layer Mobility </li></ul></ul><ul><ul><ul><li>MIP, CIP, HAWAII, TeleMIP, MIP-LR, MIPV6 </li></ul></ul></ul><ul><ul><li>Application Layer Mobility </li></ul></ul><ul><ul><ul><li>SIP based Mobility Management Scheme </li></ul></ul></ul>
    5. 5. Multimedia Protocol Stack Media Transport Application Daemon Kernel Physical Network H.323 SIP RTSP RSVP RTCP RTP 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 DNS LDAP MIP MIP variant CIP CDMA
    6. 6. Service Profile for all IP wireless network user
    7. 7. State of the Art: Related Work
    8. 8. State of the Art: Related Work
    9. 9. Related Work:
    10. 10. Qualitative comparison with Mobility approaches
    11. 11. Objective <ul><li>To develop a mobility management scheme for wireless IP networks based on SIP signaling scheme </li></ul><ul><ul><li>Support for all types of mobility </li></ul></ul><ul><ul><li>Support global roaming </li></ul></ul><ul><ul><li>Independent of underlying wireless technology </li></ul></ul><ul><ul><li>Support for real-time and non-real-time multimedia applications (both TCP and UDP/RTP based applications) </li></ul></ul><ul><ul><li>Inter-work with today’s 1G/2G telephony smoothly </li></ul></ul>
    12. 12. Technical Issues for SIP Mobility
    13. 13. SIP Mobility Advantages <ul><ul><li>Easier Interaction with associated standard IETF protocols </li></ul></ul><ul><ul><ul><li>DNS, HTTP, LDAP for location management </li></ul></ul></ul><ul><ul><ul><li>SLP for service discovery </li></ul></ul></ul><ul><ul><ul><li>AAA protocol (e.g.;Diameter) for inter-domain mobility </li></ul></ul></ul><ul><ul><ul><li>DHCP/DRCP for IP address configuration </li></ul></ul></ul><ul><ul><ul><li>tftp for firware upload </li></ul></ul></ul><ul><ul><ul><li>SDP for providing session parameters (e.g., change mid-call parameters) </li></ul></ul></ul><ul><ul><ul><li>RTP/UDP for transport, RTSP for stream control application (e.g., IP Telephony, voice mail, streaming) </li></ul></ul></ul><ul><ul><li>Elimination of triangular routing and IP-IP encapsulation associated with other mobility approaches such as MIP </li></ul></ul><ul><ul><ul><li>Reduces delay </li></ul></ul></ul><ul><ul><ul><li>Saves network overhead </li></ul></ul></ul><ul><li>End hosts should be equipped with SIP-UA </li></ul><ul><li>Suitable for real-time multimedia traffic such as voice over IP and/or video streaming </li></ul><ul><ul><li>Can be used for RTP/UDP based application as is </li></ul></ul><ul><ul><li>SIP extensions for Non-real-time application </li></ul></ul><ul><li>Complements IPV6 mobility </li></ul><ul><li>Can co-exist with MIP, Cellular IP and other Micro-mobility approaches </li></ul>
    14. 14. SIP Mobility Basics <ul><li>Supports end-to-end mobility by means of application layer signaling </li></ul><ul><li>meant for multi-media/multi-party sessions </li></ul><ul><li>SIP based mobility can also be termed as Application Layer mobility </li></ul><ul><li>More than just hand-off </li></ul><ul><ul><li>supports various types of mobility </li></ul></ul><ul><ul><li>provides flexible services </li></ul></ul><ul><li>Compensate for lack of Mobile IP deployment </li></ul><ul><li>Less reliance on underlying transport network of the ISPs </li></ul><ul><li>Supports application-layer equivalent of Mobile IP registration </li></ul><ul><li>Fast-handoff </li></ul><ul><li>Paging </li></ul>
    15. 15. Types of Mobility supported by SIP <ul><li>Terminal Mobility </li></ul><ul><ul><li>Pre-session mobility (Micro/Macro/Domain) </li></ul></ul><ul><ul><ul><li>pre-session mobility by means of unique URI (ability for a user to </li></ul></ul></ul><ul><ul><ul><li>be within reach under the same identifier </li></ul></ul></ul><ul><ul><ul><li>while using different terminals) </li></ul></ul></ul><ul><ul><ul><li>use of SIP proxy, redirect, registrar </li></ul></ul></ul><ul><ul><ul><li>Hierarchical registration for faster registration update </li></ul></ul></ul><ul><li>Mid-session mobility </li></ul><ul><ul><ul><li>Move between cells, subnets, domains, supports handoffs </li></ul></ul></ul><ul><ul><ul><li>Real-Time (RTP/UDP) </li></ul></ul></ul><ul><ul><ul><ul><li>SIP Re-invite, RTP SSRC/IP address </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Hierarchical proxy and RTP translator for fast hand-off within a </li></ul></ul></ul></ul><ul><ul><ul><ul><li>domain </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Duration limited multicast between subnet handoff </li></ul></ul></ul></ul><ul><ul><ul><ul><li>use of RTSP to control multi-media stream </li></ul></ul></ul></ul><ul><ul><ul><ul><li>server </li></ul></ul></ul></ul>
    16. 16. Mid-session mobility for TCP based application <ul><li>Mobility problem with TCP applications </li></ul><ul><ul><li>TCP socket - bound to source and destination address </li></ul></ul><ul><ul><li>One of these addresses change => connection breaks </li></ul></ul><ul><li>TCP applications: ftp, telnet, web </li></ul><ul><li>Application Layer restart and recovery capabilities </li></ul><ul><ul><li>connection: close header into HTTP request </li></ul></ul><ul><ul><li>FTP variants (e.g., bullet-proof ftp) </li></ul></ul><ul><li>Multi-homing feature of SCTP (IETF) </li></ul><ul><li>TCP-Migrate Option </li></ul><ul><li>SIP-eye enabled in the end-hosts - keeps track of the TCP end-points </li></ul><ul><li>of SIP </li></ul><ul><li>SIP Mobility Proxy (Columbia U.) </li></ul><ul><ul><li>an interceptor to forward data </li></ul></ul>
    17. 17. Basics of SIP Mobility <ul><li>Personal Mobility </li></ul><ul><ul><li>Use of one logical address to address a single user located at different terminal </li></ul></ul><ul><ul><ul><li>One address to many potential terminals </li></ul></ul></ul><ul><ul><li>Many addresses reaching one terminal </li></ul></ul><ul><ul><li>Use of forking Proxy, a user can be reached at any of the devices </li></ul></ul><ul><li>Service Mobility </li></ul><ul><ul><li>Allows users to maintain access to their services while moving or changing devices and network service providers </li></ul></ul><ul><ul><li>Maintain speed dial list, address books, buddy lists, incoming call handling (e.g, CPL) </li></ul></ul><ul><ul><li>As part of registration message (on a routine basis or upon network change) it conveys </li></ul></ul><ul><ul><ul><li>current network address </li></ul></ul></ul><ul><ul><ul><li>Properties of the device (media supported, call priority etc.) </li></ul></ul></ul><ul><ul><ul><li>Other configuration elements </li></ul></ul></ul><ul><li>Session Mobility </li></ul><ul><ul><li>Allow a user to maintain an on going media session even while changing terminals </li></ul></ul><ul><ul><li>Use of MGCP/Megaco </li></ul></ul><ul><ul><li>Third-party Call control </li></ul></ul><ul><ul><li>Refer Mechanism </li></ul></ul>
    18. 18. SIP Mobility - Mobile IP Plain Mobile IP SIP Pre-session Mobility SIP Mid-session mobility 1 2 3 4 1. SIP INVITE 2. 302 client moved 3. SIP INVITE 4. SIP OK 5. Data 1. MN moves 2. MN re-invites 3. SIP OK 4. Data CH SIP Server Home Network MN moves MN Foreign Network SIP Server CH When both move CH HA FA Home Network MN Tunnelled data data data CH SIP Server Home Network MN 1 2 3 4 5 CH SIP Server Home Network MN moves MN Foreign Network
    19. 19. Evaluation Model for SIP and Mobile IP Caller’s Network Callee’s Home Network Callee’s Foreign Network MH HA M hops MH FA High-speed link Low-speed link N hops CH P hops MIP SIP
    20. 20. SIP-Mobile IP Transport Delay vs. Packet size
    21. 21. 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 Bandwidth Efficiency Gain SIP b/w efficiency gain
    22. 22. SIP-Based Mobility in Military Environment Correspondent Host Server Re-direct Server Server Server On-going Media Session (RTP) DRCP DNS 192.4.8.18 Mobile Node SIP Domain 1 Domain 2 192.4.8.20 Server CH moves SIP Server LDAP DNS Stream Server ACN 1 SIP Server LDAP DNS Stream Server ACN 2 1. Register 2. Invite 3. Client moved 5. INVITE Proxy message 7. Re-invite Pre-session Move MN 192.6.10.18 6. Proxy 1B 1A Proxying Registration 4. Invite 192.6.11.20 MN Mid-session Move
    23. 23. SIP mobility for Appliances UPnP Controller Jini Controller LDAP Store Location Registries (User & Location) Web Browser & SIP UA Pocket PC Web phone Web server SIP User Agent Mobile Service Logic SIP Proxy SIP Proxy SIP User Agent Watcher WML SIP http http SIP Provisioning System OSGi GW SIP for Appliances Talisman Wide-area wireless v/d Short-range LAN I/f Location-sensitive services Personalized services
    24. 24. SIP Mobility - Handoff - Correspondent Host (CH) 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 BS BS
    25. 25. SIP Mobility - Handoff Corresponding Host at Mobile Host at IP0 SIP signaling RTP Invite user@domain Contact user@IP2 IP1 -> IP2 Mobile Host SIP UA RAT IP2 RTP SIP signaling
    26. 26. Hotmail.com Server Columbia.edu [email_address] Mobile Phone Fixed Phone Host [email_address] [email_address] [email_address] SIP Personal Mobility
    27. 27. Session Mobility using Call transfer [email_address] [email_address] [email_address] Ongoing session 1. REFER Bob@fixed Referred-By: B1 2. INVITE Bob@fixed Referred-By: B1 3. BYE Alice@Wonderland Session Transferred 1 2 3 4 INVITE with no SDP 200 OK [email_address] INVITE from 2 200 5 ACK SDP(4) 6 ACK [email_address] [email_address] Third party control Session Mobility RTP
    28. 28. Registration with local SIP Registrar <ul><li>From:Alice@NY (1) </li></ul><ul><li>Contact: 193.1.1.1 </li></ul><ul><li> (3) CA From:Alice@NY (2) NY </li></ul><ul><li>Registrar Contact: Alice%NY@CA Registrar </li></ul><ul><li>From:Alice@NY (4) </li></ul><ul><li>Contact: 193.1.2.3 </li></ul><ul><li>Visited Network Registrar needs to map Alice’s URI to a canonical name </li></ul><ul><li>Only first registration in CA needs to go all the way to NY </li></ul><ul><li>All SIP messages to Alice need to go through SIP server/registrar for address translation. </li></ul>
    29. 29. Use of multicast for hierarchical SIP servers for paging SIP server SIP server SIP server TTL = 1 TTL = 64 TTL = 256 Caller INVITE Forwards upstream INVITE with multicast addr. Callee has moved here searches failure INVITE with wider scope INVITE with TTL =256 failure
    30. 30. The ITSUMO Network Architecture MS: Mobile Station BS: Base Station ERC: Edge Router & Controller Control messages ( i.e.. ., signaling) Visited Network Wireline IP backbone network Home Network ERC Internet Regional IP network Regional IP network ERC Radio Access Network (RAN) Radio Access Network (RAN) BS BS BS DCA DCA IDCA MS IP Domain Control Agent Domain Control Agent Inter-Domain Control Agent BS
    31. 31. Network Signaling and Control Architecture Signaling: Wireline IP backbone network Internet Visiting Registrar 3G Access SIP 3G Access SIP Server MAAAQ SIP VR Regional IP network Visiting Network MS DCA Home Network 3G Access SIP 3G Access Regional IP network SIP Server MAAAQ SIP HR Home Registrar DCA Inter-Domain Registrar SIP Server MAAAQ IDR IDCA SIP UA in mobiles and hosts.
    32. 32. Internet Roaming (RTP Application) SIP 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 Registrar Visiting Registrar Corresponding Host SIP DRCP DRCP INVITE 128.59.10.6 IP ch 207.3.232.10 207.3.232.10 207.3.240.10 SLA/SA 128.59.11.6 RTP Translator <ul><li>SIP UA in mobiles and hosts. </li></ul>SIP Server AAAQ HR SIP Server MAAAQ VR
    33. 33. 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 Registrar Visiting Registrar Corresponding Host SIP DHCP DHCP SIP_EYE Ongoing TCP Connections INFO INFO INFO <ul><li>Equip MS with SIP_EYE. </li></ul>IP ch 207.3.232.10 207.3.232.10 207.3.240.10 128.59.10.6 IP ch1 Mobility Proxy 128.59.11.6 Register
    34. 34. ITSUMO test-bed Architecture Backbone VLAN Switch 3600 3600 tari.toshiba.com Research.telcordia.com R1 Local Server Local Server VLAN Switch R2 Local Server R3 Local Server VLAN Switch VLAN Switch SIP Server/Call Agent SIP Server Border Router Border Router QOS QOS HA/DRCP Server DRCP Server Multicast Proxy DRCP Server DRCP Server AAA Server AAA Server External Omni Antenna Micro Macro Domain External Demo SIP UA/Mini_RGW QOS QOS BURP BURP BURP SIP Server/Call Agent Ad Media Server
    35. 35. Wireless Internet Telephony Test-bed Protocols
    36. 36. Backbone Diameter Server Home AAA Diameter Server, visited AAA Home SIP Server tari.toshiba.com Research.telcordia.com 1 2 Local SIP Server Diameter Client BURP Server D R C P Server Diameter Client BURP Server D R C P Server Diameter Client BURP Server D R C P Server
    37. 37. NGN Application Server Environment IP SCE Web Server Rapid creation of new services Telcordia ™ NGN Application Server End-user devices SIP Softswitch PSTN phone SIP phone Media Server Gateway 3rd Party Application Servers API SIP 3rd Party SIP Application Servers Customer Self-Service Service Execution Services
    38. 38. NGN Application Server Architecture Services IP Service Network Service Enabling Tier Middle Tier Application Tier External B/OSS and IT Backend Infrastructure Information Content Tier SCE JAIN / Parlay / OSA APIs SIP LDAP, DIAMETER,MGCP Java Java Internet Services Gateway Open IDL Interface (CORBA) ISG APIs (Java, CORBA, XML) ISG APIs Location & Presence Applications Web Portal Applications Enterprise Applications Media Server Open Services Gateway (CORBA, Java,XML)
    39. 39. Initial/Example SIP-Based Voice Services <ul><li>Call Distribution / TOD routing </li></ul><ul><li>Unattended transfer </li></ul><ul><li>Call forward unconditional </li></ul><ul><li>Call forward on Busy </li></ul><ul><li>Call forward on No Answer </li></ul><ul><li>Single line extension </li></ul><ul><li>Find-me </li></ul><ul><li>Call screening </li></ul><ul><li>Simultaneous ringing </li></ul><ul><li>Secondary number – In/Out </li></ul><ul><li>Do not disturb </li></ul><ul><li>Call waiting </li></ul><ul><li>Call Hold </li></ul><ul><li>Consultation hold </li></ul>
    40. 40. Issues & Discussion <ul><li>SIP can partially replace or complement existing mobility solutions </li></ul><ul><li>Survivability under dynamic network condition </li></ul><ul><ul><li>When SIP server/proxy dies </li></ul></ul><ul><li>Registration with Local registrar vs. home registrar </li></ul><ul><li>Both the end hosts moving </li></ul><ul><li>SIP for Adhoc networking </li></ul><ul><li>Fast handoff mechanism </li></ul>
    41. 41. Q/A
    42. 42. References <ul><li>www.research.telcordia.com/sip-mobile </li></ul><ul><li>Application Layer Mobility Using SIP, MC2R </li></ul><ul><li>Henning Schulzrinne, Elin Wedlund </li></ul><ul><li>Application Layer Mobility Management Scheme for Wireless </li></ul><ul><li>Internet, 3G Wireless Conference </li></ul><ul><li>Dutta,Vakil, Baba, Chen,Tauil, Schulzrinne </li></ul>
    43. 43. SIP Mobility Demo for real-time audio
    44. 44. Morristown, NJ, U.S.A. TARI & Telcordia ITSUMO Outdoor Experiment
    45. 45. ITSUMO Outdoor Experiment Purpose: Under the quasi-real environment - Mobility Test - Total system feasibility check
    46. 46. ITSUMO Outdoor Experiment Base Station -Emulating cdma2000 by using WaveLAN -Mobility test by using the eight radio cells
    47. 47. ITSUMO Outdoor Experiment Driving route 300 m
    48. 48. ITSUMO Outdoor Experiment Driving Experiment <ul><li>-Evaluation of the IP mobility </li></ul><ul><ul><li>in terms of Micro, Macro and Global Mobility </li></ul></ul>
    49. 49. Mobile IP <ul><li>Mechanism developed for the network layer to support mobility </li></ul><ul><li>Originally intended for travelers with laptops over wired networks </li></ul><ul><li>Later adopted by the wireless community </li></ul><ul><li>Maintains active TCP connections and UDP port bindings </li></ul><ul><li>A mobile host is associated with a fixed IP address (home IP address) </li></ul><ul><li>When a mobile host connects to a different network other than the one its IP address belongs, the home network forwards packets to it </li></ul><ul><li>A router (home agent) on the user’s home network delivers the packets to the mobile host </li></ul>
    50. 50. Mobile IP Home Agent Foreign Agent Correspondent Host Home Network Foreign Network Mobile Host
    51. 51. Optimizations and Extensions to Base Mobile IP <ul><li>Triangular routing causes additional delays and wastes bandwidth </li></ul><ul><li>If the correspondent host knows where the mobile host is, it can send packets directly to the care-of address of the mobile host </li></ul><ul><li>Route optimization: </li></ul><ul><ul><li>binding updates sent from a home agent upon request, or </li></ul></ul><ul><ul><li>sent upon receiving a warning from a foreign agent if the mobile host changes location during a communication session </li></ul></ul><ul><li>Smooth handoff: </li></ul><ul><ul><li>former foreign agent will keep forwarding packets to the new one until the correspondent host updates its mobility binding cache </li></ul></ul><ul><li>Theoretically triangular routing avoided, but correspondent host must be able to encapsulate packets - not possible without changing the operating system of the correspondent host </li></ul>
    52. 52. Optimizations and Extensions to Base Mobile IP (contd.) <ul><li>Firewalls reject to forward packets coming from topologically incorrect addresses (host’s IP address does not match the network </li></ul><ul><li>Reverse tunneling: all packets from a mobile host go through the home agent </li></ul><ul><ul><li>triangular routing again ! </li></ul></ul><ul><li>A mobile host registers with home agent each time it changes care-of address  signaling delay for long distances </li></ul><ul><li>Regional registration: locally register within a visited domain </li></ul><ul><ul><li>hierarchical structure of foreign agents </li></ul></ul><ul><ul><li>local foreign agents under a gateway foreign agent (GFA) </li></ul></ul><ul><ul><li>home agent registers the GFA’s address as the care-of address </li></ul></ul>
    53. 53. Optimizations and Extensions to Base Mobile IP (contd.) <ul><li>Network Assisted, Mobile and Network Controlled (NAMONC) handoff: </li></ul><ul><ul><li>Faster handoff for real-time applications </li></ul></ul><ul><ul><li>Network informs mobile host that a layer 2 handoff is anticipated </li></ul></ul><ul><ul><li>Uses simultaneous bindings (multiple registrations at a time), sends multiple copies of the traffic to potential movement locations </li></ul></ul><ul><li>Network Initiated, Mobile Terminated (NIMOT) handoff: </li></ul><ul><ul><li>Foreign agents use layer 2 triggers to initiate a pre-registration prior to receiving a formal registration request from the mobile host </li></ul></ul><ul><li>Both methods assume considerable involvement of information from layer 2 </li></ul>
    54. 54. Limitations and Inefficiencies of Mobile IP <ul><li>Encapsulation of packets adds between 8 or 12 bytes and 20 bytes of overhead </li></ul><ul><li>Although triangular routing is avoided with route optimization, with reverse tunneling it becomes a fact again </li></ul><ul><li>With route optimization, changes are necessary in the operating systems of the correspondent hosts </li></ul><ul><li>With regional registration, reliability an important issue (failure of a GFA will bring the whole hierarchy down  </li></ul><ul><li>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 </li></ul>
    55. 55. Cellular IP (Columbia University, Ericsson) Home Agent Correspondent Host Internet (with Mobile IP) BS BS BS BS Gateway
    56. 56. Cellular IP <ul><li>Base stations snoop actual data packets from mobile hosts to gateway to cache the path taken by them </li></ul><ul><li>To route packets from the gateway to the mobile host, base stations use the reverse of this path </li></ul><ul><li>Hosts that have not transmitted packets for a while are removed from the routing cache of the base stations </li></ul><ul><li>Idle hosts send infrequent paging-update packets to the gateway </li></ul><ul><ul><li>coarsely maintaining the position of idle hosts (passive connectivity) </li></ul></ul><ul><li>Active hosts’ exact locations are known </li></ul><ul><li>If an active mobile host moves to another base station during a call </li></ul><ul><ul><li>it sends a route-update packet back to the gateway </li></ul></ul><ul><ul><li>new base station(s) record this path accordingly </li></ul></ul>
    57. 57. HAWAII (Bell Labs) Internet Domain Root Router Domain Root Router BS BS R R R R R BS R R R R Domain 1 Domain 2
    58. 58. HAWAII <ul><li>The path (route) between the mobile host and the domain root router is specific to that host </li></ul><ul><ul><li>established (during power-up) and updated (during movement) for that mobile host in the domain root router and intermediate routers </li></ul></ul><ul><li>This information is refreshed periodically by the mobile host </li></ul><ul><li>Different path setup schemes possible to re-establish path states during handoff </li></ul><ul><ul><li>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) </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><li>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 </li></ul>
    59. 59. TeleMIP (Telcordia) <ul><li>TeleMIP is an intra-domain mobility solution </li></ul><ul><ul><li>It uses two layers of scoping within a domain </li></ul></ul><ul><li>Reduce the latency of intra-domain location updates by specifying an intra-domain termination point (Mobility Agent or MA). </li></ul><ul><ul><li>Intra-domain updates only up to the MA, which provides a globally valid COA to mobile host. </li></ul></ul><ul><li>Reduce the frequency of global update messages </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Reduce the requirement of public addresses (IPv4) </li></ul><ul><ul><li>By promoting a two-level addressing scheme, it promotes the use of private (locally-scoped) addresses for handling intra-domain mobility. </li></ul></ul>
    60. 60. TeleMIP’s Architecture Layout
    61. 61. 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: Query 3: COA 4: Binding cache (COA) 5: Un -Encapsulated data packets sent directly to COA HLR CH Home Network: a.b.c
    62. 62. MIP-LR <ul><li>HLR can be anywhere (geographically distributed) </li></ul><ul><li>No tunneling </li></ul><ul><li>After a mobile host moves: </li></ul><ul><ul><li>if it was registered at some other foreign VLR, the new VLR deregisters it at the old VLR. </li></ul></ul><ul><li>If a VLR runs out of COAs temporarily, it issues its own IP address as COA  tunnels packets temporarily </li></ul><ul><li>After a mobile host moves: </li></ul><ul><ul><li>correspondent host will have an outdated mobility binding </li></ul></ul><ul><ul><li>a mechanism is required to update the cache on the correspondent host: </li></ul></ul><ul><ul><ul><li>Lazy caching, eager caching and tunneling from old foreign agent to the new one </li></ul></ul></ul>
    63. 63. DHCP Enhancements for Mobile Wireless <ul><li>Requirement: </li></ul><ul><ul><li>Rapid client configuration(milliseconds rather than seconds) </li></ul></ul><ul><ul><li>Automatic client reconfiguration (independent of lease time) </li></ul></ul><ul><ul><li>Efficient use of scarce wireless bandwidth </li></ul></ul><ul><ul><li>Allowing clients to be routers </li></ul></ul><ul><ul><li>Enhanced registration (e.g., user identification and security) </li></ul></ul><ul><ul><li>Flexible proxies that can act both as relay/server </li></ul></ul><ul><ul><li>Message exchange without broadcast </li></ul></ul><ul><li>How to achieve: </li></ul><ul><ul><li>Shrink message size </li></ul></ul><ul><ul><li>Minimize messages in transactions </li></ul></ul><ul><ul><li>Minimize use of broadcast </li></ul></ul>
    64. 64. DRCP DRCPDISCOVER DRCP ADVERTISEMENT(?) DRCPOFFER DRCPACCEPT Server Client DHCP Client Server DISCOVER OFFER REQUEST ACK ARP CHECK ARP REPLY 15 Sec.
    65. 65. DRCP Message Flow Client Server ADVERTISEMENT DISCOVER OFFER ACCEPT/DECLINE Time axis Server Client REQUEST/RELEASE ACK Client moves to a new Domain Extending the lease
    66. 66. DRCP vs DHCP Messages <ul><li>DHCP - 236 bytes </li></ul><ul><li>DRCP - 16 bytes </li></ul><ul><li>93.2 % improvement </li></ul>
    67. 67. QoS scheme for the Mobile Testbed MS w/Mobile IP QGS QLN QLN CH(Correspondent Host) Initial SLS negotiation 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 802.11b 802.11b 802.11b
    68. 68. AAA Functional Model AAAF AAAH A C Local Domain Home Domain AAAH: Home AAA Server AAAF: Foreign AAA Server A: Attendant(MIP FA, SIP server, …) C: Client Pre-established SA
    69. 69. Re-registration (SIP) 03/10/2001 09:52:40:236188 Sent to: 207.3.232.90:5060 REGISTER sip:research.telcordia.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.130:5060 CSeq: 1 REGISTER Expires: 0 Contact: sip:dutta@10.1.4.131:5060; expires=&quot;Sat, 10 Mar 2001 15:41:48 GMT&quot;; a ction=proxy; q=0.00 From: sip:dutta@research.telcordia.com Authorization: Basic bWlyaWFtOkJvb3N0ZXJzAMDw Call-ID: 212114567@10.1.1.130 Date: Sat, 10 Mar 2001 14:52:40 GMT To: sip:dutta@research.telcordia.com Content-Length: 0 03/10/2001 09:52:40:237866 Sent to: 207.3.232.90:5060 REGISTER sip:research.telcordia.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.130:5060 CSeq: 1 REGISTER Expires: 3600 Contact: sip:dutta@10.1.1.130:5060;q=0.00 From: sip:dutta@research.telcordia.com Authorization: Basic bWlyaWFtOkJvb3N0ZXJzAPAY Call-ID: 212114568@10.1.1.130 Date: Sat, 10 Mar 2001 14:52:40 GMT To: sip:dutta@research.telcordia.com Content-Length: 0
    70. 70. Sample INVITE and Re-Invite INVITE sip:dutta@10.1.4.51 SIP/2.0 Via: SIP/2.0/UDP 10.1.4.131:5060 CSeq: 1 INVITE Contact: sip:dutta@10.1.4.131:5060 Expires: 3600 From: sip:dutta@dutta-lt4 Call-ID: 172764989 @10.1.4.131 Content-Type: application/sdp Priority: normal Date: Fri, 09 Mar 2001 02:25:39 GMT To: sip:dutta@10.1.4.51 Content-Length: 121 v=0 o=dutta 482467205023 984104739 IN IP4 10.1.4.131 s=Untitled c=IN IP4 10.1.4.131 t=0 0 m=audio 10000 RTP/AVP 0 03/08/2001 21:27:56:924728 Sent to: 10.1.4.51:5060 INVITE sip:dutta@10.1.4.51 SIP/2.0 Via: SIP/2.0/UDP 10.1.1.130:5060 Contact: sip:dutta@10.1.1.130:5060 CSeq: 2 INVITE From: sip:dutta@dutta-lt4 Content-Type: application/sdp Date: Fri, 09 Mar 2001 02:27:56 GMT Call-ID: 172764988@10.1.4.131 To: sip:dutta@10.1.4.51; tag=388643458667.10.1.4.51 Content-Length: 121 v=0 o=dutta 661157196696 984104876 IN IP4 10.1.1.130 s=Untitled c=IN IP4 10.1.1.130 t=0 0 m=audio 10000 RTP/AVP 0
    71. 71. Performance snapshot in 802.11 Environment <ul><li>INVITE - 455 bytes 100 msec processing time between msgs (OS dependent) </li></ul><ul><li>Ringing - 223 bytes 5 msec for Invite to traverse </li></ul><ul><li>OK - 381 bytes 70 msec for Re-Invite to traverse (mostly queuing delays) </li></ul><ul><li>ACK - 261 bytes 150 msec for complete re-registration </li></ul><ul><li>Bye - 150 bytes 100 msec for address acquisition </li></ul><ul><li>De-Register - 370 bytes </li></ul><ul><li>Re-Invite - 450 bytes </li></ul><ul><li>Re-register - 425 bytes </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×