Proptotype radio network

RDRN:A Prototype for a Rapidly Deployable Radio Network�

Ricardo J. Sanchez Joseph B. [email protected] [email protected]

Gary J. Minden Victor S. Frost K. Sam [email protected] [email protected] [email protected]

Information and Telecommunication Technology CenterDepartment of Electrical Engineering & Computer Science

University of Kansas, Lawrence, KS 66045

This paper reports on the initial implementation of an experimental wireless ATM network archi-tecture called RDRN (Rapidly Deployable Radio Network). The RDRN architecture consists of twotypes of transportable nodes, remote nodes (RNs) and edge nodes (ENs), which utilize GPS-derivedlocation information to rapidly configure themselves into a high capacity wireless network oper-ating at 1-10 Mb/s over distances as far as 10 kilometers. The initial prototype has been deployedand early experiments have been conducted to validate hardware, software, and protocol design andimplementation. In addition to describing the RDRN architecture and protocols, this paper detailsexperiences at the DARPA GLOMO ’97 demonstration of the RDRN project.

I Introduction

The idea of end-to-end ATM systems extending from wide-area network (WAN) to local-area network (LAN) includinga mix of wired and wireless technologies is rapidly gainingmomentum. Extensive research has been conducted on desk-top ATM technologies area [AB97]. However, the advent ofwireless communications and the increase in user demand forefficient wireless services have created new opportunities forATM technology research. A key question in this effort is howto extend the current LAN/WAN ATM paradigm to supportmobile wireless users without impacting the existing ATM in-frastructure.

It is critical to enable technologies that support operations inwired/wireless environments. Towards this goal, DARPA ini-tiated the Global Mobile Information Systems (GloMo) pro-gram [LRS96] driven by the need to satisfy future require-ments such as mobile operation support, rapid deployment,higher speeds, and seamless integration with commercial tech-nology. Over the past two years, the Rapidly Deployable Ra-dio Network (RDRN) project has built and deployed an archi-tecture to satisfy these requirements. More specifically, theRDRN approach addresses the research issues by constructinga system based on the combination of two wireless networktechnologies; one that enables the rapid deployment of point-to-point wireless links and another that provides seamless sup-port for data communications over established point-to-pointlinks. The joint system, named Rapidly Deployable RadioNetwork (RDRN), represents a new approach to ATM-basedwired/wireless network architectures. This paper describes thedesign, implementation, and preliminary evaluation of the firstprototype of the RDRN architecture.

The rest of this paper is organized as follows. Section IIpresents the related work in the area. The RDRN architectureis described in Section III. Section IV presents initial perfor-

�This work is partially funded by ARPA contract number J-FBI-94-223and Sprint under contract CK5007715.

mance data obtained from our initial implementation. Our ex-perience during the demonstration of the RDRN project andits interoperability with other mobile research prototypes dur-ing GloMo ’97 is reported in Section V. Finally, Section VIconcludes this paper.

II Related Work

Extending the ATM paradigm from the wireline to the wirelessdomain is not a new idea. Several projects have consideredand implemented architectures for wireless ATM such as Red-Net [C+95], BAHAMA [E+95a], WATMNet [FR95], ORL’sRATM [P+96], SWAN [A+96], AWA [U+96], and WAND[Mik96]. Although most of these proposals use similar con-cepts, they vary in approach and scope. More formal effortstowards the standardization of wireless ATM technology in-clude those of official organizations such as the ATM Forumwith their WATM group [Rau97] and the ETSI standard bodywith their ETSI STC RES 10 project [ETS95], but a standardis far from complete. Our conceptual view provides a differenttwist to the traditional approach to wireless ATM by combin-ing two different wireless network technologies, an omnidi-rectional packet radio network and a point-to-point wirelessATM network, with the overall goal being the implementationof a wireless network architecture that is self-configuring andrapidly deployable in an army battlefield situation or a civil-ian disaster relief operation. Byrapidly deployablewe meanthe ability to quickly provide a network infrastructure by wayof automated (re)configuration. As mobile nodes move, thetopology of the wireless network changes causing point-to-point wireless links (and their associated connections) to be(re)setup or tear-down.

The RDRN design can be best compared to those of BA-HAMA [E+95a] and SWAN [A+96] architectures. Like BA-HAMA, RDRN features transportable base stations that canconnect through high-speed wireless links to supportad hocnetworking at the backbone level. Similarly, RDRN remote

ACM Mobile Computing and Communications Review, Volume 2, Number 2, 1998 1

