Mobility Support for IP over Wireless ATM

Mobility Support for IP over Wireless ATM Arup Acharya, Jun Li, Furquan Ansari, and Dipankar Raychaudhuri C&C Research Laboratories, NEC USA

ABSTRACT

A wireless ATM system consists of a core network infrastructure that provides mobility support to end terminals and a wireless access link. This article outlines two schemes for supporting mobility of IP terminals in this network. In the first scheme, location management and handoff support is integrated within the ATM signaling and control framework (“mobile ATM”), and mobility is transparently supported at the IP layer by mobile ATM underneath. In the second approach, the IP protocol stack is directly executed on ATM switches (without an intermediate ATM signaling stack) using an IP switching technique called IPSOFACTO, and terminal mobility is supported via Mobile IP.

T

he rapid worldwide growth of digital wireless communication services motivates a new generation of mobile switching networks to serve as infrastructure for such services. Wireless ATM [1–3] has been proposed as a candidate solution for providing broadband wireless services. A wireless ATM system consists of two major components: a “mobile ATM” wired infrastructure that supports location management of mobile users and connection handoff, and physical, medium access, and datalink control protocols for extending ATM cell transmission over wireless links. Providing mobility support within the core network for “native ATM” connections by extending the ATM signaling and con-

trol framework has been discussed in [3–6]. This article is concerned with supporting mobility within IP under this network architecture. In this article, we first summarize the location management and handoff protocols necessary to implement “mobile ATM” and then describe how mobility is transparently supported at the IP layer by mobile ATM underneath. Next, we consider an alternate approach where the IP protocol stack is directly executed on ATM switches (without an intermediate ATM signaling stack) using an IP switching technique called IPSOFACTO (for IP Switching Over Fast ATM Cell Transport) [7, 8], and terminal mobility is supported via Mobile IP [9].

MOBILE ATM The mobile ATM network architecture consists of radio ports along with components of a standard ATM network, such as switched and fixed terminals interconnected via wireline links.

Mobile ATM Mobile ATM core network

Mobile ATM

Mobile ATM

Switch + mobility

WATM base station + mobility

Mobile ATM

GSM radio interface GSM handset

WATM radio NIC

"M" NNI

"M" NNI

GSM

"M" UNI

"M" NNI

WATM terminal

Dynamic TDMA MAC, data link control

IP Switch + mobility

"M" UNI ATM base station +mobility

"M" UNI ATM base station + mobility

GSM radio card WLAN radio card

IP terminal

Wireless LAN

■ Figure 1. A generic mobile ATM network supporting GSM, wireless LAN, and wireless ATM access.

84

0163-6804/98/$10.00 © 1998 IEEE

IEEE Communications Magazine • April 1998

Mobile–ATM layer

SIG, UNI + mobility

ATM

Wireless control

SAAL

SIG, NNI + mobility SAAL

SAAL ATM

ATM

Wireless ATM radio access layer

ATM Wireless ATM PHY radio access layer

Mobile terminal

Radio port/base station

ATM PHY

Switch

■ Figure 2. Software architecture for supporting mobility.

Caller

S1 Release (foreign address) S3 S2

LOCATION MANAGEMENT In ATM, each terminal address consists of a prefix (13 bytes) that is supplied by the switch to which the terminal is connected. In our proposed integrated scheme (Fig. 3), each radio port acts as a switch with one or more wireless ATM interfaces. The network address (home address) supplied by a mobile terminal’s “home switch” serves as an endpoint identifier, which never changes regardless of the terminal’s location. When the terminal moves to a different radio port, it is assigned a “foreign address” by this radio port; that is, the radio port (foreign switch) allocates a new network prefix to the terminal. In Fig. 3, radio port b1 is the home switch for the mobile terminal, which assigns a network prefix for the terminal’s home address (b1.1); after the terminal moves to the wireless cell under radio port b3, it is assigned a foreign address, b3.1. A correspondent terminal (CT/caller) uses a mobile terminal’s home address to initiate connection setup to the terminal. If the terminal is currently attached to its home switch, then connection establishment proceeds similar to that for a fixed terminal. If the terminal’s current attachment point is a switch other than its home switch, the home switch responds to the setup(home address) message with a connection release. The release() message carries the mobile terminal’s current foreign address. The caller then issues a setup() message using the foreign address. This is routed to the mobile terminal via its foreign switch. In Fig. 3, the CT’s initial call setup message using the terminal’s home address is routed to b1, which then returns the terminal’s current foreign address (b3.1) to the caller within the release(). When connected to a switch other than its home, the mobile terminal maintains a virtual connection (location update VC) to its home switch. When the terminal changes its location, a handoff operation is executed to reroute the location update VC to the terminal’s new foreign switch. After each move, the mobile terminal sends its current foreign address to its home switch via this location update VC.

