Poster Abstract: An Open-Source IEEE 802.15.4 ... - TKN - TU Berlin

Poster Abstract: An Open-Source IEEE 802.15.4
MAC Implementation for TinyOS 2.1
Jan-Hinrich Hauer ∗ , Roberta Daidone † , Ricardo Severino ‡ , Jasper Büsch ∗ , Marco Tiloca † and Stefano Tennina ‡
∗ Telecommunication Networks Group
Technische Universität Berlin
Germany
† Department of Information Engineering
University of Pisa
Italy
‡ CISTER Research Unit
Polytechnic Institute of Porto (ISEP-IPP)
Portugal
Email: {hauer, buesch}@tkn.tu-berlin.de, {roberta.daidone, marco.tiloca}@iet.unipi.it, {rars, sota}@isep.ipp.pt
Abstract—The IEEE 802.15.4 standard has been attracting
strong interest, but in the academic community so far very little
research related to the IEEE 802.15.4 MAC has been evaluated
experimentally, with real hardware under realistic conditions.
This is mainly due to the fact that a stable, open-source
IEEE 802.15.4 MAC implementation has been unavailable for a
long time. Vendor-specific implementations are often proprietary,
cover the standard only partially or are customized to a specific
platform. Our work aims at closing this gap: we present our
open-source, platform-independent IEEE 802.15.4-2006 MAC
implementation, which has been published as a part of the 2.1
release of the TinyOS operating system.
I. INTRODUCTION
The IEEE 802.15.4 standard [1] covers the physical layer
(PHY) and the medium access control sublayer (MAC) in
the ISO-OSI layered network model. The goal is to enable
wireless connectivity between “ultra-low complexity, ultralow
cost, ultra-low power consumption, and low data rate”
devices in wireless personal area networks (WPAN). Since
its first ratification in 2003 the standard has quickly been
adopted by several other wireless communication standards,
such as ZigBee, IETF 6LowPAN and WirelessHART. Yet, in
contrast to the many analytical and simulation studies of the
802.15.4 MAC so far very little research related to the 802.15.4
MAC (and protocols on top/using it) has been evaluated
experimentally, with real hardware under realistic conditions.
While the first steps in wireless protocol design can often be
made with the help of analytical and simulation models, the
last steps, however, require the use of real hardware, in realistic
environmental conditions and experimental setups.
The lack of empirical investigations is mostly due to the fact
that available open-source 802.15.4 MAC implementations
(e.g. [2]) have limitations and/or stability problems and
most commercial implementations are proprietary, cover the
standard only partially or are customized to the vendorspecific
platforms. To close this gap, we have implemented
an open-source platform-independent IEEE 802.15.4-2006
MAC implementation and published the core as part of the
2.1 release of the TinyOS operating system [6]. Our design
is based on three goals:
Fig. 1. IEEE 802.15.4 superframe structure (source: [1])
• Platform Independence: the MAC is decoupled from
a particular mote platform and can be used on any
platform that provides a compatible TinyOS 2 execution
environment, namely, timers that satisfy the precision and
accuracy requirements specified in the standard and a
suitable radio chip (PHY) abstraction.
• Modularity: existing implementations of the 802.15.4
MAC/PHY can result in code sizes of up to 37.3 kB [3].
Given that a typical mote platform may have 48 kB of
program memory and 10 kB of RAM, the implementation
should follow a modular design that allows to select
only the subset of the MAC functionality required by the
particular application. We achieve modularity by mapping
the MAC services to a set of software components and
allow the user to select a suitable subset at compile time.
• Extensibility: To support the research community in
evaluating MAC extensions and facilitate the transition to
a future MAC revision our design is kept extensible: the
component-based design in conjunction with an advanced
radio arbitration mechanism allows flexible integration
of new components and/or modification of the MAC
superframe structure.
In the following we will provide a brief summary of the
main 802.15.4 MAC functions and detail the status of our
implementation, which consists of a core and the (optional)
GTS and security services. For more details on the core
implementation please refer also to [4].