nodes can be interconnected, via access wireless links, overthe transportable base stations in aninfrastructurenetwork-ing fashion. Unlike BAHAMA, RDRN treats both access andbackbone wireless links the same: they are both unreliablelinks that need support of link-by-link error control mech-anisms. While the backbone network in BAHAMA lookscloser to a regular ATM network, because the interconnec-tion network is through reliable microwave-based links, itlacks the ease of reconfigurability and rapidly deploymentfeatures that characterize the RDRN network at the wire-less backbone level. Compared to SWAN, RDRN featuresa similar base station design: a mobility-aware ATM switchin software which enables wireless user access and wiredATM backbone connectivity. But, unlike SWAN, RDRN alsoprovides wireless ATM backbone connectivity among trans-portable base stations to support multihop wireless topolo-gies. Earlier reports on RDRN have been published on[B+95][E+95b][SP96][B+97].

The RDRN system is distinguished by the following fea-tures:

� architecture composed of two overlaid radio networks[E+95b]

– low bandwidth orderwire network for networkconfiguration and control

– high bandwidth wireless ATM network for end-user access to edge nodes and for backbone use amongedges nodes

� network configuration, control, and management algo-rithms based on location information distributed acrossthe orderwire network [B+95][B+97]

� Phased array antenna with digital beamforming and soft-ware radio [SP96]

� Mobility-aware software-based ATM switch on edgenodes

� Adaptive wireless communication protocols based on es-timated channel conditions

III RDRN Architecture

The main objective of the RDRN architecture is to use an adap-tive point-to-point topology to gain the advantages of ATMfor wireless networks. Figure 1 shows a high-level view ofthe RDRN system which is made up of two types of nodes:Remote Nodes (RNs) providing wireless ATM access to end-users and Edge Nodes (ENs) serving as radio access point orbase stations to enable switching and connectivity among RNusers and the ATM WAN. The architecture is composed oftwo overlaid radio networks: (1) a low bandwidth, low power,omni-directional network, calledthe orderwire network, in-tended for location dissemination, topology configuration, andlink setup management among RDRN nodes; and (2) a highbandwidth, multi-directional network, calledthe WATM net-work, that features (a) 1 Mb/s point-to-point connectivity be-tween a RN and an EN and (b) 10 Mb/s point-to-point con-nectivity among ENs1. The radio networks are able to operate

1The ENs can reside at the edge of a wired ATM network or on their ownto create a multihop topology.

over distances as far as 10 kilometers. The orderwire networkprovides a coarse-grain control mechanism for managing linksto be setup over the WATM network while the WATM networkprovides a fine-grain control mechanism for controlling re-sources within established links (e.g., ATM virtual circuits) inaddition to transporting user data. Unlike traditional wirelessarchitectures, the RDRN system design features two differentwireless network technologies in one. The reason for this istwofold: one is that because of its low speed the orderwireoffers a high level ofreliability which is key to the success-ful establishment and continuous adaptation of the point-to-point links over the not-so-reliable WATM network; the otheris simplicity in the overall design by utilizing a low bandwidthomnidirectional network for orderwire control operation anda high-bandwidth point-to-point beamforming-based network,which assumes link connectivity, for the WATM network. Wenote that the architecture presented allows for flexible growthas the demand for rapidly deployable radio networks becomemore evident.

RN

RN

ATM WAN

ATMSwitch

PCIPCI EN

OC-3

RS-232

OC-12 (fiber)

EN = Edge Node

RN = Remote Node

= Radio Antenna

GPS Receiver

Packet Radio

High-capacityWireless ATM

Orderwire

EN

Low-capacityWireless ATM

Orderwire

EN

Legend

(fiber)OC-3

PCI

RN(Orderwire)

GPS ReceiverRS-232(Orderwire)

Packet Radio

Steerable Antenna(Wireless ATM) (Wireless ATM)

Steerable Antenna

Figure 1: High-level model of the RDRN system

We now proceed to describe the RDRN hardware and soft-ware design.

A. RDRN Hardware

Each node in the RDRN system (i.e., RN and EN) is best de-scribed as a transportable unit equipped with a laptop com-puter, a Global Positioning System (GPS) receiver, a 19,200b/s packet radio transceiver, a custom-designed wireless ATMhost adapter PCI card, and a custom-designed phased-arraysteerable antenna system with digital beamforming. The lap-top computer is a Toshiba Tecra 700CT with a 120 Mhz pro-cessor attached to a Toshiba docking station with PCI/ISAexpansion slots. Both the GPS receiver and the packet ra-dio transceiver are installed on ISA slots while the wirelessATM adapter is installed on a PCI slot. For multimedia sup-port on the RN, the laptop incorporates built-in microphoneand speakers for sound, and a video camera is connected toa Matrox Meteor video adapter installed on another PCI slotin the docking station. Optionally, an EN may be equippedwith a wired ATM adapter card, which is installed on a PCIslot, if connectivity to a wired ATM network is desired. The

2 ACM Mobile Computing and Communications Review, Volume 2, Number 2, 1998

antenna system features an omnidirectional receiver, a single-directional (multiple-directional) beamforming transmitter forthe RN (EN), and a full-duplex connection to the wirelessATM adapter installed on the laptop. A view of the describedRDRN unit built for the first prototype is shown in Figure 2.