SIG, NNI + mobility

Wireless control

In this network architecture, radio ports (base stations) provide connectivity to mobile terminals via a wireless link (e.g., radio). While supporting wireless ATM terminals (as in Fig. 1 ), each radio port provides a cell switching function between one or more of its wired and wireless interfaces; with regard to network routing/signaling functions, it offers user-to-network interfaces (UNIs) to wireless terminals, network-to-network interfaces (NNIs) to other switches, and possibly UNI interfaces to fixed terminals directly connected to it via wireline links. This model allows an end-to-end ATM connection to be set up to the mobile terminal. The current location of the terminal is resolved during connection setup, resulting in an optimal end-to-end path, along with handoff support for rerouting the connection when the terminal moves to another radio port. The mobile ATM layer thus consists of enhancements to ATM UNI and NNI signaling to support location management and handoff, as shown in Fig. 2. Non-ATM wireless terminals are supported in this architecture by terminating the ATM-level connection at the radio port, and forwarding the received data over the wireless segment using a separate link-specific protocol. In this scenario, the base station runs a proxy UNI signaling node, on behalf of the non-ATM wireless terminal.

Setup (home address)

Home switch

Setup (foreign address)

b4

Locn update b2

b3

b1

Move Home address b1.1

Foreign address b3.1

■ Figure 3. Location management in mobile ATM.

S Crossover switch

S1

Setup (caller) S3 S2

b4 Handoff control VC b3

b1

b2

HANDOFF After a connection has been established to a mobile endpoint, handoff protocols are necessary to reroute existing active connections when the endpoint moves to a different radio port. Several mechanisms for rerouting a connection [3, 10–14] have been proposed; we outline the path splicing method below.


■ Figure 4. The path splicing scheme for handoff.

85

Mobile ATM M NNI

IP

