Medium access control and air interface subsystem for an indoor wireless ATM network

This invention relates to systems and methods for delivering digital packets.

Continual progress with wireless technology and high-speed integrated service wired networking promises to provide mobile users with omnipresent multimedia information access in the near future. Although wireless access has previously been used to provide tetherless access to mobile users, this has been done principally to address the requirements of two specific and disjoint domains: voice telephony and indoor data LANs. Cellular telephone networks have extended the domain of telephone service over a wireless last hop, while mobile-IP LANs such as WaveLAN (Registered Trademark) from AT&T, and RangeLAN (Registered Tradermark) from Proxim, do the same for indoor users of TCP/IP data networks.

In networks capable of providing tetherless multimedia computing and information access it appears increasingly likely that the core of such networks will be based on the emerging Asynchronous Transfer Mode (ATM) cell switching networks that provide integrated support for voice, video, data, and other multimedia traffic. The use of the Virtual Channel Connection model in ATM makes it possible to provide quality of service guarantees to a specific connection. This suggests that there is a need to rethink the architecture of the wireless last hop as well. In particular, it appears to make sense to follow the ATM Virtual Channel Connection model over the wireless hop as well, thereby allowing the service quality guarantees made in the wired network to be extended end-to-end, spanning the wireless hop. It is an open question, which is presently the subject of research, as to whether the wireless last hop should use the ATM Virtual Channel Connection model, or use the connectionless delivery model as is done by present-day wireless IP LANs.

Assuming that it is logical to extend the ATM Virtual Channel Connection model over the wireless hop, an indoor wireless multimedia network has been developed at AT&T Bell Laboratories. The network, named Seamless Wireless ATM Networking (SWAN), seeks to provide continual network connection to mobile heterogeneous ATM end-points in an indoor office setting. Such end-to-end ATM connectivity requires the ability to establish, reroute, and tear-down Virtual Channel Connections to and from mobile hosts and the ability to provide service quality guarantees for these Virtual Channel Connections in the presence of mobility.

While wireless networks with end-to-end ATM are still in the development stage, cellular telephone networks, indoor wireless data LANs, and outdoor cellular metropolitan-area data networks such as Metrocom's Ricochet (Registered Trademark) are three broad I categories of wireless networks that commercially exist. Cellular telephone networks are connection oriented, and use either the older analog frequency division multiple access, or use the newer digital time or code division multiplexing. Perhaps more relevant to SWAN are the techniques used to reroute connections when mobile users roam from cell to cell, particularly in the case of the newer microcellular networks.

Closer to SWAN's domain are the indoor wireless data LANs such as WaveLAN from AT&T and RangeLAN from Proxim. The radios used in these networks are typically ISM band radios, like SWAN's radios, and may be either frequency hopping spread spectrum based, or direct sequence spread spectrum based. Frequency hopping based radios are a relatively recent development, and smart algorithms for the control of frequency hopping are still proprietary. In any event, these wireless LANs are optimized for mobile IP or mobile IPX traffic, as opposed to mobile ATM traffic. The Medium Access Control (MAC) and physical control layers in these wireless LANs are the subjects of the proposed IEEE 802.11 standard. In a broad sense, all of these networks operate in a peer-to-peer fashion with the mobile access points and the wired network access points operating as peers in a shared broadcast channel. This concept is somewhat similar to what occurs in an ethernet, and in fact the Medium Access Control layers in these wireless LANs are also ethernet variants in that the multiple access is based on Carrier Sense Multiple Access (CSMA) enhanced with collision avoidance and handshaking. Polling based Medium Access Controls have also been proposed for use in wireless data LANs.

Although considerable progress has been made with the use of wireless technology and broadband networks, many technical problems remained to be solved before a vision of omnipresent tetherless access to multimedia information can be realized. Accordingly, there is a need to provide a reliable system of controlling the linking of the base station and mobile unit for transporting data packets.

SERVING HUMANITY THROUGH COMMUNICATIONS.

