Active Base Stations and Nodes for Wireless Networks

Wireless Networks 9, 37–49, 2003 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.

Active Base Stations and Nodes for Wireless Networks

ATHANASSIOS BOULISUCLA – EE Department, 56-125B Eng. IV, MC #951594 Los Angeles, CA 90095-1594, USA

PAUL LETTIERIBroadcom Corporation, 222 N. Sepulveda Blvd., Suite 1800, El Segundo, CA 90245, USA

MANI SRIVASTAVA ∗UCLA – EE Department, 7702-B Boelter Hall, MC #951594, Los Angeles, CA 90095-1594, USA

Abstract. Mobile and wireless network systems are characterized by a highly time varying and heterogeneous operational environment.For example, the wireless link bandwidth and bit error rate can change due to fading, mobile nodes may have different capabilities, andin the course of its movements a mobile node may visit base stations that provide different sets of services, protocols, and interfaces.Adaptability, in various forms and at various levels of the system, is a key to combating the inherent variability of a mobile environment.This paper describes our work on Active Base Stations and Active Mobile Nodes that use the general approach of active networking to allowrun-time application-specific customization of communication processing done on packets at the base station and the mobile end-nodes.This is accomplished by a software-hardware architecture that allows application specified reconfigurable hardware datapaths as well assoftware functions to be inserted in the path of specified packet flows at the base station and the end-node. The reconfigurable hardwaredatapaths as well as software functions, called Packet Processing Filters (PPF), can be uploaded or downloaded across the network, and theirbehavior controlled via parameter adaptation. Examples of adaptive capabilities enabled by Active Base Stations and Active Wireless Nodesinclude: (i) flow-specific adaptation of coding/decoding and packet lengths at the two ends of a time varying wireless link; (ii) adaptationof encryption/decryption on the wireless link according to changing locale and security environment; (iii) downloading a new or proprietaryMAC protocol from a base station to visiting foreign mobiles; and (iv) dynamically uploading mobile specified services to a base stationof a different service provider. We present the basic architecture and implementation approach of our system, and description of the initialsoftware/hardware prototype.

Keywords: active networking, wireless and mobile nodes, base station, reconfigurable hardware

1. Introduction

Mobile computing must overcome two major problems to re-alize its full potential. First, the wireless link is highly timevarying, particularly outdoors and when the end points aremoving at high speeds. Second, the operational environmentis quite heterogeneous so that a mobile node during the courseof its movements may encounter base stations that providedifferent services, protocols, and interfaces.

1.1. Adaptability is the key

An important generic mechanism for combating the vari-ability and heterogeneity present in a mobile environment isadaptability. Indeed, adaptability may be present in many dif-ferent forms and at many different levels in a wireless net-work. At the lower levels adaptability requires the commu-nication and protocol processing to be dynamically modified,either by updating algorithm parameter values, or perhaps byeven changing the computation structure of the algorithm.

Adaptive communication processing and link protocols,such as adaptive equalization and adaptive error control, areused to maintain robust performance in the presence of wire-

∗ Corresponding author.

less link impairments such as fading and multipath. Adapt-ability can also be used to improve energy efficiency. Forexample, [14] describes a hybrid FEC-ARQ error controlmethod where for each packet flow a possibly different hy-brid combination of an ARQ protocol and a FEC code is cho-sen depending on the Quality of Service (QoS) requirements,and the combination itself is adapted via QoS renegotiation asavailable effective link bandwidth changes.

Adaptability is also useful at higher levels of a mobile sys-tem [12,18]. A base station needs to accommodate the diversemobile nodes with differing capabilities that may visit it, anda mobile node needs to be able to accommodate changes inavailable services and protocols as it moves to new base sta-tions. For example, a base station may download an appropri-ate MAC protocol to a new mobile entering its service area.As another example, a mobile may upload and instantiate acustom transcoding function at the base station to transcodeor scale an incoming multimedia packet stream according tothe user interface capabilities of the mobile.

1.2. Our approach

Adaptability requires run-time, application-specific custom-ization of packet processing at the base station and the end-nodes. Appropriate architectural support is necessary for this.

38 BOULIS, LETTIERI AND SRIVASTAVA

Figure 1. Basic framework and motivational examples.

The approach adopted in our work is based on a form of ac-tive networks [21]. It allows users at the communication endpoints to program the base stations, and the end-points to beprogrammed by the network, thereby customizing and adapt-ing the computation that is performed on packets at either endof a wireless link.

Our system architecture consists of Active Base Stationsand Active Wireless Nodes where application-specified cus-tom processing can be done on packet flows. The packetprocessing is done using flowgraphs composed of PacketProcessing Function (PPF) entities. The PPFs are imple-mented in software (e.g., Java) or hardware (rapidly recon-figurable datapaths inside Field Programmable Gate Arrays(FPGAs)). The hardware reconfigurability distinguishes ourapproach from conventional active networking, which hasbeen based on programming in software, typically using mo-bile code technologies such as Java. Unfortunately, this soft-ware computation is invoked whenever a packet needs to beprocessed, considerably slowing down the packet forwarding.The use of rapidly reconfigurable hardware eliminates thisperformance bottleneck for functions that are implemented inhardware.

Unlike general active networks we choose to restrict theactive enhancement to the last hop of the network (i.e., thebase station and the mobile node) since this is where adapt-ability is most needed in wireless and mobile environments.We also wanted to incorporate our design into the existinginfrastructure as easily as possible. By restricting active en-hancements to the last hop, we only need to install our soft-ware and possibly reconfigurable hardware at the base sta-tions and nodes.

Figure 1 illustrates our concept with the use of two exam-ples. In the first one an active node enters an insecure envi-ronment. Fortunately, Base Station 1 (BS1) is an active basestation so the node can upload its own encryption algorithmin the form of a PPF. The particular PPF encrypts all packetsdestined for the node before they go into the air. The activenode can periodically change the encryption algorithm to op-timize a security overhead tradeoff. In the second examplethere are two mobile nodes, one active and one regular. Theactive node runs the latest version of an application whereasthe regular node runs an older one. The active node wants totalk to the regular node but without sacrificing the advantagethat the transmission of version 2 (the newer version) data has

over the wireless channel. It just has to upload a transcoder tothe BS2 to solve the problem. The active node can now senddata of version 2; BS2 will execute the transcoder and trans-mit version 1 data to the regular node. Further, if the secondmobile node was active as well, one could simply downloadthe transcoder directly to the destination mobile, allowing alltransmissions through the air to be of version 2 data.