the requested QoS, this switch henceforth acts as the crossover switch; otherwise, the setup() is forMobile warded toward the remote destination.2 ATM IP Wireless •The crossover switch then sends a connect() mesLAN M NNI sage along the spliced subpath to the new radio Mobile Mobile port. The new radio port forwards it to the current ATM connection ATM ATM rerouted by radio port; note that the connect() now includes M "M" mobile ATM UNI NNI the VC number to be used by the mobile terminal Move IP IP-to-ATM for the connection being handed off, after it moves gateway to the new radio port. IP "M" UNI The second stage in the handoff process involves changing the data path at the crossover switch. This is Internet accomplished by sending a handoff confirm (conMobile ATM core network nection-id) signaling message from the mobile termiIP host nal to the crossover switch. The crossover switch Wireless responds by changing its internal VC routing tables so LAN that the new end-to-end path uses the spliced subpath. For example, in Fig. 4 the VC tables at switch S1 are ■ Figure 5. Interworking between mobile IP and mobile ATM. modified to reflect S1–b4 and S–S1 as the two links of the rerouted connection. It then sends a handoff confirm ack(), which tears down the existing subpath to the current The mobile terminal or current radio port, and informs the mobile terradio port decides that the terminal IP minal that it can change its operating must change its network attachment IP with transparent mobility support radio frequency and connect to the point based on signal strength meaOverlay from mobile ATM new radio port. surements. At this time, the mobile In the third stage, the mobile termiterminal sends a handoff(new nal switches to the operating frequency radio-port) signaling message to its Mobile ATM of the new radio port and changes the current radio port (b3 in Fig. 4), asking core network VC number (on the wireless segment) for a connection handoff to another for each connection to that received radio port(b4). The current radio port ■ Figure 6. Using mobile ATM to support within the connect() message. (b3) forwards this handoff() mesmobility in IP. Details regarding syntax and format sage to the new radio port (b4) via a of signaling messages necessary for handoff control VC. A separate handoff location management and handoff may be found in [3, 15–18]. procedure is executed for each connection (VC), and the handoff() message contains the following information eleIP OVER MOBILE ATM ments: • Source and destination address Consider an IP internetwork, part of which is a mobile ATM • Global connection ID network, as shown in Fig. 5. Mobile IP [9] is used to provide • Quality of service (QoS)/traffic parameters mobility support within the internetwork as a whole. However, The following protocol is then executed: within the mobile ATM “cloud,” location management and • The new radio port first executes a local call admission handoff is supported via extensions to ATM signaling and control to check if the wireless cell can accommodate the control protocols, as described in the previous section. Mobiliconnection to be handed off. ty of a terminal within the mobile ATM network is transparent • It then initiates a connection setup to the remote endto mobile IP (i.e., no location updates are generated at the point (S) of the connection, using the supplied QoS mobile IP level). Mobility support in IP within this cloud is parameters: a setup() message is sent toward the provided by mapping IP to (mobile) ATM, as shown in Fig. 6. remote endpoint (S). This message includes a flag in When a mobile host first enters the mobile ATM network, addition to the contents of a regular setup(), which it is assigned a home ATM address and a foreign IP address by indicates that the path setup is triggered by a handoff. the radio port to which it connects. This radio port acts as the • This setup() is eventually guaranteed to encounter a terminal’s “home switch” as long as the terminal remains withswitch (S1) on the existing connection path.1 This switch in the mobile ATM network. Binding between the two addresses does not change, regardless of the terminal’s mobility within attempts to splice the new path segment onto the existing the mobile ATM network. As required by mobile IP, the terpath. The traffic parameters (e.g., cell delay) computed minal’s foreign IP address is sent to the terminal’s (mobile IP) for the new path segment are combined with the computhome agent3 in the IP cloud, through a combination of staned value for the remainder of the original data path between this switch and the remote endpoint; in Fig. 4, dard IP-over-ATM protocols (e.g., ATMARP [19] or MPOA the new path segment {b4–S1} is spliced onto {S1–S}. If [20] ) within the mobile ATM cloud and regular IP outside of the cumulative path parameters fall within the bounds of the cloud. Subsequent moves within the mobile ATM network generate location updates only at the mobile ATM level; each move causes the terminal to be assigned a new foreign ATM address, and the terminals’s “home (ATM) switch” maintains 1 The connection ID is used to match an existing data path with a handthe mapping between its home and foreign ATM addresses. M UNI

off-induced setup message. 2

If no suitable crossover switch is found, the connection will be dropped when the mobile enters the new cell.

86

3

It is possible that the terminal’s (mobile IP) home agent is within the mobile ATM cloud.


IP routing table Destination IP ITF address

Switch controller/router IP

After a connection has been set up to the terminal (possibly from a host outside the mobile ATM cloud via the gateway between ATM and non-ATM portions of the internetwork), it is subsequently rerouted via handoff protocols for each move within the mobile ATM cloud. (A key point to remember is that since IP is connectionless, the underlying ATM connection will need to be torn down based on activity timers; i.e., if no IP packets are sent or received on the ATM connection for a prespecified duration, the connection will be released.)

4.1.2.3 IP packet 82