Tx Antenna: multidirectional, 8 elementsRx Antenna: omnidirectional

IF cards

in

VME chassis

Laptop

Docking Station

Antenna System

Tx Antenna Rx Antenna Tx/RxPktRadio

GPS

IF/RF Up-Converter

RF Power Amplifier

8 conn

8 conn

Front View Side View

2 connWATM host adapter

serial card

Omni recv

PktRadio/GPS recv

IF RX card

IF TX cards

RackControl

card

Figure 2: Component View of the RDRN EN/RN unit

When initially deployed, each RDRN node retrieves its lo-cation information from the GPS receiver. The location is usedby each RDRN node to steer antenna beams towards nearbynodes and nulls towards interferers. An EN is capable of form-ing multiple digitally formed beams in the direction of otherENs or towards RNs in the vicinity. Multiple digital beamsformed by a single transmitter are all of the same frequencyto allow spatial frequency reuse. The antenna system is de-signed to provide 10 Mb/s data rate on beams formed betweentwo ENs and 1 Mb/s data rate on beams formed between an ENand one or more RNs. As many as 64 users (RNs) can arbitratefor the available bandwidth in a particular beam formed by anEN using a TDMA structure; alternatively, a single RN canarbitrate for all of the bandwidth available in such beam. TheTDMA mechanism is controlled on the EN by using the GPStime reference to schedule time slots among RNs, within a sin-gle beam, that are arbitrating for available bandwidth in theuplink direction. In our initial implementation, digital beam-forming is only implemented in the transmit direction whilein the receive direction each node communicates back usingunique frequencies. Figure 3 shows an overview of the link-level mechanism utilized in the RDRN system.

The Amateur Radio Service (ARS) frequency band from1240 - 1300 Mhz was chosen for our first system prototype.The bandwidth of each beam is currently constrained to 1MSymbol/sec. Multiple RNs assigned to an EN are supportedthrough two methods, that is, multiple independent beams ofthe same frequency can be formed if the RNs are geograph-

Edge Node

-90 +90

-90 +90

Omni RxWATM Link

Directional TxWATM Link

Omni Tx/RxOrderwire

WATM linkuplink

WATM linkdownlink

+90

+90

+90

+90

Remote Node

Remote Node

Remote Node

-90

-90

-90

-90

Fiber OC-3

ATM WAN

Legend

freq1

freq2

freq4

freq3

Remote Node

Figure 3: Link-level overview of the RDRN system

ically far enough so that there is no interference, or they canbe grouped into the same beam using the TDMA mechanism.For further details on the RDRN hardware design the reader isreferred to [E+95b] and [SP96]

B. RDRN Software

Linux has been chosen as the operating environment for theRDRN system running on the laptops. The RDRN softwareis divided into two major components, theorderwire modulesand theWATM modules, that work in close coordination.

We now proceed to describe the high-level architecture interms of the algorithm embedded in the RDRN software forboth the orderwire network and the WATM network.

1. The Orderwire Network

The wireless topology is setup by initially having the ENsbroadcast their position over the orderwire network and lis-ten for location broadcast from other RDRN nodes. Simi-larly, RNs broadcast their position over the orderwire system.A location-based distributed network configuration algorithmis executed to establish WATM link-level connectivity amongENs and sets of RNs or among adjacent ENs. Network re-liability is ensured by continuously exchanging location andstatus information over the orderwire network. As RDRNnodes move, position updates from GPS receivers are used tosteer the beams in the correct direction to form point-to-pointWATM links. WATM link connectivity is established basedon closest physical proximity. The algorithm not only controlsthe assignment of beam and TDMA slots that requester nodesget assigned to for particular point-to-point WATM links, butalso the handoff of users from one EN to another. Topol-ogy reconfiguration is thus triggered whenever an EN or RNmoves. For instance, when a RN moves, state information isexchanged between the old and new point of entry (i.e., oldand new ENs) in order to reroute existing ATM virtual cir-cuits (VCs) established to the RN in question through its newpoint of attachment. Although the new routing information isexchanged over the orderwire, the actual re(establishment) ofVCs is signalled through a lighter mobility-aware version of


the NNI signaling protocol. At this stage, handoff support isonly provided when a RN moves but we are in the process ofrevamping the distributed network configuration algorithm toinclude the interesting case of mobile ENs. This new designwill be reported in an upcoming paper. For specific details ofthe described algorithm and preliminary performance resultsobtained through simulation the reader is referred to [B+97].

Figure 4 describes the protocol architecture for the order-wire system. Orderwire modules, running as user-level pro-grams on ENs and RNs, receive position updates via a GPSreceiver connected to a serial port, and receive and transmitorderwire commands over a protocol based on AX.25 [AX25]via the orderwire connected to another serial port.

Remote Node(s) Edge Node

PKT-RADIOGPS

PHY PHY

AX.25