SUPERCOMM/ICC, NEW ORLEANS, MAY 1-5, 1994, vol. VOL. 1, no. -, 1 May 1994, INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 559-565, XP000438976 RAYCHAUDHURI D: 'ATM BASED TRANSPORT ARCHITECTURE FOR MULTISERVICES WIRELESS PRSONAL COMMUNICATION NETWORKS' discloses an ATM based transport architecture for next-generation multiservices personal communications networks (PCN) capable of supporting a mix of broadband ISDN services including constant bit-rate (CBR), variable bit-rate (VBR) and packet data transport. It also teaches the use of a hierarchical ATM switching network for interconnection of PCN microcells, each of which is serviced by high-speed, shared-access radio links based on ATM-compatible cell relay principles. The wireless medium requires a custom data link layer protocol that interfaces with an ATM transport layer. A baseline approach is to define a PCS data link packet as a 53 byte ATM cell encapsulated by an additional PCS header. Additionally, the custom PCS data link layer should provide an error control mechanism using a PCS packet sequence number field in the header along with a standard CRC frame check sequence trailer. For connectionless data classes, a conventional HDLC-type error recovery protocol should be executed per VC, preferably on a selective reject basis. For connection-oriented CBR and VBR, the nominal error control mode is to detect and filter out erroneously received ATM cells before they can enter the network.

EP-A-0587980 discloses a cellular mobile radio system arranged to operate in accordance with a packet reservation multiple access protocol, wherein at least one time slot in each frame is designated for the transmission of access contention data. The system includes a base station that, consequent upon receipt of data in the said reserved field, the base station is arranged to respond by allocating available slots to satisfy the requirements of the mobile unit. The system further includes an automatic repeat request facility wherein transmission repeat requests are made in respect of those cells of a batch which are errored, as indicated by an error detector.

According to a first aspect of this invention there is provided a system as claimed in claim 1.

According to a second aspect of this invention there is provided a method as claimed in claim 6.

There is provided a system for delivering packetized data in a network, wherein the system dynamically assigns a unique address to the mobile unit, allocates bandwidth within the wireless link by a token scheme and provides forward error correction for the packet.

The system has a means for wirelessly transporting the packets between a base station and an end point which is responsive to a link cell for linking the base station and the end point. The link cell contains a header and a body. The header in turn contains a forward error correction code, a radioport id and a token. The forward error correction code provides error detection and error correction that relies solely on a one-way communication of data bits from a sender to a receiver. The radioport id is a logical id assigned such that each radio-port in a vicinity has a unique id. The token enables the wireless transportation over a selected channel of the packets between the base station and the end point. The token is utilized to allocate the selected channel from a plurality of channels.

A method is described for delivering packetized data between an endpoint and a base station. The method involves the step of providing a means for linking a base station and an end point. Then linking the base station and the end point. Then transporting wirelessly the packets between the base station and the end point.

<u style="single">DESCRIPTION OF THE DRAWINGS</u>

A more complete understanding of the present invention may be obtained from consideration of the following description in conjunction with the drawings in which: <ul id="ul0001" list-style="none" compact="compact"><li>FIG. 1 is a block diagram of a network communication model of a SWAN wireless ATM network;</li><li>FIG. 2 is a block diagram of a last hop in a wireless ATM network;</li><li>FIG. 3 is a block diagram of a reusable ATM wireless adapter architecture template;</li><li>FIG. 4 is a block diagram of a FAWN adapter architecture;</li><li>FIG. 5 is a block diagram of a base station and mobile units in SWAN;</li><li>FIG. 6 is an illustration of a format of link cells for air interface packets; and</li><li>FIG. 7 is a block diagram of embedded software on a wireless adapter.</li></ul>

<u style="single">DETAILED DESCRIPTION OF VARIOUS ILLUSTRATIVE EMBODIMENTS</u>

Although the present invention is particularly well suited to a packet communication system having a Virtual Channel Connection ATM extended to a wireless endpoint, and shall be described with respect to this application, the methods and apparatus disclosed here can be applied to other packet communication systems with a wireless endpoint.

Referring now to FIG. 1 there is shown a high level view of the network communication model adopted by the SWAN mobile networked computing environment at AT&amp;T Bell Laboratories. A hierarchy of wide-area 10 and local-area 12 wired ATM networks is used as the back-bone network, while wireless access is used in the last hop to mobile hosts. In addition to connecting conventional wired server hosts 14 and client end-points 16, the wired backbone also connects to special switching nodes called base stations 18. The base stations 18 are equipped with wireless adapter cards, and act as a gateway for communication between nearby mobile hosts 20, which are also equipped with wireless adapters, and the wired network. The geographical area for which a base station acts as the gateway is called its cell 22, and given the intended use of SWAN in an office setting, the various base station 18 nodes are distributed in room-sized pico-cells. Network connectivity is continually maintained as users carrying a variety of mobile hosts 20 roam from one cell 22 to another. The mobile hosts 20 themselves range from portable computers equipped with a suitable wireless adapter, to dumb wireless terminals that have no or little local general-purpose computing resources. All mobile hosts 20 in SWAN, however, must have the ability to participate in network signaling and data transfer protocols. Lastly, a mobile unit 20 in SWAN sends and receives all its traffic through the base station 18 in its current cell 22.

