Mobility Management in Wireless ATM Networks - Semantic Scholar

ABSTRACT Mobile ATM offers a common wired network infrastructure to support mobility of wireless terminals, independent of the wireless access protocol. In addition, it allows seamless migration to future wireless broadband services, such as wireless ATM, by enabling mobility of end-to-end ATM connections. In spite of the diversity in mobile networking technologies (e.g., cellular telephony, mobile-IP, packet data services, PCS), all of them require two fundamental mechanisms: location management and handoff. This article describes different schemes for augmenting a wired ATM network to support location management of mobile terminals and handoff protocols for rerouting a connection data path when the endpoint moves. A prototype implementation of mobile ATM integrating mobility support with ATM signaling and connection setup, is presented. It shows how mobile ATM may be used to provide mobility support to an IP terminal using non-ATM wireless access.

Mobility Management in Wireless ATM Networks Arup Acharya, Jun Li, Bala Rajagopalan, and Dipankar Raychaudhuri NEC USA, C&C Research Laboratories

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. Given the wide range of radio access technologies being deployed for both telephony and Internet access, new mobile switching architectures are needed to provide generic, costeffective support for a variety of cellular, personal communications services (PCS) and wireless data technologies. In addition, mobile networks being deployed in the next few years should be capable of smooth migration to future broadband services based on high-speed wireless access technologies, such as wireless asynchronous transfer mode (ATM) (Fig. 1) [1]. This article introduces a network architecture for supporting terminal mobility in a ATM network and presents protocols for mobility management within this architecture. This architecture, which we refer to as mobile ATM, supports mobility of both ATM and non-ATM mobile terminals through a common set of protocols for location management and handoff.

choice of ATM as the backbone network for a generic mobility supporting infrastructure is motivated by: • ATM’s superior cost/performance when used as a switching technology for large traffic volumes. • ATM’s rich transport capabilities which allows different traffic types to be carried over the same network; for example, voice circuits for cellular calls may be mapped to constant-bit-rate (CBR) connections using ATM adaptation layer type 1 (AAL1) packets, while IP datagrams may be transported through an unspecified-bit-rate (UBR) or available-bit-rate (ABR) connection using AAL5 packets. A second advantage of using mobile ATM is that it offers

Mobile ATM core network

MOTIVATION FOR MOBILE ATM Presently, there exists a wide range of technologies for supporting mobile users. Examples include cellular telephony [2, 3], PCS [4], and mobile Internet Protocol (IP) [5]. Regardless of the specific protocol, all such technologies must support two fundamental mechanisms: • Locating users prior to or during connection establishment • Rerouting connections when users move Thus, in order to support mobility, each of these existing technologies replicate mobility supporting functionality within their respective network infrastructures (Fig. 2). An important motivation for mobile ATM is to provide a high-speed backbone network that supports these two fundamental primitives, and thereby provide a common infrastructure network to a diverse set of mobile technologies. The

100

0163-6804/97/$10.00 © 1997 IEEE

S1

S3 S2 b4 ATM

b1 b2

Wireless LAN

b3 ATM

GSM Non-ATM wireless access

Second-generation (wireless ATM) terminal

■ Figure 1. Mobile ATM.

IEEE Communications Magazine • November 1997

Mobile ATM

Mobile ATM

mobility support to terminals, indepen"M" core network UNI dent of the wireless access technology. Mobile The ATM-level connection is termiSwitch WATM WATM Mobile ATM + mobility radio NIC ATM nated at the radio port, and the terminal "M" "M" UNI received traffic is forwarded on the NNI wireless segment using a link-layer Dynamic TDMA access method that is specific to the MAC, data link WATM control mobile technology being emulated on Mobile base station the mobile ATM network. The radio ATM + mobility "M" port thus acts as a gateway, converting NNI traffic from a format specific to the Switch + mobility GSM wireless link to a suitable AAL on the GSM wired ATM link. For example, if a "M" "M" GSM radio port within the mobile ATM netUNI UNI ATM base station radio work offers a wireless local area netIP terminal + mobility interface ATM base station work (LAN) access (e.g., 802.11), an + mobility IP terminal may send IP packets to the GSM Wireless radio card radio port by encapsulating the packGSM WLAN radio LAN handset ets within (Ethernet-like) wireless card LAN frames. The radio port forwards ■ Figure 2. A generic mobile ATM network supporting Global System for Mobile Commuthe received packets onto a ATM connications (GSM), wireless local area networks (LANs), and wireless ATM access. nection. Additionally, the IP terminal may use the mobility support offered by mobile ATM (instead of mobile IP) NETWORK ARCHITECTURE by mapping IP onto (mobile) ATM: the terminal’s migration between radio ports is transparent to IP, and mobile ATM (instead of mobile IP) is used for handoffs and location manhe mobile ATM network architecture consists of radio agement. The description of our current prototype later in the ports along with components of a standard ATM network, article will further illustrate this aspect. such as switched and fixed terminals interconnected via wireLastly, the primary long-term motivation for mobile ATM line links. In this network architecture, radio ports (base stais to augment the existing ATM protocol stack with mobility tions) provide connectivity to mobile terminals via a wireless support to enable wireless ATM terminals seamless migration link (e.g., radio). This architecture allows for both ATM and between radio ports. Protocols for location management and non-ATM wireless access as follows. While supporting wirehandoff described in the next two sections assume a network less ATM terminals (Fig. 3), each radio port provides a cell architecture with wireless ATM terminals; a later section switching function between one or more of its wired and wireexplains how the same network can support non-ATM wireless interfaces; with regard to network routing/signaling funcless access, specifically IP over wireless LAN. tions, it offers user-to-network interfaces (UNIs) to wireless terminals, network-to-network interfaces (NNIs) to other switches, and possibly UNI interfaces to fixed Fixed terminals directly connected to it via wireline links. terminal This model allows setup of an end-to-end ATM connection to the mobile terminal. The current location S1 of the terminal is resolved during connection setup, First resulting in an optimal end-to-end path, along with Second connection handoff support for rerouting the connection when connection the terminal moves to another radio port. The mobile ATM layer thus consists of enhancements to ATM S3 UNI and NNI signaling to support location manageS2 ment and handoff, as shown in Fig. 4. b4 Each radio port in the above architecture operates at a different radio frequency in relation to neighboring radio ports to avoid channel interference. Thus, Handoff b1 when a mobile terminal moves to a different radio port it needs to change its operating frequency to that of the radio port. Spatially adjacent radio ports comb2 b3 municate through a handoff control VC (virtual connection) to facilitate handoff signaling messages (described later). The radio coverage areas under adjacent radio ports overlap, and a handoff procedure is always executed between adjacent radio ports. Compared to an ATM network with wireline links and fixed terminals, the above architecture is different in three ways.