RN-NCP

RN-1

RN-N

GPSPKT-RADIO

PHY

AX.25

EN-NCP

PHY

adjacent RNs (and/or ENs) within range(only adjacent RNs are shown)

Figure 4: Orderwire Protocol Architecture

Once the RDRN network topology is initialized at theWATM link-level using the orderwire network, the RDRNnodes may start their configuration at the ATM level over theWATM network.

2. The WATM network

Unlike all other wireless ATM implementations found in theliterature, wireless access in the RDRN network is not re-stricted to the last hop. This makes the RDRN system veryunique by enabling high-speed multihop wireless topologiesover long distances2.

A multihop configuration is possible thanks to the novel de-sign of the RDRN ENs. Basically, an EN can be understood asa traditional base station in wireless system but with expandedfunctionality to support mobility and virtual ports of differenttypes (wired/wireless). A software-based ATM switch, calledMicro-Switch, is embedded into the EN’s architecture to pro-vide cell-level switching of user data3. Given the relative slowspeed of wireless links, the realization of ATM switching insoftware is not a major issue.

Figure 5 describes the protocol architecture for the WATMsystem. The WATM modules are a mix of user-level pro-grams and kernel drivers embedded into the Linux-ATM soft-ware [Alm]. Linux-ATM is used to provide native-mode

2High-speed multihop wireless networks configured as wireless backbonesare one of many interesting topologies that are enabled by the RDRN archi-tecture; the implications of such scenarios, however, are beyond the scope ofthis paper.

3The incorporation of ATM switching functionality on the base station(EN) itself strongly contrasts with other approaches; our architecture can befully deployed without the need of a separate ATM switch.

ATM as well as TCP/IP over ATM support to running appli-cations and user-level signaling programs on both ENs andRNs. On the RN, the WATM protocol stack looks like anyother ATM device driver to Linux-ATM. Packet are encapsu-lated/deencapsulated using AAL-5. Similarly, on the EN, mul-tiple WATM protocol stacks (and a single ATM protocol stack)look like any other ATM device driver to Linux-ATM; how-ever, ATM virtual circuit (VC) packets are routed through theMicro-Switch if configured to use AAL-0 (null) encapsulation,otherwise they are treated as AAL-5 packets and processed ac-cordingly by the Linux-ATM architecture.

UserApps

to wiredATM network

RN-N

RN-1

Remote Node(s) Edge Node

PHY

AAL

ATM

W-ATM

W-DLC

W-MAC

M-SIG

W-MAC

W-ATM

PHY

ATM

PHY

ATM

W-DLC

ATM

W-DLC

AALAAL

ATM

AAL

M-SWITCH(ATM cells) + M-SIG(AAL pkts)

adjacent RNs (and/or ENs)with established p-to-p links

(only adjacents RNs are shown)

Figure 5: WATM Protocol Architecture

Air packets transmitted over the WATM network are en-capsulated using the WATM frame format shown in Figure6. WATM frames may carry data as encapsulated ATM cellsor control information needed to ensure proper link control.There are 3 types of air packets: time-sensitive data packets,guaranteed-delivery data packets, and control packets. Sincethe WATM frame format derives from the functionality em-bedded in the WATM stack we proceed to describe the WATMstack in some detail next.

8b 8b 8b

radio

flag

frame

flag

8b

link ID frametype (2b)

enc (1b)

res (1b)

data

(1-9 ATM cells)

+ control seq (8b)

+ pad

16b

error

control

W-MACW-PHY preamble

# of cells

(4b)

orctrl type

Figure 6: WATM frame format

The WATM stack is composed of several layers: the AALlayer (ATM adaptation layer), the ATM layer (segmentationand reassembly), the W-DLC layer (data link control enhancedfor wireless), a W-MAC layer (medium access control forwireless), and a W-PHY layer (physical for wireless). We notethat the latter two layers are collapsed into one common layerfor multiple WATM stacks on an EN for reasons that will beunderstood shortly. The AAL layer provides an interface be-tween the WATM stack and the Linux-ATM architecture re-ferred earlier. The ATM layer performs ATM segmentation


and reassembly functions for AAL-5 and AAL-0 (null) encap-sulation types.

The W-DLC layer performs link control operations to trans-mit a set of ATM cells (the set could include only one ATMcell) over a point-to-point WATM link. The number of ATMcells included on a set is negotiated between peer W-DLC lay-ers and adjusted (adapted) depending on the conditions of theparticular WATM link. The idea of putting multiple ATM cellsinto one WATM frame is to minimize the high effect of encap-sulation overhead for a single ATM cell when link quality con-ditions permits it. We also decided to retain the standard ATMcell structure over the wireless WATM link without modify-ing the ATM cell header in any way or performing cell headercompression but we are considering this type of optimizationfor future prototype implementations. For packets containingATM cells, the protocol extends standard ATM QOS over theair by associating the WATM frame type to one of two prede-fined types of traffic4: delay-sensitive (e.g., voice, video) andloss-sensitive (e.g., data), with delay-sensitive traffic havinghigher priority over loss-sensitive traffic. W-DLC peer lay-ers also negotiate what type of encoding to use for a particularpoint-to-point WATM link. Experimentation with different en-coding schemes and their relation to other adaptive parameterswill be object of study in future implementations.