A distinguishing feature of the SWAN system is the use of end-to-end ATM over both the wired network and the wireless last hops 24. This is in contrast to the use of connectionless mobile-IP in present day wireless data LANs. This design choice in SWAN was motivated by the realization that advances in compression algorithms together with increased bandwidth, provided by spatial multiplexing due to the use of pico-cells and higher bandwidth RF transceivers that are now available, can allow the transmission of packetized video to a mobile unit 20. Support for multimedia traffic over the wireless segment has therefore become a driving force in SWAN. Adopting the connection-oriented model of an ATM Virtual Channel Connection over the wireless hop as well allows quality of service guarantees associated with virtual channel connections carrying audio or video traffic to be extended end-to-end. In essence, the use of end-to-end ATM allows the wireless resource to be meaningfully allocated among the various connections going over a wireless hop.

Using ATM's Virtual Channel Connection model all the way through to a mobile host 20, however, results in the need to continually reroute ATM Virtual Channel Connections as a mobile host 20 moves. The small cell sizes and the presence of quality of service sensitive multimedia traffic make this problem particularly important in SWAN. Virtual Channel Connections carrying audio or video, as far as possible, need to be immune from disruptions as a mobile host 20 is hands-off from one base station 18 to a neighboring one. Of course, ATM signaling protocol needs to accomplish the task of Virtual Channel Connection rerouting with minimum latency, and SWAN's approach to this problem is based on Virtual Channel Connection extension coupled with loop removal and mobile initiated partial rebuilds. Of more particular interest is the fact that the lower level protocol layers dealing with wireless medium access must also accomplish the task of transferring a mobile unit 20 from one base station 18 to another with minimal latency. Low latency hand-off and allocation of wireless resources among various virtual connections are therefore tasks that need to be done in the wireless hop 24 in SWAN, in addition to the usual functionality of medium access control and air-interface operation.

FIG. 2 shows a block diagram of the wireless last hop 24 of a SWAN-like wireless ATM network. The primary function of the base station 18 is to switch cells among various wired 26 and wireless ATM 28 adapters attached to the base station 18 - the base station 18 can be viewed as an ATM switch that has RF wireless ATM adapters on some of its ports. In SWAN, however, generic PCs and Sun workstations are used as base stations 18 by plugging in a wired ATM adapter card 26 and one or more RF wireless ATM adapter cards 28. The cell switching functionality is realized in software using a kernel-space-resident cell routing and adapter interface module 30, and a user-space-resident connection manager signaling module 32. The use of PCs and workstations for base stations 18 allows them to act as wired hosts as well, running application processes 34. In essence, base stations 18 in SWAN are nothing but computers with banks of radios interfaced.

At the other end of the wireless last hop 24 is the mobile unit 20 that too has a RF wireless adapter 28, a connection signaling manager module 36, and a module 38 that routes cells among various agents within the mobile unit. Although pictorially the mobile unit 20 may look like a base station 18 with no wired adapter and only one wireless adapter 28, this is not the complete truth. The connection manager 36 at the mobile unit 20 is different - for example, it does not have to provide a switch-like functionality. In addition, mobile units 20 such as dumb terminals may have only hardware agents acting as sinks as sources of ATM cells, as opposed to software processes. However, mobile units 20 that are more than a dumb terminal may run applications 40 as well.

Of particular interest is the RF ATM adapter 28 of the base station 18, the RF ATM adapter of the mobile unit 20 and their interconnection by an air interface packet (link cell) over the wireless last hop 24. A stream of ATM cells from the higher level ATM layers needs to be transported across the wireless link 24 between a mobile unit 20 and its base station 18. The issues that need to be addressed to accomplish the transport of ATM cells over the air can be classified into two categories: generic issues and ATM-specific issues.

Following are some of the problems that fall under the generic category: (1) Division of available bandwidth into channels (2) Distribution of channels among base stations (3) Regulation of access to a shared channel (4) Hand-off of mobile units from one base station 18 to another.

On the other hand, the following wireless hop problems are influenced principally by the needs of ATM: (1) Mapping of ATM cells to link cells, or air-interface packets (2) Format of air-interface packets (3) Impact of ATM cell loss due to noise and interference sources unique to wireless, such as inter-symbol interference, adjacent channel interference, frequency collision etc., and (4) Multiplexing and scheduling of different ATM Virtual Channel Connections in the same channel.