BASIC OPERATION OF IPSOFACTO The basic operation in IPSOFACTO (Fig. 7) is to map all unused incoming VCs on each input port to the switch controller. A cell-level switch path for an IP flow (unicast or multicast) is established as follows: • A sender selects an unused VC on an outgoing link to forward the first packet of a new flow. • The switch controller downstream receives the packet, selects outgoing links after an IP routing table lookup and, for each link, selects an unused VC and forwards the packet. • The controller then adds an entry in the VC tables, corresponding to {input port, input VC} and {output port(s), output VC(s)}. Subsequent packets in the flow are then switched at the cell level according to this VC table entry. For further details on IPSOFACTO, the reader is referred to [7, 8, 21, 23]. A related protocol to IPSOFACTO is Ipsilon’s

IP router (mobile IP) IPSO FACTO

Wireless ATM link

Mobile IP + IPSOFACTO

3

51

51

(a) 2

82

VC table Input Output Port VPI/VCI Port VPI/VCI 1 82 Router 1 82 3 51

2

4.1.2 (IP forwarding)

1

IPSOFACTO (IP Switching Over Fast ATM Cell Transport) [21] is a method for mapping IP flows to ATM switches. In contrast to standard IP-over-ATM techniques [19–20], no ATM signaling is necessary to set up a path for IP flows through ATM switches. Switch controllers run an IP routing protocol and execute IP forwarding. IPSOFACTO minimizes the number of packets forwarded through the controller by establishing a shortcut VC within each switch after forwarding just the first packet of each flow. Implicit control messages present in IP (e.g., TCP FIN, IP multicast Prune and Join) are used to add, delete, or modify the switched path.


(b)

1.2

3

(c) Add switched path (Port 1, VC 82 Port 3, VC 51)

■ Figure 7. Basic operation of IPSOFACTO.

MOBILITY SUPPORT VIA IPSOFACTO


IPSOFACTO ATM layer



Wireless ATM link

■ Figure 9. IPSOFACTO over wireless ATM links.





IP router (mobile IP) IPSO FACTO IP router (mobile IP) IPSO FACTO

Set up new switched path Mobile IP + IPSOFACTO Reclaim previous switched path

Internet (packet-based router network)

IP

Wireless LAN

IP host

Move IP router (mobile IP) IPSO FACTO

IP

Wireless LAN

■ Figure 8. Mobility support via IPSOFACTO (mobile IP). IP switching scheme [24], which uses IFMP [25] to communicate the mapping of a IP flow to a VC between neighboring switches in a hop-by-hop fashion.

MOBILE IP In an IPSOFACTO network, mobile IP [9] can be used to send IP packets to a mobile host: addressing of mobile terminals, location updates, and rerouting packets to the right location are handled by mobile IP. Using mobile IP, IPSOFACTO sets up a switched path (Fig. 8) to the terminal’s current location during the process of routing the first packet; this process of setting up a switched path is the same regardless of whether the destination is a static or mobile terminal. When the terminal changes its location, packets are now forwarded to its new location; consequently, IPSOFACTO sets up a switched path along the new route, and the switched path to the previous location is reclaimed. A number of optimizations for setting up and reclaiming switched paths are possible in the context of mobile IP. Details are beyond the scope of this article and will be presented in a separate article. The reader may refer to [7] for a brief outline of possible optimizations. The network shown in Fig. 8 uses IPSOFACTO within the core ATM network, while the mobile terminal connects to the core network via a wireless LAN. In this case, IP packets are transmitted over the wireless link, and IPSOFACTO’s role does not extend beyond the core network. In contrast, it is also possible to extend IPSOFACTO all the way to a mobile terminal (Fig. 9) when wireless ATM [26, 27] is used as the access protocol on the wireless link.

87

SUMMARY AND FUTURE WORK This article outlined two schemes for supporting mobility in a wireless ATM system. In the first scheme, the ATM signaling and control framework is extended to support location management and handoff. IP is mapped to (mobile) ATM under this architecture, and mobility is supported transparently at the IP level by mobile ATM underneath. In the second scheme, the IP stack is directly executed over ATM hardware using IPSOFACTO, and mobile IP is used to route packets to a mobile terminal’s current location. IPSOFACTO is responsible for reclaiming and setting up switched paths as a terminal migrates between radio ports. Our current work involves executing both the IP and ATM protocol stacks (with mobility support) on the same switch (“dual stack architecture”) and exploring how the mechanisms provided within each stack can be combined in a synergistic way.