Error detection and retransmissions are also part of the func-tionality of the W-DLC layer. WATM frames carrying delay-sensitive traffic received with errors are dropped while framescarrying loss-sensitive traffic received with errors are retrans-mitted. For all traffic types, the wireless channel state is es-timated based on the ratio of the number of frames receivedwith and without errors and is assumed to be in either a goodstate (characterized by a low BER) or a bad state (character-ized by a high BER). The WATM frame length (i.e., numberof ATM cells in frame) is adapted to the channel state with alarger frame used in the good state and a smaller one in thebad state. For loss sensitive-traffic, ann-copymechanism isalso used in the bad state to transmit multiple copies of eachframe at a time in order to reduce the total number of retrans-mission requests. The protocol uses a sliding window and ago-back-N ARQ scheme to guarantee reliability and maximizethe throughput under all channel conditions. In addition to per-forming link control operations over a set of ATM cells, theW-DLC layer also monitors link quality conditions by contin-uously sending special control packets to its peer W-DLC atthe other end. This information is used not only to determinethe channel state (i.e., good or bad) to allow adaptation butalso to prompt renegotiation of parameters with peer W-DLClayer when the adaptation scheme cannot satisfy the constraintposed by the WATM link.

The W-MAC layer in our system is somewhat simpli-fied since the WATM network already assumes point-to-pointWATM link connectivity. The W-MAC header contains a link-level address, frame type (time-sensitive data, loss-sensitivedata, or control), encoding scheme (no encoding at the mo-ment), and number of ATM cells (for data type frame) or con-trol type (for control type frames). Three service queues aremaintained by the W-MAC layer to prioritize transmission of

4For our initial implementation, all ATM cells encapsulated on a WATMframe corresponds to the same ATM VC; therefore, the VC traffic type (i.e.,ABR, CBR, VBR, etc) determines what type of WATM frame type to use.

different frame types. The error control used is a cyclic redun-dancy check (CRC) computed over the WATM frame payloadon this layer and checked at the receiver on the W-DLC layer.

The W-PHY layer appends a header to WATM frame forchannel equalization and timing at the physical level on thereceiver.

C. System Configuration

Local WATM link configuration strictly follows the orders ofa local link manager which works on behalf of the orderwireto setup, adapt, and tear-down WATM point-to-point links. Asmentioned before, such point-to-point links have already beenestablished at the physical level by close cooperation betweenthe orderwire and the beamforming antenna system that com-municates through the WATM adapter.

Upon establishment of a point-to-point WATM link at thephysical level, the link manager activates a WATM stack. Bydefault, one WATM stack is pre-configured in a RN with pre-established well-known VCs setup for ATM control messages(for example, VCI 5 for signaling and VCI 16 for ILMI ad-dress registration)5. Similarly, multiple WATM stacks are pre-configured in a EN, with the pre-established VCs required forATM control, and attached to the Micro-Switch on designatedvirtual ports.

When the link manager, running on any RDRN node, or-ders the activation of an available WATM stack for use in apoint-to-point WATM link, a WATM stack is enabled for datatransmission and is assigned an specific link-level address. Alink-level address identifies the physical beam and slot that theantenna system is to use when transmitting/receiving to/froma particular point-to-point WATM link. Since a point-to-pointWATM link corresponds to either a RN-EN or EN-EN connec-tion, the type of signaling messages that are to be exchangedthrough such particular link are defined accordingly: User-to-Network Interface (UNI) for RN-EN and Private Network-to-Network Interface (PNNI) for EN-EN connections6. Once aWATM stack is enabled at both end of a point-to-point WATMlink, it is ready to start transmitting and receiving WATM-encapsulated packets.

The RN ATM address registration occurs after its WATMstack is enabled. By default, the Micro-Switch on each ENis initialized with a unique ATM address prefix. Therefore,ENs assign ATM addresses to link-level connected RNs usingthe Interim Local Management Interface (ILMI) mechanism.Next, ATM VC connections are established using Classical IP(CLIP) over ATM. In this scheme, an ATM Address Resolu-tion Protocol (ATMARP) server7 is invoked to resolve a re-quested IP address into a destination ATM address. The des-tination ATM address is then used to establish the requestedconnection using conventional ATM signaling. Finally IPpackets can be transmitted and received over established ATMVCs.

5No data is actually transmitted or received until the stack is activated bythe link manager.

6The Micro-Switch embedded on the EN is able to understand PNNI sig-naling messages (for connections with other ENs or ATM switch) or UNIsignaling messages (for connections with directly connected host or remotelyconnected –via wireless– RNs) on any of its virtual ports.