T

ATM switch

Mobile terminal

Radio port

■ Figure 3. Network architecture of mobile ATM.


Static terminal

Multi-Access Wireless Medium — ATM has been defined for point-to-point physical media, while wireless media inherently offer multi-access capability.

101

Mobile ATM layer SIG, NNI + mobility

ATM

Wireless control

SAAL

Wireless control

SIG, UNI + mobility

SAAL

SAAL

ATM

ATM

Wireless ATM ATM radio access PHY layer

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 nonATM wireless terminal.

SIG, NNI + mobility

LOCATION MANAGEMENT

ATM PHY

In networks (ATM or otherwise), each end device Wireless ATM (terminal) is identified by a network address. radio access layer This address serves two purposes: • As an endpoint identifier for the terminal; Radio port/base station Switch Mobile terminal transport protocols use such endpoint identifiers to establish transport-level connections ■ Figure 4. Software architecture for supporting mobility. • As a location identifier; the address often also implicitly identifies the network route to reach the endpoint Message Information element Content Traditionally, a single identifier served both purposes since the location of a terminal relative SETUP/ Caller’s home address Null: if caller is at home to the network did not change. With the advent of CONNECT Called party’s home address Null: if called party is at home mobile terminals, it is no longer possible for a single identifier to support both functions. The locaRELEASE Cause MOBILE_AWAY tion of a mobile terminal will change often; so will its location identifier, since it determines reachabil■ Table 1. Changes necessary to Q.2931 signaling for location management. ity to the mobile terminal. On the other hand, its endpoint identifier (i.e., its name) should remain unchanged so that other terminals can identify the mobile termiFurthermore, wireless media are generally associated with a nal regardless of its attachment point to the network. higher bit error rate and lower bandwidths than wireline media. Thus, specific physical layer (radio), medium access LOCATION MANAGEMENT AS AN EXTERNAL SERVICE (MAC), and data link control (DLC) protocols are needed to transmit ATM cells over wireless links, with reliability compaIn this approach, the interswitch signaling protocol is not rable to wireline links and yet maintaining link utilization at aware of mobility; that is, the name of a mobile terminal is an acceptable level. This topic is outside the scope of this artiresolved to its current location id using a location management cle, and the interested reader is referred to [6, 7] for wireless service external to the connection establishment process. The ATM MAC/DLC protocols, and to [8] for design of a wireless location id is then used to set up the connection. The primary ATM network interface card (NIC). advantage of this approach is that the interswitch connection setup process does not need to be changed to accommodate Location Management — Existing protocols for connection mobile terminals. However, the network is now responsible setup assume that a terminal’s address implicitly identifies its for providing hooks to terminals to access the location manattachment point (“location”) to the network. However, with agement service, and an additional mechanism is needed to mobile terminals the location of such a terminal may no longer distinguish mobile endpoint ids from those of static endpoints be deduced from its endpoint address. Additional addressing so that the location management service is invoked solely for schemes and protocols are needed to locate and track mobile mobile endpoint ids. The second requirement will very likely terminals, along with suitable modifications to the connection setup process. For example, in Fig. 3 the mobile terminal is Caller located in the cell under radio port b3, during the setup of the Name resolution first connection. When the second connection is set up, it has (b1.1) moved to the cell under b4. Thus, the ATM connection setup S1 protocols must now be augmented to dynamically resolve a mobile endpoint’s location. The next section describes our Setup (b3.1) schemes for addressing, and location resolution, update, and caching in this network architecture (Fig. 3). Handoff — After a connection has been set up, the connection path in a network with fixed terminals does not change during the connection’s lifetime, except due to link/switch failures. This assumption is invalidated when the endpoint is mobile. For example, in Fig. 3 when the mobile terminal moves from radio port b3 to b4, connection1 needs to be rerouted by deleting the subpath from switch S3 to b3 and augmenting the truncated path from S3 to b4. Key issues for handoff support include: • Selection of a crossover switch (e.g., switch S3 in Fig. 3) such that the rerouted datapath maintains the quality of service (QoS) guarantees of the original datapath • Avoiding cell loss while rerouting the data path Non-ATM wireless terminals are supported in this architecture by terminating the ATM-level connection at the radio

102

Home node

S2

b4

b1

Name: b1.1 locn-ld: b1.1

b2

Locn update (b1.1, b3.1) Move

