A Modular Data Link Layer for Underwater Networks - CiteSeerX

A Modular Data Link Layer for Underwater Networks Jonathan Shusta, Lee Freitag and James Partan Woods Hole Oceanographic Institution Woods Hole, MA 02543 [email protected], [email protected], [email protected]

Abstract—A re-usable software architecture suitable for underwater acoustic networking research has been designed and an initial version developed and demonstrated. The core of the software is a modular data link-layer that includes medium access control (MAC) and methods for discovery, plus an interface to hardware-specific device drivers that connect to specific acoustic modems. The goal is to provide this common framework to the community as open-source, so that it can be used to speed up development and testing of new ad-hoc networks. The architecture can be described in several interfaces and adapters. Three interfaces represent portions of the data link layer (DLL) , logical link control (LLC), and MAC plus physical-layer control. The adapters include one for the operating system, a link protocol interface, and a protocol adapter. All of these interfaces and adapters are described, along with a reference implementation that includes the WHOI Micro-Modem.

away dependencies between the common conceptual components. The result is a structure that will allow insertion of different protocols for MAC as well as processes for neighbor discovery. To demonstrate the utility of the approach we have implemented a standard physical layer interface that works with the WHOI Micro-Modem. For MAC both ALOHA and MACA protocols have been written within the framework and we have demonstrated that both are interoperable with the underlying physical device using the same interface. The paper includes an in-depth overview of the software architecture and its mapping to network functionality, plus initial results of a simple ad-hoc network created as the initial implementation example.

I. I NTRODUCTION

II. P REVIOUS W ORK

Advances in underwater networking will accelerate if researchers are able to re-use software frameworks and interfaces to the physical layer as is done in terrestrial cabled and wireless networking. The most common development paradigm in use today is custom-written software that is normally not available to others to use as a starting point. In addition, network researchers that develop software targeted at a specific physical layer may have difficulty porting network software to other modems if the interface is not generalized with a driver to create a generic device. The goal of this work is to create a link layer that may be used to develop a complete ad-hoc network. Its main function is to provide an architecture that allows easy plug-in of specific link-layer functions such as medium access control (MAC) and modem-specific physical layer interfaces. The motivation for this approach is that link-layer technology in wireless sensor networks provides an inadequate basis for investigating new approaches to medium access in the acoustic underwater environment. An architectural framework is needed to provide such a development environment without introducing physical layer or operating system interdependency that subsequently reduce portability of applicability to other implementations. In addition, an open-source approach is used so that others can use the framework for applications or for underwater networking research and development. We subdivide the link layer into a set of modules to abstract

The Sensornet Protocol (SP) [1] provides a unified abstraction of a data link layer (DLL) to introduce a ”narrow waist” in the network stack. The SP interface mitigates link resource conflicts by lifting neighbor management and message pooling above the data link layer. Modular Network Layer (MNL) for Sensornets[2] introduces an overall architecture for sensor network protocols. It decomposes existing network protocols into components with interfaces to facilitate code reuse The Modular DLL (MDLL) presented here attempts to accomplish the same benefits as MNL below the ”narrow waist” of SP. III. A RCHITECTURE MDLL divides a DLL into a set of five modules and provides headers describing their five respective interfaces, which can be organized into two conceptual groups: stack interfaces and support interfaces. A sixth interface is provided for connecting the MDLL to SP or some SP-compatible uplink, the user application. An MDLL can be implemented in shared or static library form, or compiled directly into a monolithic application. No requirements on neighbor management are made. There is no requirement for a link layer address, as in SP. It is also agnostic to power-management schemes, which must be externally driven by the user application. There exist implementation

978-1-4244-2620-1/08/$25.00 ©2008 IEEE Authorized licensed use limited to: University of Massachusetts Amherst. Downloaded on July 30,2010 at 16:18:17 UTC from IEEE Xplore. Restrictions apply.

guidelines which must be well-defined in order to maintain agreement between modules on the semantic meaning of each interface method, but any standard will do.

buffer, the length of the buffer in bytes, source and destination addresses, and so on. Standardizing object attributes is beyond the scope of this work. IV. I NTERFACES

A. Interface Headers The architecture is described in the form of ANSI C headers to maximize speed, size, and portability. These define the interface methods for each component and a class containing the methods. Every interface method is expressed as a C function pointer, these are defined in interface headers. Each class is expressed as a C struct containing named pointers to the methods appropriate for that class. A pointer to a device context is always the first parameter of an interface method. A device is associated with exactly one interface set, which contains one of each of the six classes and six module context pointers. The headers additionally define a multipurpose variable type, and preprocessor defines for indicating success or failure in method return values.