Another important thing to notice here is that apart fromthe improvement one can get in the link quality using adaptivetechniques, the mobile nodes are no longer dependent uponthe base station’s administrator to provide them with new ser-vices. As long as the base stations are active, the designersof different mobile node products may simply develop PPFsto provide new services and protocols, thus facilitating thedeployment of new technologies. For example, the manu-facturer of a new ultra-portable ultra-low-bandwidth mobilenode with limited display capabilities would simply arrangefor the node to upload to the serving base station a PPF thatwould reformat incoming images to fit to the restricted dis-play. This would speed time to market as compared to thecurrent situation where the introduction of such a product willrequire a priori enhancement of the network media formatstandard.

2. Related work

In the last years there has been increasing interest in the areaof active networking. There are papers that explore the gen-eral field, proposing architectures as in [3] and [21]. Othersgive more specific applications, as in [1]. Of course, all thiswork acts as a pool of ideas in this field. There are projectshowever without the word “active” in their titles that are moreclosely related to our work largely because they are workingin the wireless mobile environment and, therefore, share ourmotivations.

Sudame and Badrinath with their work in TransformerTunnels [19] create a packet filtering mechanism that trans-forms packets at one end of a link and inverse transformsthem at the other end. The whole procedure is transparentto the applications, though there is an application that de-fines and creates the tunnel. The target environment is thewireless link, and the purpose is to improve the link qualityby application-independent coding. Thus, all packets from

ACTIVE BASE STATIONS AND NODES FOR WIRELESS NETWORKS 39

any application are subject to the tunneling mechanism al-though there is nothing inherent in the implementation ex-cluding port-specific tunneling. The whole tunneling proce-dure is done in the kernel in the most efficient way, thus pro-viding great performance for a software based implementa-tion. But because of this approach, uploadable code modulesare not possible as only native code is allowed. The tunnelsare based in code that is created and compiled in the samenode. Of course the software could be expanded to trans-fer code among compatible machines but the target usage didnot need this feature. In a way, Transformer Tunnels are aspecial case of our architecture. The same group also devel-oped Gathercast [2,7], an adaptive, programmable way to ag-gregate data traffic in the Internet without changing any net-work protocols. This work was based on Transformer Tun-nels. Our architecture is also similar to a proposal from BellCore on adaptive data acquisition for dynamic distributed en-vironments called aggregation networks [17].

Another closely related effort is the General Purpose ProxyFiltering Mechanism by Zenel and Duchamp [23]. The au-thors are motivated by the same problems as we are and setthe same goals. Namely, to adapt the communication process-ing to improve link quality and have the ability to provide newservices or protocols on the fly in the mobile environment.The approach they take is different than ours as it includes aproxy server that is similar to our Active Base Station. Thedifference is that the proxy is a fixed host separate from thebase station. Their paper implies one proxy for an area ofseveral base stations. If the mobile moves to another base sta-tion the data still needs to go through the proxy to be filtered.That means modifications in the mobile IP protocol, so thatthe data goes through the proxy in any case. But if we aretrying to enhance the communication quality, the extra delaymay minimize the benefits we can get from the filtering. Thepaper provides some interesting applications where the designcan be useful.

Finally, we wish to refer to work related to the use of re-configurable hardware in active networking applications, butappeared after our original submission of this manuscript.

The first one is IMEC’s Service Provisioning through Net-work Reconfiguration [9–11]. The second one is DynamicHardware Plug-ins (DHP) [20]. Both efforts have done con-siderable work towards software/hardware design, trying toabstract the hardware, aiming at network usability acrossmany platforms, while at the same time accepting the limi-tations of current FPGA devices.

3. Architecture

Our architecture is packet based – all processing is done onpackets that are captured as they go from the IP layer to theradio or from the radio to the IP layer (i.e., incoming and out-going packets at the network layer are available to the PPFs).This is not to imply that the processing is done at the net-work layer, or that the processing is relevant only to networklayer issues. The packets at the network layer include all in-formation of the higher layers (e.g., the transport layer, theapplication layer) and this information can be used and/or al-tered by the PPFs. Only the packets that need to be processedby PPF flowgraphs are captured. The process is completelytransparent to the application that receives or produces thesepackets. In that way one can make an old application func-tional in a new environment without modification, simply byinstantiating an appropriate PPF flowgraph somewhere alongthe packet flow path.

3.1. Basic structure

As figure 2 shows, the packets that are captured go througha network of PPFs. The structure of the network is con-stantly open to modification as new PPF flowgraphs may beinstantiated and old ones terminated. The instructions to in-stantiate or terminate a flowgraph originate at remote sites(a remote site is a mobile node or a base station, other thanthe node/base station which is currently executing the PPFs).These instructions include information regarding which pack-ets to capture and process with a particular PPF flowgraph

Figure 2. Basic architectural structure.


Figure 3. An example of flexibility.

along with the description of what the PPFs do. While the re-mote site decides how the PPFs are set up, the actual process-ing of the packets is done locally on the node accepting theinstructions.

Residing at the entrance to the PPF network is a classifierentity. Its duty is to determine which flow a packet belongsto, and consequently the PPF flowgraphs that should processthis packet. This determination is made by examining TCP/IPheader information, such as the destination and source IP ad-dresses and TCP port numbers. At the end of the PPF networkis the collector, which as its name implies, collects processedpackets from all the flows and serially writes them back to thecapturing entity, where they can continue along their normalroute to the radio or the IP layer.

This architecture provides code reusability since a PPF canbe used in many PPF flowgraphs, and is, therefore, quite flexi-ble. This not only means that one can use previously uploadedcode without the need to upload again, but more importantlyalso implies that one can use PPFs defined by other nodes. Inthis way, a mobile node has access to a large library of PPFsbeyond what it carries: PPFs that are predefined in the basestation and PPFs that belong to other nodes that have grantedpermission to use.

It is also worth noting that a PPF has the general form of anm-input n-output function. This simply means that a PPF cantake input from many different streams of data coming fromother PPFs or the Classifier, perform a collective function onthem and then produce many outputs, possibly different or thesame, which can pass along to other PPFs or to the Collector.Defined in such a way, the PPFs provide a powerful compu-tation model. Further, the interconnection of many PPFs ina PPF network makes the computation model efficient by al-lowing incremental changes and code reusability.

All these features can be better understood through an ex-ample. Suppose that one wants to perform some processingon an incoming data stream and that this kind of processinghas four subtasks called A, B, C and D. A is first performedon the data then its results are taken by B and C which canrun in parallel. In turn, their results are taken by D and theyare combined in some way. Of course it would be possibleto define one PPF that completes the entire process, perform-ing tasks B and C as threads in parallel or even serially. Butsuppose that task B is very complex as an algorithm and onedoes not want to devote time and resources to implement it, oreven worse, it is a proprietary algorithm and its source code isunavailable. By making use of our architectural features onecan devise the PPF flowgraph that is shown in figure 3. If B is

