ABSTRACT This project embarks on a solution to wireless services in a campus.

It proposes a new approach to support wireless mobile internet working on a large university campus or similar environment. The architecture of the approach combines wireless local-area network technology with high-speed switching technology. The combination provides a wireless communication system with sufficient aggregate bandwidth to handle massive, synchronized movements of mobile computers. Furthermore, the approach supports optimal routing to each mobile computer without requiring modification of the networking software on mobile computers, non-mobile computers, or routers in the existing Internet. This architecture describes the design and implementation of a campus size mobile wireless network. Through a prototype implementation, we have shown that the approach is feasible.

CHAPTER ONE 1.0 INTRODUCTION

Recent advances in personal computing and wireless local-area network (LAN) technologies have resulted in affordable laptop and palmtop computers with wireless networking capability. A portable computer with a wireless LAN adaptor can communicate directly with nearby wireless computers. To communicate with computers that are far away, a wireless mobile computer uses a nearby access station. Normally, an access station is a stationary computer with a wireless interface and a connection to conventional network facilities using terrestrial links. In particular, an access station that connects to the global TCP/IP Internet can provide a wireless mobile computer with access to other computers at sites around the world. The wireless interface of an access station can provides wireless coverage for a small geographical area approximately 50 meters in diameter. Mobile computers that reside within the area can use radio signals to communicate with the access station. Because an access station can provide wireless coverage for only a limited area, multiple access stations are needed to provide coverage for a large area. Attaching multiple access stations to an

internet introduces routing problems that result when a mobile computer migrates from the area of one access station to the area of another. Consider the example internet illustrated in Figure 1.1.

Figure 1.1 Illustration of an example internet that supports wireless mobile communication.

In the figure, two access stations, A and B, attach to an internet. Mobile computer M is communicating with computer C via access station A and two routers, R1 and

R2. To maintain network connectivity when M migrates to the coverage area of access station B, B must detect that M has arrived and then propagate a routing update message to allow packets destined for M to be forwarded to itself. To achieve optimal routing, B must propagate the routing update message to all the routers and other access stations in the internet because M could be communicating with an arbitrary set of computers attached to the campus internet. Note that packets that carry the routing update message compete with data packets for network bandwidth. The overhead of propagating routing updates is especially apparent in a large university campus where 50,000 mobile computers occupy in a small geographic area. More important, movements of mobiles at a university are massive and synchronized a large percentage of the population migrates to new locations during each change of class. Without a careful design, the campus internet may experience network congestion when most students attempt to use their mobile computers to communicate from new locations, affecting not only the mobile computers, but also the non-mobile computers in the campus internet. The situation becomes worse when congestion causes delay or loss of routing updates, forcing data packets to follow non-optimum paths.

Diverse capabilities in the mobile computers chosen by students also complicate the design. Students are likely to choose mobile computers that use various kinds of processors to run a variety of operating systems. We seek a design that can accommodate such diversity. This dissertation reports research in the area of wireless data communication. The research investigates how to design a wireless data communication system that is capable of supporting mobile internetworking in a large university campus. The system should have the following characteristics. Can handle a large volume of routing update traffic. Support optimal routing to each wireless mobile computer. Shield the campus internet from mobility management traffic. Provide seamless wireless mobile internetworking without requiring modifications to the networking software on mobile computers, nonmobile computers, or routers in the existing Internet. 1.1 STATEMENT OF PROBLEM

With cables connections are only available at pre designated locations - with wireless they can connect anywhere. Inflexible and expensive - and restrict students to specific locations where they can study, research and learn.

A Simply Wireless Local Area Network is worth considering. A wireless lan can be implemented quickly and cost effectively on your campus. Whether you are interested in wirelessly enabling a school or an MBA college, Simply Wireless are the wireless networking professionals to chat about your ideas with. Simply Wireless has a wealth of experience in the Educational Market, and is currently working with some of the leading Universities, Post Primary Schools and MBA colleges. 1.2 OBJECTIVES OF THE STIDY

There are several objectives associated with this project namely Access everywhere: Laptops are portable, and internet access is becoming more so with wireless. A wireless network means the laptops are instantly connected when they walk into class, and even on their way to class.

Accelerate learning: We are all different, some students learn at faster and slower paces. Using networked laptops and a wireless network - teaching staff can create assignments so students can work at their own pace. Flexible classroom layout: Want to shift desks around for a particular class. Do you need to add more students to the classroom network? With a wireless LAN from Simply Wireless there are no cables or data ports to to limit your flexibility.

Moving

computers

becomes

as

easy

as

moving

trolley.

For science teachers: Now science lessons can take place anywhere. The lab is a locations that's often very difficult to cable, with a wireless network, students can input data while experiments take place, and as they're observing results. Web based wireless learning is smart: Wireless makes it easier for students to work on their online assignments. They can access the school intranet from the library or cafeteria, being able to learn anywhere. In sum: You get the flexibility, portability and affordability you need, with the added assurance of Intel reliability and industry-leading expertise. Computers on wheels: If you don't have the funding to put a computer in every classroom - wireless is an easy way to maximize your technology investment. You can simply wheel your pool of computers into different classrooms as they are needed. Computers will be used by students more, and rotated hourly if needed. Students can use the pool of computers, access the school network, and work on assignments all from the library, or any wirelessly enabled location. Wireless technology enables computers to roam seamlessly throughout the school - even to portable classrooms or the playground.

More Students, less capital expenditure on IT: Your assignment; get your campus wired to the World Wide Web and other educational resources, but do it within a limited budget. Can you satisfy community expectations, while adhering to your budget? The solution is a Simply Wireless LAN. It's modular construction allows simple network additions as needed. 1.3 Significance of study

In Universities, there is no need to stand in line for a library PC. Students doing research can record their notes, interact with the Internet, and even access the library printer on their own wirelessly enabled laptops. Computers and computer networks are commonplace in education. More and more Educational facilities are taking advantage of the benefits of wireless networks. Compared to traditional cable, wireless offers a robust, secure, scalable and economical means to connect teaching staff and students to the information they need in their day to day lives. The principal advantages of a campus wireless network are:

Increased flexibility Students and teaching staff can connect wherever they need access rather than in designated computer laboratories.

Scalable your wireless network can grow as you need. Install an access point in the hallway and several classrooms are connected to the WLAN instantly. No cable to lay, need to predetermine where and how many data ports to install.

Dollars and Sense A cheaper and less intrusive solution that cable.

1.4

Scope of study

The scope of this project is to create a campus wide wireless network that is portable, flexible, and easily expandable. A universe of information is accessible when, and where, it's needed. Schools can provide network connectivity to new classrooms, without sinking money into space they will temporarily occupy. Using a Simply Wireless LAN, your educational facility can avoid expensive re-wiring or messy and often disruptive construction. Students and teachers are connected immediately. Students, teaching and administrative staff can move throughout the campus and maintain continuous network access.

1.5

Definition of terms

This section defines the terminology used in the remainder of this dissertation. General Networking Terms A network is a communication system that allows computers attached to the system to exchange data. A packet is a block of data transmitted from a computer across a network. A router is a dedicated computer that attaches to two or more networks and forwards packets from one network to another. An internet is a collection of networks physically interconnected by using routers. A communication channel is a path along which data used for communication passes. A communication link (or link) is a physical medium over which computers can send data. A frame is the basic unit of message passed across a communication link. A frame contains information that allows a network interface hardware to capture the data contained within. Maximum Transmission Unit (MTU) is the largest amount of data that can be sent across a communication link in a single frame. A host is an end-user computer that attaches to a TCP/IP internet. A datagram (or IP datagram) is a packet that passes across a TCP/IP internet. A TCP connection is

an abstraction provided by the TCP protocol software. A TCP connection between two applications allows each application to deliver data streams to the other reliably. TCP ensures sequenced, lossless delivery of each byte of data. A local area network (LAN) is a network that uses technologies designed to span a small geographic region. An Ethernet is an example of a LAN. A wireless LAN is a local area network that allows wireless communication among hosts that reside in the network. Nonstandard Terms A host is an end-user computer that attaches to a TCP/IP internet. A no mobile host is a host that attaches to an internet using a terrestrial link. A mobile host (or mobile) is a portable computer that can migrate from one network to another. This dissertation describes two types of mobile hosts. One type of mobile host does not have wireless communication capability. The other type is capable of wireless communication. This dissertation describes a system that supports the second type of mobiles. A base station is a dedicated, non-mobile computer that is capable of wireless communication with mobiles. A base station provides a group of mobiles with wireless access to an internet. Each base station supports wireless communication

for a geographical region called an area. A mobile can communicate directly with a base station once the mobile is within the area of the base station. An overlapping area is a geographical region in which a mobile can communicate with more than one base station using the wireless interface. Each mobile host is associated with an owner. The base station that is forwarding datagrams for a mobile is the owner of the mobile or the owning base station of the mobile. The owning base station of a mobile is also the default router for the mobile. Handoff refers to the process of transferring the ownership of a mobile from one base station to another. 1.6 ORGANIZATION OF WORK

In this chapter, we have discussed the personal diary briefly. I also provided the problem that led to the development of the system. The objectives of the study, significance of study, scope of study, limitation of study. In chapter two, I made a literature review of personal diary application, basically what people have done on the topic.

In chapter three I have the research methodology, the step followed. Analysis of the existing system: I stated the things that made the manual diary unworthy to use; the HLM, DFD. In chapter four, I showed the design and implementation of the system, the data dictionary, input-output specification, table format/structure, hardware and software requirement. In chapter five I have recommendation and future development; Summary, conclusion and references.

CHAPTER TWO 2.0 LITERATURE REVIEW

This chapter explains why supporting mobile computing in a TCP/IP internet is difficult, presents five approaches that researchers have proposed to overcome the difficulties, and describes wireless networking systems that are being built at other research institutions. 2.1 Internet Addressing and Routing

An IP unicast address is a 32-bit integer that has one of the three forms shown In Figure below

Figure above IP unicast address structure. Each unicast address consists of a network ID (netid) and a host ID (hostid).

As the figure illustrates, IP uses a hierarchical addressing scheme: each address consists of a network ID (netid) and a host ID (hostid); the network ID identifies a network, and the host ID identifies a host on that network. The addressing scheme facilitates routing. Conceptually, routing a datagram to a host on a given network takes two steps. First, IP routers forward the datagram to the network using the network ID part. Second, when the datagram reaches the destination network, routers deliver the datagram to the host using the host ID part. The hierarchical addressing scheme also makes routing information manageable. An IP router need not maintain routing information on a per-host basis. Consequently, routers exchange less routing information. Furthermore, since network topologies do not change frequently, routers can exchange routing information at longer intervals (e.g., once per 30 seconds, as in RIP. 3.2 The Host Mobility Problem Despite the advantages, the addressing and routing scheme of IP makes mobile computing difficult. Consider the example illustrated in Figure below

Illustration of two base stations, B1 and B2, attached to an internet. A mobile host, M, is communicating with host H using base station B1. Figure 3.2 shows two base stations B1 and B2 attached to an internet interconnected using several routers, denoted using symbol R. Station B1 supports wireless LAN A (with network ID A), and B2 supports wireless LAN B (with network ID B). Host H is using TCP/IP [Pos81c] to communicate with mobile host M via station B1. The network ID part of M's IP address is A (i.e., M is a host in wireless LAN

A). Suppose M migrates to wireless LAN B. Host H cannot communicate with M because IP routers continue to forward datagrams destined for M to wireless LAN A. Mobile M can acquire a new IP address from wireless LAN B and uses the new address to communicate with H. Host H sends subsequent datagrams to M using the new address. IP routers will correctly forward the datagrams to wireless LAN B. Thus, H and B reestablish communication. Unfortunately, changing an IP address breaks the TCP connections that already exist between M and H, because TCP uses the IP address of each end of a connection to identify the connection. To summarize the difficulties in supporting host migration in an internet: Changing an address facilitates routing, but breaks existing TCP connections. Maintaining an address keeps existing TCP connections, but creates routing problems. In theory, IP routers can treat mobile computers as a special case and maintain a host-specification route for each mobile. When a mobile migrates to a new

network, routers propagate a route update for the mobile. In practice, propagating host-specific routes for mobiles does not work well for two reasons. First, routers need special protocols to propagate the routes in a timely fashion because current IP routing protocols are not designed to operate in a rapidly changing topology. Second, routers need to propagate routes to every router in the internet because a mobile could be communicating with any host attached to the internet. 2.3 The Forwarding Concept and Address Insertion Agent When a mobile switches among base stations, it is important to maintain the TCP connections that the mobile has established. Reestablishing each TCP connection every time the mobile changes base station is unacceptably annoying. Thus, all the approaches that support mobile hosts focus on devising new routing schemes. All the proposed routing schemes can be explained using a single concept termed forwarding. At any time, a mobile host is associated with a forwarder that can reach the mobile directly. When a mobile migrates to a new network, the mobile acquires a new forwarder. Routing a datagram to a mobile consists of two steps. First, IP routers forward the datagram to the forwarder of the mobile. Second, the

forwarder delivers the datagram to the mobile. The two-step forwarding procedure indicates that a datagram destined for a mobile needs to carry two IP addresses: one identifies the mobile, and the other identifies the forwarder for the mobile. Because IP others only one destination address field, achieving the two-step forwarding requires an entity referred to as an address insertion agent. The agent must turn the datagram into another datagram that carries the two addresses and delivers the resulting datagram to the forwarder, which turns the received datagram into the original datagram and delivers the original datagram to the mobile. 3.6 The IBM Approach

Researchers at IBM Corporation also proposed using loose source routing to support mobile hosts. Unlike the IEN-135 approach, the IBM approach does not restrict all mobiles to use the same network ID. Each mobile has a home network. The network ID of a mobile's IP address identifies the home network of the mobile. Each home network has at least one mobile router (MR) that maintains the forwarder information and acts as the address insertion agent for the mobiles in the network.