The answers to these problems depend partially on the restrictions imposed by the hardware, and in particular on the characteristics of the radio transceiver.

The wireless hop in SWAN is based around the idea of a single reusable ATM wireless adapter architecture, shown in FIG. 3, that interfaces to one or more digital-in digital-out radio transceivers 42 on one side through a radio port interface 44, to a standard bus interface 46 coupled to a standard data bus 48 on the other side, and has a standard core module 50 sandwiched in between providing field-programmable hardware resources 52 and a software-programmable embedded compute engine 54 to realize the necessary data processing. Multiple implementations of this basic architecture could be made with differing form factor, different bus interfaces, and different radios, but all with the same core data processing module. This provides a uniform mechanism for making devices SWAN-ready. Implementations could range from PCMCIA adapter cards that are adjunct to laptop computers, to small-form factor cards for embedding in a wireless terminal, and to higher speed adapters with multiple radios for use in base stations. The adapter could be configured for algorithms by reprogramming the embedded software, and by reconfiguring the field-programmable hardware. System level board synthesis tools with interface synthesis and parameterized library capabilities, such as the SIERA system from Berkeley can be used to easily generate variations of the basic adapter architecture for different busses and radios. At present there exists one implementation of our standard architecture in the form of a card called Flexible Adapter for Wireless Networking (FAWN).

An article entitled "A Testbed For Mobile Network Computing" by P. Agrawal et al., published in Proc. IEEE Intl. Conference on Communications, ICC 1995, provides details of the architecture of SWAN and the FAWN adapter.

Referring to FIG. 4, there is shown a block diagram of a FAWN adapter architecture. The FAWN card 56 uses a PCMCIA bus 58 to interface with the host computer 60. A laptop computer with a PCMCIA slot can become a mobile host by plugging in a FAWN card 56.

The FAWN card 56 has a RISC processor 62, such as ARM 610 CPU, which is responsible for controlling the RF modem 64 and other peripherals through a peripheral interface 66. The FAWN card 56 is configured for use with the 2.4 GHz Industrial Scientific and Medical (ISM) band frequency hopping spread spectrum transceivers, although the transceiver interface can be easily modified by reprogramming some components, which is well known to one ordinarily skilled in the art. The RISC processor 62 operates at 20 MHz and provides sufficient processing capacity for performing the kernel, signaling and transport protocol functions.

The communication between the RISC processor 62 and the host computer 60, in a base station 18 or a mobile unit 20, utilizes a dual-port memory based interface 68 over the PCMCIA interface 70. The interface is implemented with a Field Programmable Gate Array (FPGA). There are two access modes, one mode accesses any of the CPU's peripherals, but takes longer as the interface must arbitrate for the FAWN CPU's internal bus. As each side of the dual port RAM 68 can be accessed at full speed by the host CPU and the FAWN CPU 62 the data transfers can occur at a maximum speed.

A modem controller 72 is implemented utilizing another FPGA and implements many of the low level functions necessary to support wireless access protocols. An RF modem 64, such as a 2.4 GHz FHSS modem, provides a logic level interface for data and control, as well as an analog received signal strength indicator. This band permits 83 channels of 1 MHz for frequency hopping. Currently a GEC Plessey modem can support 83 channels at a 625 Kbits/sec raw bandwidth and will support a 1.2 Mbits/sec bandwidth in another version. The modem's interface permits selection of 1 of the 83 channels, the power level, and 1 of 2 antennas. The modem 64 supplies a bit stream to a UART 74 during receive and accepts a bit stream during transmit. The UART 74 converts the bit stream from the modem 64 to bytes during receive, stripping the relevant synchronization bits and providing bytes to the controlling FPGA (modem controller) 72. During transmission the UART 74 adds synchronization bits and feeds the bit stream to the modem 64. The FPGA (modem controller) 72 includes four 64 byte buffers which store packets of data to and from the UART 74. This allows the UART 74 to asynchronously transmit and receive data without having to interrupt the FAWN CPU 62. The FPGA 72 (modem controller) includes a resettable counter operating at 1 MHz which can be utilized as a real time timer for protocol and task scheduling. An Analog to Digital Converter (ADC) 76 and low pass filter allow the received signal strength to be read by the FAWN CPU 62. A Control PAL 78 is contained within the FAWN adapter 56. The FAWN card 56 includes 4 Mbytes of SRAM 80 for program and data storage.