The architecture abstraction is divided into six interfaces. Two interfaces represent the original sublayers of a DLL from the OSI model: the logical link control (LLC) and the medium access control (MAC). A third interface for adaptation of the MAC-provided events to the device protocol is included – a physical device adapter (PHY). The fourth interface abstracts some features of the host operating system – a system adapter (SYS). The fifth interface abstracts the link protocol away from both the device protocol and the rest of the stack – a protocol adapter (PRT). We refer to the LLC, MAC, PHY combination as the stack interfaces, while SYS and PRT together are the support interfaces. An additional uplink interface allows the LLC to drive events implemented by the user application without concerning the Data Link Layer of its composition.

B. Context and Visibility

A. Common Methods

Device context is stored in a C struct which contains an interface set and six pointers with which each module may store its own context. Each module has direct access to the entire device context; any module may issue any command or raise any event indirectly, using the interface set. The uModem PHY module, for example, raises the MAC sent event when it has finished communicating with the actual device to send a frame. Module context storage is implementation-specific. For example, most MAC modules will need a state variable and a timer to represent their NAV, whereas the uModem PHY module requires these and also a read buffer, among other things. The pointers in the device context struct are therefore typeless; when a method is called the module-provided function must type-cast the pointer to access its context storage. When initializing, a module should either allocate memory for or accept a pointer to its context. When allocating on the heap during initialization, a module should take care to clean up on shutdown. The sample library modules demonstrate the ramifications of each.

Interfaces share some common methods. Every interface has get and set commands for access to both objects’ and modules’ attributes. These accept an object pointer and an attribute name in character data form. By using strings, modules may avail themselves of PHF support to trivially implement these methods. In the sample library, if the object pointer is NULL, the module itself is treated as the object in question. The initialization, shutdown, sleep and wakeup commands are common to all interfaces except the uplink. Init and shutdown should concern themselves with managing the device’s module interface and module storage context. Sleep and wakeup commands exist for supporting external power management scenarios; the sleep command should serialize the state of a module and provide it to the caller, and the wakeup command should accept such a serialized state. Finally, there is an iterate command which should contain the duty-loop code for each module, if any. All MDLL events should be driven from an iterate call and no iterate call should recurse. The intended purpose of the iterate method is to raise events, such as sent and recv, up from the PHY module.

C. Objects and Attributes

B. Support Interfaces

A hash table framework is included for establishing objects as tables of attributes; each attribute is an entry in a hash table of variable type. The variable type is a union of common ANSI C types. When working with the sample library, hash functions, tables and keys are generated during the build process with a minimal perfect hash function (PHF) generator [3]. Runtime support is provided by a separate project, libphf. Use of these tools is not required by the architecture. Link frames in the sample library which accompanies the architectural headers are expressed using this framework. Additionally, each module can be accessed or modified like an object, for transparency. The developer may change the set of keys to accommodate their attributes, but some attributes are likely to be common to many DLL systems: a pointer to a

The SYS interface provides for device locking, access to timers and delivery, random number generation, and event logging. Abstracting these common system features allows the developer to author a shared or static library which operates an MDLL without reducing the portability of their code. Having available a number of SYS modules targeted for various operating systems makes any and all other MDLL modules more portable. Ongoing development will likely expand and refine this interface. The PRT interface provides a single point for implementing packing and unpacking of frames, accessing flags and other frame attributes with get and set, and runtime access to the header size of a link frame protocol. The interface is essentially 2

Authorized licensed use limited to: University of Massachusetts Amherst. Downloaded on July 30,2010 at 16:18:17 UTC from IEEE Xplore. Restrictions apply.

an abstract data type for frames. This allows the developer to author a frame buffer layout independent of the protocol used to communicate with the physical device. C. Stack Interfaces The PHY interface consists of two commands, send and mtu, in addition to the common interface methods. The MTU query command accepts a pointer to the attributes of the outgoing frame for the purposes of calculating the maximum transmission unit for devices which support more than one type of link frame. This allows either the link or the user application to negotiate for optimal throughput by establishing what frame attributes affect MTU size. The Micro-modem, for example, supports six different rates of transmission at different frequencies, all of which have a vaguely related, but unique, MTU. The MAC interface consists of the common interface commands, send, and a full set of data-path events: recv, sent, sense. The sent event provides a success/failure indicator from the module raising it, generally a PHY module. The sense event provides a frame to the module, to support MAC protocols which rely on physical carrier sense. The recv event provides a frame for the data path through the stack. The LLC interface is identical to the MAC interface. An LLC module may require knowledge of the same events that a MAC module requires, and can easily issue the same commands to the MAC which are issued to it from the user application. Link logic can therefore be organized separate from media access. The uplink interface. consists of the neighbor events admit, updated, evicted and expired, borrowed from SP, and the data events sent, recv, sense. If the LLC module manages the neighbor table, it can raise these neighbor events to the user application with this interface. All of these events accept a variable type parameter so that the user application benefits from the same data abstraction as the other interfaces.