7Information servers are preferably run on nodes that have direct connec-tivity to the wired WAN.


IV Preliminary Performance Results

In this section, we present preliminary performance results ofexperiments conducted to investigate the impact of certain de-sign choices in the RDRN system.

Our first concern was the realization of ATM switchingin software (i.e., Micro-Switch) on the EN. In particular, wewere interested to determine whether this component may bea bottleneck in our system. Since the Micro-Switch is a self-contained module that can use any ATM-based driver attachedto its virtual port, we setup a testbed to connect two host ma-chines through a third machine running as the Micro-Switch.Each host machines consists of a 120 Mhz Pentium PC withone OC-3 ATM host adapter (ENI-155MP) running Linux2.0.25 with the Linux-ATM distribution. The switching ma-chine consists of a 120 Mhz Pentium PC but with two ENIATM host adapters operating as two virtual ports. An ATMvirtual circuit was configured between the two host throughthe Micro-Switch. Figure 7 shows the TCP over ATM per-formance on the receiving machine versus the peak cell rateon the transmitting machine using thettcp tool included in theLinux-ATM distribution. Note that the maximum throughputachieved by the Micro-Switch peaks almost 7.5 Mb/s. Sincethe WATM links were designed to work up to 1 Mb/s, thisis of no concern for EN-RN connections; however, this is aproblem for EN-EN connections where 10 Mb/s throughputsare envisioned. Increasing the computing power on an EN willdefinitely ameliorate this problem for future implementations.The cell latency across the Microswitch module was also mea-sured yielding a 70-120�secs delay. We are currently analyz-ing these limitations so the Micro-Switch component will notlonger be a bottleneck for the entire transmission range envi-sioned on the RDRN system.

0 2 4 6 8 10 120

1

2

3

4

5

6

7

8

9

TC

P T

hrou

ghpu

t at t

he R

ecei

ver

(Mb/

s)

TCP Throughput at the Transmitter (Mb/s)

Figure 7: TCP Throughput vs. Transmitted Peak Cell Rate

All remaining experiments described in this section wereconducted using the setup shown in Figure 8. A virtual circuitwas established between the RN and the fixed node through theEN. The EN and RN were positioned closed enough to min-imize the error rate on the wireless channel. Figure 9 showsTCP throughput performance for delay-sensitive traffic. Aramdon error generator was introduced to simulate errors inthe channel at specifig bit error rates (BERs). Note that end-to-end TCP throughputs, between the fixed node and the RN,

were close to 0.9 Mbps for large WATM frame sizes withouterrors. However, in the presence of errors, there is an optimalframe size that yields the best throughput in each case. Inter-estingly, at a high BER (e.g.,10�4), the optimal frame sizedoes not necesarily converge to a single ATM cell size.

OC-3Fixed

RDRN

Node

RDRNEdgeNode

RDRN

NodeRemote

1 Mbps Radio Link

Figure 8: Experimental RDRN Testbed

1 2 3 4 5 6 7 8 9 100.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9 Throughput in Real Time mode

WATM frame size in cells

TC

P T

hrou

ghpu

t in

Mbp

s

BER=0 BER=1e−5BER=1e−4

Figure 9: Delay-Sentitive Traffic: TCP Throughput vs.WATM frame size

The effect of WATM frame sizes on round-trip time de-lays was also measured using theping tool. The experimentwas also performed over a delay-sensitive WATM link. Thesmallest WATM frame size encapsulates only one ATM cell(53 bytes) and yields a constant delay of 6.5 ms; with a delayincrease of 3 ms per additional ATM cell transmitted on theWATM frame.

As a final note, we remark the fact that the primary goal ofthe initial prototype was to provide a proof-of-concept of thearchitecture and a testbed for the evaluation of new ideas ratherthan to excel as a high-performance wireless system. For ex-ample, we have tested basic beamforming connectivity overlong distances (aprox. 10 Kms) but have not yet analyzed theimpact of big distances (and observed real error rates) in ourdesign. However, we are currently planning to perform moreexperiments to better analyze the performance of the RDRNimplementation and include optimizations where considerednecessary. The analysis and the results of this investigationwill be reported in future publications.

V GloMo ’97 Demonstration

In July, 1997, an RDRN testbed was demonstrated at the an-nual DARPA GloMo meeting in Long Branch, New Jersey.The configuration featured an RDRN network prototype in aminimal configuration (i.e., one Edge Node (EN) and one Re-mote Node (RN)). The demonstration had four goals:


1. demonstrate the orderwire system for network configura-tion and control,

2. show integration of wired/wireless ATM technologies,

3. demonstrate end-to-end heterogeneous internetworkingIP over ATM/WATM, and

4. show interoperability with other GloMo participants andthe Internet at large.