already present on the active node one can simply incorporateit in the flowgraph.

The Controller is another important entity. It communi-cates with remote sites, accepting uploadable functions andfunction parameters. When the Controller receives all in-formation from the remote site (i.e., description of any newPPFs, how to connect PPFs in new or existing flowgraphs,and what kind of packets to capture), the Controller instanti-ates the new flowgraph and informs the capturing mechanismto add new packet types to the capture list. The Controllercan also terminate the execution of a PPF flowgraph when in-structed, or after a suitable period of disuse. Other importanttasks that the Controller executes are security monitoring, au-thentication and library management.

3.2. Software/hardware integration

The preceding sections have provided a general descriptionof a PPF as an uploadable algorithm that is executed on theactive node and operates on packets. This section looks at thePPFs in detail. In our system a PPF could be one of (a) aprogramming language code fragment that is executed on theactive node’s CPU, (b) a byte-code that is used to programthe reconfigurable hardware present in the node, and (c) func-tion calls to a particular API to program the reconfigurablehardware.

For instance, one could write:

new PPF <name> (in_16bit <name1>out_16bit <name2>) {new 16bit <temp>new adder(<name1>, <name1>, <temp>)new shifter(<temp>, <name2>)}

This code would define a new reconfigurable hardware PPFwith one input and one output that would add the input toitself then shift the result and give it as an output. The Con-troller would call the proper functions from the API to per-form the actual instantiation of the hardware datapaths.

While the architecture is open to all these possibilities,there is a performance versus flexibility/universality tradeoff.There is a definite performance advantage for the hardwareoption, but at a cost of introducing restrictions on what maybe considered implementable functions. Hardware functionswill have to be of low complexity in their flow control, andideally should consist largely of operations that are easily im-plemented on FPGAs, such as simple bit-manipulation opera-tions. Furthermore, without knowledge of the specifics of thereconfigurable hardware or the format of the byte code one isrestricted to a simple API.

On the other hand, to achieve maximum flexibility and uni-versality, one could use a software-based approach. The Javaprogramming language is a particularly attractive tool for this,but then the PPFs will reside in the user space and their per-formance will be much slower than in the hardware case. TheController may also be implemented in Java for reasons of


Figure 4. Execution of PPFs in different levels and interconnection between them.

universality and ease of programming especially in network-ing, but again this will cause performance to suffer.

Another option would be to have the PPF in the kernel.That would be faster than a user-space Java PPF, more flex-ible than a hardware PPF in the computations that it can do,but less universal than a Java based PPF. The kernel-basedPPF will have to be executed in native code so that one wouldhave to rely on PPFs already available in the library. Anotherapproach can be to describe a PPF using many descriptionsand let the controller decide how to implement the PPF ac-cording to available resources, time constrains, etc.

At this point, one might ask: “Why do we need hard-ware based PPFs? Is it not enough to run the PPFs on veryfast processors?” First, there are functions needed to be per-formed on data steams that are too complicated, thus intro-ducing a considerable amount of delay, or they just have realtime constrains. An example of the later case would be aMAC protocol. Software running on the node’s main proces-sor rarely guaranties real time constrains and cannot finishas fast as a dedicated hardware implementation. Even if asoftware-based PPF could meet the delay or any other perfor-mance metric imposed by the data stream, it does not meanthat a software implementation would be the most energy ef-ficient. Running multiple fast processors in a mobile node ismost certainly a bad idea when one can achieve the same per-formance with a much smaller (i.e., much less power hungry)piece of reconfigurable hardware. So to answer the earlierquestion regarding the value of hardware PPFs, they are cer-tainly worthwhile since they may outperform software PPFsboth in terms of speed and energy efficiency.

Figure 4 shows how these different implementations fitinto our architecture and how they may efficiently collabo-rate. The arrows indicate packet movement.

To efficiently use resources, part of the Classifier function-ality should be integrated in the Capturer. A captured packetthat is destined for a hardware PPF should be passed directlyto the reconfigurable hardware, rather than first to a classi-fier mechanism elsewhere in software. The classification as“a hardware bound packet” ought to occur immediately insidethe Capturer. The same holds for kernel PPFs. One shouldnot copy the packet in the user space only to copy it back inthe kernel. If a packet flow is processed by a flowgraph of

PPFs where some of them are implemented in hardware andsome in software, one wants the most efficient communica-tion among them. A good way to achieve this is to have somememory in the reconfigurable hardware that is user-memorymapped. This way the software PPFs can access the semi-processed packets without any superfluous data transfers.

It should be noted here that a Java based PPF is an arbitrarycode fragment at its core. As such it has great freedom. Forexample it can open a communication stream with the remotesite through which it can get feedback about the conditionof the channel. The code that provides this information isactually part of the PPF, so one can have distributed PPFs ina way. This great freedom results in a number of securityissues.

3.3. Security

Firstly our architecture needs to ensure that a node can onlyinstantiate a PPF flowgraph for packets that are destined for itor are produced by it. Since all useful applications of ActiveBase Stations and Nodes fall into this category, no flexibilityor performance compromise is being made. The policing taskfor this security restriction is assigned to the Controller. Thequestion is how does one know the source of the PPF instanti-ation commands. Currently we rely on the IP source addressof the packets that carry the commands. However, this ap-proach is open to IP address spoofing attacks. In a secure,stable implementation of our architecture one would have toincorporate an authentication mechanism to solve this prob-lem, perhaps using IPsec.

A second issue is the proof of the code itself. It shouldnot be able to access the memory of another application oranother PPF. As a general rule one could say that maliciouscode should have the least effect on other applications (e.g., itshould not be able to hog the resources of the system). Gen-erally this is a difficult problem when one considers a genericmobile code scheme. Fortunately, the Java language providesa secure sandbox environment were the PPFs could execute.The security model of Java is one of the reasons that it is wellsuited to our needs.

A third issue is privacy. A user space application shouldnot be able to read the buffer of the capturing entity. To ensure


this, a signature is provided with every call to the packet readfunction.

All these security issues become less severe when one con-siders hardware implementation of PPFs. There the resourcesare under better control, virtually eliminating most securityissues. A PPF will be assigned its own space on the FPGAmaking it impossible to interact with other PPFs. There isstill the problem though, of PPFs doing permanent damage onthe hardware part they are using. For that reason one wouldneed a tester that will check the reconfiguration bit-stream ofa hardware PPF (that is the equivalent of the mobile code fora software PPF) for hazardous reconfigurations. The maintask that will have to perform will be to check that no twooutputs are electrically connected together. In principle sucha checker is easy to write given appropriate details about theFPGA device.