b3

Name: b1.1 locn-ld: b3.1

■ Figure 5. Location management as a separate service.


Caller

need the network address space to be partitioned a priori between mobile and static endpoints to allow easy recognition of addresses representing mobile endpoint ids. In Fig. 5 the endpoint id b1.1 is resolved by the location management service to the mobile’s current location id, b3.1. The location id b3.1 is then used to set up the connection to the mobile.

Release (foreign address)


S3

S2

INTEGRATED SCHEME Our preferred approach to location management in mobile ATM extends and adapts the scheme proposed by the Internet Engineering Task Force (IETF) Mobile IP Working Group for (connectionless) IP [5] to (connection-oriented) ATM networks. In this approach (Fig. 6), location management is integrated with the connection setup procedure. This scheme extends the signaling framework of ATM with additional information elements (IEs) in existing signaling messages (SETUP, CONNECT, and RELEASE) to integrate location resolution of a mobile endpoint with connection setup. Location resolution of a mobile terminal is integrated with connection setup as follows. A caller issues a SETUP message using the callee’s home address without a priori knowledge of whether the callee is a mobile terminal, or which switches on the connection path are mobility-enabled. The SETUP message carries a flag which informs switches downstream (from the caller) if an entity exists upstream capable of mobility support. It is clear that the home switch of a mobile terminal must be mobility-capable. Thus, there is always at least one switch on the connection path that is capable of mobility support (when either the caller or callee is mobile). When the SETUP message reaches the NNI/UNI boundary on the callee’s side (i.e., the switch with which its home address is registered), either a CONNECT or RELEASE response is returned. A CONNECT response is returned when either a) the terminal is a static terminal or b) the terminal is mobile but presently attached to its home switch. A RELEASE message is returned when the terminal is currently attached to a switch other than its home (case c), and there is a mobility-capable switch upstream; the RELEASE message must carry the mobile’s current foreign address. In both cases b and c, the response (RELEASE/CONNECT) must identify the connection as a mobile connection to interested intermediate switches. Note that if the caller is a mobile terminal, the connection must in general be identified as a mobile connection during the SETUP phase itself. In addition, the SETUP message may also carry its home address if the caller initiated the connection from a switch other than its home. In case c above, some entity within the path traversed by the SETUP message needs to make a new attempt at establishing a connection to the mobile terminal’s current location. This attempt is made via a SETUP message that uses the mobile’s foreign address as the callee’s address (instead of its home address). However, unlike case b, the callee’s home address must be included in addition to its foreign address in the SETUP message; this allows creation of a globally unique connection id (GCID) which is needed for handoff control. The rationale for explicitly identifying a connection as “mobile” is to allow switches on the connection path that are capable of mobility support to prepare for possible handoffs of the connection in the future. It should be noted that this scheme does not require changes to the network routing or topology exchange protocols (PNNI [9]). The integrated scheme simply utilizes information provided by PNNI to route connection setups, not to propagate location information.

Setup (foreign address)

S1

b4

Setup (home address) Location update Home switch

b3

b2 b1

Move

Home address b1.1

Foreign address b3.1

■ Figure 6. Location management in mobile ATM.

Key advantages of this scheme include: • Unlike mobile IP or cellular telephony, the end-to-end connection path set up by the integrated scheme is optimal. • There is no partitioning of the address space between fixed and mobile terminals, and no special routes must be created for handling connection setup to mobile terminals. • The size of the network routing tables is unaffected by the number of mobile terminals within the system. Each radio port advertises reachability to a single network prefix (similar to a switch with only wireline interfaces). The size of network routing tables is proportional to the number of switches in the system.

PROPOSED SYNTAX FOR Q.2931 SIGNALING Table 1 summarizes the changes necessary to Q.2931 signaling [10] for location management. If any endpoint of a connection is a mobile terminal away from its home, the SETUP/ CONNECT message needs to carry the endpoint’s home address; if attached to its home switch (e.g., as would be the case for a static terminal), this new information element can be left blank. The home addresses of both endpoints of a connection are used to generate a global connection id that never changes, regardless of terminal mobility at either endpoint. When the RELEASE message is used to notify a caller of the called party’s foreign address, the “cause” information element is assigned a new value, namely MOBILE_AWAY (to distinguish between the use of RELEASE solely for connection teardown and for location resolution).

COMPARISON OF THE TWO LOCATION MANAGEMENT SCHEMES INFLEXIBILITY OF USAGE The external scheme requires that the overall network address space be globally partitioned among static and mobile terminals. This requires that each terminal be functionally labeled as a mobile or static terminal (i.e., allocated an address based on its anticipated usage pattern). This implies that a terminal

103

S2

Path rerouting

S2

NETWORK BANDWIDTH EFFICIENCY AND PROCESSING OVERHEAD

COS

2

COS 1

BS2

S1

S1

3

2

S2

3

BS2 Path Splicing

BS1

1

BS1

Handoff control VC

Path extension

S1

1

Handoff request/response

2

Handoff confirm/ack

3

Join/join complete

BS2 3 1

COS

BS1

2

■ Figure 7. Schemes for handoff. that has been labeled as “static” can never change its attachment point without requiring administrative intervention (to acquire a new address and release its old address). This defeats a primary motivation for mobile ATM: transparent migration of terminals.

LATENCY OF CONNECTION SETUP Under the external location management scheme, a connection setup to a mobile terminal must be preceded by location resolution, regardless of a mobile’s location. Although the terminal may never have relocated to a switch other than its home switch, its mobile address must be translated to a topologically significant address. Under the integrated scheme, the connection setup is routed to a mobile’s home switch; thus, there is significant gain in the connection setup latency when the mobile is at home.