DataP
Promiscuous-
ModeP
ScanP
MCPS-SAP MLME-SAP
Beacon-
TransmitP
PollP IndirectTxP
Beacon-
SynchronizeP
Resource
Radio[Tx/Rx/Off]
RadioControlP
Radio Driver / PHY
[Dis]AssociateP
FrameTx
FrameRx
DispatchQueueP
Dispatch[Un]-
SlottedCsmaP
RadioTx RadioRx RadioOff EnergyDetection
Fig. 2. Architecture Overview
PibP
II. THE IEEE 802.15.4 MAC
Coord/
DeviceCfpP
SimpleTransfer-
ArbiterP
Coord-
RealignmentP
Coord-
BroadcastP
RxEnableP
Alarm & Timer
Symbol Clock
The MAC sublayer supports different configurations and
operating modes. One commonality is that every network has
exactly one PAN coordinator, which is the primary controller
responsible for PAN identifier and device address assignment
and device synchronization. 802.15.4 PANs can either
be nonbeacon-enabled or beacon-enabled. In a nonbeaconenabled
PAN frames are transmitted according to an unslotted
CSMA-CA algorithm (nonpersistent CSMA): if the channel is
detected idle the transmission can start immediately otherwise
the device defers the transmission for a random time period
uniformly drawn from an exponentially increasing backoff
interval.
In beacon-enabled mode coordinators periodically transmit
beacons which mark the beginning of a superframe as depicted
in Figure 1. A beacon carries information about pending data
and the current network configuration. Immediately after the
beacon follows the contention access period (CAP). During the
CAP devices use a slotted variant of the CSMA-CA algorithm:
a device must sense an idle channel twice before it may
transmit and both, channel sensing and transmission must be
performed on backoff slot boundaries. The CAP is followed by
an optional contention-free period (CFP), which is portioned
in so-called guaranteed time slots (GTS). GTSs are allocated
dynamically and the corresponding time interval can be used
exclusively to transmit packets in a contention-free fashion.
The CFP is followed by an optional inactive period in which
all nodes can sleep to preserve energy and achieve low duty
cycles.
III. ARCHITECTURE & CODE STATUS
Our architecture covers a platform independent 802.15.4
MAC implementation and defines the interfaces towards the
layer below (PHY / radio driver) and above (to the network
layer). Fig. 2 shows an overview of our implementation, its
main components and the interfaces that are used to exchange
MAC frames between them. For the purpose of explanation the
architecture can be subdivided into three sublayers: the components
on the top level (white boxes) implement several MAC
data and management services, for example, PAN association
or requesting (polling) data from a coordinator. These services
typically utilize data and command frame transmission and
reception and are connected to a component that prepares
the channel access according to the (un)slotted CSMA-CA
algorithm (Dispatch[Un]SlottedCsmaP). Most of the
components on the second level (light gray boxes) are responsible
for the other portions of a superframe in beacon-enabled
mode, e.g. beacon transmission and tracking. The third level
(dark gray boxes) manages the access to the radio driver: it
controls which of the components is allowed to access the
radio at what point in time based on an extended TinyOS 2
resource arbiter. The design and implementation of the radio
driver (PHY) is platform/chip specific and thus not part of the
architecture.
Our MAC implementation includes almost the entire functionality
described in the 802.15.4-2006 specification including
the optional GTS and security services. It consists of 26
core components with a total of approx. 8000 “Physical Source
Lines Of Code” [5]. It is available online [6] as part of the
TinyOS 2 core.
The implementation is currently available for the TelosB
and micaZ platform. However, it can be ported to other
platforms with little effort: a new platform must only (1)
include a radio driver that provides the interfaces required by
our MAC implementation; (2) provide TinyOS Alarm and
Timer interfaces with a precision of a 802.15.4 symbol (62.5
kHz for the 2.4 GHz band) and an accuracy of ±40 ppm; and
(3) provide a TinyOS configuration component that connects
(“wires”) our platform independent MAC implementation to
the platform specific timer subsystem and radio driver.
ACKNOWLEDGMENT
This work has been partially supported by the EC under
contract FP7-2007-IST-2-224053 (CONET project)
REFERENCES
[1] LAN/MAN Standards Committee of the IEEE Computer Society, IEEE
Standard for Information technology – Part 15.4: Wireless Medium Access
Control (MAC) and Physical Layer (PHY) Specifications for Low Rate
Wireless Personal Area Networks (LR-WPANs), Sep. 2006.
[2] A. Cunha, A. Koubaa, R. Severino, and M. Alves, “Open-ZB: an opensource
implementation of the IEEE 802.15.4/ZigBee protocol stack on
TinyOS,” in Mobile Adhoc and Sensor Systems, 2007. MASS 2007. IEEE
Internatonal Conference on, Oct. 2007, pp. 1–12.
[3] Freescale, “802.15.4 MAC PHY Software Reference Manual,”
http://www.freescale.com/files/rf if/doc/ref manual/802154MPSRM.pdf.
[4] J.-H. Hauer, “TKN15.4: An IEEE 802.15.4 MAC Implementation for
TinyOS 2,” Telecommunication Networks Group, Technical University
Berlin, TKN Technical Report Series TKN-08-003, Mar. 2009.
[5] R. Park, “Software size measurement: A framework for counting source
statements,” Carnegie Mellon University, Tech. Rep., Sep 1992.
[6] J.-H. Hauer, R. Daidone, R. Severino, J. Büsch, M. Tiloca,
and S. Tennina, “Source code of the IEEE 802.15.4
MAC Implementation,” http://code.google.com/p/tinyosmain/source/browse/trunk/tos/lib/mac/tkn154/.