Another set of security problems arises when one consid-ers the “library” capabilities of our scheme. Which node ispermitted to use a PPF other than the one that loaded it? Howdoes one ensure proper usage of the PPFs? There are twoapproaches that are implemented in our design. In the firstone the loader of a PPF defines a list of nodes that can haveaccess to the PPF (i.e., will be able to instantiate it in theirown PPF flowgraphs). Then the problem reduces to that ofauthentication. The second approach is to require a key eachtime someone tries to incorporate the code of a PPF. The in-terested node should acquire the key from the owner of thePPF. In this case one has the problem of snoopers, so that onehas to have a secure key distribution mechanism. Anotherproblem might be that the owner is not accessible any more,making it impossible to get permission.

3.4. Resource management

It is clear that the PPFs will be executed in a resource-constrained environment. The area of the reconfigurable hard-ware is limited and so is the processing power of the CPU.This means that an active node or base station cannot blindlyaccept every request for a PPF flowgraph instantiation. A re-source management mechanism is needed. In hardware this iseasier to achieve. All hardware PPFs have their own physicalspace, so their performance is not affected by other instanti-ated PPFs. A newly instantiated hardware PPF will only re-duce the amount of free space available in the reconfigurablehardware. In order to apply some admission policy, an activenode should at least keep track of the free space available inthe hardware, as well as the quota of the hardware space usedby each remote site. When a request to instantiate a new hard-ware PPF arrives at an active node, the system should look atthe quota occupied by the specific remote site and the totalfree hardware space remaining, and make a decision. For ex-ample, if a particular remote site is using a large fraction ofthe hardware space, a new request would be denied, as we donot want a particular site to hog the hardware resources. Insoftware, resource management gets more complicated as aninstantiation of a new PPF affects the execution of other PPFs.It is a difficult problem to estimate how much of the compu-

tation power a PPF uses, and based on that and some simpleQoS parameters from the already instantiated PPFs try to de-cide on the admission of a new PPF flowgraph. The manage-ment of software PPFs becomes feasible, if the underlying op-erating system is a real-time operating system (RTOS). Thenwe can use the capabilities offered by the RTOS (e.g., guar-anties on task completion times) to provide QoS to the soft-ware PPFs. The PPFs will only need to specify simple QoSparameters like the maximum delay for processing a packetand the minimum bandwidth sustained by the PPF.

4. Implementation

This section describes the first prototype implementation ofour architecture. In section 3.1, the software part is discussedemphasizing on the controller and software-based PPFs. Insection 3.2, it is explained how hardware PPFs are imple-mented and how they are made seamlessly interoperable withsoftware PPFs. The current implementation is PC-based. Themain reason for this choice was ease of development. TheActive Base Stations and Nodes are desktop and notebookPCs that are running our software. They are equipped withLucent’s WaveLAN radios for their wireless interface. Anoff-the-shelf PCI card carrying a reconfigurable FPGA wasadded in a desktop PC to enhance it with reconfigurable hard-ware capabilities. The PPFs are running either in the mainCPU (in user mode) or in the hardware of the reconfigurableFPGA.

4.1. Software

All of the software is Java code running in the user space withthe exception of the capturing mechanism. The latter is imple-mented as a modified WaveLAN radio driver (written in C).The functionality of the driver was altered so that as packetscome in from the radio and the IP layer, they are examinedto determine whether they should be captured and placed in abuffer for later reading, or if they should continue along theirroute unobstructed. The decision is made based on a list ofdestination and/or source addresses and ports updated by thecontroller. Capture occurs when a match is found. There isalso the capability for a user process to write packets to thedriver destined for the IP or radio layer.

The Java-based software consists of two parts. The first isthe Active Enabler (AE), which runs in each node or base sta-tion that we want to be active. The second is the PPF Loader(FL), which runs in any remote site and provides the ActiveEnabler with any needed code or instructions on how to con-nect the PPFs and on which packets to capture. In short, theFL provides all information needed to instantiate or terminatea PPF flowgraph.

The AE consists of n+3 threads running in parallel, wheren is the number of PPF flowgraphs instantiated. One threadcorresponds to each PPF flowgraph, while the three remain-ing threads are the Controller (accepting messages from re-mote sites and starting new threads as needed), the Classifier


Figure 5. Hardware PPFs in a PC environment.

(for reading the packets from the modified driver and direct-ing them to the right flowgraph), and the Collector (for col-lecting the processed packets and writing them back to themodified driver). Proper consideration was given to the syn-chronization of collaborating threads and the fair handling ofCPU resources.

PPFs are defined as Java Classes. They have fields tostore the PPFs for the next level of processing, as well as amethod called “filter_packet” where the actual PPF process-ing is done. A PPF can have an arbitrary number of nextlevel PPFs. Apart from the definition of PPFs, one needsa way to describe PPF flowgraphs (i.e., a way to combinePPFs together and start the processing of selected packets).To achieve this in our system, one has to define a Class withthe reserved name “Start”. The role of the Start Class is todefine a specific PPF flowgraph, instantiate the PPF Classes,and start the processing. In order for the AE to start executionof a PPF flowgraph, a well-known code entry point has to bedefined. This role is played by the reserved-name function“run_me”, which is defined inside the Start Class. As an ex-ample, imagine that we need to get packets and process themfirst with PPF Filter1, followed by PPF Filter2, and then givethem to the Collector. The following code should be includedin the run_me function:

Filter2 f2 = new Filter2(sink);Filter1 f1 = new Filter1(f2);for (; ;){f1.filter_packet(source.get_packet());}

When a new PPF is instantiated, the next level PPF ispassed as a parameter. Therefore, in the above code frag-ment, the f1 PPF gets packets from the source, processedthem, writes them to f2, and then f2 processes them andwrites them to the sink. “Sink” and “source” are objectsthat allow the thread to communicate with the Collector andClassifier threads, respectively. More complex examples withmulti-input and multi-output PPFs are available in [4].

Note that an interesting and useful property of Java Classesis that they can be loaded over the network. Therefore, theonly job that the PPF Loader has to do is to define the PPF

Classes and the Start Class, and then transmit them to AE(recall that the structure of the PPF flowgraph is containedin Start Class). Upon arrival at the AE, the Classes are dy-namically loaded by a function. After the Classes are loaded,the AE searches for a Class named “Start” and executes its“run_me” method into a new thread. The AE also passessource and sink as parameters to allow the thread to commu-nicate with the Classifier and Collector threads.

4.2. Hardware