FORWARD COMPATIBILITY A location management scheme should be “forward compatible”; that is, as progressively more switches within a network are upgraded to become mobility-aware, the performance of the scheme should improve. This holds true for the integrated scheme; for example, when every access switch becomes mobility aware, the end-to-end path for a connection will be optimal (since, after location resolution, the connection can be rerouted closer to the caller). Thus, while backward compatibility is a valid concern, the overriding factor should be whether the scheme performs better as switches evolve toward mobility support, or its performance stagnates even though switches are upgraded.

104

The integrated scheme reserves connection resources to a mobile’s home switch, even if the mobile is not at home. This drawback exists only for a transient duration (to resolve the terminal’s current location); therefore, its impact on the network bandwidth utilization is small: if a mobile is not at home, the connection resources reserved by the SETUP request in the forward direction are released by a RELEASE response in the reverse direction. Second, the integrated approach increases the processing load on the switches. However, this increase in processing load can be expected to be much smaller than that incurred by handoff protocols, which require more complex operations to be done by the switches (e.g., crossover switch detection, setting up of a new subpath via signaling, changing the data path to the new subpath). Since there is no efficient alternative to implement handoff other than through the connection setup/teardown mechanisms, the computing power of switches needs to be upgraded to handle the increased signaling load; it is then preferable that location management be supported as well by a relatively smaller increment to the overall processing overhead.

REPLICATION OF FUNCTIONALITY An external location service will presumably be distributed across multiple servers for scalability, and will therefore need a routing protocol to route location resolution and update messages. Furthermore, transport of location resolution queries and update messages will require a data path interconnect to be either pre-established (in which queries and updates are forwarded in a connectionless fashion) or set up on demand. Much of this functionality is essentially replicating what is available from the PNNI signaling and routing framework; the integrated approach, on the other hand, leverages off the existing PNNI routing capability and signaling messages.

HANDOFF fter a connection has been established to a mobile endpoint, handoff protocols are necessary to reroute existing A active connections when the endpoint moves to a different radio port. A handoff procedure consists of three basic steps: • Selecting a crossover switch and setting up a new connection segment from the crossover switch to the new radio port • Shifting the data path at the crossover switch to the new connection segment, and optionally achieving a zero cellloss shift of the datapath • Extending the connection datapath from the new radio port to the mobile terminal after it moves under the radio port’s coverage area. Below, we consider different methods of executing handoff.


PARTIAL PATH REROUTING SCHEME

Message

Functional behavior

HANDOFF REQUEST

Select crossover switch, set up new subpath

This approach is based on removing a part of the HANDOFF RESPONSE Connect new subpath, indicate new subexisting connection and adding a new subpath path is ready from the point of detachment (the “crossover” HANDOFF CONFIRM Inform crossover switch to enable new path point). In Fig. 7, let the mobile terminal move from radio port BS1 to BS2. Then the portion of HANDOFF CONFIRM COMPLETE Respond to HANDOFF CONFIRM and the existing connection from the “handoff switch” release old path S1 to BS1 is deleted, and the remainder of the original connection path is extended to BS2. HANDOFF JOIN Set up data path on the wireless link to the Details of this protocol can be found in [11]. new radio port, complete end-to-end A key issue in this scheme is the selection/disconnection path covery of the crossover point. One method is to HANDOFF_JOIN COMPLETE Connect the data path on the wireless link iteratively probe each switch on the existing connection path such that the rerouted path through ■ Table 2. A common set of additional signaling messages. the switch (to the new radio port BS2) satisfies the QoS of the original connection path. This is an area that merits further study. PROPOSED MODIFICATIONS TO Q.2931 SIGNALING As discussed later, if “zero-cell-loss” handoff is desired, the path rerouting scheme requires cells to be buffered at BS1 All three handoff schemes require a common set of additional and transferred to BS2 before the mobile terminal can begin signaling messages: Handoff Request/Response, Handoff to receive cells at BS2. Confirm/Complete, and Handoff Join/Complete (Table 2).

PATH SPLICING In the “path splicing” method for handoff, crossover switch discovery is initiated from the destination radio port rather than the mobile terminal’s current radio port. In Fig. 7 the mobile endpoint sends a handoff request to its current radio port, BS1, asking for a handoff to BS2. BS1 forwards this message to BS2 using a pre-established handoff control VC between adjacent radio ports. BS2 first executes a local call admission control to check if the wireless link can accommodate the connection to be handed off. It then initiates a connection setup to the remote endpoint of the original connection, using the QoS parameters supplied within the handoff request message. This setup is eventually guaranteed to encounter a switch (S2) on the existing connection path, which is considered the crossover switch. This switch will then splice the new path segment (S2–BS2) onto the existing connection path (between the caller and the crossover switch). Details of this scheme can be found in [12].

PATH EXTENSION SCHEME Another simple approach to handoff consists of extending an active connection from the terminal’s current radio port to the next one. The idea here is that after handoff, the new connection consists of the existing connection from the source to BS1 followed by an additional subpath (the “extension”) from BS1 to BS2. This approach offers the advantage that no crossover switch discovery phase is required, and the existing path is maximally reused. However, the extended path also increases the end-to-end delay and reduces network utilization since the extended path may traverse the same link more than once (i.e., loops may be created). A possible solution is to optimize the path lazily after completion of handoff: • “Looping” points (switches) are detected during the path extension process. • Loops are removed by sending a specially defined operations, administration, and management (OAM) cell from a looping point. • While the OAM cell is traversing the loop, incoming cells on the connection are buffered locally at the looping point and then forwarded on the optimized path after the loop has been removed. Details of path-extension-based schemes for handoff are discussed in [13–15].