References [1] D. Raychaudhuri and N. Wilson, “ATM Based Transport Architecture for Multiservices Wireless Personal Communication Network,” IEEE JSAC, 1994. [2] D. Raychaudhuri, “Wireless ATM Networks: Architecture, System Design and Prototyping,” IEEE Pers. Commun., 1996. [3] A. Acharya et al., “Mobility Management in Wireless ATM Networks,” IEEE Commun. Mag. 1997. [4] A. Acharya et al., “Design and Prototyping of Location Management and Handoff Protocols for Wireless ATM Networks,” IEEE ICUPC, 1997. [5] A. Acharya et al., “Location Management and Handoff in Mobile ATM Networks,” Proc. 3rd Int’l. Wksp. Mobile Multimedia Commun. (MoMuC-3), 1996; also in Mobile Multimedia Communications, D. J. Goodman and D. Raychaudhuri, Eds., Plenum Press, 1997. [6] A. Acharya et al., “A Prototype Architecture for Mobile ATM Networks,” ACM Mobile Comp. Rev., 1997. [7] A. Acharya, R. Dighe and F. Ansari, “A Framework for IP Switching Over Fast ATM Cell Transport (IPSOFACTO), Proc. SPIE Voice, Video, and Data Commun., 1997. [8] A. Acharya, R. Dighe, and F. Ansari, “IP Switching Over Fast ATM Cell Transport (IPSOFACTO): Switching Multicast Flows,” Proc. GLOBECOM ’97, 1997. [9] C. Perkins, Ed., “IP Mobility Support,” RFC 2002. [10] C-K Toh, “A Hybrid Handover Protocol for Local Area Wireless ATM Networks,” ACM/Baltzer Mobile Networks and Appls., 1996. [11] H. Mitts et al., “Lossless Handover for Wireless ATM,” ACM/Baltzer Mobile Networks and Appls., 1996. [12] B. Rajagopalan, “Mobility Management in Integrated Wireless-ATM Networks,” Proc. 1st Int’l. Conf. Mobile Comp. and Networking (MobiCom), 1995. [13] P. Agrawal et al., “SWAN: A Mobile Multimedia Wireless Network,” IEEE Pers. Commun. 1996. [14] R. Yuan, “A Signaling and Control Architecture for Mobility Support in Wireless ATM Networks,” ACM/Baltzer Mobile Networks and Appls., 1996. [15] A. Acharya, J. Li, and D. Raychaudhuri, “Primitives for Location Management and Handoff in Mobile ATM Networks,” ATM Forum cont. 96–1121, 1996. [16] A. Acharya, J. Li, and D. Raychaudhuri, “Signaling Syntax Extensions for Location Management in Mobile ATM,” ATM Forum cont. 96–1624, 1996. [17] J. Li, A. Acharya, and D. Raychaudhuri, “Signaling Syntax Extensions for Handoff Control in Mobile ATM,” ATM Forum cont. 96–1625, 1996. [18] H. Mitts et al., “Micro-cellular Handover for WATM Release 1.0: Proposal for Scope and Terms of Reference,” ATM Forum cont. 97—0226, Apr. 1997. [19] M. Laubach, “Classical IP and ARP over ATM,” RFC 1577, 1994. [20] A. N. Fredette, Ed., “ATM Forum Multiprotocol Over ATM Version 1.0” (baseline text v. 16). [21] A. Acharya, R. Dighe, and F. Ansari, “IPSOFACTO: IP Switching Over Fast ATM Cell Transport,” Internet draft; draft-acharya-ipsw-fast-cell00.txt, 1997.. [22] J. V. Luciani et al., “NBMA Next Hop Resolution Protocol (NHRP),” Internet draft, work in progress; draft-ietf-rolc-nhrp-13.txt. [23] A. Acharya et al., “Dynamic QoS Support through IP Switching Over Fast ATM Cell Transport (IPSOFACTO): Mapping RSVP Flows,” Proc. Int’l. Symp. Broadband Euro. Networks (SYBEN ’98), 1998. [24] P. Newman, G. Minshall, and T. Lyon, “IP Switching: ATM under IP,” accepted for publication, IEEE/ACM Trans. Networking, 1996. [25] P. Newman et al., “Ipsilon Flow Management Protocol Specification of IPv4 Version 1.0,” RFC 1953, Ipsilon, Sprint.