For practical purposes, therefore, the nature of the wireless hop in SWAN depends on the characteristics of the particular radio transceiver that is supported by the FAWN adapter 56. With respect to slow frequency hopping, the primary radio transceiver used in SWAN is the DE6003 radio from GEC Plessey. DE6003 is a half-duplex slow frequency hopping radio operating in the 2.4 GHz ISM band, and has a data rate of 625 Kbps. Further, the radio has two power levels, and has two selectable radio antennas 82. Legal requirements dictate that the radio must be operated in such a fashion that it hop pseudo-randomly among at least 75 of the 83 available 1 MHz wide frequency slots in the 2.400 to 2.4835 MHz region such that no more than 0.4 seconds are spent in a slot every 30 seconds. Communicating transceivers hop according to a pre-determined pseudo-random hopping sequence that is known to all of them.

The slow frequency hopping mechanism suggests that a channel in SWAN's wireless hop naturally corresponds to a hopping sequence, or a specific permutation of 75 to 83 frequency slots. Channels co-located in the same geographical area should use hopping sequences such that the chances of two different channels beings in the same frequency slot at the same time is minimized, such hopping sequences are weakly orthogonal. In SWAN, 20 to 25 distinct channels are defined with their own hopping sequences and these channels are then distributed among the base stations 18 in various pico-cells. More than one channel can be allocated to a base station 18, and a base station 18 needs to have a separate radio for each channel assigned to it. The same channel cannot be assigned to two base stations 18 in cells 22 that can mutually interfere. The mobile units 20 have only one radios, and at any given time operate in a specific channel.

Also relevant to the wireless hop design are some of the timing parameters associated with the DE6003 radio transceiver used in SWAN. The radio has a maximum limit of 10 ms on the duration of a continuous transmission, and two periods of such continuous transmissions must be separated by at least 88 µs. This suggests that, at the data rate of 625 Kbps, a maximum of 6250 bits (or 781.25 bytes) can be transmitted in one burst. Therefore, the maximum size of an air interface packet is 6250 bits. Further, the overhead time to switch from receive to transmit mode is 5.8 µs maximum, and for the switch from transmit to receive mode is 30 µs maximum. Compared to the 88 µs separation between two continual transmissions, these two numbers suggest that from efficiency perspective it is better that a transceiver switch its direction after the 10 ms maximum transmission burst. Another timing parameter that results in overhead is the 80 µs time taken by the radio to hop from one frequency slot to another.

The radio provides a bit error rate (BER) of 1E-5 maximum for operation in SWAN's environment. This translates into a probability of less than 0.5% that an ATM cell will be lost due to noise. While being a much larger loss probability compared to what is easily available on the wired backbone, this cell loss probability is overshadowed due to frequency slot collision in two co-located channels. For example, if two channels using 75 long frequency hopping sequences collide even once every sequence, a loss of 4% takes place techniques such as information spreading across frequency slots and smart hopping algorithms are to the first order more crucial in SWAN's wireless hop than techniques targeted at errors only due to noise.

FIG. 5 shows the abstract architecture of a typical base station in SWAN. A base station 18 consists of multiple wireless ATM adapter cards 28 plugged into its backplane, with each card 28 handling multiple radio transceivers 42. Each radio transceiver 42 is assigned a channel 90 (frequency hopping sequence) that is different from channels 90 assigned to a radio 42 in the current or neighboring base station 18. Typically, in SWAN, a base station 18 has fewer than 3-5 radios 42 per base station 18. The preceding base station organization results in a cellular structure where each cell is covered by multiple co-located channels. A mobile unit 20 in a cell 22 is assigned to one of the radio ports on the base station 18, and frequency hops in synchrony with it.

Since carrying multimedia traffic to the mobile units 20 is a major goal in SWAN, the two important drivers for the medium access control and physical layer control subsystem were low latency hand-offs and support for multiple simultaneous channels 90 in a given cell 22. In addition, explicit allocation of wireless resources among ATM virtual channel connections is crucial. Finally, at least in the initial implementation, simplicity of implementation was considered desirable. In any case, implementing algorithmic enhancements would be easy because the wireless adapter architecture is based on software and reconfigurable hardware.