The second step in the implementation procedure was to en-hance the design to incorporate hardware-based PPFs, and wewanted to do it as seamlessly as possible. For that purposewe used an off-the-shelf board with a Xilinx 6200 family run-time reconfigurable FPGA chip. This particular FPGA has theadvantage of incremental reconfiguration as one can accessthe reconfiguration registers in random order. This kind offunctionality is crucial if one wants fast, on-the-fly, reconfig-urable hardware. The particular board, named H.O.T. Worksand made by Virtual Computer Corporation, sits on the PCIbus of a PC and a device driver is provided to supply the ba-sic interface with the host machine. The board, apart fromthe 6200 FPGA, has 1 Mbyte of SRAM and a Xilinx 4013FPGA which implements the PCI interface and the driver’sinterface. A model depicting how the H.O.T. Works board isincorporated in the system is shown in figure 5.

In order to better understand the way we used this boardinto our architecture we will present the basic parts of its in-terface. The single, most important thing to mention is thatevery reconfiguration bit of the 6200 part, every state bit of aCLB in the 6200, and every SRAM byte, is memory mapped.The control registers of the board are mapped into the I/Ospace. So by performing simple writes and reads into mem-ory or I/O space one has full access to the board. In additionto these capabilities, if one has the reconfiguration bit streamone can reconfigure the 6200 FPGA using a single commandprovided by the driver making the whole procedure very easy.The 6200 architecture also provides an easy way to accessuser defined registers inside the reconfigurable hardware. Forinstance, these registers could be the input and output regis-


ters of a PPF and with a memory read or write from the CPUone can access them.

Let us consider the processes of instantiating hardwarePPFs. The same basic infrastructure as with the Java basedController is used. The first thing that happens is that theActive Node receives the Start class and executes its run_mefunction. All information on how to reconfigure the 6200FPGA and then interact with the design (i.e., the hardwarebased PPF) resides in the run_me function. The first thing thatrun_me function does is to insert the PPF into the hardware byreconfiguring part of the 6200 FPGA. It achieves that with theuse of the driver function mentioned before and the reconfigu-ration bit stream, which is contained as a data structure in theStart class. There is a small complication here. Normally thebit stream gives a very rigid description of the design, specify-ing the exact location of the CLBs used. But there are pofxs-sibly many different PPFs inside the FPGA and the node thatproduces the bit stream could not possibly know what PPFsexist in the FPGA at a particular moment and which cells arethey occupying. The solution has to have the following form.The bit-stream is produced in some machine with the propertools but now the cell positions in this bit-stream are relativeones, not absolute. What this means is that the bit-stream fora PPF must be relocated to the appropriate cell position at thetime of PPF instantiation. This is done by adding offsets sothat the new PPF does not overlap with any existing ones inthe FPGA.