88


Mobile ATM "M" NNI



Mobile ATM "M" NNI

Mobile ATM "M" NNI

■ Figure 10. Dual stack architecture. [26] P. Narasimhan et al., “Design and Performance of Radio Access Protocols in WATMnet, a Prototype Wireless ATM Network,” Proc. 6th WINLAB Wksp. Third Generation Wireless Info. Networks, 1997. [27] C. Johnston, “A Network Interface Card for Wireless ATM networks,” Proc. IEEE PIMRC, 1996.

BIOGRAPHIES ARUP ACHARYA ([email protected]) received his B.Tech. (Honors) degree in computer science and engineering from the Indian Institute of Technology, Kharagpur, in 1987, and M.S. and Ph.D. degrees in computer science from Rutgers University in 1990 and 1995, respectively. He was then briefly associated with the Wireless Information Networks Laboratory (WINLAB), Rutgers University, as a post-doctoral fellow, where he worked on IP-multicast extensions for mobile hosts. He is presently as research staff member with the Systems Architecture Group, C&C Research Laboratories, NEC USA, Princeton, New Jersey, and is working on protocols for mobility support in wireless ATM and fast IP switching over ATM (IPSOFACTO). JUN LI ([email protected]) received his B.Sc. and M.Sc. degrees in electrical engineering from Xidian University, Xi’an, China, in 1983 and 1985, respectively. He was with Beijing Information Technology Institute as a research engineer from 1986 to 1990, working in the area of speech synthesis and recognition. From October 1987 to December 1988 he worked in NEC’s C&C Central Laboratories, Kawasaki, Japan, as a visiting scholar. From 1990 to 1993, he worked with Japanese software companies in Tokyo and San Francisco on developing and localizing network software products. Since 1993 he has been a Ph.D. student in the ECE department of Rutgers University, specializing in wireless multimedia services and broadband networking technologies. He is now with NEC C&C Research Laboratories, Princeton, New Jersey, working in the fields of mobile and wireless ATM networking technologies. FURQUAN ANSARI ([email protected]) received a B.E. (Hons.) degree in electronics and communication engineering from the University of Mysore, India, in 1994, and an M.S. degree in electrical engineering from the University of Kansas in 1996. He was briefly associated with the Indian Institute of Science, Bangalore, India, as a research assistant, where he worked on developing voice messaging system adapters. Since October 1996 he has been with NEC USA, C&C Research Laboratories, Princeton, New Jersey. His research areas include fast IP switching over ATM, mobile computing, and Internet architecture and services. DIPANKAR RAYCHAUDHURI [F] ([email protected]) received his B.Tech. (Honors) degree in electronics and electrical communication engineering from the Indian Institute of Technology, Kharagpur, India, in 1976, and M.S. and Ph.D. degrees in electrical engineering from the State University of New York at Stony Brook in 1978 and 1979, respectively. From 1979 to 1992 he was with the David Sarnoff Research Center (formerly RCA Laboratories), Princeton, New Jersey, as a member of technical staff, senior member of technical staff, and head, Broadband Communications Research. Since January 1993 he has been with NEC USA, C&C Research Laboratories, Princeton, where he is currently department head, Systems Architecture, with technical focus on ATM switching/protocols, broadband wireless, and distributed multimedia software. In 1995 his research group demonstrated one of the first proof of concept wireless ATM networks (WATMnet), capable of delivering multimedia services to portable computing devices. He has authored approximately 85 technical papers and nine U.S. patents.