In light of these considerations, the basic physical layer strategy used currently in SWAN is to assign each mobile unit 20 in a cell 22 to its own radio port, or channel, on the base station 18. The available 20-25 channels are distributed in a three-way spatial multiplexing, so that there are 7-8 channels available per cell 22, and each base station 18 is accordingly equipped with multiple radio ports. Given that a cell 22 is of the size of a room, this is more than enough for the initially envisaged usage pattern. More demanding usage patterns, such as handling conference rooms, will indeed require the ability to support multiple mobile units 20 per channel. The time between two frequency hops on a channel is called the hop frame, which is sub-divided into link cells or air-interface packets of fixed length. Access to the channel 90 is regulated by a token passing mechanism, with the base station 18 acting as the master for handing out the token. The hand-off is mobile unit initiated which transmits Hand-off Request Link Cells (HRLC) based on measurements of current base station power. On the other hand, base station searches on its idle radio ports for mobile units 20 that are seeking a base station 18. This basic scheme is detailed in the following sub-sections.

The definition of the air-interface packets, and the mapping of ATM cells onto the air-interface packets, depends on the hardware constraints. In SWAN, a standard serial communications controller chip is used in the synchronous mode resulting in the well known Synchronous Data Link Control (SDLC) protocol being used over the air. A SWAN transmitter sends SDLC frames separated by the SDLC SYNC bytes. In order to reduce the interrupt overhead to the software, a physical layer controller drives the serial communications controller. The physical layer controller accepts data units called link cells or air-interface packets from the medium access control layer, and stuffs them into the SDLC frame sent by the serial communications controller chip. The reverse is true on the receiving end. The physical layer controller needs to be in hardware, and its current implementation in the reconfigurable hardware part of the FAWN wireless adapter in SWAN is based on a design that uses fixed 64-byte sized link cells. The higher level medium access control layer communicates with the physical layer in terms of these 64-byte link cells.

Given the constraint of fixed 64-byte sized link cells, the current scheme uses the simple suboptimal strategy of encapsulating a 53 byte ATM cell to a link cell, with the remaining 11 bytes being used for medium access control header and for error control. In addition to the link cell that encapsulates an ATM cell, several other link cells are also defined for signaling purposes.

FIG. 6 shows the format of a generic link cell 84. There is a 4 byte header 86 and a 53 byte body 88, and the remaining 7 bytes are currently undefined. The header 86 has fields for Cell Type 92 which is 3 bits, RadioPortID 94 which is 8 bits, and three other fields for medium access control. The medium access control fields consists of a 1 bit Token_G field 96, a 3 bit Token_R field 98 and a 1 bit BSReq field 100. In addition, the header uses 16 bits for forward error correction (FEC) 102 of the above information. Forward error correction provides for the link cell integrity wherein the transfer of packetized data has a means for error detection and error correction that relies solely on a one-way communication of data bits from a sender to a receiver. The RadioPortID 94 is a logical id assigned by the higher level backbone signaling such that no two radio-ports in radio vicinity have the same id. This logical RadioPortID 94 is mapped by the base station 18 to the wired network address of the base station 18, and the RadioPortID 94 within the base station 18.

Seven type of link cells are defined: ATMLC for encapsulating ATM data cell, CRLC for connection request by a mobile unit that powers up, HRLC for hand-off request by a mobile unit, SYNCLC for idle channel, and CHRLCACK1, CHRLCACK2, and CHRLCACK3 for handshake during registration of a mobile unit at a base station.

The basic protocol for access regulation on a channel is that of token passing, with the base station 18 acting as the central arbiter that decides who gets the token, and hence the transmission privilege. In the one mobile unit 20 per radio port scenario, which is currently the case, this reduces to an exchange of tokens between the mobile unit 20 and the base station 18 to establish full duplex communications. The token can be held for at most N=8 link cell duration, which is slightly less than 10 ms, the length of maximum allowable continuous transmission burst. This maximum interval is used to detect lost tokens in noisy channels. The token information is a part of the link cell header 86, in the form of two fields: TOKEN_G 96 which is 1 bit and TOKEN_R 98 which is 3 bits. The G field with value 1 is used to indicate that a token is being granted to the receiver (for &lt;= N link cell duration). The R field indicates the number of ATM cells that are queued at the sender, information is used by the base station 18 in scheduling the token. In the case of an idle channel, the control will just pass back-and-forth with G=1, and R=0. Finally, in case the token is lost due to noise, the mobile units 20 do nothing, and time-out, while the base station 18 takes over the control and resets the token passing protocol.

Closely related to the medium access control is the control of frequency hopping. Although the two are logically orthogonal issues, they cannot be separated in an implementation. Instead of using a hopping scheme based on measuring hopping interval in terms of real time, we count the number of token passes to measure the length of the hop frame. In particular, hopping is done after every M=8 token grants from mobile unit 20 to base station 18. Of course, token losses are a nuisance in this scheme, and a straightforward counting of tokens will not work. We therefore count the effective number of token passes to decide when to hop. The effective number of token passes is the actual number of token passes and the number of time-outs while waiting for token.