Figure 10 illustrates the configuration for the internetwork-ing demonstration. The RDRN testbed has been highlightedfor clarity purposes. The first three goals are demonstratedwithin the context of the RDRN testbed alone. The fourth goalextends the overall testbed to include a connection to the Uni-versity of California at Santa Cruz (UCSC) Wireless InternetGateway (WINGs) ad-hoc network and a local Internet ServiceProvider (ISP) [G+97].

WINGSRouter

WINGSRouter

INTERNET

258 Kbps Radio Link

Ethernet OC-3

Fore

SwitchATMFixed

RDRN

Node

RDRN

NodeRemote

RDRN Testbed

OC-3

RDRNEdgeNode

1 Mbps Radio Link

WINGSFixed Node(USC,Calif.)

Figure 10: RDRN Internetworking Demonstration

The hardware platform used for the RDRN testbed includedfour key components:

1. Fixed Node (FN): Desktop Pentium Dell 120 Mhz run-ning Linux 2.0.25 with a PCI Ethernet interface and aPCI Efficient Networks 155 Mb/s ATM interface.

2. ATM Switch: Fore ASX-200wg with 12 OC-3c ports.

3. Edge Switch (ES): Laptop Tecra 700 CT 120 Mhz run-ning Linux 2.0.25 with a PCI Efficient Networks 155Mb/s ATM interface, a PCI Wireless ATM interface, a se-rial connection to a GPS receiver, and a serial connectionto a 19.2 Kb/s packet radio.

4. Remote Node (RN): Laptop Tecra 700 CT 120 Mhz run-ning Linux 2.0.25 with a PCI Wireless ATM interface, aserial connection to a GPS receiver, and a serial connec-tion to a 19.2 Kb/s packet radio.

Configuration details for each of these demonstrations areprovided below.

1. Orderwire System for Network Configura-tion and Control

This exercise demonstrated the orderwire’s Network ControlProtocol (NCP) in operation between EN and RN. Previouslystored GPS time and position information were retrieved fromthe GPS receivers since the demonstration were performed in-doors. The GPS information was then disseminated over theorderwire network to establish a WATM link between the ENand the RN. All relevant information about the NCP proto-col was storaged in a Management Information Base (MIB)

created for the NCP and retrieved via the Simple NetworkManagement Protocol (SNMP)[Bus]. NCP MIB information,showing the relative connectivity state between the EN andRN, was displayed in a graphical network monitor.

2. Integration of wired/wireless ATM technolo-gies

The RDRN testbed featured a wired and wireless ATM seg-ment. The entire segment demonstrated standard ATM inter-operability between a fixed node (FN), an ATM switch, an ENrunning the Micro-Switch, and a RN. End-to-end connectiv-ity was setup between the FN and the RN using ATM virtualcircuits as previously indicated in section C. .

3. End-to-end heterogeneous networking IPover ATM/WATM

The configuration needed to establish end-to-end communica-tion between the FN and the RN was completed by assigningeach node an IP address and configuring their routes to forwardto their local ATM/WATM interfaces. Two basic IP-based ap-plications were demonstrated live over the pre-configured VCbetween the FN and RN:fingerandtelnet. A teleconferencingsession using the Mbone tools was also configured betweenthe FN and RN. The Mbone session was advertised using thesdr (Session Directory Tool) tool, live audio was sent usingthe VAT Mbone tool, and video stream was sent using the VICMbone tool. In particular, the quality of the video transmittedbetween RN and FN averaged a rate of ten to twelve framesper second.

4. Interoperability with other GloMo partici-pants and the Internet

During the GloMo meeting, the RDRN testbed was connectedwith the UCSC WINGs [G+97] network. WINGs is a mo-bile wireless architecture containing packet-radio nodes thatare easily reconfigured into wireless IP routers. The wirelessIP routers are designed to enable global IP Internet access toad-hoc networking environments. Just as standard IP routers,WINGs accomplishes its job at the IP level with the additionthat it must also adapt to the dynamics of an ad-hoc networkin which the nodes move frequently.

Connecting the RDRN testbed to the WINGs network wassuccessful. The WINGs network configuration consisted of amultihop network of WINGs routers. Each WINGs router isbasically an IP router (running FreeBSD) with a 10baseT lineand a radio interface. The WINGs that was connected to theFN, through an Ethernet hub, served as the border router forthe rest of the RDRN testbed.

The overall configuration basically treated the RDRNtestbed as a subnet of the major WINGs network. Routingtables were configured in both the WINGs border router andthe FN to learn about the existence of each other. Once thiswas complete, unicast IP packets could be sent from either theFN or RN in the RDRN testbed to any node in the WINGsnetwork and viceversa. Multicast packets could also be sentsince the WINGs network acted as a multicast bridge acrossthat domain. Further, since the WINGs network was also con-


nected to a local ISP, connectivity to the Internet at large wasavailable.

