BiPS A Real-time-capable Protocol Framework
for Wireless Sensor Networks
Dennis Christmann, Tobias Braun, Markus Engel, and Reinhard Gotzhein
Computer Science, University of Kaiserslautern, 67653, Kaiserslautern, Germany
Keywords:
Real-time, Wireless Networks, Communication Protocols, Implementations, Operating Systems.
Abstract:
Distributed real-time systems present a particular challenge, because two key problems have to be solved dur-
ing their development: First, deployed protocols must provide deterministic behavior to enable a predictable
outcome. Second, the implementations of the protocols have to be in compliance with the stringent timing
constraints stated by the protocols to ensure that their runtime behavior remains deterministic. This, particu-
larly, requires an adequate isolation of time-critical protocols from less preferential applications installed on
the same node. In this paper, we present the protocol framework BiPS, which tackles these challenges for
wireless sensor networks and Imote 2 hardware platforms. Besides summarizing the various MAC protocols
both best effort and real-time-capable protocols and operating system functionalities provided by BiPS,
this paper presents comparative evaluations with TinyOS, a state-of-the-practice operating system for wire-
less sensor networks, and the real-time operating system RIOT. The results show that protocols realized with
BiPS outperforms these solutions w.r.t. predictability of execution times, thereby providing evidence of the
advantages of BiPS for real-time systems.
1 INTRODUCTION
In a real-time system, correctness does not only de-
pend on logically correct results, but also on the point
in time when the results are produced (Kopetz, 1997).
In distributed applications where the system is com-
posed of several interacting nodes, this fundamental
requirement does not only make demands on the sin-
gle nodes and their implementations, but also on the
communication system, which has to provide reliable
and delay-constrained data transfer. To meet both de-
mands, the realization of distributed real-time systems
should be a holistic approach, where protocols are
designed w.r.t. the real-time properties they have to
fulfill as well as implemented in compliance with re-
quired time constraints and in harmony with less time-
critical components. This, in turn, makes demands on
the used operating systems (OSs), which are respon-
sible for the compliance with local deadlines.
In this paper, we present the Black burst-
Integrated Protocol Stack (BiPS), a real-time-capable
protocol framework for wireless networks, which is
used in an industrial project, in which sensor values
of a production plant have to be sent over a wireless
communication medium with bounded delay. The
various protocols provided by BiPS are activated in
so-called virtual slot regions, which enable the usage
of best effort and real-time-capable protocols within
one scenario. To guarantee compliance with time con-
straints stated by the protocols, the framework runs on
top of the hardware – in our case, the sensor platform
Imote 2 (MEMSIC Inc., 2013) without further OS.
As consequence, all functionalities of a typical OS
like application schedulers (time- or event-driven)
and hardware drivers are provided by BiPS. Thus,
BiPS does not only consist of a set of protocols but
also represents a light-weight, tailored, and layered
OS (Farooq and Kunz, 2011). It comes with flexible
application interfaces to enable abstraction and tem-
poral decoupling between the time-critical protocols
of BiPS and higher layers with less stringent time con-
straints.
Compared to state-of-the-practice protocol imple-
mentations, BiPS differs in two points: First, BiPS
does not include a single protocol but consists of var-
ious MAC (Medium Access Control) protocols, ab-
stract interfaces to integrate new ones, and an ar-
chitecture to apply various protocols in one sce-
nario. Thereby, BiPS is much more flexible than
existing communication solutions like IEEE 802.11
or IEEE 802.15.4, where the combination of sev-
eral MAC schemes is not possible or severely re-
Christmann, D., Braun, T., Engel, M. and Gotzhein, R.
BiPS A Real-time-capable Protocol Framework for Wireless Sensor Networks.
DOI: 10.5220/0005938300170027
In Proceedings of the 6th International Joint Conference on Pervasive and Embedded Computing and Communication Systems (PECCS 2016), pages 17-27
ISBN: 978-989-758-195-3
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All r ights reserved
17
stricted. Second, in common implementations, pro-
tocols are realized as components of a generic (real-
time) OS like TinyOS (e.g., IEEE 802.15.4 (Cunha
et al., 2007; Hauer, 2009) or 6LoWPAN (Harvan
and Sch
¨
onw
¨
alder, 2008)), Contiki (e.g., IEEE 802.11
(Glaropoulos et al., 2014) or LOADng (Elyengui
et al., 2015)), or Nano-RK (e.g., WiDom (Pereira
et al., 2007)), whereas BiPS is protocol-centric, i.e.,
the OS functionalities have been built as auxiliary ser-
vices around the communication protocols. Hence,
BiPS is highly-optimized for the execution of real-
time protocols. Since compared to generic OSs, BiPS
has some limitations like missing support of syn-
chronization mechanisms (e.g., semaphores), the real-
time OS FreeRTOS has been integrated into BiPS
in terms of a subordinated application scheduler.
Thereby, multi-threading and priority-based preemp-
tive scheduling is supported for higher layers like
routing protocols or applications, while the execution
of time-critical components remains under control of
the BiPS core.
Different from our previous work on BiPS (Braun
et al., 2014a), in which the focus was on the interfac-
ing of implementations derived from SDL (Specifica-
tion and Description Language, (ITU-T, 2012)) mod-
els, this paper presents core functionalities of BiPS
w.r.t. its application in real-time systems. In this re-
gard, the paper gives special attention to implementa-
tion aspects, predictability at runtime, and compliance
with timing constraints.
The paper is structured as follows: Section 2 out-
lines BiPS. Details of the framework and integrated
protocols are presented in Sect. 3, and OS functionali-
ties together with implementation details in Sect. 4. In
Sect. 5, results of a comparison study between BiPS,
TinyOS, and RIOT are presented. Section 6 provides
a survey on related work. Finally, Sect. 7 concludes
the paper.
2 AN OUTLINE OF BiPS
BiPS is a protocol framework for wireless sensor
nodes tailored for the Imote 2 platform (MEMSIC
Inc., 2013). This platform is based on an Intel XS-
cale PXA271 controller with 256 KiB SRAM, 32 MiB
SDRAM, and 32 MiB FLASH. It supports clock
rates up to 416 MHz and integrates the widely used
IEEE 802.15.4-compliant CC2420 transceiver (TI,
2013).
The architecture of BiPS is presented in Fig. 1.
Besides included protocols like the synchroniza-
tion protocol Black Burst Synchronization (BBS;
(Gotzhein and Kuhn, 2011)) and several MAC proto-
sensor application, control algorithm, ...
HW timers, GPIO, DMA,...
transceiver (cc2420)
UART,LED,...
routing, middleware, ...
MAC
BBS ACTP
RB
CB
MB
black burst
1 - drivers
0 - system software
2 - MAC protocols
4 - applications
3 - higher-layer
protocols
schedulers
app
(BAS)
communication
(BCS)
multiplexer
Figure 1: Architecture of BiPS.
cols, the figure additionally shows the communication
and application scheduler of BiPS and the application
interface to decouple time-critical protocol function-
alities from higher-layer protocols.
The overall structure of BiPS follows a layered
approach, where higher layers can abstract from the
realization of lower layers by providing abstract inter-
faces: In layer 0, BiPS implements low level function-
ality to interact with the hardware, such as access to
hardware timers. Layer 1 comprises hardware drivers
for peripheral devices, such as an optimized driver for
the CC 2420 transceiver using DMA (Direct Memory
Access). While layer 0 and 1 are hardware-specific by
nature, the protocols in layer 2 abstract from hardware
details in most instances. However, full abstraction is
not possible, because some limitations of the hard-
ware – e.g., transfer rates and switching delays of the
transceiver must be considered. Currently, layer 2
includes the synchronization protocol BBS providing
network-wide synchronization in multi-hop networks
and four MAC protocols (see Sect. 3.1). To access the
MAC protocols from higher-layer protocols (layer 3)
or applications (layer 4), a multiplexer has been intro-
duced, providing a unique interface to all MAC proto-
cols and decoupling time-critical protocols from less
time-critical applications (see Sect. 3.3).
The execution of all components MAC proto-
cols on layer 2 as well as higher-layer protocols and
applications on layer 3 and 4 are controlled by
two schedulers: The BiPS Communication Scheduler
(BCS), developed and optimized for the execution of
time-critical MAC protocols, and the BiPS Applica-
tion Scheduler (BAS) for less time-stringent applica-
tions. More details on this topic are given in Sect. 4.
3 BiPS AS PROTOCOL
FRAMEWORK
The objective of BiPS is to provide an extensible
framework for (real-time-capable) MAC protocols
and homogeneous and easy-to-use interfaces to ac-
cess them. In this section, we describe already in-
PEC 2016 - International Conference on Pervasive and Embedded Computing
18
corporated MAC protocols (Sect. 3.1), mechanisms to
run them in parallel in a compatible way (Sect. 3.2),
and the multiplexer providing the upper interface to
them (Sect. 3.3).
3.1 Available MAC Protocols
Currently, BiPS supports four MAC protocols (see
Fig.1): One best effort protocol and three real-time-
capable protocols.
The best effort protocol is called Contention-
Based protocol (short: CB) and realizes a classi-
cal CSMA/CA-based (Carrier Sense Multiple Ac-
cess with Collision Avoidance) communication solu-
tion. Since backoff times are calculated by means
of configurable contention windows, CB allows
priority-based frame transmissions and slightly sup-
ports Quality-of-Service (QoS), yet without guaran-
tees w.r.t. collisions and delays.
The real-time-capable MAC protocols are called
Reservation-Based Protocol (short: RB), Arbi-
trating and Cooperative Transfer Protocol (short:
ACTP, (Christmann et al., 2012)), and Mode-Based
Scheduling with Fast Mode-Signaling (short: MB,
(Braun et al., 2014b)). RB is a TDMA-based (Time
Division Multiple Access) protocol with exclusive
slot reservations, hence enabling deterministic guar-
antees. ACTP is a so-called binary countdown pro-
tocol
1
for multi-hop networks, which provides deter-
ministic priority-based medium arbitration with con-
figurable arbitration radius and (network-wide) trans-
missions of bit sequences within guaranteed delay
bounds. For this purpose, it incorporates a collision-
resistant communication primitive called black burst,
which realizes dominant bits by the transmission of a
busy tone and recessive bits by the absence of trans-
mission. MB allows, different from RB, a well-
controlled amount of dynamic contention for time
slots, while still supporting deterministic guarantees
and, therefore, enables an efficient usage of the avail-
able network resources especially for sporadic mes-
sages. To establish the synchronization required by
the protocols, BiPS incorporates the synchronization
protocol BBS (Gotzhein and Kuhn, 2011), which is
designed for dense multi-hop networks and provides
network-wide synchronization with low and bounded
offset.
Selecting the best MAC protocol depends on a sce-
nario’s concrete message characteristics and require-
ments regarding timing and determinism: If, for in-
stance, messages are strictly periodic, RB is the best
1
A famous wired representative of this protocol class is
CAN – the Controller Area Network (ISO, 2004).
choice w.r.t. bandwidth usage and absence of colli-
sions.
3.2 Medium Slotting and Virtual Slot
Regions
Since large distributed systems realize various ap-
plications sending messages with different commu-
nication requirements (periodic/sporadic messages
with/without timing requirements), it is often not suf-
ficient to run a single MAC protocol only. Instead, the
communication system should provide suitable MAC
protocols for each application and corresponding in-
terfaces to use them.
In BiPS, this is solved by the possibility to com-
bine all MAC protocols in one scenario by multiplex-
ing their activation in time. For this purpose, BiPS
divides time into periodically repeated super slots
consisting of a configurable number of macro slots.
Macro slots start with a synchronization phase
2
and
have a configurable length, determining the resyn-
chronization interval. Macro slots are further sub-
divided into so-called virtual slot regions with con-
figurable and node-specific positions and durations.
Each virtual slot region is self-contained and assigned
to one of the MAC protocols, which organizes the
medium access within the slot region. The BCS (see
Sect. 4.1) is responsible to activate the assigned MAC
protocol based on the node’s local (but synchronized)
clock and to prevent interference between neighbor-
ing slot regions. In contrast to the periodically re-
peated super slot, each macro slot of the super slot
may have an individual structure of virtual slot re-
gions with different lengths and assigned protocols.
Figure 2 shows an example of a super slot con-
figuration for three nodes. In the example, a super
slot consists of three macro slots with different con-
figurations of virtual slot regions for each of the three
nodes. The slot regions have been assigned to differ-
ent MAC protocols, according to the scenario’s com-
munication characteristics. The access to a virtual
slot region and, hence, to a particular MAC pro-
tocol is managed by so-called Transmission Op-
portunities (TOs), which are responsible for the (de-
)multiplexing of transmissions (see Sect. 3.3).
The configurable length of slot regions as well as
the flexible assignment to MAC protocols enables tai-
loring of the communication schedule to a specific
scenario. Unassigned time slices of macro slots are
automatically joined to idle regions (white areas be-
tween virtual slot regions in Fig. 2). Since a node
2
We apply BBS but actually, any synchronization proto-
col realizing network-wide synchronization with bounded
offset and convergence delay could be used.
BiPS A Real-time-capable Protocol Framework for Wireless Sensor Networks
19
app V
a,1
app V
a,2
TX TO
id = 10
prio = 0
TX TO
id = 3
prio = 1
TX TO
id = 4
prio = 0
RX TO
id = 2
setData()
RX TO
id = 0
rxCallback()
setData() /
rxCallback()
enqueue()
callback()
enqueue()
callback()
callback()
enqueue()
ACTP: Arbitrating and Cooperative
Transfer Protocol
CB: Contention-based Protocol
(CSMA/CA)
Types of virtual slot regions
MB: Mode-based Scheduling with
Fast Mode Signaling
RB: Reservation-based Protocol
TX TO
id = 5
prio = 2
RX TO
id = 6
app V
a,3
rxCallback()
callback()
enqueue()
super slot
macro slot
V
a
V
b
V
c
FIFO
EDF
EDF
FIFO
BBS: (Re-)synchronization phase
Figure 2: Configuration of virtual slot regions of three nodes and associated transmission opportunities.
is not involved in communication during idle regions,
the BCS automatically disables the transceiver to save
energy. Therefore, BiPS inherently incorporates a
transparent and application-independent duty cycling
model on communication level, which is a precondi-
tion for wireless sensor networks (WSNs).
3.3 Multiplexing of Applications and
Access to MAC Protocols
In BiPS, applications and higher-layer protocols (lay-
ers 4 and 3) do not directly interact with the MAC
protocols but via TOs, which are located in the
multiplexer (see Fig. 1). This has several reasons:
First, MAC protocols have time-critical functionali-
ties, whereas applications and higher-layer protocols
have less requirements. Second, a direct interaction
with MAC protocols would require the protocols to
implement queueing facilities, which would increase
the complexity of the protocol. Furthermore, directly
interacting with a MAC protocol would complicate
the exchange of the protocol if a different protocol
seems to be more suitable for an application later.
To achieve that the usage of a MAC protocol is,
from an application’s perspective, transparent, easy,
and independent from the concrete protocol, BiPS in-
troduces the multiplexer, realizing a temporal decou-
pling and loose coupling between MAC protocols and
components on higher layers. This multiplexer pro-
vides a homogeneous interface to all MAC protocols,
though properties of a single transmission may differ.
The multiplexer comprises a set of TX queues
called TX TOs – to store outgoing transmissions until
they are ready to be sent. If an application or higher-
layer protocol intends to transmit a frame, it enqueues
the frame in a TX TO, which is associated with a set
of virtual slot regions and owns a priority. When a
new virtual slot region begins, the first frame of the
associated TX TO with highest priority is transferred
to the MAC protocol responsible for this slot region.
This protocol then tries to send the frame and informs
the multiplexer about success or failure afterwards,
which, in turn, informs the initiator of the transmis-
sion or depending on a configuration triggers re-
transmissions. Further configuration options of TX
TOs allow a limit on the queue size and the selec-
tion of a queueing strategy, where currently First-In-
First-Out (FIFO) and Earliest-Deadline-First (EDF)
are supported. Since a TX TO implements queue-
ing facilities and multiple applications can share a
TX TO, the same MAC protocol can be used by sev-
eral applications executed on the same node. In this
case, the TX TO also guarantees the correct delivery
of transmission confirmations.
Similar to TX TOs, the multiplexer provides RX
TOs, where applications can register a function call-
back, which is invoked whenever data is received in
an associated slot region. In this regard, multiple call-
backs can be registered in one RX TO to inform sev-
eral applications about the reception of a data frame.
The interplay of TX/RX TOs and applications,
and the association of TOs to virtual slot regions is
illustrated in Fig. 2. In this example, three applica-
tions installed on node V
a
access the multiplexer of
BiPS, which comprises four TX TOs and three RX
TOs, each identified with a unique identifier. The ex-
ample, particularly, highlights the following proper-
ties: First, one application can use several TX and
RX TOs. Second, several TX TOs can be assigned to
one virtual slot region, where priorities enforce a lo-
cal preference order. Third, TX TOs can be associated
with several slot regions to give a frame several trans-
mission chances per super slot. A similar association
holds for RX TOs.
PEC 2016 - International Conference on Pervasive and Embedded Computing
20
4 OPERATING SYSTEM
FUNCTIONALITIES IN BiPS
To run real-time-capable protocols, time-critical pro-
tocol functionality must be executed in time and with
minimal delays. Therefore, BiPS is specially tai-
lored to its target platform Imote 2 and implemented
as bare-metal solution. Instead of extending an OS by
protocols, which is actually state-of-the-practice (see
e.g, (Basmer et al., 2011)), BiPS provides a subset of
OS functions while simultaneously focusing on the
needs of real-time-capable protocols. Hence, BiPS
combines handcrafted optimized code for the Imote 2
platform (e.g., an interrupt handler written in assem-
bler and optimized hardware drivers using DMA)
with abstract interfaces and schedulers for MAC pro-
tocols as well as less time-critical applications.
According to the design of BiPS, we distinguish
between core functionalities with high requirements
w.r.t. timeliness and components with lower require-
ments. To reflect this, BiPS incorporates two sched-
ulers: The BiPS Communication Scheduler (BCS,
Sect. 4.1) responsible for the execution of time-
critical components (MAC protocols, core functions
of BiPS), and the BiPS Application Scheduler (BAS,
Sect. 4.2) executing applications and higher-layer
protocols. Both benefit from core services regarding
memory management and fault handling (Sect. 4.3).
4.1 The BiPS Communication
Scheduler
The main task of the BCS is the timely (de-)activation
of MAC protocols at the start and end of associated
virtual slot regions, respectively. In order to prior-
itize BCS over BAS, BCS and its managed compo-
nents run in the interrupt mode of the microcontroller.
To ensure timeliness when (de-)activating MAC pro-
tocols, the BCS uses a dedicated hardware timer of
the Imote 2 platform.
Execution of MAC protocols is controlled by the
BCS via a uniform interface, which has to be imple-
mented by each MAC protocol and prescribes func-
tions to be implemented to exchange data with the
multiplexer. Thereby, the extension of the frame-
work with a new protocol is straightforward. Vir-
tual slot regions are structured by the BCS in a
protocol-independent way, which ensures the isola-
tion of neighboring slot regions. In this regard, guard
times between subsequent slot regions are introduced
to compensate synchronization inaccuracies, which
have to be bounded by a maximal offset d
maxOffset
, and
other transceiver-related factors. Transceiver-related
factors include, for instance, switching delays of the
:MB-MAC
:BCS
setData(m,cB)
switchToRX
t2: TimerInterrupt
t3: TimerInterrupt
start(t1, slotDuration)
t1: TimerInterrupt
t0: TimerInterrupt
congure(t0, cong)
:MPX
t
0
t
1
d
maxOset
t
2
t
3
d
stop
d
slotDuration
virtual slot region
Figure 3: Structure of virtual slot regions and activation of
the MAC protocol by the BCS.
CC 2420 transceiver to guarantee that every node with
an assigned RX TO is in reception mode at the start
of a virtual slot region. In this context d
CC2420
T XRX
de-
notes the maximal switching delay from transmission
(TX) to reception (RX) mode, as specified by the data
sheet.
Figure 3 shows the layout of a virtual slot region
and the interface used by the BCS to control the ex-
ecution of a MAC protocol. The duration of the re-
gion d
slotDuration
depends on the specific virtual slot
region as configured in the macro slot configuration
and may allow several transmissions within one re-
gion. At t0, the slot region starts (according to the
node’s local clock). At this point, the BCS first calls
the configure function of the protocol and then exe-
cutes the multiplexer (MPX), which checks for frames
to be transmitted. Since the synchronization offset
is bounded by d
maxOffset
, all nodes have reached the
start of the slot region not later than at t1, when the
control over the medium is passed on to the MAC
protocol, which now may start transmissions. At t2,
the BCS switches the transceivers back to reception
mode, to guarantee that all nodes perceive the trans-
missions within the bounds of the assigned slot re-
gion. Thus, all MAC protocols have to ensure that
their transmissions are finished at this point in time.
Therefore, the guard time d
stop
between t2 and t3 (the
locally perceived end of the slot region), is defined
as d
stop
= max(d
maxOffset
, d
CC2420
T XRX
). By considering
the maximal synchronization offset d
maxOffset
and the
transceiver’s switching delay d
CC2420
T XRX
from TX to RX
mode, this guarantees not only that every node re-
BiPS A Real-time-capable Protocol Framework for Wireless Sensor Networks
21
ceives the end of a transmission within the slot re-
gion’s bounds, but also that a node sending in the cur-
rent slot region is ready to receive new frames at the
start of the subsequent slot region.
Using a beacon-based synchronization protocol
(limited to single-hop networks) instead of BBS in
conjunction with a macro slot duration of 1 s, an upper
bound for the synchronization offset can be derived
with d
maxOffset
= 100 µs. Together with the maximal
switching delay d
CC2420
T XRX
= 192µs, the resulting guard
time is d
stop
= 192 µs and the minimal virtual slot re-
gion duration is about 5.5 ms (for the MB protocol).
If BBS is used to synchronize a three hop network,
the maximal offset is bounded by d
maxOffset
= 338 µs.
Hence, the guard time is d
stop
= 338µs and the min-
imal length of the virtual slot region is exemplarily
6.8ms for the MB protocol.
4.2 The BiPS Application Scheduler
The BAS is responsible for the execution of less time-
stringent applications and higher-layer protocols and
is classified as cooperative, event-based, and non-
preemptive. It is small-scale, since it does not manage
processes or threads but handles function callbacks
to execute components. To be executed by the BAS,
components have to register for relevant events, such
as frame receptions or timer expirations. The events
are identified by unique identifiers, which are used to
request the event’s execution at the next scheduling
decision. Since the execution of events can be re-
quested in interrupt mode but the BAS runs in non-
interrupt mode, events, which are announced in inter-
rupt mode, can be continued after leaving this mode.
This is, for instance, used in BiPS after the reception
of a frame, which is indicated by a MAC protocol
running in interrupt mode, but must not entirely be
handled in interrupt mode due to its possibly costly
processing.
Synchronization primitives between components
managed by the BAS are not required, since they
work cooperatively and their execution can only be
interrupted by hardware interrupts. There are, how-
ever, critical sections in which a component needs to
interact with low level functions, e.g., if a message
is sent via UART (Universal Asynchronous Receiver
Transmitter). To prevent data races, access to shared
memory has to be exclusive in these cases, which is
obtained by temporarily disabling interrupts, which,
in turn, can have a negative impact on time-critical
protocols. To mitigate this effect, we measured the
worst-case processing duration d
max
intr
of all interrupt
routines of the device drivers. Then, we let BCS take
over control d
max
intr
before a time-critical event is about
to happen, which disables all non-relevant interrupts,
thereby deferring the execution of less prior compo-
nents. In order to keep d
max
intr
low, we demand the in-
terrupt routines to consume the shortest duration pos-
sible, which could be achieved by e.g. using direct
memory access (DMA) to transfer data between main
memory and devices. To further avoid undesired de-
lays, the Imote 2’s CPU provides nesting interrupts
on two levels, so lower prioritized hardware drivers,
e.g., the UART, can be interrupted by higher priori-
tized events, such as the expiration of a timer.
Though the BAS is sufficient in most instances,
the absence of tasks and preemption can limit its ap-
plicability. Thus, it is also possible to remove BAS
completely and replace it by another operating sys-
tem which can in general be ported to the Imote 2 plat-
form. This enables the development of multi-threaded
applications and higher-layer protocols without be-
ing limited by the event system of BAS and cooper-
ative scheduling. In detail, we integrated RIOT and
FreeRTOS, both classical real-time OS with support
for tasks, task priorities, synchronization primitives,
and task preemption, into BiPS. The port of an inte-
grated OS can be seen as a virtualization, because it
has only limited access to the hardware and its exe-
cution is controlled. Since interrupts destined for the
inner OS are assigned a lower priority than those used
by the BCS, not only user level tasks can be inter-
rupted by the BCS but also the kernel functionality of
the inner OS. Therefore, timeliness and prioritization
of MAC protocols over applications and higher-layer
protocols is still guaranteed. The tasks running in-
side the OS can interact with the communication sub-
system of BiPS using the multiplexer, as explained in
section 3.3. The effort of porting an OS into BiPS can
be compared to porting it to bare metal, except that
drivers for peripheral devices are already provided by
BiPS and only need an adaption layer in the port.
4.3 Memory Management and Fault
Handling
The core hardware of the Imote 2 platform offers
many features that can be used to speed up execu-
tion and to facilitate debugging of applications. In
this regard, the availability of instruction and data
caches and a Memory Management Unit (MMU) is
fundamental. In BiPS, we use the MMU for detecting
and analyzing common faults and provide tools to ex-
amine error situations. In particular, we can detect
overwriting of code and read-only data, accidental
writes to system memory such as page tables, access-
ing NULL pointers (by data access or jumping), and
execution of invalid code (provoked by illegal jumps).
PEC 2016 - International Conference on Pervasive and Embedded Computing
22
If a fault is detected, the in-system fault handler of
BiPS gives information about possible reasons. It also
prints a backtrace and offers a shell to examine mem-
ory content and to print the current virtual memory
layout, physical memory allocations, and information
about heap and stacks. There is also a GDB server
included, so the GNU debugger can be invoked on a
PC attached to the Imote 2 via serial line. This can
give even more insight, since GDB can enrich pointer
addresses by debug information.
By enabling the MMU, we can also enable the
data cache of the Imote 2, which significantly speeds
up the average execution time. On the downside,
caches introduce jitter, which is conflicting with time-
critical protocols and real-time systems. However,
in BiPS, this jitter is greatly reduced for time-critical
functions by using cache locking, a feature preventing
individual data and instructions from being evicted
from the caches.
Using the MMU also allows for shorter develop-
ment times, as BiPS and its applications work on a
common virtual memory layout and are therefore in-
dependent of their physical memory location. As re-
sult, an image with BiPS can be stored on non-volatile
memory, but it can also be executed from SDRAM,
which is much faster and saves write cycles of the
flash memory.
5 EVALUATION
In this section, experiments are presented comparing
BiPS with state-of-the-practice implementations for
WSNs. In this regard, the focus is not on the individ-
ual protocols in BiPS, since deterministic protocols
are predictable by design and CSMA/CA protocols
are well studied (see, e.g., (Ziouva and Antonakopou-
los, 2002; Wang and Kar, 2005; Koubaa et al., 2006)).
Instead, the objective is to evaluate BiPS as frame-
work for real-time-capable protocols. In this regard,
resource usage (Sect. 5.1) and predictability of timer
delays (Sect. 5.2) and delays to detect Start-Frame-
Delimiters (SFDs, Sect. 5.3) are of interest.
Since there are only few OSs supporting the X-
Scale PXA271 controller of the Imote 2, quantita-
tive comparisons are severely restricted. In partic-
ular, we only found direct support for this micro-
controller in TinyOS, which we used in version 2.1.2.
To compare BiPS with a classical real-time OS, we
added a port for the Imote 2 to RIOT (Hahm et al.,
2013a). But since RIOT does not provide a driver for
the CC2420 transceiver, comparisons are restricted to
communication-independent aspects. In all experi-
ments, the Imote 2 runs with 104 MHz.
5.1 Memory Usage
In general, memory usage of a program can be divided
into static and dynamic memory. Static memory is the
amount of memory that is needed by the application
image and consists of code plus read-only and pre-
initialized read-write data. It can be measured by tak-
ing the file size of the image after linking all object
files. Dynamic memory is the memory needed while
executing the program. It covers all read-write data
that can be seen by static analyzes of the program,
such as global variables, but there are also data, whose
size cannot be determined in advance, such as heap
and stack. It is, therefore, not trivial to give meaning-
ful numbers for dynamic memory, but one can pro-
vide minimal requirements.
The Imote 2, compared to other sensor platforms,
is very powerful: It offers 32 MiB flash memory,
which is an upper limit for static memory usage, as
well as 256 KiB SRAM and 32 MiB SDRAM, which
are upper limits for dynamic memory usage. Be-
cause of this large amount, optimizing our applica-
tions for size was a minor objective. The features
we employed, such as virtual memory handling and
a comprehensive fault handler (see Sect. 4.3), con-
sume about 59 KiB static memory and 26 KiB dy-
namic memory, of which 16 KiB are contributed to
the MMU table alone.
As minimum requirement, a BiPS application
needs 140 KiB static and 26 KiB dynamic memory.
An application using BiPS excessively requires about
350 KiB static and 35 KiB dynamic memory. Note,
however, that by compiling for size instead of per-
formance, the static size of applications can already
be reduced by 20%. If size should matter (remem-
ber: even with a large application, we only use 1% of
static and 0.1% of dynamic memory), we could also
drop features or compile the application using an al-
ternative size-optimized instruction set offered by the
processor.
5.2 Timer Delays
In real-time systems, delays to react to external events
must be low and predictable. At best, these delays are
bounded and load-independent. In the following, we
assess delays to process timers, whose expiration is a
special type of event. They are used representative for
other types of events, e.g., caused peripheral devices.
The experiment’s setup consists of one Imote 2, on
which TinyOS, RIOT, and BiPS are installed consec-
utively. In each case, there is support for (at least) two
timer variants, which are evaluated independently:
One variant, where the expiration is processed in in-
BiPS A Real-time-capable Protocol Framework for Wireless Sensor Networks
23
Table 1: Timer delays.
w/o load with load
time [µs] instructions time [µs] instructions
min avg max min avg max min avg max min avg max
TinyOS Timer 18.1 18.3 18.6 177 177 177 19.3 46.2 1316 192 497.2 15382
Alarm 13.5 13.6 13.7 112 112 112 13.5 16.8 18.4 112 112 112
RIOT virtual timer 22 22 22 663 663 663 26.7 49.9 63.4 933 933.1 1254
hw timer 2.3 2.4 2.4 49 49 50 2.3 3.5 7.6 49 49.3 50
BiPS event timer 2.3 3.3 7.9 49 49.3 50 5.3 8.8 594.2 53 86.9 13260
hw timer 1.5 1.6 1.6 13 13 13 1.5 1.7 2.5 13 13.3 14
terrupt context called Alarm (TinyOS) or hw timer
(RIOT, BiPS) –, and one variant with execution in
non-interrupt mode called Timer (TinyOS), virtual
timer (RIOT), or event timer (BiPS). The time to pro-
cess a timer is measured by performance counters of
the Imote 2. For each OS and timer variant, experi-
ments are done without and with background load and
repeated 10,000 times.
The results are shown in Table 1. Without load,
there is no concurrency. The results show that the
processing of timers in interrupt mode is, in general,
faster and less variable than in non-interrupt mode.
Due to the costly runtime model and its distinctive ab-
straction layers, hardware timer delays with TinyOS
are in general larger than with RIOT and BiPS. The
lowest and most stable delays are achieved by hard-
ware timers of RIOT and BiPS, since they benefit
from optimized implementations. Perhaps most sur-
prising are the virtual timers of RIOT, whose execu-
tion implies the preemption of an idle task and a con-
text switch, which sums up to 22µs on average.
When additional random background load is gen-
erated by a second timer
3
, evictions of data from the
Imote 2’s instruction and data caches are provoked.
Corresponding results show a deterioration of delays;
in particular, for timers processed in non-interrupt
mode. In this regard, processing delays in RIOT in-
crease the least due to the priority-based and preemp-
tive scheduling strategy. On the other hand, non-
interrupt timers of TinyOS and BiPS suffer from the
cooperative scheduling strategies, yet BiPS outper-
forms TinyOS due to better exploitation of hardware
features like data caches. In contrast to timers pro-
cessed in non-interrupt mode, the increase of delays
with hardware timers is much lower. Here, the small-
est and less variable times are achieved with BiPS due
to the usage of cache locking. Thus, reactions to timer
events are most predictable with BiPS and hardware
timers, which are therefore the best choice for the ex-
ecution of protocols with time-critical behavior.
3
This timer is processed in non-interrupt mode and with
lowest priority (if priorities are supported by the OS).
sender
receiver
2
receiver
1
logic analyzer
slot
r1
sfd
r1
slot
r2
sfd
r2
Figure 4: Experiment setup with three Imote 2 (one sender
and two receivers) to evaluate the accuracy of SFD-based
synchronization and medium slotting.
5.3 SFD-based Synchronization
According to the CC 2420’s datasheet, the process-
ing delay at receivers when detecting an SFD is typ-
ically 3 µs (TI, 2013). However, this time does not
include the delay until an SFD is recognized in soft-
ware, which additionally worsens the accuracy if ex-
ecution delays differ. To detect an SFD with low la-
tency, the CC 2420 provides an output pin signaliz-
ing the detection of an SFD. This pin is connected
to a GPIO (General Purpose Input/Output) pin of the
microcontroller, thereby enabling the triggering of
hardware interrupts.
In the following, the time difference in detecting
an SFD between several nodes is evaluated, where the
comparison is restricted to BiPS and Tiny OS, since
RIOT does not provide a CC 2420 driver. By compar-
ing delays at two receivers, we ensure that the same
piece of code is executed on all nodes of interest and
all results can be ascribed to different detection delays
in the nodes’ transceiver and variations in execution
times.
The conducted experiment consists of three
Imote 2 (see Fig. 4): One sender and two receivers.
The receivers are connected via two GPIO pins with a
Sigma2 logic analyzer
4
running with a sampling rate
of 100 MHz. After detecting a rising edge at the SFD
pin of the transceiver, the receivers raise the GPIO pin
sfd
r1
and sfd
r2
, respectively.
5
The second GPIO pin
4
http://www.asix.net/dbg sigma.htm
5
In Tiny OS, we extended the CC2420ReceiveP and
CC2420TransmitP component for this purpose.
PEC 2016 - International Conference on Pervasive and Embedded Computing
24
TinyOS BiPS
−4 −2 0 2 4
difference [µs]
Figure 5: Accuracy of SFD detection between both re-
ceivers.
difference [µs]
frequency
Mean: −1.01 µs
Median: −0.13 µs
SD: 14.21 µs
TinyOS
−40 −30 −20 −10 0 10 20 30 40
0 200 400 600
difference [µs]
frequency
Mean: 0.02 µs
Median: 0.02 µs
SD: 0.41 µs
BiPS
−40 −30 −20 −10 0 10 20 30 40
0 200 400 600
Figure 6: Accuracy of the detection of slot starts between
both receivers.
(slot
r1
, slot
r2
) is raised 10 ms after the detection of the
SFD to emulate virtual medium slotting and to eval-
uate the accuracy of slot bounds. For this purpose, a
timer is activated whose expiration time is based on
a timestamp, which was stored when detecting the
SFD.
6
Besides the control of GPIO pins, no further
application is running. In total, 1500 observations are
made with BiPS as well as TinyOS.
The results are shown in Figs. 5 and 6. In Fig. 5,
the accuracy of detecting SFD events in software is
presented. Here, the median of difference is for BiPS
as well as TinyOS almost 0µs; as expected due to the
usage of identical receivers. However, the variation
with TinyOS is much larger than with BiPS (standard
deviations 1.5µs vs. 0.06µs), thereby indicating that
the detection accuracy of SFDs with TinyOS suffers
from diverging execution delays. With BiPS, on the
other hand, delays are almost constant.
Figure 6 presents the differences in the perception
of slot starts 10 ms after the SFD event. Here, the dif-
ferences with TinyOS are very large and spread within
a range of [36.23µs, 30.58µs], where differences
6
Timestamp is taken early at driver level.
with BiPS are almost constant. Besides the more inac-
curate detection of SFDs, the significant deterioration
with TinyOS is mainly caused by the missing usage
of the Imote 2’s µs-hardware timers, which are fully
exploited by BiPS but not by TinyOS.
5.4 Portability
Since BiPS is a tailored OS for the Imote 2 platform
and highly optimized for the PXA271 processor, it is
compartively hard to port it to another platform. More
precisely, the effort depends on the features, which the
target platform can offer. If e.g., the platform does not
provide an MMU, the whole protection and debug-
ging facility of BiPS cannot be ported. On the other
hand, if an MMU is provided, a deep knowledge of
the core hardware is needed to port the memory man-
agement of BiPS to the target.
Also, if caches are provided but cache locking is
missing, the jitter of time-critical events will worsen
due to cache eviction. On the other hand, if there are
no caches at all, jitter will reduce, but the overall ex-
ecution time will rise. Thus, the results obtained in
Table 1 cannot easily be assumed for all platforms.
However, since the modularity of the architecture,
as seen in Fig. 1, is retained in the source code struc-
ture, it is possible to omit or replace the parts, which
are needed to adapt the framework to a new platform.
6 RELATED WORK
In the literature, several evaluations can be found
(e.g., in (Harvan and Sch
¨
onw
¨
alder, 2008; Silva et al.,
2009; Basmer et al., 2011)) showing that the behav-
ior and performance of a protocol highly-depends on
the implementation. In this regard, the used OS,
which is in the WSN domain often TinyOS or Con-
tiki (Dunkels et al., 2004), is crucial. However, most
protocol implementations do not scrutinize the han-
dling of concurrency in the used OS. Thus, it is often
unclear in particular, if a protocol is announced to
support real-time guarantees – how timing constraints
of the protocol are satisfied and if provided prioritiza-
tion measures are actually sufficient. In the following,
our outline of related work first covers common OSs
used for protocol implementations and compares their
suitability for real-time applications. Afterward, we
relate the capabilities of BiPS as protocol framework
with various MAC protocols with existing solutions.
The most common OS for WSNs is probably
TinyOS, an extensive and popular OS ported to many
hardware platforms. TinyOS is event-driven and tasks
are scheduled cooperatively in FIFO or EDF order.
BiPS A Real-time-capable Protocol Framework for Wireless Sensor Networks
25
Tasks are not preempted by other tasks, although in-
terrupt handlers, commands, and events can preempt
a task. Since version 2, there is also support for
full multi-threading and synchronization primitives,
yet w.r.t. the Imote 2 platform, some features like
MMU and data caches are no longer used. TinyOS
does not offer a mechanism to run the communication
stack in a privileged context, such that protocols with
stringent timing constraints are not easy to imple-
ment. Additionally, the modular structure of TinyOS
increases the amount and variance of execution delays
(see Sect. 5.2). Applications for TinyOS are written
in a specialized C dialect, called nesC, rendering the
learning curve steeper for C/C++ programmers.
Another OS, RIOT, was designed for the Internet
of Things, with a special focus on real-time commu-
nication (Hahm et al., 2013b). RIOT comes with full
multi-threading support and uses IPC (Inter-Process
Communication) to pass messages between modules,
but does not offer memory protection or advanced
measures on fault detection. The implementation of
time-critical protocols still demands some program-
ming tricks. Though there is no native port of RIOT
for the Imote 2, it can run on this platform as exten-
sion of BiPS, where all RIOT processes are scheduled
by the BAS of BiPS. Like BiPS, RIOT offers support
for C(++).
Another well-known OS is Contiki (Dunkels et al.,
2004), focused on heavily resource-constrained de-
vices. Processes are scheduled cooperatively, al-
though there is a mechanism for light-weight multi-
threading, called Protothreads, and also an additional
library offering full multi-threading support. Real-
time tasks can be employed for time-critical code and
a lot of additional functionalities are given. However,
memory protection has never been a goal of Contiki.
Programs for Contiki are written in constrained C,
i.e., not the full language is supported, with a heavy
use of C macros.
W.r.t. BiPS’s contribution as protocol framework,
there is up to our knowledge no approach with a sim-
ilar flexible integration of multiple MAC protocols.
Existing approaches are instead severely restricted
in the number and activation of supported proto-
cols. This holds both for established communication
standards like IEEE 802.15.4 (IEEE, 2011), Wire-
lessHART (IEC, 2010), and ISA 100.11a (IEC, 2012),
and for proposals from research like Z-MAC (Rhee
et al., 2008), ER-MAC (Sitanayah et al., 2010), and
(Gilani et al., 2013). In general, all proposals es-
tablish some kind of time frame (often called super-
frame) and combine TDMA- with CSMA/CA. The
pattern of allocated contention-based/-free regions is
often fixed or time slots have constant length. Thus,
compared to virtual slot regions in BiPS, the individ-
ual protocols’ application is highly constrained. Fur-
thermore, they are limited to one reservation-based
and one best effort protocol, and do not support fur-
ther classes of protocols.
7 CONCLUSION
This paper presents BiPS, a real-time-capable proto-
col framework for WSNs based on the Imote 2 plat-
form. The key contributions of BiPS are twofold:
First, from a protocol design perspective, it provides
various MAC protocols, interfaces for the flexible us-
age of them, and an infrastructure to add further MAC
protocols. Thereby, BiPS enables the usage of differ-
ent MAC protocols for different message types in one
scenario. This helps to fit the communication require-
ments and characteristics in an optimal way with min-
imal overhead (e.g., reserved bandwidth). Second,
from an implementation perspective, it brings support
for OS functionalities to run real-time-capable proto-
cols and less time-critical applications in compliance
with time constraints of the protocols. In a series of
experiments, this paper shows that with BiPS, the pre-
dictability of delays to process external events is sig-
nificantly improved. Thereby, evidence is provided
that BiPS outperforms existing solutions w.r.t. the
suitability for real-time systems.
Different from state-of-the-practice protocol im-
plementations, our approach is not based on a univer-
sal (real-time) OS but on a specially developed light-
weight and protocol-centric OS. We justify this de-
cision by the experience that compliance with time
constraints is one of the most crucial tasks of imple-
mentations in distributed real-time systems and that
the support of multiple processes/tasks with extensive
synchronization measures is less important and is ac-
tually often not needed in typical WSN applications.
However, we also admit that this makes BiPS a very
specific solution, dedicated to applications with strict
real-time requirements regarding communication and
reaction time. This also holds for the required tailor-
ing for the used hardware platform needed to meet the
real-time constraints, which on the other hand implies
drawbacks and additional efforts regarding the porta-
bility.
In our future work, we are going to exploit the us-
age of multiple channels. Furthermore, we will shift
the focus to higher layers (e.g., a QoS routing proto-
cols and service-based middleware) for which BiPS
will serve as fundament.
PEC 2016 - International Conference on Pervasive and Embedded Computing
26
REFERENCES
Basmer, T., Schomann, H., and Peter, S. (2011). Implemen-
tation Analysis of the IEEE 802.15.4 MAC for Wire-
less Sensor Networks. In Mobile and Wireless Net-
working (iCOST), Int. Conference on Selected Topics
in.
Braun, T., Christmann, D., Gotzhein, R., and Mater, A.
(2014a). SDL Implementations for Wireless Sen-
sor Networks - Incorporation of PragmaDev’s RTDS
into the Deterministic Protocol Stack BiPS. In Sys-
tem Analysis and Modeling: Models and Reusability
- 8th International Conference, SAM 2014, Valencia,
Spain, September 29-30, 2014. Proceedings, volume
8769 of Lecture Notes in Computer Science, pages
271–286. Springer.
Braun, T., Gotzhein, R., and Kuhn, T. (2014b). Mode-based
Scheduling with Fast Mode-Signaling – A Method for
Efficient Usage of Network Time Slots. Journal of
Advances in Computer Networks (JACN), 2:48–57.
Christmann, D., Gotzhein, R., and Rohr, S. (2012). The Ar-
bitrating Value Transfer Protocol (AVTP) - Determin-
istic Binary Countdown in Wireless Multi-Hop Net-
works. In Computer Communications and Networks
(ICCCN), 21st International Conference on.
Cunha, A., Koubaa, A., Severino, R., and Alves, M.
(2007). Open-ZB: an Open-source Implementation of
the IEEE 802.15.4/ZigBee Protocol Stack on TinyOS.
In IEEE 4th Int. Conference on Mobile Adhoc and
Sensor Systems, MASS 2007, 8-11 October 2007,
Pisa, Italy, pages 1–12. IEEE Computer Society.
Dunkels, A., Gronvall, B., and Voigt, T. (2004). Contiki - a
lightweight and flexible operating system for tiny net-
worked sensors. In Local Computer Networks, 2004.
29th Annual IEEE Int. Conference on, pages 455–462.
Elyengui, S., Bouhouchi, R., and Ezzedine, T. (2015).
LOADng Routing Protocol Evaluation for Bidirec-
tional Data flow in AMI Mesh Networks. CoRR,
abs/1506.06357.
Farooq, M. O. and Kunz, T. (2011). Operating Systems
for Wireless Sensor Networks: A Survey. Sensors,
11(6):5900–5930.
Gilani, M. H. S., Sarrafi, I., and Abbaspour, M. (2013).
An Adaptive CSMA/TDMA Hybrid MAC for Energy
and Throughput Improvement of Wireless Sensor Net-
works. Ad Hoc Networks, 11(4):1297–1304.
Glaropoulos, I., Vukadinovic, V., and Mangold, S. (2014).
Contiki80211: An IEEE 802.11 Radio Link Layer
for the Contiki OS. In High Performance Com-
puting and Communications, 2014 IEEE 6th Intl
Symp on Cyberspace Safety and Security, 2014 IEEE
11th Intl Conf on Embedded Software and Syst
(HPCC,CSS,ICESS), pages 621–624.
Gotzhein, R. and Kuhn, T. (2011). Black Burst Syn-
chronization (BBS) A Protocol for Deterministic
Tick and Time Synchronization in Wireless Networks.
Computer Networks, 55(13):3015–3031.
Hahm, O., Baccelli, E., G
¨
unes, M., W
¨
ahlisch, M., and
Schmidt, T. C. (2013a). RIOT OS: Towards an OS
for the Internet of Things. In INFOCOM.
Hahm, O., Baccelli, E., G
¨
unes, M., W
¨
ahlisch, M., and
Schmidt, T. C. (2013b). RIOT OS: Towards an OS
for the Internet of Things. In 32nd IEEE Int. Con-
ference on Computer Communications (INFOCOM),
Poster Session.
Harvan, M. and Sch
¨
onw
¨
alder, J. (2008). TinyOS Motes on
the Internet: IPv6 over 802.15.4 (6lowpan). Praxis
der Informationsverarbeitung und Kommunikation,
31(4):244–251.
Hauer, J.-H. (2009). TKN15.4: An IEEE 802.15.4 MAC
Implementation for TinyOS 2. Technical Report
TKN-08-003, Technical University Berlin.
IEC (2010). Industrial Communication Networks - Wireless
Communication Network and Communication Pro-
files - WirelessHART (IEC 62591 ed 1.0).
IEC (2012). Industrial Communication Networks - Wireless
Communication Network and Communication Pro-
files - ISA 100.11a (IEC 62734 ed 1.0).
IEEE (2011). IEEE Standard 802 Part 15.4: Low-Rate
Wireless Personal Area Networks (LR-WPANs). IEEE
Computer Society, New York, NY, USA.
ISO (2004). Controller Area Network (CAN), ISO 11898.
ITU-T (2012). ITU-T Recommendation Z.100 (12/11) -
Specification and Description Language - Overview
of SDL-2010.
Kopetz, H. (1997). Real-Time Systems Design Principles
for Distributed Embedded Applications. Kluwer Aca-
demic Publishers.
Koubaa, A., Alves, M., and Tovar, E. (2006). A Compre-
hensive Simulation Study of Slotted CSMA/CA for
IEEE 802.15.4 Wireless Sensor Networks. In Factory
Communication Systems, IEEE Int. Workshop on.
MEMSIC Inc. (2013). Imote2 datasheet.
Pereira, N., Andersson, B., Tovar, E., and Rowe, A.
(2007). Static-Priority Scheduling over Wireless Net-
works with Multiple Broadcast Domains. In RTSS
’07: Proceedings of the 28th IEEE International Real-
Time Systems Symposium, pages 447–456, Washing-
ton, DC, USA. IEEE Computer Society.
Rhee, I., Warrier, A., Aia, M., Min, J., and Sichitiu, M. L.
(2008). Z-MAC: a Hybrid MAC for Wireless Sensor
Networks. IEEE/ACM Trans. Netw., 16(3):511–524.
Silva, R., Silva, J. S., and Boavida, F. (2009). Evaluating
6LowPAN Implementations in WSNs. Proceedings of
9th Conferncia sobre Redes de Computadores Oeiras,
Portugal, 21.
Sitanayah, L., Sreenan, C. J., and Brown, K. N. (2010).
Emergency Response MAC Protocol (ER-MAC) for
Wireless Sensor Networks. In Abdelzaher, T. F.,
Voigt, T., and Wolisz, A., editors, Proceedings of the
9th Int. Conference on Information Processing in Sen-
sor Networks, IPSN, Stockholm, Sweden. ACM.
TI (2013). CC2420 Datasheet. Revision SWRS041c.
Wang, X. and Kar, K. (2005). Throughput Modelling
and Fairness Issues in CSMA/CA-based Ad-hoc Net-
works. In INFOCOM 2005. 24th Annual Joint Con-
ference of the IEEE Computer and Communications
Societies. Proceedings IEEE, volume 1, pages 23–34.
Ziouva, E. and Antonakopoulos, T. (2002). CSMA/CA Per-
formance under High Traffic Conditions: Through-
put and Delay Analysis. Computer Communications,
25(3):313 – 321.
BiPS A Real-time-capable Protocol Framework for Wireless Sensor Networks
27