Fig. 1. MDLL architectural concept showing direct calls, indirect commands and indirect events through the different modules.

frames. Also created were a set of attributes for link frames to represent transmitting options (rate, plane) and link estimation metrics (data quality factor, signal strength indicator) which are supported by the real device. The transmission of a single frame involves exchanging a series of messages with the device, completion of which is indicated by reading a CATXF sentence during an iterate call, which triggers the MAC sent event. Received frames are preceded by sentences which indicate some link estimation metrics. Transmission was done only with one of the available rates. Frames transmitted on the data plane use the CCTXD/CARXD sentences and frames on the control plane use CCMUC/CAMUA sentences (user mini-packets). Micro-Modem support was limited for the sake of brevity; an illustration of the Micro-Modem module’s finite state machine follows.

V. I MPLEMENTATION Our MDLL implementation has simple link management and is driven by a monolithic network protocol; the development focuses are code reusability and elimination of the vertical aspect of DLL software. To those ends, separability of the MDLL sublayers must be achieved, for example, the architecture must not force the developer to introduce new and unique states into a MAC protocol. We found that finite state machines within the MDLL are separable when some simple implementation rules are obeyed. First, for every call to a send method, a module must wait for the corresponding sent event before delivering another send call (R1). Second, FSM state transitions cannot be performed, nor expiration timers (e.g. NAV) set, until the sent event is raised to the module intending to do either (R2).

Fig. 2.

Micro-Modem physical layer (PHY) module finite state machine.

B. Medium Access Control

A. WHOI Micro-Modem

Three MAC protocols were built: an empty MAC with no state machine or NAV, a modified ALOHA which employs an acknowledgement frame instead of a full echo, and MACA.

To support the Micro-Modem [4], a stream parser was built to convert Micro-Modem NMEA sentences into link 3


phy.f iterate()

Each module is small and consists only of the necessary state machine. Adjustments in behavior could be made immediately while operating the network at sea by editing a configuration file and restarting the network. C. Logical Link Control The link manages the neighbor table with an on-demand neighbor discovery scheme. A frame will not be accepted by the LLC if its destination address is neither broadcast nor found in the neighbor table; the frame is delayed while a discovery beacon frame is transmitted to the broadcast address instead. Nodes always respond to beacon packets with a beacon acknowledgement, allowing the beaconing node to discover its neighbors. This causes contention, which is adjudicated by the MAC sub-layer. D. Network Test Our user application was a simple network, consisting of four stationary buoy nodes, generating random traffic targeted for a sink that may be between one and three hops away, depending on environmental conditions. The network and link share one unsigned four bit address space, with one reserved broadcast address and the address zero reserved as invalid. The size of network packets is limited to the smallest link MTU. Network packets contain a three bit time to live (TTL) and five bit sequence number, used to quell broadcast storms. The routing protocol employs a custody transfer scheme for delivery, flooding instead of establishing paths in the network.

um iterate() poll(fd) read(CADQF) prt.set(rx frame, DQF, value)

The second PHY iterate call reads a full CADQF, and records it. An incoming transmission is not far behind. phy.f iterate()

um iterate() poll(fd) read(CAMUA) mac.e recv(rxf)

maca recv(rx frame) sys.stop timer(nav) phy.f send(tx frame)

The third PHY iterate call reads an incoming mini-packet, the Micro-Modem module raises the MAC recv event. The MACA module determines this is the CTS it was looking for and sends the DATA frame. The final PHY send call will return, and the next few iterate calls will be limited to the fairly complex MicroModem packet cycle. Eventually, the Micro-Modem will raise MAC sent on either CATXF (transmit completed) or CAACK (acoustic acknowledgment received) depending on whether reliability was requested. MACA will transition to a backoff state, set a timer, and when that expires, transition to idle and raise the LLC sent event, freeing up the MDLL for the next frame from the user application.