In one demonstration, a WWW session was run on the RNfor browsing the Internet. In a second demonstration, UCSCwas broadcasting an Mbone live video session from SantaCruz, California via Internet. The sdr Mbone tool running onthe RDRN RN detected the UCSC’s advertisement and dis-played the live video using VIC. As an added bonus, UCSCsetup a WWW homepage in which individual users on theRDRN testbed could control the images to be downloadedfrom the video camera on the UCSC campus. Therefore, bymodifying the direction of the camera via WWW, RDRN userscould observe different angles of the image displayed by theMbone VIC tool. Nonetheless, the quality of the video sentaveraged a very low rate due to the low channel bit rate fea-tured by the WINGs routers.

VI Conclusions

The RDRN architecture serves as a testbed for research intothe area of broadband wireless network systems with an em-phasis on rapid-deployment and wireless ATM technology.The first-generation system provided a demonstration of end-to-end ATM, over wired and wireless links and seamless in-teroperability with legacy IP networks. Preliminary mea-surements shows 1 Mb/s data throughput available to a re-mote node located as far as 10 kilometers apart from an edgenode and demonstrated the viability and usefulness of adap-tive protocol design in response to changes in the environ-ment. Further evaluation demonstrated live video and audiotransmissions at reasonable rates (10-12 frames per second forvideo). Work has begun on the second-generation system ofthe project to continue evaluating architectural issues and ex-ploring further research opportunities that are enabled by theavailability of our testbed.

Acknowledgments

We thank all the members of the RDRN-I project who helpedduring the design, implementation, and evaluation of the firstprototype of the system.

References

[A+96] P. Agrawal et al. SWAN: A Mobile MultimediaWireless Network.IEEE Personal Communications,April 1996.

[AB97] I. Akyildiz and K. Bernhardt. ATM Local Area Net-works: A Survey of Requirements, Architectures,and Standards.IEEE Communications, pages 72–80, July 1997.

[Alm] W. Almesberger. Linux-ATM. Available fromhttp://lrcwww.epfl.ch/linux-atm.

[AX25] IEEE. AX.25 Amateur Packet Radio Link-Layer Pro-tocol, October 1984.

[B+95] S. Bush et al. Rapidly Deployable Radio Networks(RDRN) Network Architecture. Technical Report

10920-09, Telecommunications & Information Sci-ences Laboratory, July 1995. Online version avail-able at http://www.ittc.ukans.edu/RDRN.

[B+97] S. Bush et al. A Control and Management Networkfor Wireless ATM Systems.ACM-Baltzer WirelessNetworks (WINET), Vol 3(No 4), 1997.

[Bus] S. Bush. Network Control Pro-tocol MIB. Available fromhttp://www.ittc.ukans.edu/ sbush/rdrn/ncp.html.

[C+95] J. H. Condon et al. Rednet: A Wireless ATM LocalArea Network using Infrared Links. InProc. FirstInt’l Conf. on Mobile Computing and Networking(MOBICOM ’95), November 1995.

[E+95a] K. Y. Eng et al. BAHAMA: A Broadband Ad-HocWireless ATM Local-Area Network. InProc. Int’lConf. on Commun. (ICC ’95), June 1995.

[E+95b] B. Ewy et al. An Overview of the Rapidly Deploy-able Radio Network Proof of Concept System. Tech-nical Report 10920-16, Telecommunications & In-formation Sciences Laboratory, April 1995.

[ETS95] ETSI Work Programme (EWP) DE-RES-10-08.Multimedia over Wireless ATM, July 1995.

[FR95] L. French and D. Raychadhauri. The WATMnet Sys-tem: Rationale, Architecture, and Implementation.In Proc. IEEE Comp. Commun. Workshop, Septem-ber 1995.

[G+97] J. J. Garcia-Luna-Aceves et al. Wireless InternetGateways (WINGS). InProc. IEEE MILCOM ’97,1997.

[LRS96] B. Leiner, R. Ruth, and A. Sastry. Goals andChallenges of the DARPA GloMo Program.IEEEPersonal Communications, pages 34–43, December1996.

[Mik96] J. Mikkonen. The Magic WAND: A wireless ATMaccess system. InProc. ACTS Mobile Summit ’96,November 1996.

[P+96] J. Porter et al. The ORL Radio ATM System, Archi-tecture and Implementation. Technical Report ORLTR 96.5, Olivetti Research Ltd, 1996.

[Rau97] K. Rauhala. Baseline Text for Wireless ATM specifi-cations.ATM Forum BTD-WATM-01.03, July 1997.

[SP96] C. Sparks and G. Prescott. A Flexible BeamformingDigitally Synthesized IP Modulator. Technical Re-port 10920-15, Telecommunications & InformationSciences Laboratory, April 1996.

[U+96] M. Umehira et al. ATM Wireless Access for Mo-bile Multimedia: Concept and Architecture.IEEEPersonal Communications, October 1996.