It is of particular interest to consider the various wireless hop scenarios. After power-up a mobile unit 20 begins to transmit a "Connection-Request" link cell (CRLC). This transmission is done using a random initial frequency hopping sequence, and is at a fast rate whereby the mobile unit 20 jumps to the next frequency slot in the sequence if no base station 18 responds to the connection request link cell. The body of CRLC consists of the globally unique mobile unit id and a hop sequence id. This information is protected by a forward error correction scheme based on an (8,4) linear code. Following CRLC is a reserved time interval (of length 2 x link cell duration) for an interested base station 18 to acknowledge via a CHRLCACK1 cell. Contained in CHRLCACK1 is an 8-bit logical id that the base station 18 assigns to the mobile unit 20 for the duration of mobile unit's connection to the radio port. Following successful reception of CHRLCACK1 by the mobile unit 20, an exchange of CHRLCACK2 and CHRLCACK3 take place to finish the 3-phase handshake that constitutes the mobile unit registration process.

A mobile unit 20 in SWAN continually measures the RF power P_current of packets it receives from its base station 18. Further, two power thresholds are defined: P_min and P_thresh, with the latter being greater than the former. When P_current falls below P_thresh but is still above P_min, the mobile unit 20 initiates the process of soft hand-off by beginning to periodically transmit a "Hand-off Request" link cell (HRLC) with periodicity proportional to P_thresh-P_current. In addition, the mobile unit 20 sets the "Base station request" bit (BSReq) 100 in the header 86 of all the link cells 84 it transmits. This indicates to idle base stations 18 as well as the current base station 18 that a hand-off is needed. The body 88 of the HRLC consists of the globally unique mobile unit id, a hop sequence id, and the id of the current base station 18. Like in CRLC, the body of HRLC too is protected by an (8,4) forward error correcting linear code 102. The handshake that follows an HRLC is a 3-phase handshake similar to that in the case of a CRLC as described above. In the case when the power P_current falls below P_min, the mobile unit 20 assumes that its connection to the current base station 18 has been lost, and begins to continually transmit HRLC and switches to a fast hop rate. The fast hopping rate not only reduces the effect of frequency collision with other channels, but also reduces the average time to find a new base station 18, thus helping in the goal of low hand-off latency. Of course, the soft hand-off mechanism described earlier is the primary mechanism for low latency hand-offs as it allows registration at a new base station 18 to be done while the communication with the current base station 18 is not broken.

The base station 18 with one or more idle ports actively hunts for mobile units 20 that might want to connect. This is done according to the following process. First, using hints from the backbone, a frequency slot is chosen for the idle radio-port such that none of the radio-ports in the parent base station 18 or on neighboring base stations 18 are using that frequency slot. The idle radio-port hops to the frequency slot thus chosen. Next, it measures power at that frequency and snoops for link cell headers 84. If not activity is detected at that frequency slot, a new frequency is chosen and the hunt restarted. If activity is detected, but link cell headers 84 show that the BSReq 100 bit is not set then the base station 18 assumes that the mobile unit 20 is not interested in a hand-off, and it again restarts the hunt at a new frequency. Otherwise, the base station 18 waits for a CRLC or a HRLC link cell, or for the channel to become idle. If CRCL or HRCL is received, the base station 18 initiates the registration process for the powering-up mobile unit 20 or for the handing-off mobile unit 20, as the case may be. A three-phase handshake involving CHRLCACK1, CHRLCACK2, and CHRLCACK3 is used for this as described earlier.

Consider the interface between ATM Connection Manager and the Medium Access Control Module. In order to schedule the wireless resources among the multiple ATM virtual channel connections going over a wireless channel, the Medium Access Control module maintains a table of per Virtual Channel Connection information. When a new Virtual Channel Connection needs to be opened, the connection manager module sends a request to the Medium Access Control module indicating the bandwidth requirements as the channel time T 1 needed by this Virtual Channel Connection over a period of time T2. The Medium Access Control module uses this information to either accept or deny admission to this new Virtual Channel Connection. Further, this bandwidth specification is used by the Medium Access Control module to schedule transmission of cells belonging to different Virtual Channel Connections.