After the design is correctly instantiated into hardware onemust interact with it, i.e., provide input data and get the out-put data that are produced. Two main methods are used toachieve this. The first one is based on input and output reg-isters in the PPF design. These registers are created whiledesigning the hardware PPF, and will be part of the reconfig-urable hardware. Recall that one can access such registers bysimple memory reads and writes. There are several complica-tions with this approach. If one writes an input register, howdoes one known that it is ready (i.e., its contents are read)to be written again. When are the output data ready? Thisis a synchronization problem between the software part thatreads and writes data in the hardware of the FPGA and thehardware part that does the actual processing on the data. Tosolve this problem we are using lock bits in the input and out-put registers. Once the software part writes some data in aninput register, it is not allowed to write again unless the lockbit is cleared by the hardware. While reading from an outputregister, the software part discards any data that do not havetheir respective lock bit set properly. Another problem is thatone would like to support the notion of PPF reusability. Thismeans that different data streams from different PPF flow-graphs may use the same PPF in an interleaved way. A prob-lem is how to multiplex the input data and demultiplex theoutput data. Again the solution comes in the form of extrabits in the input and output registers. More specifically, weuse enough bits to identify each different flow of data. Whenwe write data into the input registers we add the informationof the particular flow of the data (i.e., an id-flow#). This in-

formation is propagated to the output registers, so when weread them we know which flow the data belongs to.

The first method of interacting with the hardware is a fastand clear one but it comes with one shortcoming. If the PPFhas to get many bytes in input data before it starts the compu-tation, or more importantly the amount of data is dynamicallychanging over a wide range, then the first approach resultsin large and unwieldy designs that make poor use of the re-configurable hardware available. This is where the SRAMavailable on the board becomes very useful. Instead of keep-ing the data into user defined registers that devour hardwarespace, we keep all of the input intermediate and output datainto the SRAM. One would need to define circular buffersfor input and output data. Their head and tail pointers willbe controlled and monitored by the software or the hardwarepart of the design. This method requires some extra things tobe implemented in the reconfigurable FPGA. First one needsa memory access arbiter. As the software and hardware try toaccess the memory at the same time, there should be an entityto decide on which is accessing the memory and at what time.Further, every PPF that uses the SRAM should also includea memory address generator in its hardware. The extra hard-ware needed makes the choice of a proper interaction methodwith a hardware PPF a case-by-case study.

Another important issue in the case of hardware PPFs isthe data transfers. As shown in figure 5, the data are receivedfrom the radio, passed to a place in the kernel memory, fromthere they are copied into the user space and finally throughthe PCI bus the end up in some input registers in the recon-figurable hardware. After their processing is over they followthe inverse route. Note that these data transfers are particularto the way we chose to implement our architecture, namely ina PC environment with an off-the-shelf reconfigurable board.This is, by no means, the optimal solution. In the future worksection we propose a better way to implement our architec-ture. Note also that in our current implementation the dataare always copied to the user space. Whereas this might be anunwanted overhead, it is not the main part of the data transferdelay and it was not worth the extensive alternation of the cap-turing entity for the time being. Besides, many times the dataare needed to the user space to perform some preprocessingon them before they are sent to the hardware. A good exampleof that is shown in one of the experiments we conducted.

5. Experiments

In order to evaluate the initial implementation of our architec-ture, an experimental approach was taken. Two experimentswere conducted. These are described in sections 5.1 and 5.2.A series of experiments were conducted in order to measureperformance characteristics, like delay and bandwidth, of ourimplementation. These are described in section 5.3.

5.1. Testing the basic idea

The first experiment was done in order to verify the correct-ness of our software implementation and to give us an indica-


Figure 6. Experimental hardware setup.

tion of efficiency and performance. With this experiment wemerely wish to show that it is feasible, from a performancestandpoint, to construct software based PPFs for certain typesof applications and filtering.

The setup for our first experiment consists of two nodescommunicating through a wireless link. One node is runninga program that reads the data of an audio file and sends it tothe other node. The other node runs the server side of the ap-plication that waits for audio data and plays it in real time. Inthe presence of varying amounts of noise, some packets arecorrupted as they are transmitted over the channel and there-fore are discarded. According to the packet size that our ap-plication uses, we may have considerable chunks of data lostand as a result experience a great deterioration in the percep-tion of the sound.

Suppose the application is designed for wired networks,such that it uses large packet sizes to make efficient utiliza-tion of resources. This, however, is not a good tactic for ournoisy wireless environment. With the active technology, wecan keep the application as is, but make it work satisfactorilyin the wireless environment. We do this by first making thenode that sends the audio packets active. Next, supply theother node with a suitable filter that it can upload to the activenode. The filter simply fragments large packets according to aparameter that can be set on the fly. Now the packets are madeinto smaller pieces before they are transmitted. The amountof fragmentation (a filter parameter) can be dictated remotelyby the other node according to the perceived quality of thesound or any other metric.

5.1.1. HardwareFigure 6 shows the experimental hardware used. Very simply,two PC-Card ready PC’s with Pentium processors, each run-ning Linux kernel version 2.0.30 and PCMCIA card servicesversion 2.9.5 are placed in a room with a noise generating de-vice capable of generating and transmitting into the air whiteGaussian noise in the 2.4 GHz band. WaveLAN 2.0 radiosfrom Lucent operating in the 2.4 GHz ISM band and con-trolled by the Linux operating system are used to make thewireless connection.

WaveLAN radios controlled by Linux were chosen forthis experiment largely because the source code of the Linuxoperating system (including the WaveLAN PC-Card devicedriver) is freely available and could be modified for our pur-poses. This allowed us to change the kernel WaveLANPC-Card driver so it can capture the packets of interest and

Figure 7. Fragmentation of a packet.

provide them to our filtering mechanism as well as allow thesoftware to write packets directly to the radio.

5.1.2. SoftwareNormally, the WaveLAN driver interacts with the TCP/IPsoftware also in the kernel. Callbacks are registered at cardinsertion time allowing the networking software to grab pack-ets from the radio on reception, or send them to the radio ontransmission, as well as to control various radio parameterssuch as Network ID (NWID) and frequency of operation (se-lectable within the 2.4 GHz ISM band). The modification ofthe original WaveLAN driver source code just adds the func-tionality of the capturer.

The audio client, which is written in C, opens a UDPsocket, creates packets of audio data and sends them in atimely manner. The packets have to be sent within some de-lay bounds (neither too slow nor too fast) for smooth audiooutput. The client, therefore, ensures that packets are issuedat the proper rate to coincide with the packet size. In the dataportion of the packet, the client puts a sequence number sothat the server knows what it is receiving. The server sideof the application (also written in C) just writes the receivedpackets to the audio device. If it discovers that a packet is lost(knowledge obtained by looking at the sequence number), itreplays the last packet.

The Java program that enables a node to be the AE is exe-cuted in the node that sends the audio packets. The Java pro-gram that describes the implementation of the filter and makesthe necessary actions to upload it (i.e., the FL) is executed onthe other node. The filter takes a packet and fragments it asin figure 7, which requires replicating all of the headers (i.e.,MAC, IP, UDP) and putting only a fraction of the data in thedata portion of the new packet. The size of the fraction is aparameter that can be changed remotely. That means that thefilter, which is actually executed on the node that sends theaudio data, is controlled by the receiving node. Another jobthat the filter has to do is to compute the new values of thelength and checksum fields in the IP and UDP header and setthem appropriately.

5.1.3. ResultsAs described above, the filter is not trivial. It incurs a memorycopy of 920 bytes, along with the execution of the checksumalgorithm ten times for every packet. Java, particularly theinterpreted version, is not the fastest programming languagefor performing such computations. Therefore, we expect sig-nificant delays in the packets.

When the application executes free of noise, the sound isclear. Applying our filter in the flow of the data makes thesound deteriorate somewhat perceptually, though not much.


The deterioration (if any) is due to the delay jitter our filterintroduces. When the application is operating in the presenceof noise, many (30%) 500-byte packets are lost and the soundbecomes unrecognizable without the filter. When we applyour filter, only 5% of the packets are lost (although the ab-solute number of lost packets is bigger than before, we trans-mit 10 times more packets). This makes the sound recogniz-able again. The architectural advantage we get from the filterovershadows any delay introduced by it. Note also, that whenthe filter is not needed, as when the channel is good, it couldbe terminated, and taken out of the path.

5.2. A more complex experiment

The second experiment was done in order to test our hard-ware/software design, show its flexibility and also give an-other useful example of Active Base Stations. In this exper-iment we implemented an on the fly gathercast mechanism.Gathercast [2,7], (as opposed to multicast) takes a number ofdata flows, heading towards the same destination and com-bines them or mixes them together into a single flow. Themixing is always dependent on the kind of the data we have.For instance we could get sensor data from various sourcesand average them together or we could get speech data fromvarious sources of a teleconference and mix the sounds to-gether. In the particular experiment we used data from dif-ferent sources (mimicking sensor data) that had the same des-tination, and averaged them. The term “on the fly” refers tothe fact that the destination dynamically decides whether ornot to perform a gathercast operation to the flows coming toit, and also that the number of mixed flows does not need tobe constant. If a new flow is created by another source it isautomatically mixed with the rest of the flows.

Our setup comprises several Unix machines (acting as thesources) connected through a wired network to a machinerunning Linux (the base station) and from there through aWaveLAN wireless interface connected to another node (thedestination). The base station is enhanced with the H.O.T.Works board to provide a platform of reconfigurable hard-ware, as well as the needed software components (like thecontroller and the capturer) to become an active base station.Every packet the sources send to the destination has to gothrough the base station. An application was built in Java tohelp us conduct the experiment. The application consisted ofseveral clients running on the sources and sending data to aserver, which was running on the destination node. The taskof the server is to find out how many different flows it is re-ceiving and average the data producing one final stream ofdata. The bandwidth used in the wireless link is n · B, wheren is the number of flows and B is the bandwidth occupied byone flow. Clearly, if we instantiate a PPF that does the aver-aging in the base station the used bandwidth over the wirelessbecomes B. The structure of the experiment shows the flex-ibility of our architecture. Recall that the number of sourcesis varying in time, which means that the number of inputs ofthe PPF and the PPF structure should change. More specif-ically, the PPF should check each packet to see if it is origi-

nated from a new source, and if this is true, it should updatea parameter that controls the number of inputs as well as thefunction that is performed on them. Doing all this in hardwarewould result in a huge design. It is far better to do such kindof preprocessing in software and pass the resulting parameterto the hardware.

Note that while performing this on-the fly gathercast, theend-to-end semantics are broken. In the particular experimentthis did not matter, as the data were UDP, requiring no acks.With a more complex transport layer protocol the PPF break-ing the end-to-end semantics should be aware of this and takeproper actions to prevent disturbing the balance in the trans-port layer, in other words try to artificially keep the end-to-endsemantics. For example, if we use TCP data in our experimentthe destination will produce only one ack (as it is receivingonly one flow). The mixing PPF will have to produce artifi-cial acks towards the sources.

5.3. Performance characteristics

The initial implementation prototype did not focus on per-formance. The issues of security, resource management andmost importantly the seamless interoperability among soft-ware and hardware PPFs were primarily examined. However,performance characteristics are presented for a sense of com-pletion. In this section, measurements on bandwidth achievedby PPFs, and delay introduced by PPFs, are given and brieflydiscussed. Two PPFs are examined: (1) an “empty” softwarePPF, and (2) the hardware PPF (along with its software com-ponent) used in the gathercast experiment.

The bandwidth measurements with the PPFs were com-pared against the bandwidth achieved without our system(i.e., without having any active enhancements thus withoutany packet processing). The standard network-performancemeasuring tool netperf was used to acquire the measure-ments. The measurements were also double-checked usingour own designed tool. All the results concerning bandwidthare presented in table 1.

We observe a decrease of 3.4 to 2.2 times in the effectivebandwidth when we use our system. Notice also that thereis no significant difference between the empty PPF and thehardware PPF.

In order to measure the delay that one packet incurs dueto our active system we timestamp it as soon as it is cap-tured and check it again when it is ready to exit our sys-tem and be passed for transmission to the radio. The de-lay is the difference between the current check time and thetimestamp. The real time measurements were achieved by

Table 1Bandwidth measurements.

Packet size “Raw” bandwidth Bandwidth using Bandwidth usingan empty PPF a hardware PPF

46 bytes 0.248 Mbps 0.072 Mbps 0.067 Mbps142 bytes 0.568 Mbps 0.190 Mbps 0.187 Mbps542 bytes 1.181 Mbps 0.472 Mbps 0.472 Mbps1042 bytes 1.398 Mbps 0.617 Mbps 0.617 Mbps


Figure 8. Gathercast performed in an Active BS.

using the special register that all Pentium processors have forthat purpose. The measurements have an accuracy of 5 ns.Again the two experiments with the empty PPF and the hard-ware PPF were conducted. The results taken for both caseswere very close. The average delay for 20 experiments and1000 packets per experiment was around 10ms. The firstpackets incurred large delays that rapidly deceased, reachingat a stable point of delays toggling between 12 ms and 4 ms.A thorough explanation for this rather poor performance canbe found in [4]. Here we are sufficed to say that the main rea-son for such large delays in our prototype implementation isthe kernel/user space transfers and the swapping of processesthat comes with them. This also explains the results obtainedby the bandwidth measurement experiments, namely signifi-cant degradation of bandwidth and no differentiation betweenlight-weighed PPF and heavy-weighed PPF.

6. A platform for an advanced active node

The PC-based prototype discussed in the previous sectionswas sufficient to demonstrate software/hardware integrationof PPFs, to illustrate the merits of adaptability in differentscenarios and even be used in some real-world experiments.However, it is not suitable to achieve high performance or en-ergy efficiency, mainly because all packets have to be routedthrough the processor and cross the kernel/user boundary evenif they are only destined for hardware PPFs. Recognizingthat this is a proof-of-concept prototype, one might hope fora more efficient instance of an active node or base station. In-deed, in this section we present a design for a wireless nodethat is used as a platform for a more efficient active node. Theparticular design is part of a larger project, which pursues ar-chitectural strategies for energy-efficient wireless multimedianodes [13].

In [13], two major strategies are identified for achievingenergy-efficiency in performance-demanding wireless mul-timedia nodes. The first one is aggressive adaptability inevery layer of the system, and the second one is proper intra-node dataflow. The first strategy is very important for us asit ensures that the design will make active networking pro-

visions (because this is the only way to achieve aggressiveadaptability in all layers). The second strategy argues that aCPU-centric design, which demands all data to share a com-mon bus and pass through the processor, will be inefficientboth in performance and in energy terms. An I/O-centricdesign is proposed, where the I/O devices can communicatedirectly without aid from the processor and dataflow-relatedprocessing is done in dedicated hardware. In this way theprocessor becomes a high-level controller that is inactive mostof the time. The processor is ready to intervene though whencomplex decisions are need to be made (usually at a per-linkbasis). The second strategy is important for our purposes as itensures high performance in the active networking solution.

Figure 9 shows a more concrete example of an efficient ar-chitecture for a wireless node. The intra-node router realizesthe I/O centric strategy by connecting I/O devices, the proces-sor, and the dataflow datapaths. The adaptability strategy isrealized by the run-time reconfigurable datapaths (for simple,frequent tasks) and the use of the processor (for complex, lessfrequent tasks).

To express this in PPF terms, hardware PPFs are going toimplement the simple and most frequent operations done onpackets, and the software PPFs are going to take over the mostcomplex operations where higher algorithmic flexibility is re-quired. More importantly, hardware PPFs are going to com-municate directly with the radio, not having to acquire/returnthe data to the processor crossing the kernel/user boundary, asin our first experimental prototype.

An instantiation of the architecture shown in figure 9 isthe Wireless Adaptive Network Device (WAND). WAND’simplementation is shown in figure 10. Note that the high-lighted run-time reconfigurable hardware is a Xilinx 6200FPGA. The off-the-shelf board used in our PC-based pro-totype has the exact same part. The processor is instanti-ated by a StrongARM SA-110 microprocessor, running a realtime operating system (µC/OS II). The processor controls theXilinx 6200 FPGA at a high level by managing the hard-ware PPFs (i.e., adding, deleting, replacing). However, thedata flowing through the hardware PPFs do not have to passthrough the processor unless they need to be processed by


Figure 9. An efficient wireless node architecture.

Figure 10. WAND’s implementation.

software PPFs as well. This sets the basis for high perfor-mance and energy efficiency.

7. Conclusions

In order to find the maximally adaptive way to combat thewireless link deficiencies and the heterogeneity of the mo-bile environment we propose the use of Active Base Stationsand Active Mobile Nodes. We define the notion of an up-loadable Packet Processing Filter as the central component ofour design. Our proposed architecture considers performance,flexibility, universality and security issues. These issues arerelated to the way we choose to implement our PPFs (i.e., inhardware or software). The first prototype of our architectureincludes both software and hardware based PPFs. The exper-iments we conducted to evaluate our first implementation ap-

proach showed its viability and the benefits one can get fromActive Nodes and Active Base Stations.

Acknowledgements

This work was supported by DARPA/ITO, NSF, and theUCLA School of Engineering and Applied Science.

References

[1] D.S. Alexander, M. Shaw, S.M. Nettles and J.M. Smith, Active bridg-ing, in: Proceedings of the ACM SIGCOMM’97 Conference, Cannes,France (September 1997).

[2] B.R. Badrinath and P. Sudame, Gathercast: The design and implemen-tation of a programmable aggregation mechanism for the Internet, in:Proceedings of IEEE International Conference on Computer Commu-nications and Networks (ICCCN) (October 2000).


[3] S. Bhattacharjee, K.L. Calvert and E.W. Zergura, An architecture foractive networking, in: High Performance Networking (HPN’97), WhitePlains, NY (April 1997).

[4] A. Boulis, Active base stations and mobile nodes for a wireless, mo-bile environment, M.S. thesis, University of California, Los Angeles,Electrical Engineering Department (1999).

[5] A. Boulis, P. Lettieri and M.B. Srivastava, Active base stations & nodesfor a mobile environment, in: Proceedings of the First ACM Interna-tional Workshop on Wireless Mobile Multimedia (WOWMOM’98) (Oc-tober 1998) pp. 31–37.

[6] A. Fox, S.D. Gribble, E.A. Brewer and E. Amir, Adapting to networkand client variability via on-demand dynamic distillation, in: Proceed-ings of the Seventh International Conference on Architecture Supportfor Programming Languages and Operating Systems (ASPLOS-VII),Cambridge, MA (October 1996).

[7] Gathercast, http://paul.rutgers.edu/∼sudame/gcast-dist.html

[8] J. Gosling and H. McGilton, The Java language environment, Sun Mi-crosystems White Paper (1995).

[9] Y. Ha, P. Schaumont, L. Rijnders, S. Vernalde, F. Potargent, M. Engelsand H. De Man, A scalable architecture to support networked reconfig-uration, in: Proceedings of IEEE ProRISC (November 1999) pp. 677–683.

[10] Y. Ha, P. Schaumont, M. Engels, S. Vernalde, F. Potargent, L. Rijndersand H. De Man, A hardware virtual machine to support networked re-configuration, in: Proceedings of the 11th International Workshop onRapid System Prototyping, Paris (June 2000) pp. 164–169.

[11] Y. Ha, S. Vernalde, P. Schaumont, M. Engels and H. De Man, Buildinga virtual framework for networked reconfigurable hardware and soft-ware objects, in: Proceedings of the 2000 International Conference onParallel and Distributed Processing Techniques and Applications, LasVegas (June 2000) pp. 164–169.

[12] T.D. Hodes and R.H. Katz, Composable ad hoc location-based servicesfor heterogeneous mobile clients, Wireless Networks, Special Issue onMobile Computing (1998).

[13] P. Lettieri, Architectural strategies for energy-efficient wireless multi-media nodes, Ph.D. dissertation, University of California, Los Angeles,Electrical Engineering Department (2000).

[14] P. Lettieri, C. Fragouli and M.B. Srivastava, Low power error con-trol for wireless links, in: Proceedings of the 3rd Annual ACM/IEEEInternational Conference on Mobile Computing and Networking(MobiCom’97), Budapest, Hungary (26–30 September 1997) pp. 139–150.

[15] P. Lettieri and M.B. Srivastava, Adaptive frame length control for im-proving wireless link throughput, range, and energy efficiency, in:Proceedings of IEEE INFOCOM’98, San Francisco, CA (29 March–2 April 1998) pp. 564–571.

[16] P. Lettieri and M.B. Srivastava, Advances in wireless terminals, IEEEPersonal Communications (March 1999).

[17] M. Little, A. Poylisher, A. Umar and S. Chamberlain, Aggregation net-works: efficient and adaptive data acquisition for dynamic distributedenvironments, in: Proceedings of the Third Annual FedLab Sympo-sium – Advanced Telecommunications & Information Distribution, USArmy Research Labs (February 1999).

[18] B. Noble, M. Price and M. Satyanarayanan, A programming interfacefor application-aware adaptation in mobile computing, in: Proceedingsof the Second USENIX Symposium on Mobile & Location-IndependentComputing, Ann Arbor, MI (April 1995).

[19] P. Sudame and B.R. Badrinath, Transformer tunnels: A frameworkfor providing route-specific adaptations, in: USENIX Annual Techni-cal Conference (1998).

[20] D.E. Taylor, J.S. Turner and J.W. Lockwood, Dynamic Hard-ware Plugins (DHP): Exploiting reconfigurable hardware for high-performance programmable routers, in: Proceedings of the 4th IEEEInternational Conference on Open Architectures and Network Pro-gramming (OPENARCH), Anchorage, AK (2001).

[21] D. Tennenhouse and D. Wetherall, Towards an active network archi-tecture, ACM Computer Communications Review 26(2) (April 1996)5–18.

[22] D. Wetherall and D. Tennenhouse, The active IP option, in: Proceed-ings of the 7th ACM SIGOPS European Workshop, Ireland (September1996).

[23] B. Zenel and D. Duchamp, A general purpose proxy filtering mech-anism applied to the mobile environment, in: Proceedings of the 3rdAnnual ACM/IEEE International Conference on Mobile Computingand Networking (MobiCom’97), Budapest, Hungary (26–30 Septem-ber 1997) pp. 248–259.

Athanassios Boulis is a PhD student in the Electri-cal Engineering Department at UCLA. He receivedhis MS degree from the same Department in 1999,and his BS degree from the Technical University ofCrete, Greece, in 1997. His current research inter-ests focus on distributed algorithms and protocols forwireless ad hoc sensor networks, as well as the de-sign of platforms to dynamically deploy such algo-rithms into the sensor network.E-mail: [email protected]

Paul Lettieri received a B.S. in electrical engineer-ing magna cum laude from Rensselaer Polytech-nic Institute in Troy, NY, in 1995. While pursuingthis degree, he did an internship with Pitney Bowesin Shelton, CT, designing and evaluating embeddedsystems. Then, funded in part by a MICRO fel-lowship, he did his graduate work at the Universityof California, Los Angeles, receiving a Master’s in1997 and a Ph.D. in 2000, both in electrical engi-neering. Dr. Lettieri is currently employed in the

Home Networking Division of Broadcom Corporation, where he is involvedin the design and development of wireless networking integrated circuits.E-mail: [email protected]

Mani Srivastava (Ph.D. Berkeley 1992) is an As-sociate Professor of Electrical Engineering Depart-ment at UCLA. Previously, he was at Bell Labo-ratories Research at Murray Hill, NJ, from 1992through 1996. At UCLA his research group Net-worked and Embedded Systems Laboratory(http:/nesl.ee.ucla.edu) conducts researchon various aspects of power-aware and wireless dis-tributed embedded computing systems. He has pub-lished over 80 papers, received five US patents, and

was awarded the Okawa Foundation grant (1998), the NSF CAREER award(1997), and the President of India’s Gold Medal (1985).E-mail: [email protected]

Documents

Active Base Stations and Nodes for Wireless Networks