To send a datagram to a mobile that is away from its home network, a sender transmits the datagram, without using the LSRR option. IP routers will forward the datagram to the home network of the mobile. When the datagram reaches the home network, an MR intercepts the datagram and forwards the datagram using the LSRR option to the current forwarder of the mobile. The forwarder then delivers the datagram to the mobile. When it replies, the mobile uses the LSRR option to carry the address of the forwarder to the sender. The IBM approach assumes that the sender will perform a route reversal procedure [PB94] when responding to the datagram from the mobile. 3.7 The SONY Approach Researchers at SONY Corporation proposed an approach that incorporates the forwarder function into each mobile. Thus, each mobile has two IP addresses, one permanent address, called a virtual IP (VIP) address that is used to identify the mobile, and one temporary IP (TIP) address for the forwarder. Like the IBM approach, the SONY approach also uses routers, called primary resolvers [TUSM94], at home networks to intercept datagrams and serve as address insertion agents for mobiles. When a mobile migrates to a foreign network, the mobile uses a mechanism (e.g., Dynamic Host Configuration Protocol to obtain a

temporary address. The mobile then uses a control packet to carry the VIP-to-TIP binding back to its primary resolver. Routers along the path are allowed to snoop the control packet and cache the binding in a table called Address Translation Table. A no mobile host can also install an Address Translation Table to make communication with mobiles more efficient. Thus, besides the primary resolvers, intermediate routers and hosts that have installed the AMT can serve as address insertion agents for mobiles. The advantage of the SONY approach is self-sufficiency: a mobile need not rely on a forwarder to be able to communicate when visiting a foreign network. However, the mobile still needs to obtain a temporary address from the foreign network. The extra address requirement makes the scheme unappealing in an environment where IP addresses are a scarce resource. For the next version of IP, IPv6, where IP addresses are abundant, researchers have proposed using schemes similar to the SONY approach to support mobile hosts. 3.10 Related Wireless Data Network Systems A number of institutions are building wireless data network system for mobile computing research. Carnegie Mellon University is building a wireless networking infrastructure called Wireless Andrew [HJ96]. Currently, Wireless Andrew consists

of two types of wireless systems: a wide area system using 19.2 Kbits/second Cellular Digital Packet Data (CDPD) service and a local area system using 2 Mbits/second NCR WaveLAN technology. A wireless access station called Wave POINT provides wireless access for mobiles in a small geographical area. All WavePOINT stations are connected to a dedicated backbone network consisting of 10 Mbits/second Ethernet [MB76] hubs. Routers interconnect the backbone network to the campus internet. WaveLAN uses proprietary link layer protocols to allow a mobile to roam from the area of one WavePOINT station to another without losing network connectivity. At the University of California at Berkeley, researchers are building a wireless network system, InfoNet [LBSR95], for supporting the InfoPad project [N+96]. A mobile computer in InfoPad is a portable multimedia terminal called Pad. Each Pad uses two wireless links to communicate with a Gateway, which provides Pads with access to a backbone network. The link from a Pad to a Gateway is a Proxim radio link with a capacity of 244 Kbits/second; the link from a Gateway to aPad is a Plessey radio link with a capacity of 700 Kbits/second [LBSR95]. Each Gateway supports a small geographical region, called picocell, with a typical radius of 10 meters. Server processes use protocols to support seamless migration of a Pad

from one picocell to another. The servers make the Pad appear to be a stationary terminal attached to the backbone network. The Mosquito Net project at Stanford University is investigating operating system and application issues in mobile and wireless computing. Researchers have built a test bed that consists of a wireless network and a collection of wired networks. The wireless network uses the Ricochet micro-cellular data network service provided by Metricom. The service uses pole-top radio units to provide wireless access for mobiles. Each radio unit offers a raw data rate of 100 Kbits/second. Ricochet uses Metricom proprietary routing protocols to provide roaming service to mobiles. Mosquito Net uses a scheme similar to the IETF Mobile IP scheme to support transparent host migration among the wireless network and the wired networks, with emphasis on not using foreign agents.

CHAPTER THREE 3.0 Research methodology

Research methodology is a collective term for the structured process of conducting research. There are many different methodologies used in various types of research and the term is usually considered to include research design, data gathering and data analysis. Research methodologies can be quantitative (for example, measuring the number of times someone does something under certain conditions) or qualitative (for example, asking people how they feel about a certain situation). Ideally, comprehensive research should try to incorporate both qualitative and quantitative methodologies but this is not always possible, usually due to time and financial constraints. Research methodologies are generally used in academic research to test hypotheses or theories. A good design should ensure the research is valid, i.e. it clearly tests the hypothesis and not extraneous variables, and that the research is reliable, i.e. it yields consistent results every time. The approach used here is SSADM.

What is SSADM? Structured Systems Analysis and Design Method (SSADM) is a systems approach to the analysis and design of information systems. SSADM was produced for a UK government office concerned with the use of technology in government, from 1980 onwards. The names "Structured Systems Analysis and Design Method" and "SSADM" are now Registered Trade Marks of the Office of Government Commerce (OGC), which is an Office of the United Kingdom's Treasury. Introduction System design methods are a discipline within the software development industry which seek to provide a framework for activity and the capture, storage, transformation and dissemination of information so as to enable the economic development of computer systems that are fit for purpose. SSADM is a waterfall method by which an Information System design can be arrived at; SSADM can be thought to represent a pinnacle of the rigorous document-led approach to system design, and contrasts with more contemporary Rapid Application Development methods such as DSDM.

3.1

The existing system

The present system is a system of communication where students, personnel and lecturers have no mobile communication network. They communicate either meeting each other or by using the network of popular service providers like MTN. 3.2 The proposed system

The proposed system is a system that will provide a campus wide wireless network that is portable, flexible, and easily expandable. A universe of information is accessible when, and where, it's needed. Schools can provide network connectivity to new classrooms, without sinking money into space they will temporarily occupy. Using a Simply Wireless LAN, your educational facility can avoid expensive re-wiring or messy and often disruptive construction. Students and teachers are connected immediately. Students, teaching and administrative staff can move throughout the campus and maintain continuous network access. 3.3 The Cross point approach to the new system

This chapter proposes a new approach to support wireless mobile internetworking called cross point, the proposed approach combines wireless LAN technology with asynchronous Transfer Mode (ATM) switching technology. The combination provides a wireless communication system with sufficient aggregate bandwidth to handle both data transfer and routing updates. The chapter describes the architectural design, the addressing and routing scheme, design issues, and analyses of the bandwidth requirements. It provides an overview of how the design can be used to support mobile internetworking in a large university campus. 3.4 Architectural Design

The design uses a scalable, high-speed communication fabric to interconnect all base stations and special purpose routers called cross point routers. Base stations provide wireless access for mobile hosts (or mobiles). Cross point routers interconnect the cross point network to the campus internet, allowing mobiles to communicate with hosts outside cross point. The high-speed communication fabric provides high-bandwidth, low-latency communication channels among the attached cross point processors (i.e., base stations and cross point routers). 3.5 An Overview

We use an example to provide an overview of how the design can be used to support mobile computing. Figure 4.2 shows a mobile host, M, is communicating

Illustration of the architectural design of a cross point wireless mobile network. A high-speed communication fabric interconnects all base stations and cross point routers.

with a host, S, that attaches to the campus internet. Base station B1 and cross point router R are forwarding IP datagrams for M. The datagrams pass through the data channel d1, which is the channel that B1 and R used to transport

datagrams to each other. When mobile M migrates to the area of base station B2, B2 uses the control channel to exchange control messages with B1. Once B1 allows B2 to capture M, base station B2 will inform router R to forward the datagrams destined for M over data channel d2, allowing seamless ommunication between mobile M and host S. Both M and S are unaware of the routing change. The cross point protocol software handles all the details to support seamless mobile communication. 3.6 Special Interface for High-Speed Processing

To process control and data messages at high speed, each cross point processor includes a special interface. The interfaces handle routing within cross point and control functions that allow seamless mobile communication. In particular, the interface implements an address-to-circuit binding for selecting an outgoing virtual circuit using a destination IP address (e.g., a mobile's IP address). When a mobile migrates to the area of a new base station, the interfaces handle all route changes. When routing information arrives at the interface, the interface automatically updates its address-to-circuit binding and begins using the new binding. 3.7 Analysis of Bandwidth Requirement

Note that when a handoff occurs, the new owner base station uses the control VCs to deliver a route update to all the other cross point processors. The update traffic can be significant when many mobiles move in synchronized fashion. This section provides two analyses of the bandwidth required to handle routing updates that result from massive, synchronized movement of mobiles. The first analysis considers the aggregate bandwidth requirement on the ATM switching fabric; the second investigates the individual link bandwidth requirement of a base station. The analyses assume that there are N cross point processors attached to the ATM network, a base station uses point-to-point circuits to deliver each route update to all the other processors, and each update is carried in an ATM cell. Thus, a base station transmits (N - 1) cells per route update. Also, the analyses assume that ATM links use Synchronous Digital Hierarchy (SDH) framing scheme. Because of the framing overhead, the available bandwidth at the ATM layer is 149.760 Mb/s on a 155.520 Mb/s link and 599.040 Mb/s on a 622.080 Mb/s link. 3.8 Aggregate Bandwidth Analysis

Suppose that there are M mobiles that change base stations every second. Because each change results in (N 1) cells transferred through the ATM fabric,

the aggregate bandwidth (BW) required to support the updates can be represented using the following equation: BW = M * (N - 1) *53 *8 bits=second (4.1) 3.9 Link Bandwidth Analysis

Another approach to analyzing the bandwidth requirement takes into account the maximum number of mobiles a base station can handle. If the wireless LAN hardware allows a base station to handle at most M mobiles, the base state can generate at most M*(N-1) route update cells that result from M new mobiles entering its area. Suppose that all M mobiles migrate to the base station's area within one second. In this case, Equation 4.1 is still valid in deriving the needed bandwidth. 3.10 Comparison to Other Approaches (why my proposed approach is the best) This section compares the cross point approach to the Columbia and the IETF Mobile IP approaches. Both the Columbia and the Mobile IP approaches are capable of supporting mobile internetworking in a campus environment, without requiring modification to the no mobile hosts and IP routers. The cross point approach takes a step further, without requiring modification or addition to the

networking software on each mobile. The Columbia approach requires each mobile host to install an additional software module that processes beaconing messages from base stations and determines with which base station to associate. The Mobile IP approach requires each mobile to install an additional software module that implements the Mobile IP protocol. Cross point versus the Columbia Approach Both the cross point and the Columbia approaches focus on building a campus sized wireless mobile network. Both approaches reserve a single IP network ID for the mobiles. A mobile host uses the same IP address regardless of which base station the mobile is using. Base stations cooperate to support seamless mobile communication as mobiles roam the campus. In essence, both approaches use protocols to make each mobile appear to be a stationary computer that attaches to a virtual wireless subnet of the campus internet. The Columbia approach attaches base stations to the campus internet. Conceptually, the wireless subnet is embedded in the campus internet. As a result, base stations can use IP tunnels to transport datagrams that are destined for remote mobiles. No additional cables or equipment are needed to interconnect base stations.

However, embedding the wireless subnet in the campus internet increases the load on the campus internet. Three types of traffic compete with each other for the available network resources on the campus internet: the traffic originated from the no mobile hosts attached to the campus internet, the traffic of the control messages that are needed to support seamless mobile communication, and the traffic of the tunneled datagrams. When network congestion occurs, each type of traffic has equal chance of being discarded by the IP routers on campus. Cross point takes a different approach: base stations are attached to a high-speed interconnect, which then connects to the campus internet using cross point routers. In other words, the cross point network is a parallel network of the campus internet. The advantage of using a parallel network is that all the traffic to support seamless mobile communication is concerned within the high-speed interconnects. The non-mobile hosts on the campus internet are not affected by the mobility management traffic. However, building a parallel network costs more because new equipment needs to be purchased, and each base station needs to be connected to the high-speed interconnect.

CHAPTER FOUR 4.0 SYSTEM DESIGN

PROTOCOLS AND ROUTING: DESIGN As described in the previous chapter, multiple base stations are needed to provide wireless coverage for the entire campus. As a mobile roams the campus, base stations must cooperate to transfer the ownership of the mobile from one base station to another. This chapter describes how cross point processors use protocols to determine the ownership of a mobile and to transfer the ownership of a mobile from one base station to the next. The ownership information is the routing information that cross point processors use to forward datagrams for mobiles. This chapter describes routing within cross point and protocol design. The next chapter will describe implementation details. 4.1 Routing

Each cross point processor maintains a routing table for forwarding datagrams. The table contains one entry for each mobile. A routing entry for a mobile contains both the ownership and reachability information of the mobile. To

illustrate how cross point processors cooperate to forward a datagram to a mobile, consider the example illustrated in Figure 4.1. In the figure, a cross point processor, P, receives a datagram destined for a mobile, M. Processor P consults the routing entry that corresponds to M. The routing entry indicates mobile M is reachable via base station B, so processor P forwards the datagram across the cross point interconnect to base station B. When it receives the datagram, base station B retrieves the routing entry for M and learns that M is

Figure 5.1 Routing a datagram across Crosspoint to a mobile. The routing table on each Crosspoint processor maintains a routing entry for each mobile host.

reachable locally; base station B forwards the datagram over the wireless interface to M. Processor P is either a base station or a cross point router. If P is a base station, the sender of the datagram must be another mobile; if P is a cross point router, the sender must be a host outside cross point. When mobile M answers the sender with a reply, base station B receives the reply. Since it owns M, base station B forwards the reply. If the reply is for another mobile, base station B forwards the reply using its routing table, as described earlier. If the reply is for a host outside cross point, B immediately forwards the reply to a pre-assigned cross point router without consulting the routing table. 4.2 Routing Between Two Mobiles

Routing between two mobiles is more complicated. Two mobiles can be in-range or out-of-range of each other. If two mobiles are in-range of each other, the two can communicate directly, without the support from base stations. If two mobiles are out-of-range of each other, base stations must provide routing support to allow the two mobiles to communicate. Because a mobile assumes direct communication with the other mobile is possible, base stations must provide

support to allow two mobiles that are out-of-range of each other to communicate. 5.2 Protocol Overview The routing process described in the previous section assumes each Crosspoint processor has a correct routing entry for each mobile. In a wireless network environment where hosts are mobile, routing protocols that are designed for wired networks (e.g., Routing Information Protocol (RIP) [Hed88] or Open SPF Protocol (OSPF) [Moy94]) are inadequate. Thus, Crosspoint uses four protocols to maintain the routing table on each Crosspoint processor. The goal of the protocol design is to ensure the following invariant: At any time, exactly one base station handles a mobile host's communication requests.

Overlapping areas present a challenge to achieving the design goal. When a mobile emits a frame, one or more base stations may receive the frame. Furthermore, a base station that receives the frame has no knowledge of which other base stations have received the same frame. The initial capture protocol ensures that only one base captures the mobile when the mobile initiates communication the _rst time. As the mobile roams, the hando_ protocol ensures that the ownership of the mobile is passed from one base station to the next. The owner of the mobile uses the revalidation protocol to determine whether the mobile is still reachable. Finally, the recapture protocol ensures that only one base station captures the mobile when the mobile was previously determined unreachable and initiates communication.

The rest of this chapter describes the design of each of the protocols. 45 5.3 The Hando_ Protocol A base station uses the hando_ protocol to negotiate and transfer the ownership of a mobile. As Figure 5.2 illustrates, the protocol follows a request-reply interaction between a base station that tries to capture a mobile and the mobile's owner. To capture the mobile, the non-owner base station sends a hando_ request to the owner and awaits a reply. The owner processes the request and responds with either a positive acknowledgment (i.e., an ACK) or a negative acknowledgment (i.e., a NAK)1. An ACK reply permits the non-owner to capture the mobile; a NAK reply denies the request2. If anACK arrives, the non-owner captures the mobile and informs the other

Crosspoint processors about the ownership change by propagating a routing update. handoff ACK/NAK handoff request Owner Non-Owner Time Time ACK propagate route update Figure 5.2 Hando_ protocol interaction between a base station that tries to obtain the ownership of a mobile and the owner base station of the mobile. The nonowner propagates a route update for the mobile when receiving a hando_ ACK message from the owner. 1The owner base station uses a hando_ algorithm to process the request. Chapter 8 will describe

the hando_ algorithm in details. 2Chapter 8 will describe how the hando_ protocol handles loss of protocol messages. 46 5.3.1 Handling Multiple Requests Because a mobile may stay in an overlapping area, the mobile's owner may receive hando_ requests from multiple base stations. Because it does not know in advance how many hando_ requests will arrive, the owner does not wait for all requests to arrive then process them. Instead, the owner processes each request as the request arrives. Once it has permitted a base station to capture the mobile, the owner denies subsequent hando_ requests to capture the mobile. The owner includes the new

owner's ID in each hando_ NAK message to inform the requesting base station that subsequent hando_ requests should direct to the new owner. 5.3.2 Matching a Request and a Reply Each hando_ request carries a sequence number that allows the requesting base station to match a reply. A hando_ reply in response to a hando_ request carries the sequence number of the request. A base station only accepts a reply with a matched sequence number and from the correct sender. 5.3.3 Reducing the Frequency of Sending Hando_ Requests If every frame emitted from a mobile causes a hando_ request sent to the mobile's owner, the owner may be overwhelmed when the mobile is situated in an overlapping

area and emits many frames in a short interval. A base station uses two schemes to reduce the frequency of sending a hando_ request. First, if the signal strength to a mobile is weak (e.g., less than a threshold), a base station does not send a hando_ request for the mobile, because the probability of receiving an ACK is low, and even if the base station receives an ACK, communication with the mobile may be impossible. We have observed that a base station's antenna can be more sensitive than a mobile's. As a result, the situation where a base station can receive a frame from a mobile, but the mobile cannot receive a frame from the 47 base station can occur. In such circumstances, a base station can use the signal threshold to minimize the e_ect of asymmetric reception.

Second, a base station imposes a _xed time interval _Thando_ between two successive hando_ requests. Thus, the rate at which a base station sends hando_ requests is bounded. 5.4 The Initial Capture Protocol When all the Crosspoint processors initialize the _rst time, no processor has a valid routing table3. When a mobile initiates communication, all the base stations that detect the mobile must use the initial capture protocol to ensure that only one base station captures the mobile. We describe two designs of the protocol below. In the _rst design, all base stations that detect the mobile submit a bid for the mobile to the others. The base station that has the highest bid captures the mobile. The second design uses the hando_ protocol for the initial capture4.

5.4.1 Bidding for a Mobile Conceptually, the bidding process consists of three steps. First, all the base stations that detect the mobile form a bid. Second, each of the base stations starts a timer and sends the bid to the other participants of the bidding process. Third, a participant compares incoming bids with its own bid; if an incoming bid is greater than the local bid, the participant ceases its attempt to capture the mobile by canceling its timer. Eventually, the base station with the highest bid captures the mobile after its timer expires. To form a bid, a base station encodes the measured signal strength to the mobile in the high-order bits and a random number in the low-order bits. Thus, a base 3Chapter 8 will describe the initialization procedure a Crosspoint processor takes before become operational. 4The current implementation uses the second design.

48 station that has a better signal to the mobile has a higher bid, and base stations that have the same signal strength to the mobile have equal chance to capture the mobile. Finally, base stations compare host IDs to break a tie. Because a base station that detects the mobile does not know which other base stations have also detected the mobile, the base station cannot send its bid directly to the participants of the bidding process. However, the base station knows that the participants must belong to the set of neighboring base stations, whose areas overlap with the base station's area. Thus, the base station sends its bid to all the neighboring base stations. A base station that is not a participant discards the incoming bids.

The set of neighboring base stations can be con_gured statically during initialization. A base station can also determine the set dynamically by checking incoming hando_ requests. Because a hando_ request is triggered by a frame emitted from a mobile, if a base station receives a frame from a mobile followed shortly by a hando_ request for the mobile (e.g., 10 ms later), the base station can add the sender of the request in the set of neighbors. 5.4.2 Using Hando_ for Initial Capture Alternatively, base stations can use the hando_ protocol for initial capturing a mobile. The idea is simple: each Crosspoint processor uses a prede_ned formula to initialize its routing table. The formula ensures that the routing entry of each mobile is consistent across all Crosspoint processors. In particular, the owner of a given mobile is set to the same Crosspoint router. Thus, when a mobile initiates

communication, each of the base stations that detect the mobile will send a hando_ request to the same Crosspoint router. The Crosspoint router allows the sender of the _rst hando_ request to capture the mobile. Unlike the bidding process, the Crosspoint router does not use a timer to wait for all the hando_ requests to arrive. That is because the Crosspoint router does not know a priori how many hando_ requests will arrive. When only one base station 49 detects the mobile, the latency is unnecessary. The owner trades a possible nonoptimal hando_ decision for a reduced latency in hando_ processing. 5.5 The Recapture Protocol Recall that a routing entry contains both the ownership and reachability information about a mobile. If a mobile becomes unreachable, Crosspoint processors change

the reachability information in the routing entry for the mobile, but maintain the ownership information. When a previously unreachable mobile initiates communication, each of the base station that detect the mobile looks up the routing entry that corresponds to the mobile and sends a hando_ request to the owner of the mobile. If it also detects the mobile, the owner captures the mobile and then processes each incoming hando_ request. If it does not detect the mobile, the owner permits the sender of the _rst arriving hando_ request to capture the mobile. 5.6 The Revalidation Protocol Once a base station has captured a mobile, the base station needs to revalidate the mobile periodically for two reasons. First, the mobile may be turned o_ by its user.

Without a mechanism for determining the mobile's status, subsequent datagrams to the mobile may end up wasting resources. Once it has determined that the mobile is no longer reachable, the base station can propagate the information to the other Crosspoint processors. For example, when a datagram for the mobile from a Crosspoint router arrives, the owner can send a control message to inform the router that the mobile is no longer reachable. The router then discards subsequent datagrams that are destined for the mobile, thereby limiting the use of resource on useless tra_c. Second, the mobilemay not emit a frame when it roams into the area of a new base

station. Consequently, the new base station cannot detect the mobile. Meanwhile, datagrams are being forwarded to the mobile's owner, which no longer has a wireless link to the mobile. Note that the mobile may emit frames (e.g., ACKs) if it were 50 able to receive the datagrams forwarded by the owner. And, the emitted frames are exactly what the new base station needed to capture the mobile. When such a situation occurs, the owner needs a way to detect the mobile's absence and request the assistance of the other base stations to locate the mobile. 5.6.1 The Two Stages of Revalidation A base station uses the revalidation protocol to determine whether a mobile that it

owns is still reachable. The owner base station initiates the protocol when it receives a datagram destined for the mobile, and the mobile has not emitted a frame for a prede_ned period. The owner uses ICMP echo requests [Pos81b] to elicit a response from the mobile. A response from the mobile indicates the mobile is still reachable. The revalidation protocol consists of two stages. Each stage corresponds to a search range. The _rst stage corresponds to a a local search. The owner starts a timer and continues to forward datagrams for the mobile. If the mobile emits a frame (e.g., a datagram in response to the received datagrams), the base station infers that the mobile is still reachable and stops the search by canceling the timer. When the

timer expires, the base station sends an ICMP echo request to the mobile and starts another timer. After sending a _xed number of ICMP echo requests without receiving a reply, the base station proceeds to the second stage. The second stage corresponds to a neighborhood search. The owner requests the assistance of the neighboring base stations to locate the mobile. As in the _rst stage, the owner starts a timer to send an echo request. Unlike the _rst stage, after the timer expires, the owner sends an echo request to the mobile and a control message to the neighboring base stations. Upon receiving the control message, each of the neighboring base stations sends an echo request to the mobile. A neighbor that receives an echo reply from the mobile will send a hando_ request to the owner, indicating the mobile is still reachable. The owner keeps trying until either the mobile

responds or the number of retries exceeds a threshold. In the later case, the owner declares the mobile unreachable. 51 5.6.2 Discussion The two stages of revalidation reect the owner's inability to distinguish the following three cases: 1) the mobile is active but does not emit a frame; 2) the mobile is active but no longer in-range of its owner; 3) the mobile has been deactivated. All the above cases have the same outcome: the owner does not receive a frame from the mobile. In the _rst case, the mobile is active and still in-range of the owner. The mobile is likely to respond to either the incoming datagrams or the echo requests. If the mobile

is using TCP [Pos81c], incoming datagrams normally arrive in groups (i.e., the packet train model described in [Jai86]). Moreover, a TCP receiver normally transmits an ACK segment for every two data segments received [Bra89]. Thus, the mobile is likely to emit a frame in response to the incoming datagrams before the _rst echo request is sent. In the second case, the mobile is active but out-of-range of the owner. The owner relies on neighboring base stations to detect the mobile. Using the neighboring base stations exploits the locality property of movement. In the third case, the mobile is no longer reachable. The revalidation protocol will run to the completion. Although resources are consumed to determine the status of the mobile, once the mobile is determined unreachable, subsequent datagrams

destined for the mobile will be discarded and do not trigger another revalidation. As long as the mobile does not attract incoming datagrams (e.g., a TCP client [CS93]), the owner will not invoke revalidation, even if the mobile is unreachable. 5.7 Summary Crosspoint uses host speci_c routing. Each Crosspoint processor maintains a routing entry for each mobile. The routing entry that corresponds to a mobile contains the ownership and reachability information for the mobile. This chapter describes four protocols that Crosspoint processors use to determine the ownership and reachability 52 information for a mobile. The initial capture protocol ensures that only one base captures a mobile that initiates communication the _rst time. The hando_ protocol

ensures that the ownership of a mobile is passed from one base station to the next. The revalidation protocol is used by the owner of a mobile to determine whether the mobile is still reachable. Finally, the recapture protocol ensures that only one base station captures a mobile that was previously determined unreachable and initiates communication. 53 6. PROTOCOLS AND ROUTING: IMPLEMENTATION The previous chapter describes routing concepts and the design of four protocols: initial capture, hando_, revalidation, and recapture. This chapter focuses on the implementation details. It uses a _nite state machine [ASU88] model to explain protocol processing. The model provides a concise and precise description of how the

Crosspoint protocol software handles events such as timeouts and incoming messages, and hence is well suited for guiding protocol implementation. 6.1 Finite State Machine, Events, and Routing Table As the name implies, a _nite state machine has a _nite set of states. One of the states in the set is designated as the initial state. A _nite state machine begins in the initial state and makes state transitions in response to input events. Conceptually, each Crosspoint processor maintains a _nite state machine for each mobile. Each _nite state machine is augmented with memory. A Crosspoint processor uses the memory to store data needed for processing input events. An input event is either a message or a timeout. A message event is either a frame emitted from a mobile, a datagram destined for a mobile, or a protocol message (e.g., a hando_ request). A Crosspoint processor can invoke zero or more protocol actions when

processing an input event. A protocol action includes emitting a protocol message, setting/resetting a timer, or modifying the memory of a state machine. Each Crosspoint processor uses a table to store routing entries. There is one entry for each mobile. The memory of a mobile's state machine corresponds to the routing entry for the mobile. For e_cient access, the table entries are indexed by mobile host ID (i.e., the host ID portion of the IP address of a mobile). To access the routing 54 entry for a mobile given the mobile's IP address, a Crosspoint processor extracts the host ID from the IP address, uses the ID as an index to the routing table, and accesses the entry in constant time. 6.1.1 The Seven States

Each state machine has 7 states. Based on reachability information, the 7 states are categorized into 3 groups: _ Group 1: Reachable Locally { LOCALLY OWNED { HANDOFF ACKED { REVALIDATE _ Group 2: Reachable Remotely { REMOTELY OWNED { HANDOFF REQUESTED _ Group 3: Unreachable { UNREACHABLE LOCAL { UNREACHABLE REMOTE At any time, a mobile's state machine is in one of the 7 states. The routing entry for the mobile stores the current state information. We briey describe each state below; later sections will explain the role of each state in detail.

If a mobile's state1 on a base station is LOCALLY OWNED, the base station is the owner of the mobile. State HANDOFF ACKED indicates that the owner has permitted another base station to capture the mobile by sending a hando_ ACK message. State REVALIDATE indicates that the owner is verifying whether the mobile is still reachable. 1We use the current state of a mobile's state machine to denote the mobile's state. 55 If a mobile's state on a Crosspoint processor is REMOTELY OWNED, the Crosspoint processor is not the owner of the mobile. State HANDOFF REQUESTED indicates that the processor has sent a hando_ request to the mobile's owner and is waiting for a hando_ reply from the owner.

Finally, if a mobile's state on a Crosspoint processor is UNREACHABLE REMOTE or UNREACHABLE LOCAL, the Crosspoint processor cannot reach the mobile. State UNREACHABLE REMOTE indicates that the processor does not own the mobile. State UNREACHABLE LOCAL indicates that the processor is the owner of the mobile. 6.1.2 The Owner ID Each Crosspoint processor has an identi_er (ID). Unrelated to the ID of a mobile, the ID of a Crosspoint processor is a 16-bit integer that uniquely identi_es the processor. To identify the owner of a mobile, the routing entry for the mobile contains an owner ID _eld. A Crosspoint processor can use the owner ID _eld to derive the data channel and the control channel with which to communicate with the owner of the mobile. 6.2 Protocol Processing Using Finite State Machines

We use the state machines illustrated in Figures 6.1 and 6.2 to explain the protocol processing on a base station and on a Crosspoint router, respectively. As the _gures show, the state machine on a Crosspoint router is much simpler than that on a base station. Because it does not have a wireless interface, a Crosspoint router does not try to capture a mobile. The state machine on a Crosspoint router moves between the REMOTELY OWNED state and the UNREACHABLE REMOTE state. In contrast, the state machine on a base station can move among all 7 possible states. Although each base station (or Crosspoint router) uses the same state machine to process events for all mobiles, each mobile has its own current state. The current

state of a mobile determines how a Crosspoint processor processes an input event for the mobile. Each input event is tagged with the ID of a mobile. When an event for 56 handoff NAK handoff req timeout echo request (start timer) handoff NAK handoff req LOCALLY UNREACHABLE UNREACHABLE HANDOFF REQUESTED

REMOTELY OWNED OWNED HANDOFF ACKED HANDOFF REMOTELY ACKED OWNED REVALIDATE (owner) (non-owner) ACKED * timestamp has not been updated for a preset time period (1) forwarded if carries IP (2) buffered if carries IP (3) discarded by rate limit (4) discarded HANDOFF handoff req timeout (> k retries)

unreachable frame (1) bcast route update route update frame (3) frame (4) datagram* frame (2) route update frame (2) handoff ACK handoff req handoff ACK frame (1) handoff req

handoff ACK handoff req handoff NAK (start timer) handoff req handoff ACK bcast route update handoff req handoff NAK frame (2) frame (1) (cancel timer) LOCAL REMOTE begin Figure 6.1 A _nite state machine used to explain the protocol processing on a base

station. The state machine begins in the UNREACHABLE REMOTE state. 57 UNREACHABLE REMOTELY OWNED (Crosspoint Router) unreachable handoff req handoff ACK route update route update handoff req handoff NAK REMOTE begin

Figure 6.2 A _nite state machine used to explain the protocol processing on a Crosspoint router. The state machine begins in the UNREACHABLE REMOTE state. the mobile occurs, the Crosspoint processor retrieves the routing entry of the mobile and processes the event. 6.3 Initial Capture After system initialization, the ownership of every mobile is unknown. Each Crosspoint processor sets the state of every mobile to UNREACHABLE REMOTE and the owner ID of every mobile to a predetermined Crosspoint router. That is, for a given mobile, the state and owner ID of the mobile on all Crosspoint processors are identical. Because the state of each mobile is set to UNREACHABLE REMOTE, Crosspoint processors

discard incoming datagrams destined for mobiles. Crosspoint processors use frames emitted from a mobile to detect the presence of the mobile and establish the correct routing state for the mobile. To illustrate how Crosspoint processors cooperate to establish the routing state for a mobile, consider the following example. 58 Assume that a mobile, M, emits a frame, and the frame is received by one or more nearby base stations. A base station that receives the frame uses the source IP address carried in the frame to retrieve routing entry that corresponds to M. Because M's state is UNREACHABLE REMOTE, as Figure 6.1 shows, the base station bu_ers the frame, sends a hando_ request to the mobile's owner, changes the mobile's state to

HANDOFF REQUESTED, and awaits a reply from the owner. While waiting (i.e., in the HANDOFF REQUESTED state), the base station bu_ers other IP frames received from M. Because M's owner is set to a Crosspoint router, and M's state on the router is set to UNREACHABLE REMOTE, as Figure 6.2 illustrates, the router answers the _rst incoming hando_ request with a hando_ ACK and changes M's state to REMOTELY OWNED. In the REMOTELY OWNED state, the owner denies subsequent hando_ requests. That is, the owner allows the sender of the _rst hando_ request to capture M. The base station that receives the hando_ ACK reply from the router changes M's state to LOCALLY OWNED, broadcasts a routing update to the other Crosspoint proces-

sors, forwards the bu_ered frames, and starts handling M's communication requests. That is, the base station captures M and becomes the owner of M. A Crosspoint processor that receives the route update changes M's state to REMOTELY OWNED and records the new owner's ID in the routing entry. Thus, the routing state for mobile M is established. 6.4 Hando_ After initial capture, mobile M has an owner base station. As M communicates, M emits frames. A base station that receives a frame from M uses the state information about M to process the frame. If M's state is LOCALLY OWNED, the base station is the owner of M; the base station forwards the frame. If M's state is REMOTELY OWNED, the base station sends a hando_ request to M's owner and changes M's state to HANDOFF REQUESTED.

59 The owner of mobileM processes the hando_ request using the hando_ algorithm2. If the algorithm denies the request, the owner sends a hando_ NAK message back to the requesting base station, without changing M's state. If the algorithm accepts the request, the owner answers the request with a hando_ ACK message and changes M's state to HANDOFF ACKED. In the HANDOFF ACKED state, the owner denies subsequent hando_ requests and awaits a route update message from the new owner. When the hando_ ACK message arrives, the new owner changes M's state to LOCALLY OWNED and broadcasts a route update message for M. When it receives the

route update message, the previous owner changes M's state from HANDOFF ACKED to REMOTELY OWNED, completing the ownership transfer. 6.4.1 Limiting Hando_ Request Rate As described in section 5.3.3 of the previous chapter, a base station imposes a minimum delay _Thando_ between two successive hando_ requests. To implement the policy, a base station maintains a timestamp, Tnext hando_ , for each mobile. When a base station sends a hando_ request for a mobile, the base station adds _Thando_ to the time at which the hando_ request is sent, and stores the result in the Tnext hando_ . Tnext hando_ indicates the time beyond which the base station can send the next hando_ request for the mobile. 6.4.2 Datagram Forwarding During Hando_

Because transferring the ownership of a mobile from one base station to another requires exchanging protocol messages across a network, the time needed to complete the ownership transfer is nonnegligible. Figure 6.3 illustrates the latency needed to complete the ownership transfer of a mobile, M. In the _gure, base station A is the owner of M. Another base station, B, uses the hando_ protocol to obtain the ownership of M from A. The ownership transfer requires three messages exchanged between the two base stations. At time T1, base 2Chapter 8 will describe the hando_ algorithm. 60 T2 T1 T1 T2

handoff ACK route update datagrams from M buffered datagrams from M buffered datagrams for M forwarded to M datagrams for M forwarded to M Base Station B (New Owner) handoff request datagrams from M forwarded (for mobile M) datagrams for M forwarded to M datagrams from M discarded datagrams for M forwarded to B (Owner of M) Base Station A

(LOCALLY_OWNED) (HANDOFF_ACKED) (HANDOFF_REQUESTED) (HANDOFF_REQUESTED) (HANDOFF_ACKED) (LOCALLY_OWNED) T4 T3 (REMOTELY_OWNED) T4 (LOCALLY_OWNED) datagrams for M forwarded to M datagrams from M discarded datagrams from M forwarded datagrams for M forwarded to B T3 Figure 6.3 Illustration of the latency needed to complete an ownership transfer, the handling of datagrams at various time intervals, and the change of states on the

participating base stations. Vertical lines down the _gure represent increasing time and diagonal lines across the middle represent network packet transmission. station B sends a hando_ request for M to base station A and changes M's state to HANDOFF REQUESTED. At time T2, A processes the request, answers with a hando_ ACK, and changes M's state to HANDOFF ACKED. After processing the hando_ ACK, B broadcasts a route update and changes M's state to LOCALLY OWNED at T3. At time T4, A receives the route update and changes M's state to REMOTELY OWNED, completing the ownership transfer. The latency needed to complete the ownership transfer, referred to as hando_ latency, is T4 T1. While the hando_ processing is taking place, datagrams destined for M as well as

emitted from M can arrive at both base stations. The next two subsections describe how the protocol is designed to avoid packet lost and minimize duplication of packets between T1 and T4. 61 6.4.2.1 Handling Datagrams from Mobiles During Hando_ When base station B obtains the ownership of mobile M from base station A, M must be in-range of B. Furthermore, B must have a better wireless link to M. Two cases are possible. First, if M is in-range of A, then the signal strength between A and M must be weaker than that between B and M. Second, M is out-of-range of A, so A transfers the ownership to B. The two cases are illustrated in Figures 6.4 and 6.5, respectively. mobile handoff ACK

handoff req M owner AB Figure 6.4 Illustration of a hando_ occurs while mobile M is situated in an overlapping area of two base stations, A and B. Base station A is the owner of M. Base station B is using the hando_ protocol to obtain the ownership of M from A. B has a better wireless link to M than A. In the _rst case, M is in-range of base stations A and B. Thus, during the ownership transfer, both base stations can receive datagrams emitted from M. The state of mobile M determines how each base station processes a datagram received from M. As Figure 6.3 illustrates, between T1 and T3, base station B bu_ers datagrams

from M because M's state during the interval is HANDOFF REQUESTED. After receiving 62 mobile handoff ACK M B owner A handoff req Figure 6.5 Illustration of a hando_ occurs while mobile M is away from the area of its owner, base station A. Base station A allows base station B to capture M because M is out-of-range of A. the hando_ ACK at T3, B delivers the bu_ered datagrams and starts forwarding datagrams emitted from M. Thus, from T1 to T4, B delivers all the datagrams

emitted from M, without a loss. Base station A also receives the datagrams that B receives between T1 and T4. Between T1 and T2, A forwards datagrams from M because A owns M. Between T2 and T4, A has allowed B to capture M, so A discards datagrams from M. The way A and B handle the datagrams received from M between T1 and T2 possible duplicate delivery of datagrams. Because A has already forwarded datagrams from M received between T1 and T2, when B delivers the bu_ered datagrams at T3, the datagrams received between T1 and T2 are duplicates. The number of duplicates is at least one if the frame that triggers the hando_ request carries an IP datagram3. The total number of duplicates that can result depends on how often M emits IP datagrams between T1 and T2. No duplicate results if the frame that trigger the

3Other than emitting IP frames, a mobile can emit ARP frames as well. 63 hando_ request is not an IP frame, and M does not emit datagrams between T1 to T2. If B does not bu_er the datagrams received between T1 and T2, the probability of duplicating datagrams during hando_ is eliminated. However, as the second case illustrates, bu_ering datagrams between T1 and T2 is necessary to avoid datagram loss. In the second case, illustrated in Figure 6.5, mobile M is away from its owner's area (i.e., A's area) while the ownership transfer occurs. Because base station A cannot receive datagrams emitted from M, base station B must bu_er the datagrams received from M between T1 and T2 to avoid loss of datagrams.

These two cases illustrate that bu_ering in one case can cause possible duplication of datagrams, while in the other case can prevent loss of datagrams. Because a base station cannot distinguish between the two cases, the base station always bu_ers datagrams emitted from a mobile when the mobile's state is HANDOFF REQUESTED. 6.4.2.2 Handling Datagrams Destined for Mobiles During Hando_ Besides handling datagrams from mobile M, base stations A and B also handle incoming datagrams that are destined for M. Figure 6.3 shows how each base station handles a datagram destined for M at various intervals between T1 and T4. From time T1 to T2, base station A is the owner of M, so A forwards the datagram directly to M over the wireless interface. Between T2 and T4, A has allowed B to captureM and is waiting for a route update from B (i.e.,M's state is HANDOFF ACKED);

A forwards the datagram to B because B has a better wireless link to M. From time T1 to T3, base station B is not the owner of M. However, mobile M is in-range of B, so B forwards the datagram directly to M. Between T3 and T4, B is the owner of M, so B forwards the datagram directly to M. 64 6.4.3 Avoiding Redundant Redirect Messages During Hando_ Completing the ownership transfer of a mobile requires the new owner of the mobile to propagate a route update message to the previous owner and the other Crosspoint processors. Because the route update message takes a _nite amount of time to reach a destination Crosspoint processor, a datagram destined for the mobile can arrive at the destination processor before the route update arrives. When such a datagram arrives, the processor will forward the datagram to the previous owner of

the mobile. Forwarding such a datagram can result in a redundant redirect message from the previous owner, as the example illustrated in Figure 6.6 explains. Tb Tc redirect redundant information Ta incoming datagram new owner previous owner Crosspoint processor P datagram route update Figure 6.6 Illustration of how the relative order in receiving a route update can cause

the previous owner to generate a redundant redirect message. The horizontal lines from left to right represent increasing time. In the _gure, a base station (denoted as new owner) captures a mobile and propagates a route update at Ta. The route update reaches the previous owner of the mobile at Tb and a Crosspoint processor, P, at Tc. On receipt of the route update, the previous owner and P immediately make an ownership change for the mobile 65 (shown as thick lines). Between Tb and Tc, a datagram destined for the mobile arrives at processor P. P forwards the datagram to the previous owner because P has not received the route update yet. When the datagram from P arrives, the previous owner forwards the datagram to the new owner and sends a redirect message back to P. The redirect message informs P that future datagrams to the mobile should be

directed to the new owner. The redirect message is redundant because P has already learned the ownership change at Tc. If a point-to-point virtual circuit is used to deliver the route update, the new owner can propagate the route update in the following order to reduce the possibility of generating redundant redirect messages4. First, the update is sent to the Crosspoint routers. Second, the update is sent to the other base stations excluding the previous owner. Finally, the update is sent to the previous owner. Because mobile hosts tend to access stationary server computers outside Crosspoint, mobiles are more likely to communicate with hosts outside Crosspoint. Thus, datagrams destined for a given mobile are more likely to arrive at a Crosspoint router

than at a base station. By propagating a route update _rst to the Crosspoint routers, the new owner allows the Crosspoint routers to make the routing change as soon as possible, thus reducing the probability of datagrams forwarded by Crosspoint routers arriving at the previous owner. Sending a route update to the previous owner last also helps in reducing redundant redirect messages from the previous owner. For example, in Figure 6.7, processor P receives the route update earlier than the previous owner. Thus, P can forward datagrams that arrive between Tb and Tc directly to the new owner. However, if a datagram arrives between Ta and Tb, P will forward the datagram to the previous owner. If the previous owner receives the forwarded datagram before Tc, the previous

owner forwards the datagram to the new owner without generating a redirect, because the previous owner handles the datagram in the HANDOFF ACKED state (see Figure 6.3). 4If a point-to-multipoint virtual circuit is used, the new owner only delivers a single copy of a route update and hence cannot manipulate the order of sending the update. 66 Ta Tb Tc new owner previous owner datagram incoming datagram datagram Crosspoint processor P

state is HANDOFF_ACKED route update route update Figure 6.7 Avoiding redundant redirect messages by sending route update to the previous owner last. The horizontal lines from left to right represent increasing time. Manipulating the order of propagating a route update cannot eliminate redundant redirect messages completely. For example, in Figure 6.7, if the datagram that P forwards between Ta and Tb arrives at the previous owner after Tc, the previous owner will send a redundant redirect message back to P. The probability of generating such a redirect message decreases as the interval between Ta and Tb decreases and the interval between Tb and Tc increases. Allowing the previous owner to receive a

route update last decreases the interval between Ta and Tb and increases the interval between Tb and Tc, thus reducing the probability of generating redundant redirect messages. 6.5 Processing Datagrams Destined for Mobiles Subsection 6.4.2 has described how a base station handles an incoming datagram that is destined for a mobile during hando_. This subsection de_nes precisely how a Crosspoint processor uses a mobile's state to process datagrams destined for the mobile. 67 6.5.1 Processing on a Crosspoint Router Each Crosspoint router has two network interfaces: one attaches to the campus internet, and the other attaches to the Crosspoint interconnect. A Crosspoint

router forwards datagrams between the two interfaces. Figure 6.8 illustrates how a Crosspoint router processes a datagram destined for a mobile using the state of the mobile5. REMOTELY OWNED UNREACHABLE REMOTE send redirect to sender if from Crosspoint send ICMP host unreachable if from campus (discard datagram) (forward datagram to owner) send redirect to sender if from Crosspoint datagram destined for a mobile

datagram destined for a mobile Figure 6.8 Illustration of how a Crosspoint router uses a mobile's state to process a datagram destined for the mobile. Redirect is a control message. In the UNREACHABLE REMOTE state, the router discards the datagram because the mobile is unreachable. In addition, if the datagram comes from the campus internet, the router sends an ICMP host unreachable [Pos81b] message back to the sender; if the datagram comes from the Crosspoint interconnect, the router does not send an unreachable control message to the sender because only the owner of the mobile can issue an unreachable control message. Instead, the router sends a redirect control message to the sender to correct the routing entry on the sender.

5Recall that a mobile's state on a Crosspoint router only has two possible values. 68 In the REMOTELY OWNED state, the router forwards the datagram to the owner of the mobile. If the datagram arrives from the Crosspoint interface, the datagram is a misrouted datagram, so the router sends a redirect message back to the sender. 6.5.2 Processing on a Base Station Each base station has two interfaces: one is the wireless interface, and the other is the Crosspoint interface. A base station can receive a datagram destined for a mobile from either interface. Figure 6.9 shows how a base station handles a datagram destined for a mobile using the state of the mobile. HANDOFF REQUESTED

REMOTELY OWNED REVALIDATE LOCALLY OWNED HANDOFF ACKED Owner Non-owner datagram (discard) (forward to mobile) (forward to mobile) (forward to mobile) unreachable datagram

(discard) Group 1: Reachable Locally Group 2: Reachable Remotely Group 3: Unreachable (forward to owner) datagram redirect datagram datagram* datagram datagram (fwd to new owner) UNREACHABLE UNREACHABLE LOCAL REMOTE * may trigger a transition to the REVALIDATE state. redirect

Figure 6.9 Illustration of how a base station processes a datagram destined for a mobile. The _gure shows the 7 states in 3 groups. Messages unreachable and redirect are control messages. 69 The _gure shows the 7 states in 3 groups. If the mobile's state is in group 1, the base station is the owner of the mobile; the base station forwards the datagram over the wireless interface to the mobile, except in the HANDOFF ACKED state. In the HANDOFF ACKED state, the base station has allowed a base station to capture the mobile; the base station forwards the datagram to the new owner because the new owner has a better wireless link to the mobile (see also subsection 6.4.2.2). If the mobile's state is in group 2, the mobile is reachable, but the base station

is not the owner of the mobile. In the HANDOFF REQUESTED state, the mobile is inrange of the base station, so the base station forwards the datagram directly to the mobile. The base station does not send a redirect message in the HANDOFF REQUESTED state because the datagram could be forwarded from the owner of the mobile, as the previous paragraph described. In the REMOTELY OWNED state, the base station forwards the datagram to the owner of the mobile and sends a redirect control message back to the sender. The redirect message informs the sender about the correct owner of the mobile. If the mobile's state is in group 3, the mobile is unreachable; the base station

discards the datagram. In addition, the base station sends an unreachable control message to the sender if the state is UNREACHABLE LOCAL or sends a redirect message if the state is UNREACHABLE REMOTE. The unreachable message informs the sender that the mobile is unreachable. Except in the LOCALLY OWNED state, the base station does not change the mobile's state after processing the datagram. The datagram can cause a state transition from the LOCALLY OWNED state to the REVALIDATE state, as the next section explains. 6.6 Revalidation Recall from the previous chapter that a base station uses the revalidation protocol to verify whether a local mobile is still reachable. The owner uses ICMP echo requests

[Pos81b] to elicit a reply from themobile. A reply from the mobile indicates the mobile 70 is still reachable and concludes the revalidation. The owner may request neighboring base stations to help locate the mobile. Revalidation is triggered by a datagram destined for a mobile arriving at the mobile's owning base station. The owner forwards the datagram and records the time at which the datagram arrived in a variable, Tdatagram. The owner then computes _T as Tdatagram Tframe, where Tframe is the time at which the owner received a frame from the mobile. If _T is greater than a preset threshold, _Trevalidate, the owner starts the revalidation protocol. The owner changes the mobile's state from

LOCALLY OWNED to REVALIDATE and starts a timer (see the _nite state machine illustrated in Figure 6.1). While in the REVALIDATE state, the owner continues to forward datagrams for the mobile. If the mobile emits a frame, the owner cancels the timer and changes the mobile's state back to LOCALLY OWNED. If the timer expires, the owner sends an ICMP echo request to the mobile and start another timer. After sending a _xed number of ICMP echo request without receiving a reply, the owner declares the mobile unreachable and changes the mobile's state to UNREACHABLE LOCAL. Intuitively, _T is a measure of how long ago the owner last heard from the mobile, computed at the time the datagram arrives. If the maximum moving velocity of

the mobile is _max, _max _ _T is the maximum distance that the mobile can migrate during _T . Given a _xed _max, a larger _T determines a larger _max__T and a higher probability that the mobile migrates out of the owner's area during _T . Whether the mobile will move out of the owner's area also depends on factors such as the location of the mobile, the size and shape of the owner's area, and the actual moving velocity of the mobile. We assume that the owner base station does not have the support to obtain this additional information. Therefore, the owner cannot determine precisely whether the mobile has moved out of its area during _T. However, the owner can deduce with high con_dence that the mobile is still in its area if _T is very small (e.g.,

1 ms). The threshold _Trevalidate represents a level of con_dence. If _T is less than _Trevalidate, the owner assumes that the mobile is still in its area, without invoking revalidation. 71 6.6.1 On-Demand Revalidation The revalidation strategy described above is termed on-demand because a base station starts the revalidation only in response to an incoming datagram. If a mobile does not emit frames, and there is no datagram destined for the mobile, the mobile's owner does not try to determine the mobile's whereabouts. In fact, there is no need to determine the mobile's whereabouts because no host is trying to communicate with

the mobile. The advantage of on-demand revalidation is economical use of resources. For a mobile that emits frames in response to received datagrams, the emitted frames serve as self-identifying messages that can reduce the frequency of revalidation. For an active but idle mobile that does not attract incoming datagrams, no resources are consumed in determining the mobile's status and location. The disadvantage of the on-demand approach as described is that it can cause misdelivery of a datagram destined for a mobile that seldom emits frames. Consider the example of a mobile that does not emit a frame when migrating from the area of its owner to the area of another base station, B. Because it cannot detect the mobile, base station B cannot capture the mobile. If a datagram for the mobile arrives, the

owner attempts to forward the datagram to the mobile and starts the revalidation protocol. The forwarded datagram cannot reach the mobile because the mobile has migrated out of the owner's area. Eventually, the revalidation protocol will cause an ownership transfer to base station B. However, before the ownership transfer is completed, datagrams destined for the mobile will arrive at the old owner and will be lost. In order to avoid datagram loss, the owner base station has to bu_er each datagram that is forwarded to the mobile during revalidation. If revalidation results in an ownership transfer, the owner forwards the bu_ered datagrams to the new owner. If

it still maintains the ownership, the owner discards the bu_ered datagrams, because the owner has already forwarded the datagrams to the mobile. 72 6.6.2 Periodic Validation Alternatively, a base station can use a periodic validation scheme. Unlike ondemand revalidation, the scheme requires a mobile to emit frames periodically. The emitted frames allow base stations to detect the presence of the mobile. Because there is no guarantee that a mobile will emit frames periodically, special means are needed to implement the scheme. We present two ways to implement the scheme below. First, a base station can use ICMP echo requests to force an active mobile to emit frames regularly. For example, a base station can schedule a timer event that occurs

at a _xed interval. When a timeout occurs, the base station checks each active mobile that it owns. If a mobile has not emitted a frame during the interval, the base station sends an echo request to the mobile. If a mobile does not emit a frame within a preset number of intervals, the base station starts the revalidation protocol to determine the mobile's status. The approach described above requires a base station to periodically monitor all the active mobiles that the base station owns. The periodically processing overhead increases as the number of active mobiles increases. Furthermore, the bandwidth required for sending and receiving echo requests increases as the number of active

mobiles that do not emit frames regularly increases. Also, requiring an active, batterypowered mobile that seldom communicates with other hosts to periodically process an echo request wastes the mobile's power source unnecessarily. Finally, the approach still requires using the revalidation protocol because an echo request may not reach a mobile, and the checking interval is not in_nitesimally small; a mobile may migrate out of its owner's area in one or more checking intervals without being detected. The second approach requires a mobile to run a simple user-level background process. Periodically, the process wakes up and transmits a message. The approach does not require modi_cation of a mobile's networking software or operating system. It is

especially useful for a mobile that runs real-time applications that emits frames infrequently, such as real-time audio or video receivers. However, the approach consumes network bandwidth and power on a mobile. 73 6.7 Recapture Once revalidation completes, an unreachable mobile's state on the mobile's owner is set to UNREACHABLE LOCAL. Unlike propagating a route update, the owner does not broadcast a message to inform the other processors that the mobile is unreachable. Instead, the owner propagates the information as needed: when a datagram for the mobile arrives, the owner informs the sender of the datagram by sending

an unreachable control message. The control message allows the receiving processor to change the mobile's state to UNREACHABLE REMOTE, without changing the owner ID _eld. Thus, an unreachable mobile's state on a non-owner processor is either REMOTELY OWNED or UNREACHABLE REMOTE, depending on whether the processor has received an unreachable control message. Like initial capture, when an unreachable mobile becomes active and emits a frame, base stations cooperate to establish the routing state for the mobile. Unlike initial capture, the owner of an unreachable mobile is a base station not a Crosspoint router. Because an unreachable mobile's owner is a base station, the owner may recapture the mobile, which makes recapturing an unreachable mobile more compli-

cated than capturing a mobile the _rst time. The following two cases explains why recapturing is more complicated than initial capture. Case One. An unreachable mobile becomes active and emits a frame while away from its owner's area. In this case, the mobile's owner does not receive the frame. A nearby base station that receives the frame will send a hando_ request to the owner and changes the mobile's state to HANDOFF REQUESTED. As the state machine in Figure 6.1 illustrates, because the mobile's state on the owner is UNREACHABLE LOCAL, the owner answers the _rst arriving hando_ request with a hando_ ACK and changes the state to HANDOFF ACKED. In the HANDOFF ACKED state, the owner denies subsequent hando_ requests. In other words, the owner allows the sender of the _rst arriving hando_ request to capture the mobile, just like a Crosspoint router does for initial capture.

74 Case Two. An unreachable mobile becomes active and emits a frame in its owner's area. In this case, the owner receives the frame and recaptures the mobile. The owner changes the mobile's state from UNREACHABLE LOCAL to LOCALLY OWNED and broadcasts a route update. Broadcasting the route update is necessary because a subset of the processors may have set the mobile's state to UNREACHABLE REMOTE. In the LOCALLY OWNED state, the owner may receive incoming hando_ requests because other base stations may also detect the mobile. The owner uses the hando_ algorithm to process each request. If the owner denies a request, the mobile's state remains in

the LOCALLY OWNED state; if the owner accepts a request, the mobile's state is changed to HANDOFF ACKED and to REMOTELY OWNED when a route update from the new owner arrives. 6.7.1 One Frame Two Captures Handling the second case makes recapturing a mobile more complicated than initial capturing a mobile. In the second case, a single frame emitted from the mobile can trigger two broadcasts of route updates, one from the owner and the other from one of the owner's neighbors. This phenomenon occurs when the neighbor receives the same frame that causes the owner to recapture the mobile, and the neighbor has a better wireless link to the mobile than the owner. Because both base stations

receive the same frame simultaneously, the owner broadcasts a route update while the neighbor sends a hando_ request to the owner. The route update and the hando_ request travel in opposite direction. When it receives the hando_ request, the owner permits the neighbor to capture the mobile because the neighbor has measured a stronger signal to the mobile. The neighbor captures the mobile and broadcasts a route update shortly after the route update from the owner arrives. The _rst broadcast is redundant because the broadcast is immediately superseded by the second. Because the owner has no knowledge of how many base stations have detected the mobile and the relative signal strength from various nearby base 75

stations to the mobile, the owner cannot foresee whether an incoming hando_ request will result an ownership transfer. The owner can delay for a _xed interval before recapturing the mobile. During the interval, the owner processes incoming hando_ requests. At the end of the interval, the owner transfer the ownership to the base station that has the highest signal strength to the mobile. The longer the delay is, the lower the probability of a redundant recapture becomes. However, the scheme increases the latency of recapturing a mobile. Moreover, if the owner is the only base station that detects the mobile or has the highest signal strength to the mobile, the introduced latency is unnecessary.

Thus, the protocol design does not prevent the redundant recapture from occurring; it trades a possible redundant capture for an optimal latency in recapturing a mobile. Finally, it is worth mentioning that the initial capture protocol avoids the \single frame two captures" phenomenon. 6.8 Summary This chapter describes protocol processing using a _nite state machine model. Conceptually, each Crosspoint processor maintains a _nite state machine for each mobile host. The _nite state machine that corresponds to a mobile de_nes how each Crosspoint processor handles input events intended for the mobile. Each state machine has 7 states. The 7 states and the protocol processing associated with each state are carefully designed to prevent packet loss and to minimize the probability of generating duplicated datagrams during hando_. If Crosspoint processors use

unicast to deliver route update messages, we show that the new owner can reduce the probability of generating redundant redirect messages by sending the route update to the previous owner last. 76 7. SUPPORTING COMMUNICATION BETWEEN MOBILES The wireless hardware used in Crosspoint supports direct communication between two mobiles. The network software on a mobile also supports direct communication with other mobiles in the same IP network. Recall from Chapter 4 that all mobiles use unmodi_ed network software and reside in a single IP network. Thus, a mobile always assumes direct communication with another mobile is possible. Communi-

cation difficulties arise when two mobiles that are out-of-range try to communicate directly. This chapter describes how base stations use software techniques to allow two mobiles that are out-of-range of each other to communicate. 7.1 Direct Communication Communication between two mobiles that are in-range of each other is similar to communication between two hosts attached to a common Ethernet [MB76] cable: each can send a frame directly to the other. To send a frame to another mobile, a mobile inserts the recipient's physical address1 in the frame header and transmits the frame over the wireless interface. When the wireless interface hardware of the recipient receives the frame, the interface checks the destination physical address in

the frame header against the physical address assigned to the interface; if the two addresses match, the interface hardware passes the frame to the host processor for further processing. 1We use the physical address assigned to the wireless interface of a host as the host's physical address. 77 7.1.1 Address Resolution Protocol (ARP) and ARP Cache Conceptually, sending an IP datagram directly to a mobile requires two steps. First, the sending host uses the receiving mobile's IP address to obtain the receiving mobile's physical address. Second, the sending host encloses the datagram in a frame and delivers the frame using the obtained physical address. The sender can use Address Resolution Protocol (ARP) [Plu82] to automate the _rst step. To use ARP,

the sender inserts the receiver's IP address in an ARP request and broadcasts the request. When it receives the request, the receiver sends a reply that contains its physical address directly to the sender [Plu82, Com95]. To reduce the frequency of using ARP, a host uses an ARP cache to store the bindings of IP address to physical address. Figure 7.1 illustrates the contents of an ARP cache. IP Address Physical Address 128.211.10.2 08:00:0e:20:20:48 08:00:0e:20:83:5a 128.211.10.102 128.211.10.101 08:00:0e:20:e0:20 ..... ..... Figure 7.1 IP-to-physical address bindings in an ARP cache.

To delete unused entries and maintain up-to-date bindings, a host assigns a lifetime to each cache entry and periodically ages all the entries in the cache. When the lifetime of an entry reaches zero, the host removes the entry. When it updates an entry, the host reinitializes the lifetime of the entry. A host can use a received ARP message (i.e., a request or a reply) to update an entry. Each ARP message carries the IP-to-physical address binding of the sending host. When an ARP message arrives, the host checks its ARP cache to see if the 78 entry for the sender exits. If so, the host updates the entry using the binding carried in the received message [Plu82, Com95]. 7.2 Indirect Communication via Base Stations Two mobiles that are out-of-range of each other cannot communicate directly.

However, if each is in-range of a base station, the two can communicate via the base stations. Figure 7.2 illustrates how two base stations, B1 and B2, support communication between two out-of-range mobiles, X and Y . B1 B2 Y X mobile mobile ARP for Y base station base station Proxy-ARP reply ARP for X Proxy-ARP reply Figure 7.2 Illustration of how two base stations use proxy-ARP to support communication between two mobiles that are out-of-range of each other. Base station B1 is the owner of X, and base station B2 is the owner of Y . Assume

that X and Y communicate the _rst time. To send the _rst datagram to Y , X broadcasts an ARP request to obtain Y 's physical address. Y cannot receive the request, but B1 can. When it receives the request, B1 starts a timer and waits for a reply from Y . If the timer expires before the reply from Y arrives, B1 answers the request. Because Y does not reply, B1 sends a reply to X after the timer expires. 79 The reply carries the binding of Y 's IP address to B1's physical address. When it receives the reply, X extracts the binding from the reply, installs the binding in its ARP cache, and sends the datagram destined for Y to B1. B1 forwards the datagram to B2, which in turn forwards the datagram to Y. Likewise, when Y sends the _rst datagram to X, Y broadcasts an ARP request to determine X's physical address. B2 answers the ARP request for X, receives the datagram from Y , and forwards the

datagram to B1, which then forwards the datagram to X. The mechanism in which a host (e.g., B1) answers the ARP request intended for another host (e.g., Y ) by supplying its own physical address is known as proxyARP [Pos84, BP87, Com95]. By invoking proxy-ARP, base station B1 diverts datagrams destined for Y to itself, then forwards the datagrams to Y . B1 uses a timer to determine whether to invoke proxy-ARP. If Y answers before the timer expires, B1 knows that X and Y can communicate directly and cancels the timer. If the timer expires, B1 infers that X and Y cannot communicate directly and invokes proxyARP. Interestingly, X and Y still can communicate directly even if Y answers after the timer expires. In this case, X receives the ARP reply from B1 earlier than the reply from Y . Because X uses both replies to update its ARP cache [Plu82], the second reply supersedes the _rst. Consequently, X uses Y 's physical address to communicate

with Y . 7.2.1 Handling Hidden Terminals The scheme described in the previous section assumes that if base station B1 can communicate with mobile X directly, but cannot communicate with mobile Y directly, then X and Y cannot communicate directly. The assumption does not hold if a situation known as hidden terminal [Kar90, All93] occurs. Figure 7.3 illustrates the situation. In the _gure, mobile X can communicate directly with both B1 and Y ; B1 and Y are out-of-range of each other; mobile Y can communicate directly with both B2 and X; B2 and X are out-of-range of each other. 80 X Y

mobile mobile base station B1 B2 base station Figure 7.3 A network con_guration that illustrates the hidden terminal situation. X is in-range of both B1 and Y . Y is out-of-range of B1. B1. B1 and Y are said to be hidden terminals to each other. Apply the scenario described in the previous section to this con_guration. When X broadcasts the ARP request to determine Y 's physical address, both B1 and Y answer. Y answers immediately, and B1 answers after the timer expires. X receives the reply from Y , then the proxy-ARP reply from B1. The proxy-ARP reply from B1 supersedes the reply from Y and thus prevents X from communicating with Y directly. Similarly, Y uses B2 to communicate with X. Thus, X and Y are unable to communicate directly. To handle the hidden terminal situation, base station B1 (or B2) uses the following

strategy. As before, B1 starts the timer when the ARP request from X arrives. While waiting for a reply from Y , B1 monitors datagram transmission from X to Y . A datagram from X to Y indicates X can communicate directly with Y . Therefore, B1 ceases the attempt to invoke proxy-ARP by canceling the timer. 81 7.3 The Default Router Physical Address Recall that the wireless interface of every base station uses the same IP address, and the address is the default router address of every mobile. A mobile's default router is the owning base station of the mobile. In other words, a mobile uses its owner to communicate with hosts outside Crosspoint. To send data to its owner, a mobile encloses the data in a frame with the owner's physical address as destination and transmits the frame. When the frame arrives, the owner recognizes that it is the

intended recipient by checking the destination physical address. Besides receiving frames destined for itself, the owner base station can receive frames destined for other hosts2. The owner discards a received frame that is destined for another host. The example shown in Figure 7.4 illustrates why the owner needs to _lter received frames. Y mobile X mobile B base station Figure 7.4 An example that shows a base station, B, does not forward frames ex-

changed between two mobiles, X and Y . B uses destination physical address to _lter received frames. 2Recall that base stations listen in promiscuous mode. 82 In the _gure, two mobiles, X and Y , communicate directly in the area of their owner, base station B. B can receive the frames exchanged between X and Y . When X sends a frame to Y , the frame carries the physical address of Y as the destination address. When it receives the frame, B does not forward the frame because the destination physical address does not match B's physical address. If B does not check the destination physical address and forwards the frame, Y will receive two copies of the same frame. Although using destination physical address to _lter received frames avoids dupli-

cates, _ltering can prevent a base station from serving a mobile. Consider the case where a mobile switches to a new owner. The ARP cache on the mobile contains the IP-to-physical address binding of the previous owner. If the mobile does not change the binding, the new owner will not forward datagrams emitted from the mobile. The new owner can _x the binding by using a technique known as gratuitous-ARP, in which a host sends an ARP reply (or request) to update an ARP cache entry on the receiving host [Ste94]. Immediately after capturing the mobile, the new owner sends a gratuitous-ARP reply to the mobile. The reply carries the IP-to-physical address binding of the new owner. On receipt of the gratuitous-ARP reply, the mobile replace the binding of the previous owner with the binding carried in the reply. Alternatively, all base stations can use the same physical address3. Thus, the

mapping of the default router IP address to physical address is one-to-one and onto. A mobile uses the same binding regardless of with which base station the mobile is associated. As a result, a mobile need not update its ARP cache when switching to a new base station. As the example in Figure 7.5 shows, using a single default router physical address is better than using gratuitous-ARP. In the _gure, mobile X is in-range of base stations B1 and B2. Base station B1 is the owner (i.e., the default router) of X, and B2 is the owner of Y . Since X is communicating with its owner, the ARP cache on X contains an entry that binds 3We pick the physical address of an arbitrary base station as the default router physical address. 83 X

B1 B2 base station base station ARP request mobile mobile Y (owner of X) (owner of Y) Figure 7.5 An example that demonstrates using a single default router physical address is better than using gratuitous-ARP. the default router IP address to B1's physical address. Base station B2 broadcasts an ARP request to determine mobile Y 's physical address. The request contains the binding of the default router IP address to B2's physical address. When X receives the request, it extracts the binding from the request and updates the corresponding

entry in its ARP cache. Thus, the entry for the default router on X binds to B2's physical address, preventing X to communicate with B1. By using the same physical address for the default router, the ARP request from B2 carries the same binding as that maintained in X's ARP cache. Thus, the ARP request from B2 does not change the ARP cache on X. However, both B1 and B2 will accept a datagram emitted from X that is destined for the default router. Only B1 forwards the datagram because B1 owns X. 7.4 Avoiding Wireless Communication among Base Stations By using the same physical address for the wireless interface of every base station, frames emitted from base stations all have identical source physical address. A base 84 station can use this property to ignore frames coming from adjacent base stations.

We use the example illustrated in Figure 7.6 to explain why a base station need to ignore frames emitted from adjacent base stations. B2 base station Y mobile X mobile B1 base station Crosspoint Interconnect Figure 7.6 A network con_guration used to illustrate why it is necessary to avoid wireless communication among base stations. In the _gure, two nearby base stations, B1 and B2, are in-range of each other and are supporting the communication between two mobiles, X and Y. When X sends

a datagram to Y , B1 receives the datagram and forwards it across the Crosspoint interconnect to B2. Base station B2 encloses the received datagram in a frame and sends the frame to Y . Both Y and B1 receive the frame. If B1 forwards the frame from B2, a forwarding loop results. If the datagram is a unicast datagram, the frame from B2 will have Y 's physical address as destination. B1 can discard the frame because the destination physical address does not match the default router physical address. However, if the datagram is a multicast datagram, because destination IP multicast address determines destination physical address [Dee89], both X and B2 use the same destination physical address to deliver the datagram. Thus, B1 must use the source physical address to discard the frame from B2. 85

7.5 Two Communicating Mobiles Moving Towards Each Other Two mobiles that stay in the same area may not be able to communicate directly. For example, consider the two mobiles in Figure 7.7. X mobile Y mobile B base station Figure 7.7 A network con_guration that illustrates two mobiles in the same area cannot communicate directly. The two mobiles use their owner to communicate. Mobiles X and Y are on each side of their owner base station, B. Both can communicate with B, but are out-of-range of each other. As mentioned earlier, base station B uses proxy-ARP to allow X and Y to communicate indirectly.

Assume that X and Y move in-range of each other while communicating via B. Although direct communication is possible, the two still use B to communicate, because each has a cached binding of the other's IP address to B's physical address. Indirect communication via B remains until either one times out the cached binding and broadcasts an ARP request. Indirect communication via B is ine_cient because each datagram exchanged between X and Y traverses the wireless LAN twice. To allow X and Y to communicate directly, base station B can send a gratuitous-ARP reply that carries the binding of 86 Y 's IP address to Y 's physical address to X and another gratuitous-ARP reply that carries the binding of X's IP address to X's physical address to Y . The above scheme assumes that B can determine precisely when X and Y can communicate directly and invokes gratuitous-ARP accordingly. After each updates

the ARP cache using the gratuitous-ARP reply, both will not be able to communicate via B. Because base stations do not have support to determine precisely when two mobiles can communicate directly, the current implementation does not use gratuitousARP. Instead, a base station uses a special echo request. The echo request is special because the base station arti_cially sets the source IP address of the echo request to a reserved, unassigned address. When a mobile receives the special echo request, the mobile responds with an echo reply to the reserved address. Because the address is unassigned, the mobile will not _nd the corresponding physical address in its ARP cache. Thus, the mobile will broadcast an ARP request to obtain the physical ad-

dress. Because the IP address is reserved, and base stations are programmed not to reply the ARP request, the mobile will not receives a reply. The mobile retransmits the ARP request for a _xed number of times, then gives up. The purpose of the special echo request is not to generate an echo reply, but to force the receiving mobile to broadcast ARP requests that allows nearby mobiles to update ARP cache. Because an ARP request carries the IP-to-physical address binding of the sender, a receiving mobile that has a cached ARP entry for the sender will update the cached entry using the binding carried in the request [Plu82]. Consider again the example in Figure 7.7. While base station B is forwarding datagrams for X and Y , B sends the special echo request to each as a probe packet. The probe packet causes each mobile to broadcast ARP requests. If X and Y are

in-range of each other, both will update the ARP cache using the ARP request from the other, making direct communication possible. If X and Y are out-of-range, the ARP requests from one will not reach the other; thus both can still communicate using B. 87 7.6 Two Communicating Mobiles Moving away from Each Other In contrast to the situation described above, two mobiles that are communicating directly can move out-of-range of each other, as Figure 7.8 illustrates. Y mobile X mobile X Y

B base station Figure 7.8 Illustration of two mobiles that are communicating directly can move away from each other. Dashed arrows indicate moving paths of mobiles. In the _gure, two nearby mobiles X and Y are communicating directly in the area of their owner, base station B. The two mobiles move away from each other while communicating. When the mobiles are out-of-range, direct communication becomes impossible. Both have no knowledge of the situation and continue to use the other's physical address to deliver datagram to the other. To allow X and Y to communicate when they are out-of-range, B can use gratuitousARP to change the ARP cache on each and forwards datagrams between them. However, B does not support to determine whether X and Y are out-of-range. In other

words, base station B has a mechanism to allow the two to communicate, but does not know when to invoke the mechanism. 88 One approach to the problem is to manipulate the lifetime of individual ARP cache entries on each mobile. The ARP cache entries on X (or Y ) can be classi_ed into two sets: one set contains the entry that binds the default router IP address to physical address; the other set contains the rest of the entries. All the ARP entries in the second set correspond to the mobiles with which M is interested in communicating. The idea is to assign a shorter lifetime (e.g., 1 minute) to each entry in the second set.

Thus, X can quickly time out stale entries and obtains the latest bindings. However, the approach increases the frequency that X broadcasts an ARP request and requires additional software support on X. 7.7 A Simple Approach As the previous section shows, cached ARP bindings can impede seamless communication between two mobiles. Consider the ARP cache on a mobile, X, that is communicating with another mobile, Y . The ARP cache entry for Y on X has two possible bindings: 1) if X uses one or more base stations to communicate with Y , the entry binds Y 's IP address to the default router physical address; 2) if X communicates with Y directly, the entry binds Y 's IP address to Y 's physical address. As long as X and Y are in-range of base stations, the cached binding in the _rst case does not impede the communication between X and Y. However, the cached binding

causes ine_cient routing when X and Y are capable of direct communication. In the second case, the cached binding impedes the communication between X and Y when the two are out-of-range. To prevent cached ARP entries from impeding communication between two mobiles, base stations can enforce the following policy: Two mobiles always communicate via one or more base stations. Base stations can use proxy-ARP and gratuitous-ARP to implement the policy. With the policy, base stations no longer need to determine whether two mobiles can communicate directly. However, the policy introduces ine_ciency: two mobiles 89 that are in-range of each other cannot communicate directly4. Observations so far

have shown that two mobiles that are in-range of each other rarely communicate. If the observation holds, the simplicity of this approach may outweigh the introduced ine_ciency. 7.8 Summary In Crosspoint, two mobiles that wish to communicate assume direct communication is possible. If they are in-range of each other, the two mobiles can communicate directly without the assistance from nearby base stations. If they are out-of-range of each other, the owner base station of each of the mobiles uses proxy-ARP and forwarding to make the communication possible. In addition to using proxy-ARP, base stations can use gratuitous-ARP to modify the ARP cache on a mobile. However, the cached ARP entries on mobiles can still impede seamless communication. For example, when two mobiles that are communi-

cating directly move out-of-range of each other, the two mobiles cannot maintain the communication because each of the mobiles still transmits frames using the physical address of the other as destination. This chapter suggests an approach that can prevent cached ARP entries from impeding communication between two mobiles as described above. The approach prohibits direct communication between two mobiles. The advantage of the approach is simplicity because base stations need not determine whether two mobiles can communicate directly. The disadvantage of the approach is nonoptimal routing between two mobiles that can communicate directly. Further research is needed to justify the

approach. 4Two mobiles that are in-range of each other but out-of-range with all base stations still can communicate directly. 90 8. MISCELLANEOUS ASPECTS OF CROSSPOINT Previous chapters explain the design and implementation of the Crosspoint protocols and routing. This chapter describes three supplementary topics: 1) the steps that a Crosspoint processor takes to become operational after power-up; 2) the schemes and protocol extensions that Crosspoint processors use to handle message loss and processor failure; 3) the algorithm that each base station uses to process incoming hando_ requests.

8.1 Initialization When a Crosspoint processor (i.e., a base station or a Crosspoint router) powers up, the processor must complete an initialization procedure before it can provide services to mobiles. The procedure consists of two sequential steps. 8.1.1 The First Step of Initialization In the _rst step, a processor retrieves a set of static data from a permanent store (e.g., a disk device) and uses the retrieved data to initialize the Crosspoint software and network devices. The processor learns its ID and the Crosspoint network ID in this step. The processor uses the Crosspoint network ID to determine whether an IP address belongs to a mobile host and to extract a mobile's host ID from the mobile's IP address. The processor then con_gures the network interface to establish two communication channels to each of the other Crosspoint processors. If it is a base station, the processor proceeds to complete the following additional

tasks. The processor initializes its wireless interface and assigns the default router IP address and physical address to the interface. The processor learns the ID of 91 the Crosspoint router to which the processor forwards datagrams destined for hosts outside Crosspoint. The processor also learns the ID of each of the neighboring base stations, for use by the revalidation protocol. 8.1.2 The Second Step of Initialization After completing the _rst step, the processor establishes its identity and the communication channels to the other processors. In the next step, the processor retrieves a copy of the routing table from an operational processor across the Crosspoint interconnect and uses the retrieved copy to initialize its own routing table. The proces-

sor selects a target processor randomly and sends a download request to the target processor. If it is operational, the target processor will respond to the request by transmitting its routing table to the requesting processor. If the target processor does not respond, the processor selects another target randomly and retries. After trying a preset number of times without success, the processor infers that no processor on campus has a valid routing table (e.g., all processors reboot simultaneously). In this case, the processor invokes a self-initialization algorithm to initialize its routing table. For each entry in the table, the algorithm initializes the current state _eld to UNREACHABLE REMOTE and the owner ID _eld to a predetermined Crosspoint router. Each Crosspoint processor uses the same algorithm to ensure the routing

state for a given mobile is consistent across all processors. 8.2 Reliability Considerations The Crosspoint design assumes that the Crosspoint interconnect is a network system that delivers packets with best-e_ort. That is, the system does not guarantee that a packet sent across the interconnect will arrive at the destination processor intact. Besides possible loss of packets, Crosspoint processors may fail. Best-e_ort delivery can create inconsistent routing states on Crosspoint processors. For example, if a processor misses a route update for a mobile, the processor will maintain an 92 inconsistent routing state for the mobile, with respect to the other processors that have correctly received the route update. This section discusses schemes and protocol extensions that minimize or rectify

inconsistency. The discussion is based on the following two assumptions. First, the communication channels between each pair of processors are functional. Additional protocol software can be used to monitor individual channels and alert administration sta_ if channel failure occurs. Second, each processor is either functional or nonfunctional. A processor cannot be in a half-functional state (e.g., can transmit but cannot receive). 8.2.1 Handling Message Loss and Processor Failure During Hando_ Recall that the hando_ protocol uses a request-reply type of interaction between two base stations. A base station, A, sends a hando_ request for a mobile, M, to M's owning base station, B, and awaits a reply. Because communication failures can occur,

base station A starts a timer before sending the request to avoid waiting forever. If the reply arrives, base station A cancels the timer and proceeds. If the timer expires, base station A assumes that the request was lost, retransmits the request, and starts another timer. If the reply does not arrive after a preset number of retransmissions, base station A assumes that base station B has failed and captures M. If base station B agrees that base station A can capture mobile M, B sends a hando_ ACK reply and awaits a route update message. B uses timers and retransmissions to ensure that A receives the reply and captures M. If a route update message does not arrive after a preset number of retransmissions, base station B assumes that

base station A has failed and broadcasts a route update to recapture M. Broadcasting the route update is necessary because A may have failed during propagation of the route update for M. In addition, base station B starts the revalidation protocol to ensure that M will emits a frame that allows a nearby base station to capture M. 93 8.2.2 Reliable Ownership Transfer The protocol interaction described above illustrates an important protocol design decision: ownership transfer from one base station to another is reliable. Once an owner base station allows another base station to capture a mobile, the owner ensures that the new owner captures the mobile. The ownership transfer completes after the

(previous) owner receives a route update for the mobile from the new owner. Thus, the previous owner always maintains a correct routing state for the mobile. If a datagram destined for the mobile arrives, the previous owner can correctly forward the datagram to the new owner. 8.2.3 Handling Inconsistent Routing States Because the Crosspoint interconnect is a best-e_ort delivery system, the system does not guarantee that a route update propagated from a base station will arrive at every intended recipient. Furthermore, Crosspoint protocols do not check whether all the intended recipients have received the update. Thus, it is possible that a Crosspoint processor misses a route update. Because a route update carries the latest ownership

and reachability information for a mobile, a processor that misses the route update will maintain outdated information for the mobile. To rectify outdated ownership information, Crosspoint processors use two schemes. First, base stations use broadcast to propagate a route update. Although broadcasting a route update does not guarantee that the route update will arrive at every receiver, each broadcast provides a new opportunity for a Crosspoint processor to update the routing entry for a mobile. The second scheme uses redirect control messages. A processor uses a redirect control message to inform another processor about the change of ownership for a mobile. Unlike a route update, a redirect message for a

mobile is originated from a processor that does not own the mobile. A processor sends a redirect message in response to a misrouted datagram. For example, if a processor has an outdated ownership information for a mobile, the processor will forward a 94 datagram destined for the mobile to a base station that does not own the mobile. The base station will respond to the misrouted datagram with a redirect message. It is important that a redirect message for a mobile is originated from a processor that has reliable ownership information for the mobile. Observe that the set of processors that are likely to receive a misrouted datagram destined for the mobile is the set of the previous owners of the mobile. As mentioned in section 8.2.2, the protocol

design ensures that each of the previous owners maintains reliable ownership information for the mobile. Thus, a redirect message in response to a misrouted datagram will contain reliable information that the receiver can use to reach the correct owner. Another form of a redirect message is a hando_ NAK message. If a processor receives a hando_ request for a mobile that the processor does not own or has handed o_ to another processor, the processor denies the request using a hando_ NAK message. In the NAK message, the processor encloses the owner (or the new owner) of the mobile. 8.2.4 Handling Denial of Service A lost route update can cause a more serious consequence: denial of service. To

understand the cause, consider the following example. Suppose a previously unreachable mobile, M, becomes active and emits a frame. A base station captures M and broadcasts a route update for M. If a Crosspoint router, R, misses the route update, and M's state on R is UNREACHABLE REMOTE, then R will discard incoming datagrams that are destined for M. Thus, mobile M cannot communicate with hosts outside Crosspoint via router R. Crosspoint processors use the following scheme to solve the service denial problem. Suppose a mobile emits a datagram, and the mobile's owning base station forwards the datagram to a Crosspoint processor. When the datagram arrives, the processor can infer that the mobile is reachable.

Applying the scheme to the example given earlier. Router R checks each datagram received from the Crosspoint interconnect. If a datagram is originated from a mobile, 95 and the mobile has a unreachable state, router R change the state for the mobile to reachable. 8.2.5 Resolving Simultaneous Capture A simultaneous capture situation occurs when the owner of a mobile fails while more than one base station is waiting for a hando_ reply from the owner. The waiting base stations detect that the owner has failed and capture the mobile; each broadcasts a route update at about the same time. Consequently, the routing state for the mobile on all processors becomes inconsistent. A protocol similar to the bidding

protocol described in section 5.4.1 of Chapter 5 can be used to resolve the situation. Each route update message includes an additional _eld used to carry a bid. Before broadcasting a route update for a mobile, a base station forms a bid by concatenating the signal strength to the mobile with a random number, and includes the bid in the route update. After broadcasting the route update, the base station monitors incoming route update messages. If another route update for the same mobile arrives shortly (e.g., 50 ms) after the broadcast, the base station infers that a simultaneous capture has occurred and compares the bid carried in the incoming route update to the local bid. If the local bid is larger, the base station starts a timer for recapturing

the mobile. If another route update that carries a larger bid arrives, the base station cancels the timer. If all the incoming bids are less than the local bid, when the timer expires, the base station broadcasts the route update again to ensure that the routing state for the mobile is consistent across all processors. Because there is no guarantee that all the base stations that involve in the simultaneous capture will receives the route update from each other, another round of bidding may occur. In the worst case, two or more base stations may become the owner of the same mobile. Consider the following scenario. Suppose two adjacent base stations, B1 and B2, simultaneously capture mobile M, and each misses the route update from the other. Thus, each of the base stations regards itself as the owner of M and forwards datagrams for M. Because both base stations can reach M

96 directly, mobile M can still receive incoming datagrams. However, both base stations will forward a datagram emitted from M, thus generating duplicates. It is likely that B1 and B2 will forward the datagram from M to a common Crosspoint processor (e.g., a Crosspoint router). Figure 8.1 illustrates the situation. processor P B1 B2 M mobile Crosspoint Interconnect base station base station Figure 8.1 An example that shows two adjacent base stations both claim to be the

owner of a mobile, M. Both base stations forward datagrams for M. Processor P received the forwarded datagrams and detects that M has two owners. In the _gure, when B1 and B2 forwards the datagram from M to processor P, P receives two copies of the same datagram one after another. P uses a timestamp to detect that M has two owners. Processor P uses a redirect message to select either base station as the owner. 97 8.3 The Hando_ Algorithm Recall from Chapter 4 that each base station uses a hando_ algorithm to process each incoming hando_ request. Figure 8.2 illustrates a logical view of the hando_ processing on a base station. accept or deny handoff algorithm

(handoff parameters) handoff request (local parameters) Figure 8.2 A logical view of the hando_ processing on a base station. Each hando_ request carries a set of parameters. Each base station also maintains a corresponding set of parameters. When a base station receives a hando_ request for a mobile that the base station owns, the owner base station compares the parameters carried in the request with the corresponding parameters maintained locally. The result of the comparison either denies or accepts the request. The hando_ processing gives the owner priority in maintaining the ownership of the mobile over the requesting base stations. The owner uses threshold values to implement the priority policy. For

example, the owner allows a requesting base station to capture the mobile only if the requesting base station's signal strength to the mobile exceeds the signal strength maintained locally by a prede_ned threshold. 98 8.3.1 Parameters Used in Hando_ Decisions Signal strength is the primary parameter used in a hando_ decision. When a base station receives a frame from a mobile, the base station obtains a measure of the signal strength (SS) to the mobile from the wireless hardware1. In addition, the base station records the time at which the frame arrives. The frame arrival time, Tframe, is then used to derive an integer value called IFT (Inter-Frame Time), which measures the time interval between two successive frames from the mobile. After obtaining SS

and IFT, the base station computes a weighted running average for each, denoted as MSS (Mean Signal Strength) and MIFT (Mean Inter-Frame Time), respectively. MSS0 = SS if IFT > _Texpire MSSi = (1 _) MSSi1 +_ SS otherwise (0 < _ < 1; i _ 1) (8.1) MIFT0 = IFT if IFT > _Texpire MIFTi = (1 _) MIFTi1 + _ IFT otherwise (0 < _ <1; i _ 1) (8.2) Values MSSi and MIFTi each represent a weighted running average of a series of measurements up to the current measurement; constants _ and _ determine the

weight assigned to the current measurement. The base station does not keep the two means forever; it initializes each mean with the current measurement when the IFT exceeds a preset interval, _Texpire. After deriving MSS and MIFT, the base station stores the two values along with Tframe as the hando_ parameters for the mobile. When sending a hando_ request for the mobile, the base station only includes MSS and MIFT in the request. The base station does not include Tframe in the request because Crosspoint processors do not synchronize their clocks. Thus, Tframe only has local signi_cance. The receiving base 1The wireless hardware currently deployed in Crosspoint provides three measurements of the

wireless link quality between a base station and a mobile: signal level, silence level, signal quality [Cor93]. We calculate signal strength as signal level minus silence level. The signal quality measurement is not used because the signal level measure is more accurate. 99 station uses the time at which the hando_ request arrives, Trequest, to approximate the Tframe maintained at the sending base station. The subsequent 3 subsections describe how the hando_ algorithm uses the 3 parameters in a hando_ decision. We use the example illustrated in Figure 8.3 to explain the algorithm. mobile MIFT MSS

M BA owner of M Crosspoint interconnect handoff request for M Figure 8.3 An example used to explain the hando_ algorithm. Base station A sends a hando_ request for mobile M to M's owner, base station B. In Figure 8.3, base station B owns mobile M. Base station A receives a frame from M and sends a hando_ request for M to B. B receives the request and invokes the hando_ algorithm to process the request. 8.3.2 Hando_ Using Frame Arrival Time (Tframe) Before B uses the hando_ parameters maintained locally to process the request, B must determine whether the parameters are valid. B uses the following heuristic

to determine: let _t be the di_erence between the request arrival time (Trequest ) and 100 the latest frame arrive time (Tframe) that B maintains for M; if _t exceeds _Texpire, then the MSS and MIFT parameters for M are inaccurate and cannot be used. Constant _Texpire is set to 10 seconds. If _t exceeds _Texpire , base station B has missed the frame that triggers A to send the hando_ request, and has not received a single frame fromM for _t seconds. Base station B infers that mobileM has migrated to the area of base station A and allows A to capture M. Figure 8.4 uses pseudo-code to summarize the hando_ processing. Trequest Tframe Texpire

 t > Texpire) then ACK else continue t = Trequest - Tframe : a predefined constant : the time at which the latest frame from mobile M arrives : the time at which the handoff request for mobile M arrives Calculate if ( Figure 8.4 The _rst step of hando_ processing: comparing frame arrival time, Tframe, with the request arrival time, Trequest. 8.3.3 Hando_ Using Mean Signal Strength (MSS) If _t is less than _Texpire , base station B checks the MSS parameter next. Let the MSS for M maintained locally be MSSlocal, the MSS carried in the hando_ request be MSSremote, and _MSS be MSSremote minus MSSlocal . If _MSS is greater than a threshold, _MSS, B learns that the requesting base station, A, has

a much stronger signal to M, and allows A to capture M; otherwise, B checks to see if it receives the frame, f, that triggers A to send the hando_ request, using the following heuristic. Assume that dmax is the maximum delay for a hando_ request to propagate from one base station to another. If it receives frame f, base station B will record the 101 arrival time of f in Tframe. If _t, which is Trequest Tframe, is less than dmax, then B deduces that it has received frame f. If base station B receives frame f, then mobile M is still in-range of B; B denies A's request to capture M, even if A has a stronger signal to M (i.e., 0 < _MSS _ _MSS). The motivation is to give base station B priority in maintaining the ownership of M over base station A. Figure 8.5 summarizes the processing.

MSSremote MSS MSSlocal dmax t MSL > MSS ) then ACK MSS = MSSremote - MSSlocal t < dmax ) then NAK : mean signal strength carried in the handoff request : a predermined threshold : mean signal strength maintained locally : the maximum delay for a handoff request to arrive = Trequest - Tframe if ( if (

Calculate else continue /* yes; mobile is still in-range */ /* receive the frame that triggers the handoff request? */ Figure 8.5 The second step of hando_ processing: comparing mean signal strength and checking frame reception. If base station B misses frame f, the hando_ decision becomes complicated, as the next subsection explains. 8.3.4 Hando_ Using Mean Inter-Frame Time (MIFT) At this point, base station A does not have strong enough signal to capture mobile M from base station B, which is the owner of M. But, A receives a frame from M that B misses. It appears that A has received one more frame from M than B. As Figure 8.6 shows, that may not be the case. 102 base station B

base station A T1 T2 T3 T4 T5 handoff request Figure 8.6 Illustration of two base stations, A and B, receive frames emitted from a mobile during the period between T1 and T5. A solid \X" represents a received frame; a dotted \X" represents a missed frame. The horizontal arrows represent increasing time. In the _gure, base stations A and B both receive frames emitted from mobile M during the period between T1 and T5. At time T5, base station A receives a frame from M and sends a hando_ request to B. Base station B receives the request and infers that it has missed the frame. Because A does not send a hando_ request for each received frame, B does not know that A misses two frames between T2 and T5.

Moreover, because a base station uses a received frame to obtain a sample of signal strength, B has obtained one more sample than A between T1 and T5. Base station B can make a better hando_ decision if B knows the frame arrival pattern at base station A. The MIFT parameter approximates a frame arrival pattern using a single integer and does not require synchronized clocks on base stations. Figure 8.7 illustrates how base stations A and B calculate the MIFT for M, using the same frame arrival patterns illustrated in Figure 8.6. In the _gure, base stations A and B each calculate the MIFT for M using Equation 8.2, which is de_ned in subsection 8.3.1. The constant _ is set to 1=2. At time T5, base station A sends a hando_ request that carries integer 80 as the MIFT for M to B. Base station B receives the request and infers that it has missed the frame that

M emits at T5. B uses the request arrival time (Trequest ) to compute the interframe time IFT3, as if a frame from M has arrived at Trequest . B then uses IFT3 to derive 103 IFT IFT IFT 1 base station B IFT 0 T1 T2 T3 T4 40 base station A 40 40 40 40 40 T5

handoff request 80 40 40 40 40 120 Time MIFT ( = 1/2) Time MIFT ( = 1/2) T1 T2 T3 T4 T5 23 IFT IFT 01 MIFT = (1 )MIFT + IFT & MIFT = IFT i i-1 i 0 0

Figure 8.7 Illustration of how base stations A and B compute the mean interframe time (MIFT) using a series of inter-frame time (IFT) measurements. the MIFT for M. Note that B does not use Trequest to update the Tframe parameter for M. Thus, the missed frame causes B to compute a larger IFT (inter-frame time) for M when receiving the next frame from M. Let the MIFT from base station A be MIFTremote, the MIFT base station B derives be MIFTlocal , and _MIFT be MIFTlocal minus MIFTremote. A positive _MIFT indicates base station B has missed more frames in the recent past than base station A. If _MIFT is greater than MIFTlocal, base station B allows A to capture M; otherwise, B denies the request. Factor is a constant between 0 and 1 (e.g., 1/8). Like the threshold for checking signal strength (_MSS), value MIFTlocal represents a threshold that gives the owner (i.e., base station B) priority in maintaining the ownership of mobile M. Figure 8.8 summarizes the processing.

104 MIFTremote MIFTlocal : mean inter-frame time carried in the handoff request : mean inter-frame time maintained locally : a constant between 0 and 1 Calculate & MIFT = MIFTlocal if (MIFT > * MIFTlocal MIFTlocal else NAK - MIFTremote ) then ACK Figure 8.8 The third step of hando_ processing: comparing mean inter-frame time, MIFT. 8.3.5 An Example Use of MIFT

To make the use of MIFT more concrete, consider another example, illustrated in Figure 8.9. Base station B owns M and is forwarding datagrams for M. Base station B has a better signal to M than base station A has. Suppose the wireless link between B and M suddenly experiences a prolonged interference. As a result, B cannot receive frames emitted from M. The interference does not a_ect the wireless link between A and M; base station A continues to receive frames from M, obtains the measurements of signal strength for M, and sends hando_ requests to B. Because it cannot receive frames from M, base station B cannot obtain new measurements of signal strength for M. Consequently, base station B cannot update the mean signal strength (MSS) that corresponds to M. That is, base station B still maintains a higher MSS than A, despite the interference. Therefore, base station A cannot use the MSS parameter to capture M. Base station A can count on either

_t (Trequest Tframe) exceeding _Texpire or the _MIFT parameter exceeding the threshold. Since _Texpire is 10 seconds, base station A has a higher probability of capturing M using the MIFT parameter. 105 M mobile BA base station base station experiencing interference owner Figure 8.9 An example that illustrates the use of the MIFT parameter. Base station B owns mobile M and is serving M. When the wireless link between B and M experiences prolonged interference, base station A can use the MIFT parameter to capture M.

8.4 Summary This chapter describes three aspects of Crosspoint: system initialization, reliability issues, and the hando_ algorithm. After power-up, a Crosspoint processor must complete a two-step procedure to become operational. In the _rst step, the processor initializes the Crosspoint software modules and establishes two communication channels to each of the other Crosspoint processors. In the second step, the processor retrieves a copy of the routing table from an operational Crosspoint processor, and uses the retrieved copy to initialize its own routing table. If none of the other Crosspoint processor has a valid routing table, the processor initializes the routing table using a prede_ned algorithm. The Crosspoint protocols described in the previous chapters need to be extended

to handle message lost and processor failure. In particular, the hando_ protocol has been extended to achieve reliable ownership transfer from one base station to 106 another. Reliable ownership transfer allows a base station to issue reliable redirect control messages, which is is essential for correcting inconsistent routing states. A base station uses the hando_ algorithm to determines whether it should transfer the ownership of a local mobile to another base station. The algorithm makes the hando_ decision using a combination of three parameters: mean signal strength (MSS), mean inter-frame time (IFT), and the time at which the base station receives a frame from the mobile (Tframe). The MSS is the primary parameter used in the hando_ decision. The IFT approximates the arrival pattern of frames emitted

from the mobile. The Tframe allows the base station to determine whether the other two parameters are valid. The algorithm gives the owner priority in maintaining the ownership of the mobile over the requesting base stations. 107 9. EXPERIMENTAL RESULTS This chapter describes a prototype implementation of the Crosspoint network and presents results of three experiments conducted using the prototype. The _rst experiment measures the hando_ latency. The second experiment studies the impact of hando_ on TCP throughput. The third experiment studies the e_ects of motion and interference on TCP performance in a realistic building environment. In each experiment, additional code is inserted into the Crosspoint software modules to gather

data into kernel memory bu_ers. Application programs read the gathered data from the kernel bu_ers for o_-line analysis. 9.1 Experimental Network Con_guration Figure 9.1 illustrates the prototype system used for conducting the experiments. The prototype consists of an ATM switch that provides a high-speed interconnect among a Crosspoint router and three base stations. The Crosspoint router is a SPARC IPC workstation. Each base station consists of two computers: a SPARC IPC workstation with an ATM interface and a 120 MHz Pentium (i586) PC with a wireless interface1; the two computers communicate using a 10 Mbits/sec (Mbps) Ethernet. The wireless interface is a WaveLAN adaptor that o_ers a raw data rate of 2 Mbps. The connection between each IPC workstation and the ATM switch is a 100 Mbps _ber link. Each IPC workstation uses two point-to-point permanent virtual circuits

(PVCs) to communicate with each of the other IPC workstations. One PVC uses AAL5 to carry IP datagrams, and the other PVC uses raw ATM cells to carry control 1At the time when the prototype system was built, we could not obtain the wireless adaptors for the SPARC processors or the ATM adaptors for the Pentium processors. 108 ATM Switch FORE ASX-100 Sun IPC Sun IPC Sun IPC 10 Mbps Ethernet 2 Mbps

Sun IPC WaveLAN i586 i586 i586 Crosspoint router base station Purdue Campus Internet 10 Mbps Ethernet 100 Mbps Fiber Figure 9.1 Illustration of the prototype system used for conducting the experiments. messages. The prototype system attaches to the campus internet using a 10 Mbps Ethernet interface. All the IPC workstations run version 4.1.3 of the SunOS operating system. All

the Pentium PCs run the Xinu operating system [Com84]. The core of the Crosspoint software resides in the SunOS kernel. The driver for the wireless interface and the rest of the Crosspoint software reside in Xinu. Only one mobile host is used in the experiments. The mobile host is a 90 MHz Pentium laptop PC running the Windows95 operating system. The mobile host uses vendor supplied networking software and driver code without any modi_cations. 9.2 Experiment 1: Hando_ Latency The _rst experiment measures hando_ latency, the time it takes to complete an ownership transfer from one base station to another. The three base stations were 109 placed on each oor of the Computer Science building. The mobile host roamed in the CS building while using a combination of TELNET [PR83], FTP [PR85], and HTTP

[BLFN96] to communicate with hosts on the Internet. A set of four timestamps were gathered during each hando_. Figure 9.2 illustrates when each of the four timestamps is taken. Ta Tc Tb Ta Tb T1 T3 (Previous Owner) (New Owner) Base Station B2 Base Station B1 Handoff ACK Route Update

Handoff Request T4 T2 Handoff Latency = T4 - T1 ~ 1/2 + Figure 9.2 Illustration of the four timestamps, T1 to T4, taken during each hando_ to calculate the hando_ latency. The vertical arrows pointing down the page represent increasing time. In the _gure, base station B1 uses the hando_ protocol to obtain the ownership of the mobile from base station B2. During the ownership transfer, base station B1 records two timestamps, T1 and T3; base station B2 records the other two timestamps, T2 and T4. Timestamp T1 stores the time at which B1 sends the hando_ request.

Timestamp T2 stores the time at which B2 receives the hando_ request message. Base station B2 answers the request with an hando_ ACK message. When the hando_ ACK 110 reply arrives, B1 stores the arrival time in T3, and then propagates a route update message. B1 uses point-to-point virtual circuits to deliver the route update to each of the other Crosspoint processors. As described in Chapter 6, B1 delivers the route update to B2 last in order to reduce the probability of generating redundant redirect messages. When the route update arrives, B2 stores the arrival time in T4. The hando_ latency, H, is de_ned as T4 T1. Because the base stations do not synchronize their clocks, the hando_ latency cannot be calculated by subtracting T1

from T4. However, timestamps T1 and T3 can be used to compute the interval _Ta, and T2 and T4 can be used to compute the interval _Tb. As Figure 9.2 illustrates, H is the sum of _Tb and _Tc. Because _Tc cannot be derived using timestamps T1 and T2, we use 1=2 _Ta to approximate _Tc, and _Ta as the upper bound for _Tc. Thus, for each set of the captured timestamps, two values, Happrox and Hmax, are computed using the following two equations: Happrox = 1=2 _Ta + _Tb (9.1) Hmax = _Ta + _Tb (9.2) Let the number of processors attached to the ATM network be N. Because the new owner uses point-to-point virtual circuits to deliver the route update message, _Tb is a function of N:

_Tb = C + (N 1) _ t (9.3) where C represents the sum of the following three values: the propagation delay of the hando_ ACK message, the processing time of the hando_ ACK message, and the time to form the route update message; t is the time the new owner takes to transmit a single route update message to a Crosspoint processor. The new owner transmits a total of N 1 route update messages. Because the prototype system has only 4 Crosspoint processors attached to the ATM network, we use the following scheme to simulate delivering the route update message sequentially to N 1 processors, where N is greater than 4. Suppose base

station B1 captures the mobile from base station B2. Base station B1 _rst sends the 111 route update to the Crosspoint router, sends N 3 copies of the route update to base station B3, and _nally sends the route update to base station B2. That is, in addition to sending the route update to the Crosspoint router and the previous owner, the new owner sends N 3 copies of the route update messages to the base station that does not participate in the hando_ interaction. In this way, the new owner disseminates N 1 route update messages after capturing the mobile. 9.2.1 Results and Analysis We performed 7 measurements, with N ranging from 10 to 500. For each mea-

surement, 50 sets of timestamps were gathered. Figures 9.3 and 9.4 plot the values of Happrox and Hmax for each measurement, respectively. The _gures show that both Happrox and Hmax increase as N increases. The results show that the hando_ latency is less than 19 ms if 500 Crosspoint processors were attached to the ATM network. Figure 9.5 shows that the mean for _Ta does not increase with N, while the mean for _Tb is linearly proportional to N. The mean for Happrox or Hmax is also linearly proportional to N. In essence, the results of the experiment agree with Equation 9.3 and con_rm that _Ta is independent of N. Recall from Chapter 6 that during interval _Ta, the new owner bu_ers datagrams

emitted from the mobile. Because _Ta is independent of N, the number of datagrams that will be bu_ered during _Ta is also independent of N. The mean for _Ta, calculated using the 350 sets of gathered timestamps, is 0.728 ms, and the standard deviation is 0.0143 ms. The 99% con_dence interval for the true mean is between 0.726 ms and 0.730 ms. Assume that the wireless adaptor of the mobile operates at the maximum speed (i.e., 2 Mbps), and that the inter-frame interval is 0 second. The number of octets that the mobile can transmit in 0.730 ms is 192 octets. Since the wireless adaptor transmits frames at least 60 octets in length, the new owner will bu_er at most 3 frames on average during _Ta, in addition to the frame that triggers the hando_ request. 112

0.00 2.00 4.00 6.00 8.00 10.00 12.00 14.00 16.00 18.00 20.00 5 10 15 20 25 30 35 40 45 50 Time (millisecond) Handoff Latency (Approximation) N = 500

N = 400 N = 300 N = 200 N = 100 N = 50 N = 10 Figure 9.3 Results of Experiment 1: the Happrox values for N ranging from 10 to 500. 0.00 2.00 4.00 6.00 8.00 10.00 12.00

14.00 16.00 18.00 20.00 5 10 15 20 25 30 35 40 45 50 Time ( millisecond) Handoff Latency (Upper Bound) N = 400 N = 300 N = 200 N = 100 N = 50 N = 10 N = 500 Figure 9.4 Results of Experiment 1: the Hmax values for N ranging from 10 to 500.

113 N Mean (Happrox) Std. Dev. (Happrox) Mean (Hmax) Std. Dev. (Hmax) 10 1.497 0.033 1.857 0.042 50 2.911 0.046 3.277 0.056 100 4.721 0.095 5.088 0.125 200 8.078 0.117 8.432 0.120 300 11.552 0.125 11.915 0.134 400 14.957 0.186 15.320 0.193 500 18.357 0.172 18.734 0.211 Table 9.1 The mean values and standard deviations of Happrox and Hmax, shown is milliseconds. 0.00 2.00 4.00

6.00 8.00 10.00 12.00 14.00 16.00 18.00 20.00 0 50 100 150 200 250 300 350 400 450 500 Time (millisecond) Number of Processors (N) Experiment 1 Upper Bound Approximation Delta Tb

Delta Ta Figure 9.5 Plot of the mean values of Hmax, Happrox, _Ta, and _Tb. 114 9.3 Experiment 2: the Impact of Hando_ on Throughput This experiment investigates the impact of hando_ on TCP throughput. Figure 9.6 illustrates the setup for the experiment. As the _gure shows, the experiment uses only two base stations, B1 and B2. The two base stations and the mobile host, M, are in the same room, within line of sight of each other. Mobile M can use either base station to communicate with host H. The mean signal strength between M and B1 is 94% of the highest signal strength observed; the mean signal strength between M and B1 is 81%.

M Crosspoint router B2 B1 R ATM Switch mobile host base station base station H H M: TCP data host H M: TCP ACKs Figure 9.6 Illustration of the setup for Experiment 2. This experiment consists of 5 tests. Each test was repeated 20 times. In each iteration, mobile M uses FTP [PR85] to retrieve a 10 megabyte _le from host H. H reads the _le from a local disk and uses TCP to transport the _le to M, which stores 115

the received data into a _le on its local disk. The ftp application program that runs on M is part of the Windows95 software distribution; the program uses a 8760 octet TCP receive bu_er. The ftp program on H uses a TCP send bu_er of 4096 octets. The TCP maximum segment size used in the transfer is 1460 octets. In Test 1, base station B1 is programmed to be the owner of M and to deny the hando_ requests from B2. Thus, M does not switch base stations while data transfer is in progress. In Test 2, base station B2 is programmed to be the owner of M and to deny the hando_ requests from B1. In Tests 3 to 5, both base stations are programmed to periodically alternate serving as the owner of M; the time between hando_s is set to 2 seconds, 5 seconds, and 10 seconds, respectively. During each test,

mobile M is stationary. In a sense, Tests 3 to 5 simulate the mobile moving from the area of one base station to the area of another using software. The experiment uses two timestamps recorded at the base stations to calculate the throughput, one taken at the instant when the _rst data segment of the transfer from H is received, and the other taken when the ACK segment for the last data segment of the transfer from M is received. The throughput, T , is calculated as follows. T=S _T (9.4) S is the size of the _le, and _T is the interval between the two timestamps. 9.3.1 Results and Analysis Figure 9.7 plots the measured throughput of each test.

By analyzing the data sequence numbers and ACK sequence numbers captured at the base stations, we found three iterations that show packet loss on the wireless link. No packet loss occurred during hando_s. To study the impact of hando_ on throughput, the throughput numbers for the three measurements are not included in calculating the mean throughput and standard deviation for each test. Figure 9.8 shows the mean throughput and standard deviation for each of the 5 tests. 116 101 102 103 104 105

106 2 4 6 8 10 12 14 16 18 20 Throughput (Kbytes/second) Measurement Number Test 1 Test 2 Test 3 Test 4 Test 5 Figure 9.7 The results of Experiment 2. The results show that data transfer using base station B1 alone achieves better throughput than using B2 alone. The results also show that the mean throughput decreases slightly as the hando_ frequency increases. Because each ownership change results in a broadcast of a route update message, the load on each base station

increases as the hando_ frequency increases. The calculated standard deviations show that the overhead of hando_ is not signi_cant; other factors such as queuing delay, the load on the Ethernet, and disk access latency can outweigh the overhead of hando_. For example, the mean throughput di_erence between Test 3 and Test 5 is 0.40 Kbytes/sec, which is less than the standard deviations of both tests. The sharp throughput decrease in the 10th iteration of Test 2 (see Figure 9.7) prompted us to investigate the cause. Analyzing the sequence numbers of both data segments and ACK segments that are captured at base station B2 reveals the cause: during the transfer, mobileM misses two consecutive data segments transmitted from B2. Figure 9.9 plots the data sequence numbers received at B2. 117

105 102 103 104 Mean Throughput (Kbytes/sec) Test 103.59 103.76 104.26 (0.55) (0.50) (0.50) 103.75 (0.30) (0.45)

103.99 12345 Figure 9.8 The mean throughput for each test. The numbers in parenthesis are standard deviations. As Figure 9.9 shows, around 86 seconds into the transfer, the sending TCP pauses for 830 ms before resuming data transmission. The pause and subsequent TCP slowstart [Jac88] is the cause of the decreased throughput. For comparison, Figure 9.10 plots the data sequence numbers of a transfer that does not experience loss of data. Besides Test 2, Tests 4 and 5 also show packet loss on the wireless link, as shown in Table 9.2. In the 14th iteration of Test 4, mobile M misses one data segment. However, the throughput of the transfer only decreases slightly, compared to the mean throughput

for the test. Analyzing the captured data sequences numbers and ACK sequence numbers show that duplicate ACKs from the receiving TCP trigger the fast-retransmit mechanism on the sending TCP. The fast-retransmit mechanism reduces the retransmission latency by retransmitting the lost data segment immediately upon receiving three ACKs for the same data segment, without waiting for a retransmission timeout. Figure 9.11 illustrates how the fast-retransmit mechanism is triggered. In the _gure, the data segments are originated from host H; the ACK segments are originated from mobile M. At time t1, M acknowledges receiving data segment 118 0 2e+06

4e+06 6e+06 8e+06 1e+07 1.2e+07 20 40 60 80 100 Data Sequence Number Time (second) The 10th Iteration of Test 2 Figure 9.9 Plot of the data sequence numbers for the 10th iteration of Test 2. The gap in the plot indicates data loss. 0 2e+06 4e+06 6e+06

8e+06 1e+07 1.2e+07 0 10 20 30 40 50 60 70 80 90 100 Data Sequence Number Time (second) The First Iteration of Test 3 Figure 9.10 Plot of the data sequence numbers for a transfer that does not experience data loss. 119 Test Iteration Retransmission Throughput Mean Throughput Count (Kbytes/s) (Kbytes/s) #1 (none) N/A N/A 104.26 #2 #10 2 data segments 100.96 103.75

#3 (none) N/A N/A 103.59 #4 #14 1 data segment 103.19 103.76 #5 #18 1 data segment 101.88 103.99 Table 9.2 Packet loss vs. TCP throughput. D0 by sending ACK segment A1. Host H receives A1 and transmits 4 more data segments, D1 to D4. The owning base station of M forwards the 4 data segments to M, which receives only D2 to D4. Mobile M transmits two duplicate ACKs at t3 and t4. When the two duplicate ACKs arrive at H, the TCP on H invokes the fast-retransmit to deliver D1 immediately. When D1 arrives, mobileM responds with ACK segment A5 at t5, indicating successful reception of data segments D1 to D4. By using fast-retransmit, the sending TCP reduces the retransmission latency of data segment D1 to 280 ms. If retransmission timer were used, the retransmission latency is at least 500 ms, because the sending TCP (i.e., SunOS 4.1.3 TCP) uses a

500-millisecond resolution retransmission timer [LMKQ90]. The reduced retransmission latency improves the TCP throughput. 9.3.2 Other Observations While analyzing the captured data for each measurement, we found two instances of TCP data segments arriving at the base stations out-of-order. After comparing the captured data at the Crosspoint router with the captured data at the base stations, we conclude that the out-of-order deliveries occur during hando_. Figure 9.12 helps explain why out-of-order delivery can occur during hando_. 120 fast retransmit A1

D0 t1 t2 t3 t4 t5 Time 280 ms D1 D2 D3 D4 A1 A1 A1 A5 D1 D5 lost segment Data segment to mobile ACK segment from mobile Figure 9.11 Illustration of how the receiving TCP uses duplicate ACKs to trigger the fast-retransmit mechanism on the sending TCP. Data segment D1 forwarded by the base station fails to arrive at the mobile. The sending TCP invokes fast-retransmit when 3 ACKs for the same data segment arrive. In the _gure, two successive datagrams, D1 and D2, destined for mobile M arrive

at Crosspoint router R. Base station B1 is the owner of M when R forwards D1. Before forwarding D2, R receives a route update from B2, indicating B2 is the new owner of M. R makes the routing change and forwards D2 to base station B2. Meanwhile, base station B1 forwards datagram D1 to base station B2. Thus, datagrams D1 and D2 are racing towards B2 from di_erent paths at the same time. An out-oforder delivery occurs if D2 arrives at B2 earlier than D1. Because TCP is designed to handle out-of-order datagrams, and the out-of-order datagrams arrive at the base station one after another within 10 ms, the impact on TCP performance is negligible. 9.4 Experiment 3: Motion and TCP Performance Unlike the previous experiment, which uses software to simulatemotion and hand-

o_, in this experiment, the mobile actually moves in a realistic o_ce building environment. Base stations compare signal strengths to determine the ownership of the 121 B1 R B2 D1 D2 D1 previous owner of M Crosspoint router D2 D1 new owner of M Figure 9.12 Illustration of a possible out-of-order delivery during hando_.

mobile. We conducted 20 independent measurements of _le transfer throughput using the same mobile host, the same nonmobile host, and the same _le as the previous experiment. The experimental setup is also similar to the previous experiment, except that base station B2 is replaced with another base station, B3. Base stations B1 and B3 are situated on separate oors of the Computer Science building. Building walls are the primary physical obstructions among mobile M and the two base stations. As Figure 9.13 illustrates, mobile M travels back and forth in the overlapping area of base stations B1 and B3 while retrieving the 10 megabyte _le from host H. During the _le transfer, M travels at walking speed continuously. Base stations B1 and B3 use the hando_ algorithm to determine the ownership of M. Two hando_s occur each time when M completes a round-trip in the overlapping area. 9.4.1 Results and Analysis

Figure 9.14 plots the results of the experiment. The mean throughput is 90.06 Kbytes/sec, and the standard deviation is 3.37 Kbytes/sec. The mean throughput is 13% lower than the lowest mean throughput obtained in the previous experiment. By analyzing the data sequence numbers captured in the two base stations, we conclude 122 M H R Crosspoint router B3 B1 ATM Switch base station base station host

Figure 9.13 Illustration of the setup for Experiment 3. that the primary cause for the decreased throughput is packet loss on the wireless link. As described in the previous section, the sending TCP pauses for a short interval before resuming data transfer when the mobile misses a data segment. Each pause indicates that a retransmission timeout has occurred at the sending TCP. As packet loss rate increases, the number of the retransmission timeout increases, which in turn degrades TCP throughput. Figures 9.14 and 9.15 show the correlation between throughput and the number of retransmission timeouts that occurs at the sending TCP. An invalid assumption in TCP also contributes to the decreased throughput. TCP assumes that network congestion causes packet loss [Jac88]. Thus, TCP reduces data

transmission rate substantially when a retransmission timeout occurs. Analyzing the 123 80 85 90 95 100 2 4 6 8 10 12 14 16 18 20 Throughput (Kbytes/second) Measurement Number 90.06 standard deviation: 3.37 Figure 9.14 The results of Experiment 3. The horizontal line indicates the mean throughput.

5 10 15 20 25 2 4 6 8 10 12 14 16 18 20 Count of Retransmission Timeout Measurement Number Figure 9.15 The number of retransmission timeouts that occurs at the sending TCP. 124 captured data shows that interference and weak radio signal cause packet loss, not network congestion. 9.4.2 Signal Strength and Hando_ The experiment also allows us to study how the base stations compare signal

strengths to determine the ownership of mobile M. The WaveLAN wireless hardware o_ers 3 measures of the wireless link quality: signal level, silence level, and signal quality [Cor93]. Both the signal level and the silence level are 6-bit integers; the signal quality is a 4-bit integer. We compute signal strength as the signal level minus the silence level. The signal quality measure is not used because the signal level measure o_ers higher resolution. The base stations compute the signal strength to mobile M each time a frame emitted from M arrives. Because M is in-range of both base stations, each base station can measure the signal strengths to M independently. Figures 9.16 and 9.17 show a sample of the signal strengths measured at base stations B1 and B3, respectively. The _gures show variations of signal strengths as M completes a round trip in the overlapping area. Two hando_s occur during the

trip, indicated by the two vertical lines. The measured signal strengths, however, are not used in the hando_ decisions. As mentioned in the previous chapter, each base station computes a mean signal strength (MSS) for M using the measured signal strengths. In this experiment, the MSS is the only parameter used in the hando_ decisions. Figures 9.18 and 9.19 plot the values of MSS that correspond to the measured signal strengths shown in Figures 9.16 and 9.17, respectively. 9.5 Summary We built a prototype Crosspoint network consisting of three base stations and one Crosspoint router. The system provides wireless coverage for the entire Computer Science building at Purdue University, West Lafayette, Indiana. We conducted three experiments using the prototype Crosspoint network. The results of the _rst experiment show that the hando_ latency is linearly proportional

125 0 2 4 6 8 10 12 14 16 18 10 15 20 25 30 Signal Strength Time (second) Base Station B1

12.59 26.85 captures mobile M hand off M to B3 Figure 9.16 A sample of the signal strengths measured at base station B1. The vertical lines represent ownership change. 0 2 4 6 8 10 12 14 16 18

10 15 20 25 30 Signal Strength Time (second) Base Station B3 26.85 hand off M to B1 12.59 capture M Figure 9.17 A sample of the signal strengths measured at base station B3. The vertical lines represent ownership change. 126 0 2 4 6

8 10 12 14 16 18 10 15 20 25 30 Mean Signal Strength Time (second) Base Station B1 12.59 26.85 Figure 9.18 Plot of the mean signal strengths. The vertical lines represent ownership change. 0

2 4 6 8 10 12 14 16 18 10 15 20 25 30 Mean Signal Strength Time ( second) Base Station B3 12.59 26.85

Figure 9.19 Plot of the mean signal strengths. The vertical lines represent ownership change. 127 to the number of processors attached to the Crosspoint interconnect. The results of the second experiment show that packet loss has greater impact on TCP throughput than hando_ frequency. The results of the third experiment show that TCP does not perform well in a wireless environment where packet loss rate is higher than in a wired environment. 128 10. CONCLUSIONS AND FUTURE WORK This dissertation describes the design and implementation of a campus-sized wire-

less mobile network. The architectural design uses a scalable switching fabric that provides high-speed interconnections among base stations and Crosspoint routers. The protocol design focuses on supporting seamless wireless mobile communication without modifying the networking software and hardware of each mobile. Through a prototype implementation of Crosspoint, we have shown that the approach is feasible. The following sections outline the major contributions of the research and discuss the directions for future research. 10.1 Major Contributions This dissertation makes several contributions to the area of mobile computing. _ The dissertation describes an architectural design of a wireless data communication system that is capable of handling a large volume of routing update

tra_c, supporting optimal routing to each mobile host, and shielding the campus internet from mobility management tra_c. _ The prototype implementation of Crosspoint has demonstrated that it is feasible to support wireless mobile computing without requiring modi_cation of conventional network software on mobile hosts, nonmobile hosts, or IP routers in the existing Internet. _ The research of Crosspoint focuses on providing seamless network connectivities for mobile hosts that roam within a wireless subnet consisting of multiple radio transceivers; each of the radio transceivers provides wireless coverage for 129 a small geographical area approximately 50 meters in diameter. The research contributes to the mobile IP research in the area of solving micro mobility management problem. 10.2 Future Work The future research directions of Crosspoint focus on:

_ Investigating the feasibility of using a hierarchical architecture. _ Supporting inter-campus wireless mobile computing. _ Improving TCP performance. _ Supporting IP multicasting. _ Supporting the IETF Mobile IP design. 10.2.1 Hierarchical Architecture and Inter-Campus Mobility Support The current Crosspoint architectural design supports a campus-sized wireless mobile network. An extension to the architectural design is needed to support intercampus wireless mobile computing. Figure 10.1 illustrates an example hierarchical architectural design. In the _gure, each campus supports a local Crosspoint network. Each of the campus-sized Crosspoint networks connects to a central high-speed interconnect using a core Crosspoint router. To achieve optimal routing, the core routers maintain a host

speci_c routing entry for each of the mobile hosts on all three campuses. Base stations and Crosspoint routers that reside in a campus only maintain host speci_c routes for mobiles that are present in the campus. The campuses need not use the same IP network pre_x1. A mobile host uses the same IP address when visiting a foreign campus. 1If each campus uses a unique network ID, the IETF Mobile IP scheme can also be used to support inter-campus host migration (see section 10.2.4). 130 M M R4 R5 high-speed interconnect

To other networks R1 interconnect high-speed B1 R2 interconnect high-speed B2 Campus C1 Campus C2 R3 high-speed interconnect Campus C3

Figure 10.1 Illustration of a hierarchical design that supports inter-campus wireless mobile computing. Delivering a datagram to a mobile host in a foreign campus takes multiple steps. First, the datagram is forwarded to one of the core routers. The core router consults its routing table and forwards the datagram to the core router of the campus in which the mobile currently resides. The second core router forwards the datagram across the local Crosspoint network to the mobile. To support inter-campus mobile computing, base stations use an inter-campus hando_ protocol. To explain how the protocol works, consider the following example and the illustration in Figure 10.1. Suppose mobileM migrates from its home campus,

C1, to campus C2. Base station B2 in campus C2 detects M. Because it does not have a routing entry for M, B2 cannot send a hando_ request to the owner of M. Instead, B2 forwards the hando_ request to R2, the core router of campus C2. Because it 131 has a routing entry for M, R2 forwards the hando_ request to R1, the core router of campus C1. On receipt of the hando_ request, R1 forwards it to the owner of M, base station B1. Similarly, the hando_ reply from B1 travels the reverse path to arrive at B2. Base station B2 captures M and propagates a route update to the other Crosspoint processors in campus C2, including router R2. R2 determines that M has migrated to a foreign campus and the information to the other core routers. In this

way, router R1 learns that mobile M has migrated to campus C2 and propagates the information to the other Crosspoint processors in campus C1. The hierarchical architecture and the inter-campus hando_ protocol sketched above requires further study to understand the design trade-o_s and implementation details. 10.2.2 Improving TCP Performance The experimental results of Chapter 9 show that TCP does not perform well in a wireless environment, where packet loss rate is higher than a wired environment. Researchers have proposed various schemes to improve TCP performance in a wireless environment. For example, one scheme [CI94] exploits the fast-retransmit mechanism. However, the scheme requires a mobile host to use a modi_ed version of TCP/IP. Another scheme installs a snoop module [BSK95] at each base station. The snoop

module caches unacknowledged data for mobiles and perform local retransmissions across the wireless link to mobiles. The snoop approach is more suitable for Crosspoint because it allows base stations to handle the details of improving TCP throughput, without requiring modi_cations to the TCP/IP software on mobiles. Further research is needed to determine whether the snoop approach works well in Crosspoint. In particular, the hando_ protocol may require modi_cation, in order to transfer the state information maintained by the snoop module to the new owner. 132 10.2.3 Supporting IP Multicasting The Crosspoint protocol design focuses on supporting unicast data streams. An extension to the current design will be needed to support IP multicasting. Initial investigation indicates that in addition to using the Internet Group Management

Protocol (IGMP) [Dee89] to track active groups, base stations need a protocol to determine the multicast groups of which a mobile is a member. For example, during the ownership transfer for a mobile, the previous owner can inform the new owner about the multicast groups that the mobile is participating. Thus, the new owner can determine whether to join the groups on behalf of the mobile. Alternatively, the new owner can send an IGMP membership query message to the mobile immediately after capturing the mobile. Besides determining the active groups in its wireless LAN, a base station needs an e_cientmechanism to disseminate the information to the other Crosspoint processors. The route update message can carry the information of new groups. For example,

when a base station captures a mobile, the base station determines whether it needs to join new groups to support the mobile, as described earlier. If so, the base station inserts the IP addresses of the new groups in the route update message and broadcasts the route update message. That is, the route update message serves as both a unicast routing update and a multicast routing update. 10.2.4 Supporting the IETF Mobile IP Protocols With the e_orts of the IETF Mobile IP Working Group, standard protocols are emerging that support host mobility in the global Internet. The Crosspoint design can be extended to use the IETF Mobile IP design in the following way. From the perspective of Mobile IP, a Crosspoint network is a subnet attached to the Internet using a set of Crosspoint routers. The Crosspoint routers can serve

as the home agents for local mobiles and as the foreign agents for visiting mobiles. When a wireless mobile visits a Crosspoint network, the mobile neither changes its IP address nor obtains a local address. The _rst base station that captures the mobile 133 creates a routing entry for the mobile, informs the other Crosspoint processors, and acquires a Crosspoint router as the foreign agent for the mobile. The Crosspoint router establishes an IP tunnel between the home network of the mobile and the Crosspoint network. Conceptually, a datagram destined for the mobile _rst reaches the mobile's home network, travels across the IP tunnel to the Crosspoint network, and then reaches the mobile using Crosspoint routing.

When a local mobile visits a foreign network, one of the Crosspoint routers serves as the home agent for the local mobile. Once it has established an IP tunnel to the foreign network, the Crosspoint router captures the mobile by propagating a route update to the other Crosspoint processors. That is, the Crosspoint router serves as the home agent for the mobile and the owner of the mobile as well while the mobile is away. Further research is needed to investigate the impact of supporting Mobile IP on the design and implementation of Crosspoint. For example, each of the Crosspoint processors may need to install a separate routing table that supports e_cient insertion and deletion of routing entries for visiting mobiles. BIBLIOGRAPHY

134 BIBLIOGRAPHY [All93] D. Allen. Hidden Terminal Problems in Wireless LAN's. IEEE 802.11 Working Group Paper, 1993. [ASU88] A. V. Aho, R. Sethi, and J. D. Ullman. Compilers: Principles, Techniques, and Tools. Addison-Wesley, Reading, Massachusetts, 1988. [B+94] T. Blackwell et al. Secure Short-Cut Routing for Mobile IP. In Proceedings of USENIX Summer 1994 Conference, pages 305{316, June 1994. [Bak94] Mary Baker. Changing Communication Environments in MosquitoNet. In Proceedings of the IEEE Workshop on Mobile and Computing Systems and Applications, pages 64{68, Dec. 1994. [BCDB95] M. Borden, E. Crawley, B. Davie, and S. Batsell. RFC-1821: Integration of Real-time Services in an IP-ATM Network Architecture. Request For Comments, August 1995. Internet Network Information Center. [BLFN96] T. Berners-Lee, R. Fielding, and H. Nielsen. RFC-1945: Hypertext

Transfer Protocol { HTTP/1.0. Request For Comments, May 1996. Internet Network Information Center. [BP87] R. Braden and J. Postel. RFC-1009: Requirements for Internet Gateways. Request For Comments, June 1987. Internet Network Information Center. [BP93] Pravin Bhagwat and Charles Perkins. A Mobile Networking System based on Internet Protocol (IP). In Proceedings of Mobile and Location Independent Computing, pages 69{82, Aug. 1993. [Bra89] R. Braden. RFC-1122: Requirements for Internet Hosts { Communication Layers. Request For Comments, Oct. 1989. Internet Network Information Center. [BSK95] H. Balakrishnan, S. Seshan, and Randy H. Katz. Improving Reliable Transport and Hando_ Performance in Cellular Wireless Networks. In ACM Wireless Networks, Dec. 1995. 135

[BZCS96] M. G. Baker, X. Zhao, S. Cheshire, and J. Stone. Supporting Mobility in MosquitoNet. In Proceedings of the 1996 USENIX Technical Conference, Jan. 1996. [Cav94] John D. Cavanaugh. Protocol Overhead in IP/ATM Networks. ftp://ftp.magic.net/pub/magic/overhead.ps.Z, August 1994. [CB95] Stuart Cheshire and Mary Baker. Experiences with aWireless Network in MosquitoNet. In Proceedings of the IEEE Hot Interconnects Symposium '95, Aug. 1995. [CD95] AT&T Wireless Communications and Networking Division. Data Manual: WaveLAN Air Interface. Document No.: 407-0024785 (Draft), June 1995. [Cer79] Vint Cerf. IEN-110: Internet Addressing and Naming in a Tactical Environment. Internet Engineering Notes, August 1979. [CI94] R. Caceres and L. Iftode. Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments. IEEE Journal on

Selected Areas in Communications, Oct. 1994. [Com84] Douglas E. Comer. Operating System Design: The Xinu Approach. Prentice-Hall, Englewood Cli_s, New Jersey, 1984. [Com95] Douglas E. Comer. Internetworking with TCP/IP: Principles, Protocols, and Architecture, Vol. I. Prentice-Hall, Englewood Cli_s, New Jersey, third edition, 1995. [Con93] CDPD Consortium. Cellular Digital Packet Data System Speci_cation. July 1993. Release 1.0. [Cor93] NCR Corporation. Interface Speci_cation For WaveLAN Host Adapter: Type IBM AT. Document No.: 407-0024326, Rev. A, 1993. [CS93] D. E. Comer and D. L. Stevens. Internetworking with TCP/IP Vol. III: Client-Server Programming and Applications. Prentice-Hall, Englewood Cli_s, New Jersey, 1993. [Dee89] S. Deering. RFC-1112: Host Extension for IP Multicasting. Request For Comments, Aug. 1989. Internet Network Information Center.

[Dro93] R. Droms. RFC-1541: Dynamic Host Con_guration Protocol. Request For Comments, Oct. 1993. Internet Network Information Center. [For93] The ATM Forum. ATM User-Network Interface Speci_cation Version 3.0. Prentice-Hall, Englewood Cli_s, New Jersey, 1993. 136 [G+91] K. S. Gilhousen et al. On the Capacity of a Cellular CDMA System. IEEE Transactions on Vehicular Technology, 40(2):303{312, May 1991. [Hed88] C. Hedrick. RFC-1058: Routing Information Protocol. Request For Comments, Aug. 1988. Internet Network Information Center. [HJ96] Alex Hills and David B. Johnson. A Wireless Data Network Infrastructure at Carnegie Mellon University. IEEE Personal Communications, 3(1):56{63, Feb. 1996. [IDJ91] J. Ioannidis, D. Duchamp, and G. Q. Maguire Jr. IP-based Protocols for Mobile Internetworking. In Proceedings of ACM SIGCOMM '91, pages 235{245, Sept. 1991.

[IJ93] J. Ioannidis and G. Q. Maguire Jr. The Design and Implementation of a Mobile Internetworking Architecture. In Proceedings of USENIX Winter '93 Conference, pages 491{502, Jan. 1993. [IT92a] ITU-T. Draft Recommendation I.150: B-ISDN ATM Functional Characteristics. ITU Study Group XVIII, June 1992. [IT92b] ITU-T. Draft Recommendation I.361: B-ISDN ATM Layer Speci_cation. ITU Study Group XVIII, June 1992. [IT93] ITU-T. Draft Recommendation I.363: B-ISDN AAL Speci_cation. ITU Study Group XVIII, Jan. 1993. [Jac88] Van Jacobson. Congestion Avoidance and Control. In Proceedings of ACM SIGCOMM '88, pages 314{328, Aug. 1988. [Jai86] Raj Jain. Packet Trains - Measurements and a New Model for Computer Network Tra_c". IEEE Journal on Selected Areas in Communications, SAC-4(6):986{995, Sept. 1986. [JM96] David B. Johnson and David A. Maltz. Protocols for Adaptive Wireless

and Mobile Networking. IEEE Personal Communications, 3(1):34{42, Feb. 1996. [Kar90] Phil Karn. MACA - A New Channel Access Method for Packet Radio. In Proceedings of the ARRL 9th Computer Networking Conference, Sept. 1990. [KMM95] R. Kohno, R. Meidan, and B.Milstein. Spread Spectrum Access Methods for Wireless Communications. IEEE Communications Magazine, pages 58{67, Jan. 1995. 137 [LBSR95] M. T. Le, F. Burghardt, S. Seshan, and J. Rabaey. InfoNet: the Networking Infrastructure of InfoPad. In Proceedings of Compcon 1995, March 1995. [LMKQ90] S. J. Le_er, M. K. McKusick, M. J. Karels, and J. S. Quarterman. The Design and Implementation of the 4.3BSD UNIX Operating System. Addison-Wesley, Reading, Massachusetts, 1990.

[MB76] R. M. Metcalfe and D. R. Boggs. Ethernet: Distributed Packet Switching for Local Computer Networks. Communications of the ACM, 19(7):395{ 404, July 1976. [Moy94] J. Moy. RFC-1583: OSPF Version 2. Request For Comments, March 1994. Internet Network Information Center. [MS93] A. Myles and D. Skellern. Comparison of Mobile Host Protocols for IP. Journal of Internetworking: Research and Experience, 4(4):175{194, Dec. 1993. [N+96] Shankar Narayanaswamy et al. Application and Network Support for InfoPad. IEEE Personal Communications, March 1996. [Par94] Craig Partridge. Gigabit Networking. Addison-Wesley, Reading, Massachusetts, 1994. [PB94] C. Perkins and P. Bhagwat. A Mobile Networking System Based on Internet Protocol. IEEE Personnal Communications, First Quarter 1994. [Per96] Charles Perkins. IP Mobility Support. Internet Engineering Task Force

(IETF) INTERNET DRAFT (work in progress), May 1996. Internet Network Information Center. [PJ96] Charles Perkins and David B. Johnson. Mobility Support in IPv6. Internet Engineering Task Force (IETF) INTERNET DRAFT (work in progress), Jan. 1996. Internet Network Information Center. [Plu82] D. Plummer. RFC-826: Ethernet Address Resolution Protocol. Request For Comments, Nov. 1982. Internet Network Information Center. [PMS91] R. L. Pickholtz, L. B. Milstein, and D. L. Schilling. Spread Spectrum for Mobile Communications. IEEE Transactions on Vehicular Technology, 40(2):313{321, May 1991. [Pos80] J. Postel. RFC-768: User Datagram Protocol. Request For Comments, Aug. 1980. Internet Network Information Center. [Pos81a] J. Postel. RFC-791: Internet Protocol. Request For Comments, Sept. 1981. Internet Network Information Center. 138

[Pos81b] J. Postel. RFC-792: Internet Control Message Protocol. Request For Comments, Sept. 1981. Internet Network Information Center. [Pos81c] J. Postel. RFC-793: Transmission Control Protocol. Request For Comments, September 1981. Internet Network Information Center. [Pos84] Jon Postel. RFC-925: Multi-LAN Address Resolution. Request For Comments, Oct. 1984. Internet Network Information Center. [PR83] J. Postel and J. Reynolds. RFC-854: Telnet Protocol speci_cation. Request For Comments, May 1983. Internet Network Information Center. [PR85] J. Postel and J. Reynolds. RFC-959: File Transfer Protocol. Request For Comments, Oct. 1985. Internet Network Information Center. [Pry95] Martin De Prycker. Asynchronous Transfer Mode: Solution for Broadband ISDN. Prentice-Hall, Englewood Cli_s, New Jersey, third edition, 1995. [Rap96] Theodore S. Rappaport. Wireless Communications: Principle and Practice. Prentice-Hall, Englewood Cli_s, New Jersey, 1996.

[SP80] C. Sunshine and J. Postel. IEN-135: Addressing Mobile Hosts in the ARPA Internet Environment. Internet Engineering Notes, March 1980. [Ste94] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, Reading, Massachusetts, 1994. [TCT92] F. Teraoka, K. Cla_y, andM. Tokoro. Design, Implementation and Evaluation of Virtual Internet Proptocol. In Proc. 12th International Conference on Distributed Computing Systems, pages 170{177, June 1992. [Ter93] Fumio Teraoka. VIP: a Protocol Providing Host Migration Transparency. Journal of Internetworking: Research and Experience, 4(4):195{221, Dec. 1993. [Ter96] Fumio Teraoka. Mobility Support in IPv6. Internet Engineering Task Force (IETF) INTERNET DRAFT (work in progress), April 1996. Internet Network Information Center. [Tuc93] Bruce Tuch. Development of WaveLAN, and ISM Band Wireless LAN. AT&T Technical Journal, 72(4):27{37, July/August 1993.

[TUSM94] F. Teraoka, K. Uehara, H. Sunahara, and J. Murai. VIP: A Protocol Providing Host Mobility. Communications of the ACM, (8):67{75, Aug. 1994. 139 [TYT91] F. Teraoka, Y. Yokote, and M. Tokoro. A Network Architecture Providing Host Migration Transparency. In Proceedings of ACM SIGCOMM '91, pages 209{220, Sept. 1991. [WYOT93] H. Wada, T. Yozawa, T. Ohnishi, and Y. Tanaka. Mobile Computing Environment Based on Internet Packet Forwarding. In Proceedings of USENIX Winter '93 Conference, pages 503{517, Jan. 1993. VITA 140 VITA John Chueng-Hsien Lin was born in Hsin-Chu, Taiwan, on March 16, 1962. In 1984, he graduated from National Taiwan University, Taipei, Taiwan, with a bach-

elor's degree in mechanical engineering. After serving two years in the Taiwanese Marine Corps as a communication o_cer, he enrolled in the Department of Information and Computer Science at The Georgia Institute of Technology, and received his master's degree in the Spring of 1988. After graduation, he worked for HenzeMovates, Incorporated for two years as a software engineer and later for Bell-Northern Research (BNR) as a member of the scienti_c sta_. In 1991, he left BNR and joined the internetworking and systems research group at Purdue University under the direction of Professor Douglas Comer. While attending Purdue, he received the Outstanding Teaching Assistant award from the Purdue ACM in 1992 and a two-year fellowship from the UniForum Associ-

ation in 1993. His research interests include computer operating systems, distributed systems, internetworking, and mobile computing.