The implementation of the medium access control and physical layer control subsystem for SWAN can be viewed as a three-way hardware-software co-design task where the functionality can be implemented at one of three locations: as software on the base station CPU or the mobile unit CPU, as embedded software on the wireless adapter, and on field programmable hardware on the wireless adapter. In the case of a dumb terminal with an embedded wireless adapter, there is no CPU in the terminal, so that the entire functionality is on the wireless adapter itself. In the current implementation, the physical layer control is implemented on the field programmable hardware on the wireless adapter, the Medium Access Control is implemented as software on the wireless adapter, and the ATM connection manager that Medium Access Control talks to as software either on the base station or mobile unit CPU, or on the wireless adapter itself in the case of a dumb terminal.

The organization of the software embedded on the wireless adapter is shown in FIG. 7. The software is organized as a multi-threaded system. The finite state machines corresponding to the Medium Access Control protocol at each radio port are implemented as FSMs 104 running in the interrupt mode. There is one such FSM 104 for each radio port. These can be viewed as very high priority threads. The Medium Access Control FSMs 104 communicate with a main thread 106 that runs in the user mode and handles queue management and dispatching of ATM cells to the Medium Access Control FSMs 104 on one side, and to other threads or to the base station/mobile unit CPU on the other side. The inter-thread communication is done using queues of pointers 108, with the ATM cells themselves being stored in a shared memory area. It is worth pointing out that in the case of dumb terminals with no CPU of their own, the ATM connection manager 110 and the threads that source or sink ATM cells are also run on the embedded CPU (an ARM610 processor) on the wireless adapter. An IRQ Handler 112 processes interrupt requests in response to a queue status change.

On-going work is extending the basic token passing medium access control to accommodate ad hoc networks where no a priori base station is present, and do trade-off between forward error correction and wireless link level retransmissions on a per virtual channel connection basis. <dl id="dl0001" compact="compact"><dt>10</dt><dd>WAN</dd><dt>12</dt><dd>LAN/SWAN</dd><dt>14</dt><dd>Server</dd><dt>16</dt><dd>Wired End Point</dd><dt>18</dt><dd>Base Station</dd><dt>20</dt><dd>mobile host/units</dd><dt>22</dt><dd>cell</dd><dt>24</dt><dd>last hop</dd><dt>26</dt><dd>wired ATM adapter</dd><dt>28</dt><dd>wireless ATM adapter</dd><dt>30</dt><dd>cell router &amp; adapter interfaces</dd><dt>32</dt><dd>connection manager</dd><dt>34</dt><dd>applications</dd><dt>36</dt><dd>mobile connection manager</dd><dt>38</dt><dd>mobile cell router &amp; adapter interfaces</dd><dt>40</dt><dd>applications</dd><dt>42</dt><dd>digital transceiver</dd><dt>44</dt><dd>radio port interface</dd><dt>46</dt><dd>standard bus interface</dd><dt>48</dt><dd>standard bus</dd><dt>50</dt><dd>standard core module</dd><dt>52</dt><dd>field programmable hardware resources</dd><dt>54</dt><dd>compute engine</dd><dt>56</dt><dd>FAWN</dd><dt>58</dt><dd>PCMCIA</dd><dt>60</dt><dd>to host processor (PCMCIA Bus)</dd><dt>62</dt><dd>RISC processor/ARM CPU/FAWN CPU</dd><dt>64</dt><dd>RF Modem</dd><dt>66</dt><dd>Peripheral Interface</dd><dt>68</dt><dd>Dual Port RAM</dd><dt>70</dt><dd>PCMCIA Interface</dd><dt>72</dt><dd>Modem Controller</dd><dt>74</dt><dd>UART</dd><dt>76</dt><dd>ADC</dd><dt>78</dt><dd>Control PAL</dd><dt>80</dt><dd>SRAM</dd><dt>82</dt><dd>Antenna</dd><dt>84</dt><dd>generic link cell</dd><dt>86</dt><dd>header</dd><dt>88</dt><dd>body</dd><dt>90</dt><dd>channel</dd><dt>92</dt><dd>Cell Type</dd><dt>94</dt><dd>RadioPortID</dd><dt>96</dt><dd>Token_G</dd><dt>98</dt><dd>Token_R</dd><dt>100</dt><dd>BSReq</dd><dt>102</dt><dd>FEC</dd><dt>104</dt><dd>Medium Access Control FSM</dd><dt>106</dt><dd>main thread</dd><dt>108</dt><dd>queue status pointer</dd><dt>110</dt><dd>application thread</dd><dt>112</dt><dd>IRQ handler</dd></dl>