Handoff Request — A mobile terminal signals its current radio port to initiate handoff using Handoff Request message. The handoff procedure is executed separately for each connection. The Handoff Request message includes a networkwide unique global connection identifier (GCID) [16, 17] to identify the specific connection for which the handoff procedure is to be executed. Typically, the GCID will consist of the ATM addresses of both endpoints, plus an additional pair of identifiers (to distinguish multiple connections between the same pair of endpoints). For example, the BLLI (broadband low-layer information) [10] may be used to identify a specific connection between common endpoints [16]. Handoff Response — The current radio port indicates to the mobile terminal that a connection subpath has been established to the new radio port. The Handoff Response includes the connection GCID. During this phase of Handoff Request and Response, the mobile terminal continues to receive and transmit data via its current radio port. Handoff Confirm — The mobile terminal informs its current radio port that it is ready to switch to the new radio port for the specific connection identified by the GCID. At this time, the mobile terminal stops transmitting cells to its current radio port. The Handoff Confirm is propagated up to the crossover switch (COS), which then shifts the data path to the new connection segment. Handoff Complete — As the Handoff Confirm message propagates from the COS to the current radio port, the existing connection segment between the COS and the radio port is released. It is then forwarded to the mobile terminal, indicating that the mobile terminal may now switch to the new radio port. Handoff Join — Once the mobile terminal has received a Handoff Confirm message for each of its connections, it changes its operating radio frequency to that of the new radio port. For each connection, it then sends a Handoff Join to the new radio port to close the loop on the signaling path. Handoff Join Complete — The radio port informs the mobile terminal of the VC number to use on the new link. At this time, the mobile terminal may begin to send/receive cells under the new radio port.

105

THE IMPACT OF HANDOFF ON QOS There are two key issues regarding how handoff affects the QoS of an existing connection. First, when a network accepts a connection to a fixed endpoint, the requested QoS is made available to the connection during its lifetime with a high probability in the absence of network failures. The same cannot be said for a connection to a mobile endpoint which is rerouted when the mobile terminal changes its radio port. This may occur, for example, when the mobile terminal moves under the coverage area of a radio port which is unable to provide the same QoS as that provided by the previous radio port. In this situation, the endto-end QoS parameters of the connection will need to be renegotiated. The second issue is that of minimizing the effects of QoS disruption during the process of handoff. Connection handoff entails a period of time during which the end-to-end connection data path is incomplete. The extent to which this disruption affects application performance depends on the nature of the application and the period of disruption. For example, a voice application can withstand short disruptions, but a data application cannot tolerate any. In some cases applications may mask the effects of disruption using different strategies. For example, lost segments of a data connection may be recovered through retransmisson. Video applications may extrapolate from current information to compensate for lost data. Either way, data loss may be perceived as a disruption of the negotiated QoS. One way to minimize QoS disruption during handoff is to ensure a “lossless handoff” [18–20]. To ensure a lossless

handoff, all cells in transit during the handoff process are buffered within the network (at either a switch or a radio port) to maintain in-sequence cell delivery (without loss) to the mobile terminal. In general, the sequence of actions [18] is: • The crossover switch sends a “marker” cell along the existing connection segment to the current radio port. Thereafter, it shifts the data path to follow the connection segment to the new radio port. • The new radio port buffers incoming cells along the (new) connection segment from the crossover switch. • The current radio port buffers all cells in the period between receiving a Handoff Confirm (from the mobile terminal) and the marker cell (from the crossover switch). It then transfers the buffered cells to the new radio port. • Once the new radio port receives the buffered cells from the current radio port, it first delivers these cells followed by cells that were buffered locally. Transfer of buffered cells from the existing radio port to the new radio port ensures that cells are not delivered out of order, and buffering cells at both radio ports ensures that cells are not lost. Some early results on the necessary buffer space can be found in [19]. For some applications, the cell transfer delay and delay variation may be more important than avoiding cell loss. In this case, depending on the allowable delay variation, the current radio port may transfer the buffered cells to the new radio port without waiting for the marker cell to arrive.

Switch controller

Radio port1

NNI+mobility

Linux/ Pentium PC Switch controller Fixed terminal

NNI+mobility

Application program

GSMP client

IP

Native ATM interface

Location mgmt

WaveLan wireless control


UNI 3.1+ mobility

Linux/ Pentium PC

IP pac

kets PC

Switch 2 Linux/ Pentium PC

NEC Model5S GSMP interface

Mobile terminal

Radio port2 IP over ATM

UNI 3.1 + location caching

Linux/ Pentium PC

Application program IP interface

IP over ATM

GSMP client

Handoff

Switch 3 Location mgmt NEC Model5S GSMP interface

NEC Model5S GSMP interface Switch 1


UNI 3.1+ mobility

Crossover switch Switch controller

Linux/ Pentium PC

NNI+mobility GSMP client

■ Figure 8. Prototype implementation of mobile ATM.

106


IP

PROTOTYPE

IP with transparent mobility support from mobile ATM