VI. A NALYSIS A. In Application A pseudocode description of a call stack demonstrating MACA operating with the Micro-Modem module follows. The user application calls the LLC send method and then calls iterate several times on some schedule. The call stack demonstrates event generation and the division of each module context. Pseudocode methods store references to, and allocate memory for, objects, and also read and write to devices via SYS, transition each modules’ internal state and manipulate their timers. maca send(tx frame) store(tx frame) allocate(RTS) phy.f send(RTS)

maca sent(result) transition(S WAIT CTS) sys.set timer(nav)

The first PHY iterate call reads a full CAMUC; the device write was successful and the acoustic command has been transmitted. The Micro-Modem module raises the MAC sent event. The MACA module determines the RTS was successfully transmitted and now waits for a CTS. phy.f iterate()

mac.f send(...)

um iterate() poll(fd) read(CAMUC) free(txf) stop timer(io) transition(S IDLE) allocate(result) mac.e sent(result)

B. Code Separability

um send(txf) store(txf) write(CCMUC) transition(S WAIT sys.set timer(io)

An LLC call to MAC send resolves to MACA, which holds onto the data frame for later, and sends an RTS with the PHY interface. The Micro-Modem module hangs on to the RTS frame in case of an IO failure.

Micro-Modem support for reliability reveals an interesting aspect to code separability. If the PHY layer raises the MAC sent event immediately upon completing a transmission – i.e. when a CATXF sentence is read off the device – then an ACK-less MAC protocol must either be rewritten with some new back-off state to accommodate the propagation time of IO) the return ACK, violating either or both goals of separability and code reuse, or it must disable the device’s ACK feature altogether, defeating the purpose of bolstering an ACK-less protocol with such a transparent feature. Likewise, a MAC protocol that supports ACK (or NACK) either employs its own and never makes use of the device ACK, or suppresses its own

4


and loses control over when and whether to return an ACK at all, notwithstanding the device might support ACK and not NACK or vice versa. The alternative is for the PHY layer to raise MAC sent only after the ACK exchange has completed. In the case of the Micro-Modem, a CAACK sentence is read when the acoustic acknowledgment is received. If the return-receipt is not requested, sent may be raised on CATXF. However, this approach reduces the throughput of the network to the efficiency curve that limits the ALOHA protocol, unless the request for reliability can properly instruct the Micro-Modem module how long to wait before forgoing the CAACK sentence and raising the sent event. An initial reaction might be to propose a feedback mechanism that could leverage link estimation to assist the PHY layer in determining how long to wait for CAACK. However, if throughput can be maximized for such a PHY module in this manner, then it can also work for ALOHA itself, which puts the concept of running arbitrary MAC protocols over such a device at odds with the device’s own features, and further suggests that it would have already been thoroughly investigated.

VII. C ONCLUSION A modular open-source software architecture has been developed and demonstrated for simple ad-hoc networks. While the initial implementation includes and uses an interface to the WHOI Micro-Modem, the system is intended to be device independent in order to allow network researchers to write code that can be run on multiple hardware platforms. While time will tell if this will be successful, this first step is key to starting a process that will involve multiple institutions and projects and advance the state of the art in underwater acoustic networking. ACKNOWLEDGMENTS This work was supported in part by the DARPA State of Hawaii CEROS program, the Office of Naval Research (N00014-08-M-0016), and the National Science Foundation (OCE-0532223, CNS-808498, and CNS-808467). R EFERENCES [1] J. Polastre, L. Hui, P. Levis, J. Zhao, D. Culler, S. Shenker, I. Stoica, ”A Unifying Link Abstraction For Wireless Sensor Networks.” Proceedings of the Third ACM Conference on Embedded Networked Sensory Systems (SenSys), Nov 2005. [2] C.T. Ee, R. Fonseca, S. Kim, D. Moon, A. Tavakoli, D. Culler, S. Shenker, and I. Stoica, ”A Modular Network Layer for Sensornets.” Proceedings of OSDI, 2006. [3] B. Jenkins, ”Minimal Perfect Hashing,” [online document], 2004 Sep 3, [cited 2008 May 15], available HTTP: http://burtleburtle.net/bob/hash/perfect.html ` [4] L. Freitag., M. Grund, J. Partan , S. Singh , P. Koski , K. Ball , OThe WHOI Micro-Modem: An Acoustic Communications and Navigation ´ Proc. Oceans 2005, Washington, system for Multiple PlatformsO, D.C. Sept. 2005.

5