matches that of an existing connection path; consequently: • Switch1 (controller) sends a Q.2931 connect() reply on his section describes a proofthe new subpath of-concept implementation Mobile ATM core network • Sends a GSMP message to for mobile ATM. The prototype the switching fabric to currently supports: change data paths • Extended Q.2931 signaling ■ Figure 9. Using mobile ATM to support mobility in IP. • Sends a release() down the to integrate location resoluexisting subpath toward tion with connection setup radio port1 • New Q.2931 signaling mesAs with location management, the rerouting of the ATM sages and control functions to support handoff through connection path is transparent to IP and is handled within path splicing mobile ATM. • IP over mobile ATM In essence, the prototype shows that mobility support in IP Our prototype implementation consists of a network with may be obtained by mapping IP to mobile ATM, which is a three ATM switches (2.4 Gb/s NEC Model 5S) running generic network, instead of using IP-specific mobility support GSMP [21]. Each switch is controlled through an external (viz. mobile IP). 200Mhz Pentium PC, running Linux [22] as the operating system. GSMP is a simple client-server protocol that allows the switch controller (client) to add/delete/modify VCs on the switch (server). No signaling software runs on the switches INTERWORKING MOBILE ATM themselves. The NNI signaling software runs on the external WITH MOBILE IP switch controllers; when the signaling for connection setup/deletion is completed, the switch controller issues a he previous section demonstrated how mobile ATM may be GSMP message to add/delete entries in the VC tables within used to provide mobility support in IP. Additional interthe switch. working support is necessary to allow mobility of terminals The two radio ports provide a wireless LAN interface, between a mobile ATM network and a (mobile) IP network. using an off-the-shelf WLAN card (WaveLAN [23]. An NEC Briefly, this is achieved by employing a gateway at the boundary Versa laptop with a PCMCIA WaveLAN card acts as the between the two networks, as shown in Fig. 10, and an address mobile terminal, running only the IP protocol stack. Mobility resolution service to translate between IP and ATM addresses. between radio ports is emulated by changing the default gateThe gateway uses this service to map the destination IP address way of the mobile terminal to be one radio port or the other. of incoming packets (from the IP cloud) to a corresponding The prototype network thus support two radio coverage areas ATM address. In case of a mobile terminal, the IP address under radio ports 1 and 2; both operate in the same frequency resolves to its home ATM address. The mobile ATM network and overlap in space. then uses this address to resolve the terminal’s current locaThe mobile terminal is associated with two addresses that tion via the integrated location management scheme described never change: a home IP address and a home ATM address. earlier, and set up a ATM connection to its current radio The binding between the two addresses is static and locationport; the radio port forwards the received data as IP packets independent; the IP address can be resolved to the correvia its wireless packet interface to the mobile terminal. sponding ATM address using an address resolution protocol As shown in Fig. 10, mobility of a terminal is handled by such as ATMARP [24]. In the prototype, radio port1 is the mobile IP [5] as long as the terminal moves within the IP net“home switch” for the mobile terminal, and advertises reachawork. When it enters the mobile ATM network, it is assigned a bility to the terminal’s home ATM address. As the mobile terhome ATM address and a foreign IP address, by the radio port minal moves within the mobile ATM network, it acquires a to which it connects. This radio port acts as the terminal’s second ATM (foreign) address, which reflects its current radio “home switch” as long as the terminal remains within the mobile port. When the fixed terminal (Fig. 8) initiates a Transmission ATM network. Both of these addresses do not change, regardControl Protocol (TCP) connection to the mobile terminal’s less of the terminal’s mobility within the mobile ATM network. IP address, the IP address is first resolved to the home ATM Mobility of the terminal within the mobile ATM network is address. Then, using the integrated location resolution scheme transparent to mobile IP (and consequently to the IP cloud). outlined earlier, an ATM connection is set up to the mobile No location updates are generated at the mobile IP level terminal’s current radio port; thus, location management is except when the terminal first enters the mobile ATM netprovided by mobile ATM and completely transparent to IP work, when the terminal’s foreign (IP) address is sent to the (i.e., to the TCP connection) as shown in Fig. 9. terminal’s home agent in the IP cloud (as required by mobile In this prototype handoff is initiated after the mobile termiIP); this is accomplished by regular IP over ATM protocols nal moves to the new radio port and supports a preliminary (e.g., Multiprotocol over ATM [25]). Subsequent moves withversion of the path splicing scheme: the necessary signaling is in the mobile ATM network generate location updates only at supported through modifications to the Q.2931 SETUP mesthe mobile ATM level: each move causes the terminal to be sage. Consider an active connection to the mobile terminal assigned a new foreign ATM address, and the terminals’ from the fixed terminal while it is located under radio port1. “home (ATM) switch” maintains the mapping between its The ATM data path consists of fixed terminal–switch1– home and foreign ATM addresses. switch2–radio port1. The terminal then changes its default (IP) After a connection to the terminal from the gateway has been gateway on its wireless LAN interface, to point to radio port2. set up, it is subsequently rerouted via handoff protocols for each When the first data packet (on the active TCP connection) is move within the mobile ATM cloud. A key point to remember is received by radio port2, it sends a setup(ATM address of FT) that since IP is connections, the underlying ATM connection will toward the fixed terminal: the setup() message also includes a need to be torn down based on activity timers; that is, if no IP GCID. This message is routed along the path radio packets are sent or received on the ATM connection for a preport2–switch3–switch1. At switch1, the GCID within the setup() specified duration, the connection will be released.

IMPLEMENTATION

Overlay

T

T


107

Mobile ATM IP

"M" NNI

"M" UNI

Mobile ATM "M" NNI

IP

IP

Wireless LAN

Mobile ATM

Mobile ATM

"M" NNI

"M" NNI

ATM connection rerouted by mobile ATM

IP to ATM gateway

Move

IP

IP

"M" UNI Wireless LAN Internet

IP-mobile ATM core network

IP host

■ Figure 10. Interworking between mobile IP and mobile ATM.

RELATED WORK

CONCLUSIONS

he concept of wireless ATM was first proposed in [1, 26]. his article introduced a network architecture for mobile Since then, there has been significant work in this area. ATM that integrates location management and handoff T T The software architecture of a wireless ATM base station, within the ATM signaling and control framework. ATM uses MAC/DLC for a wireless ATM link, and preliminary ideas on handoff are presented in [11, 27]. Reference [8] describes the hardware design of a wireless ATM NIC card, while [7] reports performance figures for a DLC protocol for CBR and UBR over wireless ATM links. Preliminary ideas on integrating location and handoff schemes (path extension, path rerouting, and path splicing) within the ATM protocol stack are presented in [15] and form the basis of our work in this article. Necessary changes to the Q.2931 signaling message syntax, and an early prototype implementation, are described in [14, 28]. Contributions to the ATM Forum to standardize basic support for mobility can be found in [16, 29, 30]. An architecture-level overview of our work in mobile/wireless ATM is given in [31]. Other early work in this area include [13, 32–34]. Most of them have focused on an initial systems design to support mobile users through an ATM network; therefore, mobility support has been provided as an “add-on” rather than considered an integral component of the overall architecture. For example, the method presented in [34], namely broadcast paging to determine a mobile terminal’s current location, does not scale as the number of base stations in the network increases. References [33, 35, 36] propose architectures for supporting mobility in ATM similar to cellular telephony: the core network is mobility-unaware, with an overlay of mobility-supporting servers. Different mechanisms to select a crossover switch have been investigated in [37], while [19, 20] suggest using OAM cells for lossless handoff initiated from the current radio port.

108

separate paths for data flow and signaling: a mobile terminal’s location is resolved during the signaling phase preceding connection setup, thereby setting up an optimal end-to-end data path. Schemes for addressing, location resolution, location update, and location caching are presented. When a terminal changes its wireless access point, the end-to-end data path needs to be rerouted; three schemes for selecting a crossover switch were briefly described. It described our prototype implementation of mobile ATM to demonstrate support for non-ATM wireless access and validate our claim that mobile ATM can provide a generic platform for mobility support, by mapping IP to mobile ATM and eliminating the need for mobile IP. Current work at the network architecture level includes interworking mobile ATM with other mobility protocols such as GSM or mobile IP. The idea is that, for example, when a terminal moves within the mobile ATM “cloud” its mobility is handled by mobile ATM transparent to IP; however, when the terminal moves across “clouds” (e.g., between a IP network and a mobile ATM network), mobility will be supported by mobile IP; therefore, mobile IP datagrams will need to be translated to appropriate mobile ATM functions at the gateway. An overview of interworking mobile IP with mobile ATM was presented in this article. Other ongoing work includes optimizing location resolution by making use of routing information; for example, in our proposed location resolution it is not necessary that the release(foreign address) be returned all the way to the caller, for it is possible for an intermediate switch to initiate a


setup() to the foreign address. Mechanisms to optimally select such a switch, based on topology information from routing protocols, are under study. Also, scalable and efficient mechanisms to cache a terminal’s location within the network are being investigated; location caching is helpful in reducing the delay to resolve a terminal’s current location. With regard to handoff protocols, detailed schemes for zerocell-loss handoff are being considered for prototype implementation.

REFERENCES [1] D. Raychaudhuri and N. Wilson, “ATM Based Transport Architecture for Multiservices Wireless Personal Communication Network,” IEEE JSAC, Oct. 1994. [2] EIA/TIA, “Cellular Radio-Telecommunications Intersytem Operations,” Tech. rep. IS-41, rev. B, 1991. [3] M. Rahnema, “Overview of the GSM System and Protocol Architecture,” IEEE Commun. Mag., Apr. 1993. [4] Y. B. Lin and S. K. DeVries, “PCS Network Signaling using SS7,” IEEE Pers. Commun., June 1995. [5] IETF, “IP Mobility Support,” RFC 2002, Oct. 1996. [6] H. Xie et al., “Data Link Control Protocol for Wireless ATM Access Channels ICUPC,” Nov. 1995. [7] 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. [8] C. Johnston, “A Network Interface Card for Wireless ATM Networks,” Proc. PIMRC, 1996. [9] ATM Forum, “Private Network-Network Interface Specification Version 1.0,” doc. af-pnni-0055.000, Mar. 1996. [10] The ATM Forum, “ATM User-Network Interface (UNI) Signalling Specification, Version 3.1,” ftp://ftp.atmforum.com/pub/UNI/ver3.1 1994. [11] R. Yuan et al., “A Signaling and Control Architecture for Mobility Support in Wireless ATM Networks,” ACM/Baltzer Mobile Networks and Appls., Dec.1996. [12] A. Acharya, J. Li, and D. Raychaudhuri “Mobile ATM: Network Architecture and Protocols for Location Management and Handoff,” submitted to Infocom ’98. [13] P. Agrawal et al., “SWAN: A Mobile Multimedia Wireless Network,” IEEE Pers. Commun., Apr. 1996. [14] A. Acharya et al., “Design and Prototyping of Location Management and Handoff Protocols for Wireless ATM Networks,” Proc. ICUPC, Nov. 1997. [15] A. Acharya et al., “Location Management and Handoff in Mobile ATM Networks,” Proc. 3rd Int’l. Wksp. Mobile Multimedia Commun., Sept. 1996. [16] J. Li, A. Acharya, and D. Raychaudhuri, “Signaling Syntax Extensions for Handoff Control in Mobile ATM,” ATM Forum cont. 96–1625, Dec. 1996. [17] 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. [18] R. Yuan, S. K. Biswas, and D. Raychaudhuri “Mobility Support in Wireless ATM Networks,” Proc. 5th WINLAB Wksp. Third Generation Wireless Info. Networks, Apr. 1995. [19] M. Ajome Marsan et al., “Buffer Requirements for Loss-Free Handovers in Wireless ATM Networks,” Proc. 3rd IEEE ATM Workshop, May 1997. [20] H. Mitts et al., “Lossless Handover for Wireless ATM,” ACM/Baltzer Mobile Networks and Appls., Dec. 1996. [21] P. Newman et al., “Ipsilon’s General Switch Management Protocol,” RFC 1987. [22] http://www.linux.org/. [23] http://www.wavelan.com/. [24] M. Laubach, “Classical IP and ARP over ATM,” RFC 1577 1994. [25] ATM Forum, “Multiprotocol Over ATM Version 1.0, baseline text version 16, A. N. Fredette, Ed. [26] D. Raychaudhuri and N. Wilson, “Multimedia Personal Communication Networks: System Design Issues,” Proc. 3rd WINLAB Wksp. 3rd Generation Wireless Info. Networks, Apr. 1992; also in Wireless Communications, J. M. Holtzman and D. J. Goodman, Eds., Kluwer, 1993. [27] D. Raychaudhuri et al., “WATMnet: A Prototype Wireless ATM System for Multimedia Personal Communication,” IEEE JSAC, Jan. 1997. [28] A. Acharya, “A Prototype Architecture for Mobile ATM Networks,” ACM Mobile Comp. Rev., Apr. 1997. [29] A. Acharya, “Primitives for Location Management and Handoff in Mobile ATM Networks,” ATM Forum cont. 96–1121, Aug. 1996. [30] A. Acharya, J. Li, and D. Raychaudhuri, “Signaling Syntax Extensions for Loca-


tion Management in Mobile ATM,” ATM Forum cont. 96–1624, Dec. 1996. [31] D. Raychaudhuri, “Wireless ATM Networks: Architecture, System Design and Prototyping,” IEEE Pers. Commun., Aug.1996. [32] L. Van Hauwermeiren et al., “Requirement for Mobility Support in ATM,” Proc. Globecom, 1994. [33] J. H. Condon et al., “Rednet: A Wireless ATM Local Area Network Using Infrared Links,” Proc. 1st Int’l. Conf. Mobile Comp. and Networking, 1995. [34] K. Y. Eng et al., “BAHAMA: A Broadband Ad-Hoc Wireless ATM Local Area Network,” Proc. ICC, 1995. [35] B. Rajagopalan, “Mobility Management in Integrated Wireless-ATM Networks,” Proc. 1st Int’l. Conf. Mobile Comp. and Networking, 1995. [36] B. Akyol and D. Cox, “Handling Mobility in a Wireless ATM Network,” Proc. Infocom, 1996. [37] C. K. Toh, “Performance Evaluation of Crossover Switch Discovery for Wireless ATM LANs,” Proc. Infocom, 1996.

BIOGRAPHIES ARUP ACHARYA ([email protected]) received a B.Tech (Hons.) degree in computer science and engineering from IIT, Kharagpur, India, 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 WINLAB, Rutgers University, as a post-doctoral fellow where he worked on mobile IP and IP-multicast. He is presently a research staff member with the Systems Architecture Group, NEC USA, C & C Research Laboratories, Princeton, New Jersey, and is working on mobile-ATM protocols and fast IP switching over ATM. JUN LI ([email protected]) received 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 at NEC’s C&C Central Laboratories, Kawasaki, Japan, as a visiting scholar. From 1990 to 1993 he worked with Data Control Limited in Tokyo and San Francisco, 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 USA, C&C Research Laboratories, Princeton, NJ, working in the fields of mobile and wireless ATM networks. BALA RAJAGOPALAN ([email protected])received a B.Tech (Hons) degree in computer science from the Indian Institute of Technology, Kharagpur, in 1985, and M.S and Ph.D. degrees in computer science from the University of Illinois at Urbana-Champaign in 1988 and 1991, respectively. He was a member of technical staff at AT&T Bell Laboratories from September 1991 to December 1995, working on network design and engineering, and the design and analysis of routing and multicasting algorithms for IP and ATM networks. From January 1996 to January 1997 he was with the Internetworking Research Department at Bellcore as a research scientist, working on quality of service and mobility-related issues in the emerging integrated services Internet. Since January 1997 he has been with NEC USA, C&C Research Laboratories, Princeton, NJ, as a member of research staff. His research areas are Internet architecture and services, distributed systems, and mobile computing. DIPANKAR RAYCHAUDHURI [F] ([email protected])received a B.Tech. (Honors) degree in electronics and electrical communication engineering from the Indian Institute of Technology, Kharagpur, 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 member of technical staff (1979-87), senior member of technical staff (1988–1989), and head, Broadband Communications Research (1990–1992). Since January 1993, he has been with NEC USA, C&C Research Laboratories, Princeton, NJ, 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 9 U.S. patents. He is currently a technical editor for the IEEE/ACM Trans. on Networking and has served as chair, IEEE ComSoc Data Communication Systems Committee (1990–1991) and IEEE ComSoc Distinguished Lecturer (1993–1995). Since 1996 he has been vice-chair of the ATM Forum’s Wireless ATM Working Group.

109