See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/328027684

Denial-of-Sleep Defenses for IEEE 802.15.4 Coordinated Sampled Listening

(CSL)

Preprint · July 2018

CITATIONS READS

0 646

2 authors:

Konrad-Felix Krentz Christoph Meinel

Siemens German University of Digital Science
25 PUBLICATIONS 160 CITATIONS 1,518 PUBLICATIONS 17,131 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Konrad-Felix Krentz on 02 October 2018.

The user has requested enhancement of the downloaded file.

 Denial-of-Sleep Defenses for IEEE 802.15.4 Coordinated Sampled Listening (CSL)

Konrad-Felix Krentz and Christoph Meinel

affiliation: Hasso-Plattner-Institut, Universität Potsdam
postal address: Hasso-Plattner-Institut, P.O. Box 900460, 14440 Potsdam, Germany
e-mail: {first name.surname}@hpi.de
corresponding author: Konrad-Felix Krentz

Abstract
Coordinated sampled listening (CSL) is a standardized medium access control protocol for IEEE 802.15.4 networks, also col-
loquially called “ZigBee networks”. Unfortunately, CSL comes without any protection against so-called denial-of-sleep attacks.
Such attacks deprive energy-constrained devices of entering low-power sleep modes, thereby draining their charge. Repercussions
of denial-of-sleep attacks include long outages, violated quality-of-service guarantees, and reduced customer satisfaction. How-
ever, while CSL has no built-in denial-of-sleep defenses, there already exist denial-of-sleep defenses for a predecessor of CSL,
namely ContikiMAC. In this paper, we make two main contributions. First, motivated by the fact that CSL has many advantages
over ContikiMAC, we tailor the existing denial-of-sleep defenses for ContikiMAC to CSL. Second, we propose several security
enhancements to these existing denial-of-sleep defenses. In effect, our denial-of-sleep defenses for CSL mitigate denial-of-sleep
attacks significantly better, as well as protect against a larger range of denial-of-sleep attacks than the existing denial-of-sleep de-
fenses for ContikiMAC. We show the soundness of our denial-of-sleep defenses for CSL both analytically, as well as empirically
using a whole new implementation of CSL.
Keywords: Internet of things, link layer security, MAC security, denial-of-sleep

1. Introduction wake-up sequence periodic

collision avoidance wake up
Sender

Transmit
Receive
The IEEE 802.15.4 radio standard has become a main Sleep
choice for implementing Internet of things (IoT) applications periodic wake up wake-up payload acknowledgement
frame frame frame
[1]. Part of the success of IEEE 802.15.4 is the availability of
Receiver

5 numerous energy-efficient medium access control (MAC) pro-
tocols for IEEE 802.15.4 networks, all of which fall into one of
two classes [2]. Synchronous MAC protocols, on the one hand,
depend on network-wide time synchronization. Such kind of
MAC protocols often feature high reliability, but a basic issue
10 with them is that, in wireless mesh networks like IEEE 802.15.4
networks, securing network-wide time synchronization is noto-
riously difficult. Thus, unsurprisingly, many synchronous MAC
protocols were found vulnerable [3, 4]. Asynchronous MAC
protocols, on the other hand, work without network-wide time
15 synchronization and hence avoid many of the vulnerabilities of
synchronous MAC protocols in the first place. 30
1.1. Coordinated Sampled Listening (CSL)
A standardized asynchronous MAC protocol is coordinated
sampled listening (CSL) [1]. Its operation is shown in Figure
35
20 1. Rather than staying in the energy-consuming receive mode,
CSL wakes up periodically to scan the channel for a so-called
“wake-up frame”. Wake-up frames are transmitted by CSL in
a continuous sequence before transmitting an actual “payload
frame” and contain the time when the transmission of that pay-
40
25 load frame begins. This hint enables the receiver of a wake-up
frame to temporarily go back to sleep until the transmission of
Transmit
Receive
Sleep
periodic wake up periodic wake up periodic wake up
Figure 1: Transceiver modes while CSL transmits a unicast frame. The sender
shortly enables the receive mode before transmitting for doing a clear channel
assessment (CCA).
the payload frame is about to begin. If the payload frame is a
unicast frame, CSL expects an “acknowledgement frame” in re-
sponse. The absence of an acknowledgement frame causes CSL
to retransmit after a random back-off period, unless a maximum
number of retransmissions is reached already.
Additionally, CSL comprises two crucial optimizations.
The first optimization relates to the length of wake-up se-
quences. This length defaults to span a whole wake-up interval,
but is shortened in what the IEEE 802.15.4 radio standard calls
“synchronized transmissions”. As part of this optimization,
CSL piggybacks its current phase, i.e., the time until its next
wake up, on acknowledgement frames, as well as, optionally, on
payload frames. This piggybacked data enables CSL to learn
and keep track of the wake-up times of neighboring nodes.
Later, when transmitting a unicast frame to a receiver whose

Preprint submitted to Computer Networks July 25, 2018

 Denial-of-Sleep Sender Receiver Attacker
Attacks against CSL

External Internal

Ding-Dong Pulse-Delay Collision Chatty Deaf

Ditching Attacks Attacks Node Node
Broadcast Unicast PDoS
Attacks Attacks Attacks

Figure 2: Classification of denial-of-sleep attacks against CSL

Figure 3: Collision attack against CSL’s wake-up frames. Interfering with uni-
cast transmissions ensues energy-consuming retransmissions, as well as the un-
certainty about the affected neighbor’s wake-up time to extend.
wake-up time is known, CSL only transmits wake-up frames for
the clock drift-based uncertainty about the receiver’s expected Sender Receiver Attacker
wake-up time and starts this wake-up sequence right before the
45 receiver may wake up at the earliest. The second optimization
relates to CSL’s throughput. If CSL has multiple outgoing pay-
load frames for the same destination, CSL supports to transmit
these frames in bursts. That is, without sending another wake-
up sequence, CSL transmits such pending unicast or broadcast
50 frames right after the last received acknowledgement or sent
Figure 4: Pulse-delay attack against broadcast frames. Jamming frames that
broadcast frame, respectively. Receivers are informed whether piggyback a CSL phase and replaying these jammed frames delayed misleads
more payload frames follow through the Frame Pending flag of victim nodes into learning wrong wake-up times, likely causing subsequent
the IEEE 802.15.4 frame header. transmissions to the affected neighbor to fail.
As for security, CSL relies on IEEE 802.15.4 security to en-
55 crypt the payload of non-wake-up frames, as well as to ensure
the authenticity and freshness of non-wake-up frames. Wake- Unlike ding-dong ditching, collision and pulse-delay at-
up frames, by contrast, are left unsecured by CSL. Internally, tacks are external denial-of-sleep attacks that primarily aim to
for implementing encryption and authentication, IEEE 802.15.4 mislead CSL into staying more time in the energy-consuming
security uses a variant of Counter with CBC-MAC (CCM). Be- 90 transmit mode. In collision attacks, an attacker attains this
60 sides CCM, another core component of IEEE 802.15.4 security goal by jamming unicast frames, acknowledgement frames, or
is the addition of an incrementing frame counter to each out- wake-up frames that precede unicast frames, all of which results
going secured frame. These frame counters serve in generating in retransmissions, as shown in Figure 3 [7]. To some extent,
and restoring a secured frame’s CCM nonce, as well as in as- CSL’s optimization of shortening wake-up sequences mitigates
suring its freshness at the receiver side. 95 collision attacks. But, collision attacks can also deprive CSL
of updating stored wake-up times for long, thus causing the
65 1.2. Denial-of-Sleep Attacks against CSL uncertainty about the affected neighbor’s wake-up time to in-
crease and wake-up sequences to him to stretch. In pulse-delay
However, while IEEE 802.15.4 security prevents basic
attacks, on the other hand, an attacker (i) jams frames that
eavesdropping, injection, and replay attacks, it does not protect
100 piggyback a CSL phase and (ii) replays these jammed frames
against any of the denial-of-sleep attacks shown in Figure 2.
delayed, as shown in Figure 4 [8]. Such delayed frames pass
Therein, we generally distinguish external and internal denial-
IEEE 802.15.4 security since IEEE 802.15.4 security considers
70 of-sleep attacks. Whereas external denial-of-sleep attacks can
secured frames fresh as long as they contain a greater frame
be launched without possessing any cryptographic keys, in-
counter than the previously accepted secured frame from the
ternal denial-of-sleep attacks require access to one or more
105 sender. Further, since the piggybacked CSL phase of a delayed
appropriate cryptographic keys.
frame is relative to its time of transmission, CSL learns wrong
As a further umbrella term, ding-dong ditching subsumes
wake-up times as a result. Ultimately, subsequent unicast trans-
75 external denial-of-sleep attacks that primarily aim to mislead
missions to the affected neighbor are likely to fail, thus ensuing
CSL into staying more time in the energy-consuming receive
retransmissions, too. Again, these repercussions exacerbate
mode [5]. For this, an attacker can, e.g., (i) inject or replay
110 over time as the uncertainty about the affected neighbor’s wake-
wake-up frames and (ii) inject or replay a payload frame [6].
up time extends. An alternative way to carry out pulse-delay
In effect, CSL will receive and process these transmissions.
attacks works via a hidden wormhole [8].
80 Of course, IEEE 802.15.4 security eventually rejects injected
Beyond that, an attacker may exploit captured crypto-
and replayed payload frames, but only after having consumed
graphic keys to add two kinds of energy-draining nodes to
energy for their reception and processing already. Moreover,
115 the victim network. First, a “chatty node” sends single frames
as CSL sends acknowledgement frames immediately without
or bursts of frames to its neighbors. In particular, chatty nodes
checking the authenticity and freshness of received unicast
may launch path-based denial-of-service (PDoS) attacks, where
85 frames beforehand, CSL will consume additional energy for
a chatty node sends packets to distant destinations [9]. In effect,
acknowledging injected and replayed unicast frames.

2
 every node along the path expends energy for receiving, pro-170
120 cessing, and forwarding these packets. Second, a “deaf node”
intentionally acknowledges unicast frames only after a couple
of retransmissions or not at all.
1.3. Denial-of-Sleep Defenses for ContikiMAC
Thus far, there seems to be no effort on protecting CSL
125 against denial-of-sleep attacks, but there do exist defenses175
against external denial-of-sleep attacks for a predecessor of
CSL, namely ContikiMAC [10, 11, 5, 12]. Like CSL, Contiki-
MAC wakes up periodically to scan the channel for incoming
transmissions. Yet, unlike CSL, ContikiMAC does so by per-
130 forming two clear channel assessments (CCAs). If one of these180
CCAs indicates a busy channel, ContikiMAC stays in receive
mode to potentially receive a frame. Correspondingly, an out-
going frame is repeatedly transmitted for a whole wake-up
interval, spaced by short silence periods in between. When re-
135 peatedly transmitting a unicast frame, ContikiMAC breaks up185
prematurely if an acknowledgement frame is received within
such a silence period. Conversely, if a unicast frame remains
unacknowledged, ContikiMAC retransmits by repeatedly trans-
mitting that unicast frame after a random back-off period again,
140 unless a maximum number of retransmissions is reached al-190
ready. Also like CSL, ContikiMAC learns the wake-up times
of neighboring nodes so as to shorten sequences of unicast
frames.
1.4. Contributions 195
145 This paper makes two main contributions:
• We tailor the existing defenses against external denial-of-
sleep attacks for ContikiMAC to CSL. Switching from
ContikiMAC to CSL brings many advantages, as we de-200
tail in Section 5. Crucially, CSL does not depend on
150 CCAs to detect incoming transmissions, which makes
CSL more resilient to interference and easier to config-
ure [13].
205
• In the course of tailoring the existing defenses against
external denial-of-sleep attacks for ContikiMAC to CSL,
155 we apply several security enhancements to them. Gen-
erally, we improve on their effectiveness, fix all their
vulnerabilities we identified, as well as adapt them to210
also protect against internal denial-of-sleep attacks. A
detailed description of all our security enhancements is
160 postponed to Section 4.3.
1.5. Organization 215
The rest of this paper is structured as follows. Section 2
completes our discussion of related work. Section 3 presents
the design of our denial-of-sleep defenses for CSL. Section 4
165 analyzes the security of our denial-of-sleep defenses for CSL.
Section 5 outlines our practical implementation. Section 6 re-220
ports on our empirical evaluation. Section 7 concludes and sug-
gests topics for future research. For reference, Appendix A
summarizes our notations.
3
2. Related Work
In this section, we complete our discussion of related work,
beginning with efforts related to basic IEEE 802.15.4 security
and coming on to existing denial-of-sleep defenses thereafter.
2.1. IEEE 802.15.4 Security
One major limitation of IEEE 802.15.4 security is that it
leaves session key establishment unspecified. The proposals for
filling this gap can be clustered into public-key cryptography
(PKC)-based [14, 15, 16], key distribution center (KDC)-based
[17], and key predistribution-based protocols [18, 19]. Unfor-
tunately, all current PKC- and KDC-based protocols appear to
be susceptible to denial-of-sleep attacks since, by injecting re-
quests for session key establishment, attackers can either trigger
energy-consuming processing or communication [20]. By con-
trast, key predistribution-based protocols process requests for
session key establishment energy efficiently and can thus reach
higher denial-of-sleep resilience.
Accordingly, our denial-of-sleep defenses for CSL build
upon a key predistribution-based protocol - the Adaptive Key
Establishment Scheme (AKES) in particular [18, 19]. AKES
establishes pairwise or group session keys by means of a three-
way handshake. A node A initiates this three-way handshake
by broadcasting a HELLO. The HELLO contains a cryptographic
random number RA and is either authenticated with pairwise
or group session keys. However, only receivers that already
established session keys with A can distinguish between fresh
authentic, and inauthentic or replayed HELLOs from A. Any
receiver B that wishes to establish session keys with A stores A
as a tentative neighbor and replies with a HELLOACK. Like A’s
HELLO, B’s HELLOACK also contains a cryptographic random
number RB . Furthermore, the HELLOACK is authenticated with
0
a pairwise session key KA,B that is derived from the predis-
tributed shared secret KA,B between A and B, as well as the
two cryptographic random numbers RA and RB . Optionally, the
HELLOACK also contains B’s group session key KB,∗ encrypted
0
with KA,B . Upon receipt of the HELLOACK from B, A checks
its authenticity, among others. If successful, A completes the
three-way handshake by sending an ACK to B. Analogous to B’s
HELLOACK, A’s ACK is authenticated using the pairwise session
0
key KA,B and may carry A’s group session key KA,∗ encrypted
0
with KA,B . After completing this three-way handshake, A and B
0
store each other as permanent neighbors and can use KA,B - or
their group session keys KA,∗ and KB,∗ - as CCM keys in IEEE
802.15.4 security.
Another major limitation is that IEEE 802.15.4 security
only provides sequential freshness, i.e., only ascertains that no
frame is accepted more than once [21]. By contrast, strong
freshness is provided if the receiver of a frame can additionally
ensure that the frame was sent within a limited time span prior
to its reception [21]. Strong freshness is desirable in IEEE
802.15.4 networks since delaying data or control traffic may
cause various issues.
Among the solutions for achieving strong freshness, Krentz
et al.’s Intra-Layer Optimization for IEEE 802.15.4 Security
 (ILOS) appears to be unique in that it neither incurs a com-
225 munication overhead nor requires network-wide time synchro-
nization [12]. The idea of ILOS is to let IEEE 802.15.4 security280
cooperate with ContikiMAC on replacing frame counters with a
new concept called wake-up counters. As their name suggests,
wake-up counters are incremented in lockstep with Contiki-
230 MAC’s wake ups, even if ContikiMAC has to skip over a wake
up due to sending at that time. Furthermore, as we will dis-285
cuss shortly, Krentz et al.’s denial-of-sleep-protected version of
ContikiMAC maintains precise estimates of the wake-up times
of neighboring nodes, which enables the prediction and restora-
235 tion of a neighbor’s current wake-up counter. Thus, unlike
frame counters, wake-up counters need not be sent along with290
secured frames, which reduces the security-related per-frame
overhead. More importantly, if a secured frame is delayed by a
critical period of time, receivers will end up restoring a wrong
240 CCM nonce. Consequently, receivers consider delayed secured
frames inauthentic, thereby achieving strong freshness. Addi-
tionally, ILOS also prevents pulse-delay attacks, at least when295
delayed secured frames exceed ILOS’ quite loose bounds.
2.2. Denial-of-Sleep Defenses
245 2.2.1. Ding-Dong Ditching
An effective pattern for defending against ding-dong ditch-300
ing emerged to be the embedding of one-time passwords
(OTPs) in synchronization or frame headers [22, 23, 24, 25,
26, 11, 12]. Here, the general idea is to validate the embedded
250 OTPs during reception and, if an OTP turns out invalid, to dis-
card the incoming transmission without receiving the rest of it.305
For generating these OTPs, it is common to pass a key deriva-
tion function a symmetric key and a varying portion, such as a
frame counter [23, 26, 11], a timeslot index [22, 24], a random
255 number [25, 11], or a wake-up counter [12].
Krentz et al.’s Practical On-The-fly Rejection (POTR) ap-
plies the “OTP pattern” to ContikiMAC and AKES [11]. Nor-310
mally, POTR derives OTPs from wake-up counters, as well as
AKES’ group session keys [12]. However, since group session
260 keys are not in place while AKES establishes them, POTR de-
rives the OTPs of AKES’ HELLOACKs and ACKs from a predis-
tributed network-wide key and AKES’ cryptographic random315
numbers instead. The OTPs of HELLOs, on the other hand, are
also derived from wake-up counters and group session keys, but
265 only permanent neighbors of a HELLO sender can validate them.
To prevent ding-dong ditching with HELLOs anyway, POTR co-
operates with AKES. More specifically, as AKES rate-limits the320
number of outgoing HELLOACKs, POTR rejects HELLOs with in-
valid OTPs during reception at times when AKES will not send
270 a HELLOACK due its rate limitation anyway [19].
2.2.2. Collision Attacks
There is comparatively little research on protecting against
collision attacks [22, 27, 5]. Ren et al. proposed to reactively
switch to a low-power sleep mode upon detecting a collision at-
275 tack [27]. Yet, their reactive defense suffers from the issue that,
if a victim node detects collision attacks, unicast transmissions
to this node will fail. As a result, a victim node’s neighbors330
may also suspect a collision attack, potentially creating a snow-
ball effect. Alternatively, Krentz et al. proposed a proactive
defense against collision attacks for ContikiMAC, entitled Se-
cure Phase-Lock Optimization (SPLO) [5]. The approach of
SPLO is to confine the maximum length of sequences of unicast
frames throughout a session by sending a keep-alive frame to a
permanent neighbor whose wake-up time was not updated for
a critical period of time. The overhead of sending these keep-
alive frames is considered low since AKES prescribes to send
keep-alive frames to uncommunicative permanent neighbors
anyway for the purpose of freeing allocated random-access
memory (RAM) [18]. Further, as SPLO deletes permanent
neighbors that do not acknowledge keep-alive frames, collision
attacks against the keep-alive frames themselves may actually
reduce a victim node’s energy consumption. This is because
no upper-layer traffic will be sent to a deleted neighbor up until
reestablishing session keys with him.
2.2.3. Pulse-Delay Attacks
In addition to mitigating collision attacks against Contiki-
MAC, SPLO also makes ContikiMAC resistant to pulse-delay
attacks. For this, the approach of SPLO is to exclusively use ac-
knowledgement frames for learning wake-up times and to not
only ensure the authenticity of acknowledgement frames, but
also their strong freshness [5]. SPLO inherits both these ideas
from Ganeriwal et al.’s Secure Pairwise Synchronization Proto-
col (SPS) [8]. However, note that neither SPS nor SPLO actu-
ally prevent pulse-delay attacks. Rather, both confine the maxi-
mum offset due to pulse-delay attacks. This undetectable offset
needs to be considered when estimating a receiver’s wake-up
time. Fortunately, unlike in ILOS, this undetectable offset is
tiny in SPS and SPLO.
2.2.4. Chatty Nodes
Many so-called en-route filtering schemes were proposed to
mitigate PDoS attacks [28, 29, 9]. Their common idea is to add
extra authentication tags to packets so that intermediary nodes
can filter out packets “en-route”. However, current en-route fil-
tering schemes incur a high communication overhead and do
not protect against chatty nodes that inject or replay broadcast
frames. Hence, we conjecture that a more lightweight, as well
as more holistic defense would be to rate-limit the number of
frames that a node is willing to receive from a particular neigh-
bor. Furthermore, if a neighbor exceeded this rate, its frames
could be rejected on the fly. In this paper, we build the foun-
dation of such a defense by enabling receivers to attribute valid
OTPs to particular neighbors already during reception. Cur-
rently, this is hardly feasible either due to deriving OTPs from
group keys [26, 11, 12] or due to leaving out support for broad-
325 cast frames in the first place [7, 23, 24, 25].
2.2.5. Deaf Nodes
Though only designed to protect from collision and pulse-
delay attacks, SPLO actually mitigates deaf nodes, too [5]. This
is because SPLO confines the maximum length of sequences of
unicast frames and thereby lowers the worst-case energy con-
sumption for retransmissions.
4
 3. Denial-of-Sleep Defenses for CSL
385
To protect CSL against all of the above denial-of-sleep at-
tacks, we propose CSL-enabled and security-enhanced versions
335 of POTR, SPLO, and ILOS, named POTR++, SPLO++, and
ILOS++, respectively. The focus of this section is on introduc-
ing the design of POTR++, SPLO++, and ILOS++. Then, in390
Section 4 we analyze the security of POTR++, SPLO++, and
ILOS++, as well as point out their security enhancements over
340 POTR, SPLO, and ILOS.
3.1. POTR++: CSL-Enabled and Enhanced POTR 395
The basic design of POTR and POTR++ is quite similar.
Both introduce a special frame format, as well as correspond-
ing procedures for validating incoming frames during recep-
345 tion. Also, both integrate with AKES so as to resolve the con-
flict that frames exchanged during session key establishment400
have to be protected against ding-dong ditching without ses-
sion keys in place. Finally, both POTR and POTR++ derive
OTPs from wake-up counters. On the other hand, a fundamen-
350 tal difference between POTR and POTR++ is that POTR++ ex-
clusively derives OTPs from pairwise session keys in order to
provide a basis for pinpointing and evicting chatty nodes, too.405
Another notable difference between POTR and POTR++ is that
POTR++ includes support for burst forwarding.
355 3.1.1. Frame Format
When we defined the frame format of POTR++, a first de-
sign decision was where to embed OTPs. A first option is to410
leave wake-up frames unsecured and to embed OTPs in payload
frames. But, a drawback of this first option is that receivers of
360 unwanted payload frames will always need to receive both an
entire wake-up frame plus the beginning of the payload frame
before they can reject it. A second option is to embed OTPs in415
wake-up frames along with all necessary information for decid-
ing whether to receive the payload frame. Yet, while this second
365 option accelerates the rejection of unwanted payload frames,
it will extend wake-up frames and hence necessitate prolong-
ing the time in receive mode during CSL’s periodic wake ups.420
Thus, there is a trade-off between rejection speed and the dura-
tion of periodic wake ups. As shown in Figure 5, POTR++ goes
370 for faster rejection speed. In that figure, l denotes the length of
an OTP in bits. The choice of l is a trade-off between per-frame
overhead and resistance to guessing attacks. Furthermore, λ de-425
notes the “burst index” - the first payload frame after a wake-up
sequence always has burst index λ = 0, a payload frame that
375 follows right after has burst index λ = 1, and so on.
Note that a format for broadcast frames is missing in Figure
5. This is because POTR++ requires sending broadcast frames430
as normal unicast frames to each permanent neighbor one after
another. Though this seems to incur a high overhead, this way
380 of transmitting broadcast frames may actually save energy, es-
pecially when it comes to implementing channel hopping, as
we demonstrate in Section 6.1. Three further advantages of435
sending broadcast frames as normal unicast frames are (i) that,
5
in this way, pairwise session keys can serve to secure broad-
cast transmissions without difficulty, (ii) that broadcast trans-
missions securely update stored wake-up times as a side effect
(thanks to SPLO++), thereby lowering the amount of keep-
alive frames, and (iii) that failed broadcast transmissions are
recognized and retried, thus improving reliability.
HELLOs, however, are still to be broadcasted as usual since
not-yet-discovered neighbors should receive HELLOs, as well.
This leaves the problem of how to authenticate HELLOs with
pairwise session keys. To this end, POTR++ includes multiple
CCM message integrity codes (MICs) in a HELLO, one for each
permanent neighbor, and generates them using the respective
pairwise session key. The ordering of the CCM MICs corre-
sponds to the ordering of the sender’s neighbor list. Thus, for
extracting its MIC, the receiver of a HELLO from a permanent
neighbor needs to know its index within the sender’s neighbor
list. Fortunately, AKES exchanges these indices while estab-
lishing session keys. POTR++ also uses these indices as 1-byte
source addresses in some types of wake-up frames.
3.1.2. On-the-Fly Rejection
Depending on which type of frame is being received,
POTR++ performs different checks, which we detail below.
Throughout, if any check fails, POTR++ disables the receive
mode immediately.
Wake-Up Frames. When receiving a wake-up frame, POTR++
first checks that its length complies with POTR++’s frame
format. Then, POTR++ proceeds to perform special checks,
depending on which type of payload frame follows. If a HELLO
follows, POTR++ ensures (i) that the HELLO is not destined
to a co-located IEEE 802.15.4 network by inspecting the des-
tination personal area network identifier (PAN ID) contained
in the wake-up frame and (ii) that receiving the HELLO does
not result in exceeding a maximum rate of incoming HELLOs.
POTR++ implements this rate limitation via a leaky bucket
counter (LBC), as shown in Figure 6. This nicely allows the
short-term rate of incoming HELLOs to overshoot, while still
enforcing a maximum long-term rate of incoming HELLOs [19].
Yet, to avoid penalizing authentic HELLOs, the LBC is decre-
mented again if a HELLO turns out authentic. If a HELLOACK fol-
lows, POTR++ validates (i) that AKES recently sent a HELLO
at all, (ii) that AKES can reply with an ACK, which may not
be true since AKES restricts itself to sending a maximum rate
of ACKs, (iii) that the HELLOACK is not destined to a co-located
IEEE 802.15.4 network by inspecting the destination PAN ID
contained in the wake-up frame, and (iv) that receiving the
HELLOACK does not ensue exceeding a maximum rate of in-
coming HELLOACKs. Again, POTR++ implements this rate
limitation via an LBC and decrements that LBC if a HELLOACK
turns out authentic. If an ACK or normal unicast frame follows,
POTR++ ascertains that the OTP matches the expected one.
Concretely, if A sends an ACK or normal unicast frame to B, the
OTP is expected to match the l-bit truncated CCM MIC over the
frame length of the ACK or normal unicast frame. Furthermore,
this CCM MIC is to be generated using the pairwise session
0
key KA,B between A and B as CCM key, and the CCM nonce
 5 bytes 1 bit 7 bits 6 bits 2 bits 2 bytes 1 byte 1 byte bits 2 bytes 1 byte
HELLO: Destination Rendezvous Time
PAN ID
HELLOACK: Frame Extended
SHR Unused Length Frame Subtype Rendezvous
ACK: Type Source Payload OTP Time
normal unicast: Address Frame’s
Length

the rendezvous time is encoded as the number of remaining wake-up frames

(a)

5 bytes 1 bit 7 bits 6 bits 1 bit 1 bit 2/8 bytes 1 byte 1 byte
HELLO: CCM MICs
Source
HELLOACK: Frame Extended
SHR Unused Length Frame
Unused Address Payload
ACK: Type CCM MIC
normal unicast: Command Frame Pending Sequence Number Pe di g Fra e’s Le gth

distinguishes upper-layer traffic and link-layer commands, such as keep-alive frames omitted if no frame is pending

(b)

5 bytes 1 bit 6 bits 2 bits

7 bits 2 bytes
authenticated acknowledgement: Frame Extended CSL Phase CCM MIC
SHR Unused Length Frame Unused
unauthenticated acknowledgement: Type

omitted if

(c)

Figure 5: POTR++’s format of (a) wake-up frames, (b) payload frames, and (c) acknowledgement frames. Sticking with the standardized format of these frames
would require transmitting many more fields that are functionally unnecessary, only delaying on-the-fly rejection and increasing energy consumption. Therefore,
POTR++ departs from the standardized format of CSL frames by leveraging the IEEE 802.15.4-compliant customization mechanism of “extended frame types”.

inauthentic HELLOs fill the bucket 460 POTR++’s frame format.

the u ket’s apa ity defines the a epta le
short-term rate of inauthentic HELLOs
the u ket’s leakage rate defines the
acceptable long-term rate of inauthentic HELLOs
Figure 6: Mitigation of ding-dong ditching with HELLOs
465
shown in Table 1. Finally, if all the type-specific checks passed,
440 POTR++ also validates that the wake-up frame’s rendezvous
time is not unreasonably late.
470
Payload Frames. When receiving a payload frame, POTR++
performs the following checks. In the case of a HELLO from a
non-permanent neighbor, POTR++ ensures that AKES can re-
445 ply with a HELLOACK at all. This may not be the case because
AKES restricts itself to sending a maximum rate of HELLOACKs475
and because AKES may run out of memory. Note, however,
that AKES is interested in receiving HELLOs from permanent
neighbors since AKES uses such HELLOs to trigger a reestab-
450 lishment of session keys after reboots, as well as to suppress
redundant HELLOs [18]. In the case of a HELLOACK, POTR++
validates that its length complies with POTR++’s frame format.480
In the case of an ACK or normal unicast frame, POTR++ ascer-
tains that its length matches the one that was announced in the
455 wake-up frame. Furthermore, if more normal unicast frames
burst in, POTR++ always makes sure that their length matches
the length announced in the previous one. 485
Acknowledgement Frames. When receiving an acknowledge-
ment frame, POTR++ just ensures that its length complies with
6
3.2. SPLO++: CSL-Enabled and Enhanced SPLO
SPLO and SPLO++ use similar means for preventing pulse-
delay attacks, as well as for mitigating collision attacks. To
prevent pulse-delay attacks, on the one hand, both exclusively
use acknowledgement frames for updating wake-up times and
not only ensure the authenticity of acknowledgement frames,
but also their strong freshness. To mitigate collision attacks,
on the other hand, both keep the maximum uncertainty about
a permanent neighbor’s wake-up time below a user-defined
threshold tu by sending keep-alive frames in the absence of
upper-layer traffic. However, a crucial difference between the
two is that SPLO++ leverages the predictability of clock drifts
so as to lower the amount of keep-alive frames. Also, SPLO++
comprises a largely revised initialization of wake-up times. In
the following, we first specify how SPLO++ securely updates
learned wake-up times, as well as how SPLO++ schedules
keep-alive frames. Later in Section 3.3.2, we also specify
SPLO++’s initialization of wake-up times.
3.2.1. Resisting Pulse-Delay Attacks
Once wake-up times are initialized, each node A stores for
every permanent neighbor B the last known wake-up time τA,B
of B. A exclusively updates τA,B when receiving a fresh authen-
tic acknowledgement frame from B. For ensuring the authentic-
ity of B’s acknowledgement frame, on the one hand, A just ver-
ifies the CCM MIC of the acknowledgement frame. However,
unlike specified by CSL, all nodes must check the authenticity
of normal unicast frames before replying with an authenticated
 Sender Receiver Attacker
acknowledgement
acknowledgement
Figure 7: SPLO++ checks the authenticity of received ACKs and normal uni-
cast frames before replying with an authenticated acknowledgement frame, as,
otherwise, if an attacker guesses an OTP right, he would get a replayable ac-
knowledgement frame. Guessing attacks can even be launched while another
node is sending due to the capture effect.
acknowledgement frame, as, otherwise, attacks become possi-
ble, as illustrated in Figure 7. For ensuring the strong fresh-
490 ness of B’s acknowledgement frame, on the other hand, two
complementary measures of SPLO++ are to (i) only accept ac-
knowledgement frames within a limited time frame of duration
ta and (ii) generate CCM nonces like specified in Table 1. The
effectiveness of these two measures will become apparent in
495 Section 4.1.2. Only after ensuring the authenticity and fresh-
ness of a received acknowledgement frame, A updates τA,B . For
this, A extracts B’s CSL phase (i.e., the time between when the
transmission of the acknowledgement frame’s synchronization
header (SHR) has ended and the B’s next wake-up time) from
500 the authenticated acknowledgement frame. Then, A uses this
CSL phase to calculate a new value of τA,B .
3.2.2. Mitigating Collision Attacks
530
SPLO++ schedules keep-alive frames like follows. Ini-
tially, a node A has no estimate of its clock drift ηA,B against a
505 new permanent neighbor B, which is why A can only assume
A’s and B’s clocks to diverge by 2θ at most, where θ is the
frequency tolerance of the employed clocks. Hence, A has
to send B a keep-alive frame 2θ tu
seconds after discovering B,535
unless A sends another normal unicast frame to B beforehand
510 anyway. For example, if tu = 2ms and θ = 15ppm, A sends
the first keep-alive frame to B after 66s of inactivity, minus a
bit to account for retransmissions. However, every time when
A updates τA,B to τ0A,B , A can compute its current clock drift540
τ0 −τA,B
against B as ηA,B = (ω0 A,B−ωA,B )×tw , where tw is the interval of
A,B
515 CSL’s periodic wake ups, ωA,B is the wake-up counter of B at
time τA,B , and ω0A,B is the wake-up counter of B at time τ0A,B .
From then on, A compensates for ηA,B and assumes ηA,B to be545
correct up to θη < θ. Thus, A can also raise the duration after
which A sends B keep-alive frames, yet not too much as ηA,B
520 may deviate from the real clock drift too much otherwise [30].
Also note that, in order to get a precise estimate of ηA,B , the
difference τ0A,B − τA,B should be sufficiently long [30], which550
may necessitate delaying the initialization and updating of ηA,B
until two sufficiently distant samples are in place.
525 3.3. ILOS++: CSL-Enabled and Enhanced ILOS
Like ILOS, ILOS++ has the responsibilities to generate and555
restore CCM nonces, as well as to initialize and maintain all
7
Table 1: Format of CCM Nonces
Occasion CCM Nonce
wake-up IDA kαkλkωB , where IDA is A’s MAC ad-
frame from A dress, α = 0, λ = 0, and ωB is B’s wake-
to B up counter at time of receiving the wake-up
frame
HELLO from A IDA kαkλkωA , where IDA is A’s MAC ad-
dress, α = 1, λ = 0, and ωA is A’s wake-
up counter when sending the HELLO - ωA is
also contained in the HELLO, but a perma-
nent neighbor B of A restores ωA like spec-
ified in Section 3.3
unicast frame IDA kαkλkωB , where IDA is A’s MAC ad-
from A to B dress, α = 2, λ is the burst index, and ωB
is B’s wake-up counter at time of receiving
the wake-up frame that led to receiving the
unicast frame
acknowledge- IDA kαkλkωA , where IDA is A’s MAC ad-
ment frame dress, α = 3, λ is the burst index of the
from A to B acknowledged unicast frame, and ωA is A’s
wake-up counter at time of receiving the
wake-up frame that led to receiving the ac-
knowledged ACK or normal unicast frame
relevant data. In the following, we detail how ILOS++ meets
these responsibilities.
3.3.1. Generation and Restoration of CCM Nonces
ILOS++ generates CCM nonces like shown in Table 1. The
security of this construction of CCM nonces will be proven in
Section 4.1, but, basically, rests on two complementary mea-
sures. On the one hand, ILOS++ avoids collisions among CCM
nonces of different types of frames by using a common base for-
mat and the distinguishing field α. On the other hand, ILOS++
also avoids collisions among CCM nonces of the same frame
type by including the burst index, as well as either the sender’s
or the receiver’s wake-up counter.
As CCM nonces either contain the receiver’s or the sender’s
wake-up counter, it is either necessary that the sender predicts
the receiver’s wake-up counter or that the receiver restores the
sender’s wake-up counter. Predicting a wake-up counter is nec-
essary to generate the CCM nonces of unicast frames and OTPs.
To do so, a sender A predicts a receiver B’s wake-up counter at
time of receiving A’s wake-up frame as ωA,B + tw ηA,B
t−τA,B
, where
τA,B is A’s last known wake-up time of B, ωA,B is B’s wake-up
counter at time τA,B , t is the expected wake-up time of B around
which A arranges its wake-up sequence, and ηA,B = 1 if not yet
initialized. Restoring a wake-up counter is only necessary to
restore the CCM nonce of a HELLO from a permanent neighbor.
To aid receivers of HELLOs in doing so, senders have to time
HELLOs so that the end of the transmission of a HELLO’s SHR
falls right in the middle between two consecutive wake ups of
the sender. This enables a permanent neighbor B of A to restore
A’s wake-up counter at time of transmitting a HELLO by round-
t−τ
ing ωB,A + twB,A ηB,A − 12 , where τB,A is B’s last known wake-up

605
Figure 8: Initialization of wake-up counters and wake-up times in parallel to
AKES’ three-way handshake
610
time of A, ωB,A is A’s wake-up counter at time τB,A , t is when
the HELLO’s SHR arrived, and ηB,A = 1 if not yet initialized.
560 For implementing the prediction and restoration of wake-
up counters, ILOS++ requires a node A to store each perma-
nent neighbor B’s wake-up counter ωA,B at time τA,B . In this
regard, note that when SPLO++ updates τA,B to τ0A,B , A already615
knows B’s wake-up counter ω0A,B at time τ0A,B because A had to
565 correctly predict B’s wake-up counter ω0A,B at time τ0A,B . Thus,
whenever SPLO++ updates τA,B to τ0A,B , ILOS++ updates ωA,B
to the correctly predicted wake-up counter ω0A,B of B at time
τ0A,B without any additional calculations. 620
3.3.2. Initialization of Wake-Up Counters and Times
570 SPLO++ and ILOS++ initialize wake-up times and coun-
ters in parallel to AKES’ three-way handshake, as shown in Fig-
ure 8. Therein, the HELLO carries A’s current wake-up counter
ωA . Though attackers can delay HELLOs, B takes this informa-625
tion for granted and initializes ωB,A to ωA and τB,A to the time
575 when the HELLO’s SHR arrived minus t2w . As B generates the
CCM nonce of the HELLOACK, B uses this data for the first time
so as to predict A’s wake-up counter. If this prediction is in-
correct, B will not receive an ACK in response and eventually
delete A from its list of tentative neighbors. Otherwise, it may630
580 still be the case that τB,A is slightly offset due to pulse-delay at-
tacks. Hence, B corrects τB,A upon receiving A’s ACK like is ex-
plained shortly. Similarly, B’s HELLOACK carries B’s CSL phase
ϕ1 and B’s current wake-up counter ωB . A also takes this data
for granted and uses it to initialize τA,B and ωA,B . In addition,635
585 the HELLOACK carries a cryptographic random number Q that
is newly generated for each transmission and retransmission.
After receiving B’s HELLOACK, A acknowledges with an unau-
thenticated acknowledgement frame. As opposed to authenti-
cated acknowledgement frames, unauthenticated acknowledge-640
590 ment frames can be sent immediately without executing AKES’
checks beforehand. If all of AKES’ checks turn out to succeed,
A then sends an ACK to B, containing ϕ2 and Q, where ϕ2 is A’s
CSL phase when receiving the HELLOACK’s SHR. When gen-
erating the CCM nonce of the ACK, A uses τA,B and ωA,B for
645
595 the first time so as to predict B’s wake-up counter. Likewise,
only if A predicts B’s wake-up counter correctly, A will get an
authentic acknowledgement frame in response and, else, will
delete B from its list of permanent neighbors. Next, upon re-
ceiving an authentic ACK from A, B ensures that Q is unmod-
ified and uses ϕ2 to correct its value of τB,A . Also, B updates
650
600
ωB,A to A’s correctly predicted wake-up counter at time of re-
ceiving B’s HELLOACK. Lastly, B replies with an authenticated
8
acknowledgement frame containing B’s CSL phase. If A finds
B’s authenticated acknowledgement frame authentic, A uses ϕ3
to correct its value of τA,B and updates ωA,B to B’s correctly
predicted wake-up counter at time of receiving A’s ACK.
4. Security Analysis
In this section, we analyze the security of POTR++, SPLO++,
and ILOS++. We start with showing that basic IEEE 802.15.4
security is preserved if using wake-up counter-based CCM
nonces and replay protection. Next, we argue that POTR++
and SPLO++ greatly mitigate denial-of-sleep attacks against
CSL. Finally, in Section 4.3, we point out our security enhance-
ments over POTR, SPLO, and ILOS.
4.1. IEEE 802.15.4 Security
4.1.1. Uniqueness of CCM Nonces
In order for CCM nonces to be secure, they must never reoc-
cur in conjunction with the same key. Owing to using pairwise
session keys and since all CCM nonces include the sender’s
MAC address and the distinguishing field α, it suffices to ensure
that no CCM nonce coincides with other CCM nonces from a
particular sender to a particular receiver for each value of α
within a session:
HELLOs. As for α = 1, the inclusion of the sender’s wake-up
counter ensures that such CCM nonces differ from previous
ones of a particular sender within a session since CSL needs
to transmit wake-up frames for an entire wake-up interval be-
fore sending another HELLO, thus causing a sender’s wake-up
counter to increment in the meantime.
Unicast Frames. As for α = 2, CCM nonces include the burst
index and the receiver’s wake-up counter at time of receiving
the wake-up frame that led to receiving the unicast frame. The
inclusion of the burst index distinguishes CCM nonces of nor-
mal unicast frames within a burst. Thus, it remains to ensure
that the included wake-up counter differs in “spaced” transmis-
sions of unicast frames from a particular sender to a particular
receiver within a session. As SPLO++ keeps the uncertainty
about a receiver’s wake-up time below tw within a session, CSL
will arrange the wake-up sequences of spaced transmissions
of unicast frames around distinct wake ups within a session.
Hence, the included wake-up counter indeed differs in spaced
transmissions of unicast frames within a session.
Authenticated Acknowledgement Frames. As for α = 3, CCM
nonces include the burst index of the acknowledged unicast
frame and the sender’s wake-up counter at time of receiving
the wake-up frame that led to receiving the acknowledged uni-
cast frame. Since the burst index differs when acknowledging
individual normal unicast frames of a burst, it remains to ensure
that the included wake-up counter differs when acknowledging
spaced transmissions of unicast frames within a session. This
holds true since CSL can receive at most one wake-up frame
per wake up and because the wake-up counter at time of a wake
up is unique within a session.
 4.1.2. Freshness Guarantees
655 Recall that strong freshness is provided if a receiver can not
only ensure that a frame was never accepted before, but also that
it was sent within a limited time span prior to its reception [21].
Together, SPLO++ and ILOS++ do achieve strong freshness,
as we argue below.
710
660 HELLOs. Let A be a permanent neighbor of B. Suppose B re-
ceives a HELLO from A delayed by ≥ tw . Then, B will round A’s
wake-up counter to a different value than was used by A to gen-
erate the CCM nonce of the HELLO. As a result, B will consider
the HELLO inauthentic. The same reasoning applies to why B715
665 never considers the same HELLO authentic twice.
Unicast Frames. Suppose B receives A’s unicast frame f de-
layed by ≥ tw . Then, B will derive f ’s CCM nonce from a
different wake-up counter than was predicted by A. Hence, B720
will consider f ’s CCM MIC inauthentic and discard f . How-
670 ever, a subtlety is that the sender of a unicast frame may miss
the corresponding acknowledgement frame and decide to re-
transmit. As a result, a receiver may accept the same unicast
frame twice. To this end, ILOS++ adds “sequence numbers”725
to normal unicast frames, as shown in Figure 5b. These se-
675 quence numbers are maintained on a per-neighbor basis and are
incremented each time a normal unicast frame is transmitted
to a permanent neighbor, yet not incremented when retransmit-
ting the last normal unicast frame. Consequently, receivers can
identify and filter out duplicates. On the other hand, adding se-730
680 quence numbers to ACKs and HELLOACKs is unnecessary since
AKES detects duplicated ACKs and HELLOACKs by itself.
Authenticated Acknowledgement Frames. Suppose B receives
an authenticated acknowledgement frame f delayed by > ta .735
Since B only accepts acknowledgement frames for ta , f must
685 originally have been sent in response to a different unicast
frame. There are two cases how this may happen. First, f was
originally sent in response to a different normal unicast frame
of the same burst. In this case, B will include a different burst740
index in f ’s CCM nonce. Second, f was originally sent in
690 response to a previous spaced transmission of a unicast frame.
In this case, B will include a different wake-up counter in f ’s
CCM nonce. In both cases, B ends up considering the CCM
MIC of f inauthentic and rejects f . 745
Unauthenticated Acknowledgement Frames. The strong fresh-
695 ness of unauthenticated acknowledgement frames, which are
solely sent in response to HELLOACKs, is ensured only after
the corresponding ACK comes in. Suppose B receives an unau-
thenticated acknowledgement frame f from A delayed by > ta .750
Since B only accepts acknowledgement frames for ta , f must
700 originally have been sent in response to a different HELLOACK.
However, the originally acknowledged HELLOACK contained a
different cryptographic random number Q, thus causing B to
reject A’s ACK and AKES’ three-way handshake to remain in-755
complete.
705 4.2. Denial-of-Sleep Resilience
4.2.1. Ding-Dong Ditching
Below, we argue that POTR++ mitigates ding-dong ditch-
ing, regardless of which type of frame a ding-dong ditcher in-
jects or replays.
HELLOs and HELLOACKs. POTR++ mitigates ding-dong ditch-
ing with HELLOs and HELLOACKs by only letting such types of
frames pass at a maximum rate, if they seem valid and are of
interest at all. To exemplify the effectiveness of this defense, let
us compare the time that CSL needs to spend in receive mode
during its periodic wake ups if tw = 125ms and l = 16 any-
way with the additional worst-case time in receive mode when
1
accepting HELLOs at a rate of 15 Hz. Assuming the standard
data rate of IEEE 802.15.4 in the 2.4-GHz band of 250 kbit s ,
the time in receive mode per wake up is ((12+5)×8) = 0.544ms
250
minimum. Here, 12 is the number of bytes of a maximum-
length wake-up frame as per POTR++’s frame format and +5
allows for detecting a wake-up frame’s SHR when the begin-
ning of the previous wake-up frame was just missed. Thus, on
a percentage basis, the base time in receive mode is 100% ×
0.544ms
= 0.43%. For comparison, receiving one maximum-
tw
length HELLO takes (133×8)
250 = 4.256ms. Moreover, we have to
account for the unfortunate case that the SHR of the wake-up
frame of a HELLO may be detected right at the end of a peri-
odic wake up. In such cases, receivers need to stay in receive
mode slightly longer to see whether the SHR is the beginning
of a wake-up frame. In the case of a HELLO, receivers may need
to receive up to 6 more bytes as per Figure 5a, which trans-
lates into an additional time in receive mode of up to 0.192ms.
Altogether, the additional worst-case time in receive mode is
0.192ms + 4.256ms. Yet, on a percentage basis, receiving one
1
maximum-length HELLO at 15 Hz only adds 0.03% to the base
time in receive mode at most. Thus, when configuring POTR++
to only let HELLOs and HELLOACKs pass at a moderate rate,
POTR++ makes CSL practically resistant to ding-dong ditch-
ing with HELLOs and HELLOACKs.
ACKs and Normal Unicast Frames. One method for ding-dong
ditching with ACKs or normal unicast frames is to (i) inject or
replay a wake-up sequence and (ii) inject or replay an ACK or
normal unicast frame. However, for this method to work out,
ding-dong ditchers need to come up with valid OTPs as in-
valid OTPs trigger an on-the-fly rejection. Crafting a valid OTP
seems impossible since a ding-dong ditcher has, by definition,
no cryptographic key of the victim network. Also, guessing
an OTP or replaying an OTP that is older than ≥ tw is point-
less because such an OTP will turn out invalid with probability
1 − 2−l . On the other hand, a victim may consider a replayed
OTP that is younger than < tw valid, but this means that the
victim node missed the original transmission. Hence, in terms
of energy consumption, there will be no difference compared
to receiving the original transmission. This even holds true if a
ding-dong ditcher tampers with the length of an ACK or normal
unicast frame because this invalidates the replayed OTP.
Another method for ding-dong ditching with ACKs or nor-
mal unicast frames is to “jump on” the unicast transmissions of
9
760 legitimate nodes. That is, after a victim node received a wake-
up frame or a normal unicast frame with the Frame Pending
flag set, a ding-dong ditcher can inject or replay an ACK or nor-810
mal unicast frame. But, the only repercussion of such an attack
is that the victim node receives the ding-dong ditcher’s frame
765 instead of the legitimate frame. This does not result in an in-
creased energy consumption because, if the attacker’s frame has
a different length than was previously announced, the attacker’s815
frame will be rejected on the fly.
Acknowledgement Frames. Since POTR++ validates the length
770 of acknowledgement frames during reception, ding-dong ditch-
ers can not cause a higher energy consumption by injecting
long ones. 820
4.2.2. Collision Attacks
Next, we argue that SPLO++ mitigates collision attacks,
775 too.
HELLOACKs and ACKs. Owing to initializing wake-up times
early on, the sender of a HELLOACK or ACK already has an esti-825
mate of its new neighbor’s wake-up time and can hence shorten
wake-up sequences before HELLOACKs and ACKs. Furthermore,
780 since this estimate is initialized only a couple of seconds be-
fore transmitting a HELLOACK or ACK, the uncertainty about a
new neighbor’s wake-up time is tiny and hence wake-up se-830
quences before HELLOACKs and ACKs are very short. Therefore,
retransmissions of HELLOACKs and ACKs also consume little
785 energy, which is why collision attacks against transmissions of
HELLOACKs and ACKs are benign.
Normal Unicast Frames. Recall that SPLO++ keeps the uncer-835
tainty about a permanent neighbor’s wake-up time stays below
a user-defined threshold tu . Thus, wake-up sequences before
790 normal unicast frames do not exceed a maximum duration of
about tu . In practice, wake-up sequences can get slightly longer
than tu since CSL rounds up the number of required wake-up840
frames and always has to send one more wake-up frame to also
reach receivers that missed the beginning of a wake-up frame.
795 4.2.3. Pulse-Delay Attacks
In Section 4.1.2, we showed that authenticated acknowl-
edgement frames turn out inauthentic if they are delayed by845
> ta . This means that, if the receiver of an authentic acknowl-
edgement frame uses the contained CSL phase to compute the
800 sender’s last wake-up time, the offset due to pulse-delay at-
tacks is upper-bounded by ta . As also discussed in Section
4.1.2, delaying unauthenticated acknowledgement frames by850
> ta causes AKES’ three-way handshake to fail, thereby pre-
venting pulse-delay attacks while initializing wake-up times up
805 to ta , as well. Altogether, pulse-delay attacks cause no reper-
cussions if senders account for the undetectable offset ta when
estimating wake-up times. 855
10
4.2.4. Chatty Nodes
POTR++ provides a basis for detecting chatty nodes through
the adoption of pairwise session keys. In fact, owing to deriv-
ing OTPs from pairwise session keys, a chatty node that sends
plenty of normal unicast frames or ACKs with valid OTPs can
be considered compromised as no other node than the chatty
node and the victim node can access their pairwise session key.
Likewise, authentic HELLOs and HELLOACKs can be attributed
to the sender due to authenticating them with pairwise session
keys.
4.2.5. Deaf Nodes
Deaf nodes are also mitigated by SPLO++ by confining the
maximum length of wake-up sequences.
4.3. List of Security Enhancements
• Thanks to its move to pairwise session keys, POTR++
allows for pinpointing and evicting chatty nodes. Of
independent interest, authenticating link layer frames
via pairwise session keys also prevents certain attacks
against upper-layer protocols, such as fragment duplica-
tion attacks [31].
• A potential vulnerability of the original version of POTR
is the dual use of group session keys as CCM keys and for
generating OTPs. Though POTR XORs group session
keys before using them to generate OTPs, the security
of this construction is left unproven. POTR++ fixes this
potential vulnerability by staying within the framework
of CCM.
• The original version of SPLO does not shorten sequences
of HELLOACKs and ACKs and thus leaves transmissions
of HELLOACKs and ACKs vulnerable to collision attacks.
SPLO++ fixes this vulnerability by initializing wake-up
times earlier during AKES’ three-way handshake than
SPLO. This enables confining the maximum length of
wake-up sequences before HELLOACKs and ACKs already.
• Two other vulnerabilities of SPLO relate to the initial-
ization of wake-up times and counters. First, SPLO
acknowledges ACKs without checking their authenticity
beforehand, which leaves the initialization of wake-up
times and counters vulnerable to attacks like the one
shown in Figure 7. SPLO++ hence ensures the authen-
ticity of ACKs before acknowledging them. Second, in
SPLO, the cryptographic random number Q is gener-
ated by the HELLOACK receiver, which does not have the
desired effect. As argued in Section 4.1.2, SPLO++’s
solution to generate Q at the sender side now prevents
pulse-delay attacks against the initialization of wake-up
times.
• Lastly, while SPLO assumes clocks to diverge by θ at
most, SPLO++ goes a step further by estimating clock
drifts and compensating for them. As we show in Section
6, this makes SPLO++ outperform SPLO in mitigating
collision attacks.
860 5. Implementation
We implemented CSL along with our defenses for the
Contiki-NG operating system. Thus far, there seem to be only
two energy-efficient MAC protocols available for Contiki-NG,
namely ContikiMAC and timeslotted channel hopping (TSCH).
865 As mentioned already, ContikiMAC depends on CCAs to de-
tect transmissions, rendering ContikiMAC hard to configure
and susceptible to interference [13]. Moreover, there are three
more drawbacks of ContikiMAC compared to CSL. First, Con-
tikiMAC requires padding short frames with extra bytes, as
870 otherwise they may fall in between ContikiMAC’s two regular
CCAs [10]. Second, ContikiMAC is prone to duplicate recep-
tions of broadcast frames since senders need to strobe broadcast
frames not only for an entire wake-up interval, but once more
915
to cover corner cases [32]. Third, ContikiMAC is vulnerable
875 to a special kind of ding-dong ditching attack, namely straight-
forward jamming attacks [5]. While the synchronous MAC
protocol TSCH avoids all of these drawbacks, it is insecure,
as detailed in [4, 19]. Thus, our implementation of CSL is a
920
valuable contribution to the Contiki community.
880 Our target platform are CC2538 system on chips (SoCs),
which are built into many IoT devices, such as OpenMotes and
RE-Motes [33]. CC2538 SoCs comprise up to 512KB of pro-
gram memory, up to 32KB of RAM, and an 2.4-GHz IEEE
802.15.4 transceiver. This built-in transceiver, in particular,
885 supports parsing incoming frames during reception, as well as925
sending IEEE 802.15.4 frames back-to-back. These capabilities
are necessary to implement the on-the-fly rejection of POTR++
and the wake-up sequences of CSL.
A remarkable feature of our CSL implementation is its sup-
890 port for channel hopping, which generally proved to be an ef-930
fective means to withstand interference, as well as to allevi-
ate fading effects [34]. This feature is realized following Al
Nahas et al.’s generic channel hopping extension “MiCMAC”
to asynchronous MAC protocols [35]. The rationale of MiC-
895 MAC is to do each consecutive periodic wake up on a differ-935
ent pseudo-random channel. As for unicasts, a sender may be
able to predict a receiver’s current channel and otherwise re-
sorts to transmit on one channel for as long as it takes to revisit
this channel in the worst case. Fortunately, our implementation
900 works without this fallback mechanism since we derive chan-940
nels from wake-up counters and MAC addresses, both of which
are known to senders of unicast frames. However, as for broad-
casts, MiCMAC always requires transmitting on one channel
for as long as it takes to revisit this channel in the worst case.
905 Normally, this is a severe drawback of MiCMAC, but POTR++945
only requires broadcasting HELLOs as usual and requires send-
ing other broadcast frames as unicast frames anyway. Further-
more, HELLOs are sent very rarely once the network topology
becomes stable [18, 19].
950
910 6. Empirical Evaluation
In this section, we report on a set of experiments we con-
ducted to assess both the communication overhead and the ef-
955
fectiveness of our denial-of-sleep defenses for CSL. In sum, it
11
CSL without IEEE 802.15.4 security
CSL with IEEE 802.15.4 security
CSL with our denial−of−sleep defenses
wake−up frame
payload frame
acknowledgement frame
0 5 10 15 20 25 30
overall length of link layer fields (in bytes)
Figure 9: Link layer overhead when unicasting data
turned out that (i) our denial-of-sleep defenses actually reduce
the communication overhead as compared to the original ver-
sion of CSL, (ii) that our denial-of-sleep defenses render CSL
resistant to ding-dong ditching, and (iii) that our denial-of-sleep
defenses for CSL greatly mitigate collision attacks. Further-
more, in comparison to Krentz et al.’s denial-of-sleep-protected
version of ContikiMAC, our denial-of-sleep-protected version
of CSL mitigates both ding-dong ditching and collision attacks
significantly better.
6.1. Communication Overhead
An apparent drawback of our denial-of-sleep defenses for
CSL is their addition of new fields, such as OTPs. To asses this
overhead, the overall length of the link layer fields of wake-
up, payload, and acknowledgement frames was logged while
unicasting data. Furthermore, this was done using three differ-
ent configurations. First, all denial-of-sleep defenses, as well
as IEEE 802.15.4 security were disabled and the standardized
frame format was used. Second, IEEE 802.15.4 security was
then enabled. Finally, all our denial-of-sleep defenses were en-
abled, too. Throughout, 2-byte OTPs, 2-byte MACs addresses,
and 8-byte CCM MICs were used.
The, maybe surprising, results are shown in Figure 9. As for
wake-up frames, POTR++ actually reduces the overall length
of link layer fields. This is because POTR++ elides destina-
tion addresses and checksums, as well as because POTR++ en-
codes rendezvous times more concisely. As for payload frames,
POTR++ also reduces the overall length of link layer fields
by eliding checksums and source addresses. Furthermore, re-
call that all our denial-of-sleep defenses use wake-up counters,
which, unlike frame counters, need not be transmitted. As for
acknowledgement frames, POTR++, again, achieves signifi-
cant savings by encoding the CSL phase more concisely, as well
as by avoiding frame counters and checksums.
Another critical design decision of POTR++ is to send
broadcast frames as unicast frames to each permanent neigh-
bor one after another. To compare the energy consumption of
transmitting broadcast frames as usual and as unicast frames,
a network of 20 nearby OpenMotes was set up. The behavior
of the OpenMotes was as follows. After establishing session
keys with every other OpenMote and learning the clock drift
against each other OpenMote, an OpenMote began to send
maximum-length broadcast frames with a random delay of 0
 1 HELLO receive mode (24mA)
broadcast
number of channels
transmit mode (24mA)
2 HELLO
broadcast processing (13mA)
4 HELLO
broadcast
HELLO
8 broadcast
16 HELLO
broadcast
0 10 20 30 40 50
mean consumed charge (in mAs)
Figure 10: Consumed charge per transmission of a zero-padded HELLO and a
maximum-length broadcast frame
- 4.5min in between. In the background, each OpenMote ran
Contiki-NG’s tool “Energest” to trace the energy consumed for
transmitting these broadcasts (which are transmitted as unicast
frames), as well as AKES’ HELLOs (which are transmitted as
960 usual) [36]. For a fair comparison, each OpenMote padded its1015
HELLOs with as many zeroes as possible. Initially, each Open-
Mote ran our denial-of-sleep-protected version of CSL using
default settings, i.e., tu = 2.38ms; θ = 15ppm; θη = 3ppm;
keep-alive frames were sent after 5min of inactivity once the
965 clock drift was initialized; and the number of employed chan-1020
nels was 16. Then, this experiment was also repeated using 8,
4, 2, and 1 channel(s).
As shown in Figure 10, the energy consumed for pro-
cessing is very low, regardless of how broadcasts are sent.
970 This is because our implementation leverages the hardware-1025
accelerated CCM implementation of CC2538 SoCs and widely
avoids busy-waiting. Also, the energy consumed for receiv-
ing is very low, but is noticeable when transmitting broadcast
frames as unicast frames, which is due to performing more
975 CCAs and receiving acknowledgement frames. The bulk of the1030
energy is consumed for transmitting. Moreover, when trans-
mitting broadcast frames as usual, the energy consumption for
transmitting increases linearly with the number of channels,
whereas, when sending broadcast frames as unicast frames, the
980 energy consumption is independent of the number of channels.1035
On the other hand, when sending broadcast frames as unicast
frames, the energy consumption depends on the number of
permanent neighbors, which was always 19 in this experiment.
That said, many more neighbors than 19 do often not even fit
985 in the constrained RAM of IoT devices [37]. Altogether, these1040
results show that sending broadcast as unicast frames is not
only a viable choice, but actually advantageous in combination
with MiCMAC.
6.2. Resilience to Denial-of-Sleep Attacks
990 To put the resilience to ding-dong ditching of our denial-of-
sleep-protected version of CSL into perspective, the following
experiment compares the energy consumption of protected and
unprotected versions of CSL and ContikiMAC under unicast at-
tacks. This time, for gauging the energy consumption directly,1050
995 an OpenMote was connected with a µCurrent Gold and a Rigol
DS1000E oscilloscope in series like in [33]. In five successive
runs, the OpenMote’s energy consumption was gauged while
receiving injected maximum-length unicast frames if running
(i) the original version of CSL without IEEE 802.15.4 secu-
1000 rity, (ii) the original version of CSL with IEEE 802.15.4 se-
curity, (iii) our denial-of-sleep-protected version of CSL using
the default settings mentioned in Section 6.1, (iv) the origi-
nal version of ContikiMAC, and (v) Krentz et al.’s denial-of-
sleep protected version of ContikiMAC, which was configured
60 1005 to send keep-alive messages after 5min of inactivity and to as-
sume θ = 15ppm. Throughout, 2-byte OTPs, 2-byte MAC ad-
dresses, and 8-byte CCM MICs were used.
The results are shown in Figure 11a. As for the original
version of CSL, unicast attacks are rather severe since injected
1010 unicast frames are not only fully received, but also acknowl-
edged, as explained in the introduction. Moreover, when en-
abling IEEE 802.15.4 security, acknowledgement frames ad-
ditionally carry a CCM MIC, thereby aggravating unicast at-
tacks. As for our denial-of-sleep protected version of CSL, the
energy consumption actually does not increase as compared to
receiving no wake-up frame at all. This is because, if an OTP
turns out invalid, POTR++ disables the receive mode immedi-
ately, which often happens earlier than when CSL would stop
scanning for a wake-up frame. The original version of Con-
tikiMAC, on the other hand, behaves like the original version
of CSL. Both of them not only receive injected unicast frames,
but also acknowledge them. Moreover, as ContikiMAC first
searches the silence period in between two consecutively trans-
mitted unicast frames, the worst-case time in receive mode is
longer than that of the original version of CSL, even though
ContikiMAC sends shorter acknowledgement frames. Krentz et
al.’s denial-of-sleep-protected version of ContikiMAC greatly
mitigates unicast attacks, but, as opposed to our denial-of-sleep-
protected version of CSL, does not nullify the additional energy
consumption due to unicast attacks.
To compare the resilience to collision attacks of protected
and unprotected versions of CSL and ContikiMAC, the follow-
ing experiment was conducted. In five successive runs, two
OpenMotes ran the same five configurations that were men-
tioned above. In each run, the two OpenMotes sent maximum-
length unicast frames to each other with a random delay of 0
- 4.5min in between. Further, to simulate a collision attack,
these unicast frames were not acknowledged. The energy con-
sumed for transmitting and retransmitting these unicast frames
was traced via Energest. Throughout, the maximum number
of retransmissions was 5, burst forwarding was disabled, and a
wake-up interval of tw = 125ms was used.
As shown in Figure 11b, the original version of CSL turned
out to be particularly susceptible to collision attacks if IEEE
1045 802.15.4 security is disabled. This is because the simulated
collision attacks prevent both OpenMotes from learning each
other’s wake-up time, thus causing CSL to always transmit
wake-up sequences that span a whole wake-up interval. By con-
trast, when enabling IEEE 802.15.4 security, collision attacks
become much less severe. This positive result comes down
to the use of AKES for session key establishment. Specif-
ically, in the course of AKES’ three-way handshake, each
OpenMote sends one unicast frame to the other OpenMote and
12
 CSL without IEEE 802.15.4 security ●

CSL with IEEE 802.15.4 security ●

receive mode (24mA)
CSL with our denial−of−sleep defenses transmit mode (24mA)
ContikiMAC without IEEE 802.15.4 security processing (13mA)
ContikiMAC with denial−of−sleep defenses

0.00 0.10 0.20 0.30 0 5 10 15 20 25 30 35 40

consumed charge (in mAs) mean consumed charge (in mAs)

(a) (b)

Figure 11: Consumed charge due to (a) unicast attacks and (b) collision attacks

hence learns the other OpenMote’s wake-up time. Beyond that,1095 [3] X. Lu, M. Spear, K. Levitt, N. S. Matloff, S. F. Wu, A synchronization
1055 AKES sends keep-alive frames so as to check if a permanent attack and defense in energy-efficient listen-sleep slotted MAC protocols,
in: Proceedings of the Second International Conference on Emerging
neighbor is still in range. As a side effect, these keep-alive Security Information, Systems and Technologies (SECURWARE 2008),
frames update wake-up times and hence reduce the uncertainty IEEE, 2008, pp. 403–411.
about the other OpenMote’s wake-up time. Of course, an at-1100 [4] W. Yang, Q. Wang, Y. Qi, S. Sun, Time synchronization attacks in
tacker can also interfere with these keep-alive frames, but, as IEEE802.15.4e networks, in: Proceedings of the International Conference
on Identification, Information and Knowledge in the Internet of Things
1060 discussed in Section 2.2.2, this will usually decrease the energy (IIKI 2014), IEEE, 2014, pp. 166–169.
consumption of victim nodes. Nevertheless, AKES does not [5] K.-F. Krentz, Ch. Meinel, H. Graupner, Countering three denial-of-sleep
reliably defend against collision attacks because AKES sup-1105 attacks on ContikiMAC, in: Proceedings of the International Conference
presses keep-alive frames to permanent neighbors that recently on Embedded Wireless Systems and Networks (EWSN 2017), Junction,
2017, pp. 108–119.
sent a fresh authentic broadcast frame, which do not neces- [6] M. Brownfield, Y. Gupta, N. Davis, Wireless sensor network denial of
1065 sarily update wake-up times as a side effect. Our denial-of- sleep attack, in: Proceedings of the Sixth Annual IEEE SMC Information
sleep-protected version of CSL further reduces the mean con-1110 Assurance Workshop (IAW ’05), IEEE, 2005, pp. 356–364.
sumed charge due to collision attacks from 1.76mJ to 1.045mJ [7] A. D. Wood, J. A. Stankovic, Denial of service in sensor networks, IEEE
Computer 35 (10) (2002) 54–62.
by leveraging the predictability of clock drifts. Additionally, [8] S. Ganeriwal, C. Pöpper, S. Čapkun, M. B. Srivastava, Secure time syn-
SPLO++ enforces a maximum uncertainty about a permanent chronization in sensor networks, ACM Transactions on Information and
1070 neighbor’s wake-up time throughout a session. Similar to an1115 System Security (TISSEC) 11 (4) (2008) 23:1–23:35.
[9] J. Deng, R. Han, S. Mishra, Defending against path-based DoS attacks in
unsecured version of CSL, an unsecured version of Contiki-
wireless sensor networks, in: Proceedings of the 3rd ACM Workshop on
MAC strobes for a whole wake-up interval if the receiver’s Security of Ad Hoc and Sensor Networks (SASN ’05), ACM, 2005, pp.
wake-up time is unknown, thereby rendering collision attacks 89–96.
severe. Again, enabling AKES and SPLO greatly alleviates the1120 [10] A. Dunkels, The ContikiMAC radio duty cycling protocol, Tech. Rep.
T2011:13, Swedish Institute of Computer Science (2011).
1075 effects of collision attacks, but less than our version of SPLO. [11] K.-F. Krentz, Ch. Meinel, M. Schnjakin, POTR: practical on-the-fly re-
jection of injected and replayed 802.15.4 frames, in: Proceedings of the
International Conference on Availability, Reliability and Security (ARES
7. Conclusions and Future Work 1125 2016), IEEE, 2016, pp. 59–68.
[12] K.-F. Krentz, Ch. Meinel, H. Graupner, More Lightweight, yet Stronger
While IEEE 802.15.4 security protects CSL against basic 802.15.4 security through an intra-layer optimization, in: Proceedings of
eavesdropping, injection, and replay attacks, it offers no denial- the 10th International Symposium on Foundations & Practice of Security
of-sleep protection. To fill this gap, we have proposed CSL- (FPS 2017), Springer, 2017.
1130 [13] M. Sha, G. Hackmann, C. Lu, Energy-efficient low power listening for
1080 enabled and security-enhanced versions of POTR, SPLO, and wireless sensor networks in noisy environments, in: Proceedings of the
ILOS. Together, POTR++, SPLO++, and ILOS++ turned out 12th International Conference on Information Processing in Sensor Net-
to make CSL resistant to ding-dong ditching and pulse-delay works (IPSN ’13), ACM, 2013, pp. 277–288.
[14] A. d. l. Piedra, A. Braeken, A. Touhafi, Extending the IEEE 802.15.4
attacks, as well as resilient to collision attacks and deaf nodes.1135 security suite with a compact implementation of the NIST P-192/B-163
Furthermore, we have argued that POTR++ and ILOS++ pro- elliptic curves, Sensors 13 (8) (2013) 9704–9728.
1085 vide a basis for pinpointing and evicting chatty nodes. For fu- [15] G. Piro, G. Boggia, L. A. Grieco, Layer-2 security aspects for the IEEE
ture work, it remains to actually counter chatty nodes. Another 802.15.4e MAC, Internet-Draft, version 3 (2014).
[16] S. Sciancalepore, G. Piro, E. Vogli, G. Boggia, L. A. Grieco, G. Cavone,
interesting direction for future research is to further mitigate1140 LICITUS: a lightweight and standard compatible framework for securing
collision attacks by, e.g., adjusting transmission powers or re- layer-2 communications in the IoT, Computer Networks 108 (Supplement
acting to anomalous numbers of retransmissions. C) (2016) 66–77.
[17] A. Perrig, R. Szewczyk, J. Tygar, V. Wen, D. E. Culler, SPINS: security
protocols for sensor networks, Wireless networks 8 (5).
1090 References 1145 [18] K.-F. Krentz, Ch. Meinel, Handling reboots and mobility in 802.15.4 se-
curity, in: Proceedings of the 31st Annual Computer Security Applica-
[1] IEEE Standard 802.15.4 (2015). tions Conference (ACSAC ’15), ACM, 2015, pp. 121–130.
[2] P. Huang, L. Xiao, S. Soltani, M. Mutka, N. Xi, The evolution of MAC [19] K.-F. Krentz, Ch. Meinel, H. Graupner, Denial-of-sleep-resilient session
protocols in wireless sensor networks: a survey, IEEE Communications key establishment for 802.15.4 security: from adaptive to responsive, in:
Surveys Tutorials 15 (1) (2013) 101–120. 1150 Proceedings of the International Conference on Embedded Wireless Sys-
tems and Networks (EWSN 2018), Junction, 2018.

13
 [20] J. Großschädl, A. Szekely, S. Tillich, The energy cost of cryptographic Appendix A. Notations
key establishment in wireless sensor networks, in: Proceedings of the
2nd ACM Symposium on Information, Computer and Communications1220 • IDA : the 2- or 8-byte MAC address of A, depending on
1155 Security (ASIACCS ’07), ACM, 2007, pp. 380–382.
which kind of IEEE 802.15.4 addresses are used
[21] D. R. Raymond, R. C. Marchany, S. F. Midkiff, Scalable, cluster-based
anti-replay protection for wireless sensor networks, in: Proceedings of 0
the IEEE SMC Information Assurance and Security Workshop (IAW ’07), • KA,B : the predistributed pairwise key between A and B
IEEE, 2007, pp. 127–134. 0
1160 [22] A. Wood, J. Stankovic, G. Zhou, DEEJAM: defeating energy-efficient • KA,B : the pairwise session key between A and B
jamming in IEEE 802.15.4-based wireless networks, in: Proceedings of
the 4th Annual IEEE Communications Society Conference on Sensor, • KA,∗ : A’s group session key
Mesh and Ad Hoc Communications and Networks (SECON ’07), IEEE,
2007, pp. 60–69. 1225 • l: the length of an OTP in bits
1165 [23] R. Falk, H.-J. Hof, Fighting insomnia: a secure wake-up scheme for wire-
less sensor networks, in: Proceedings of the Third International Confer- • ta : the duration of the reception window for acknowl-
ence on Emerging Security Information, Systems and Technologies (SE- edgement frames
CURWARE ’09), 2009, pp. 191–196.
[24] S. Aljareh, A. Kavoukis, Efficient time synchronized one-time password • tu : the maximum uncertainty about a permanent neigh-
1170 scheme to provide secure wake-up authentication on wireless sensor net-
works, International Journal of Advanced Smart Sensor Network Systems bor’s wake-up time
(IJASSN) 3 (2013) 1–11.
[25] C.-T. Hsueh, C.-Y. Wen, Y.-C. Ouyang, A secure scheme against power1230 • tw : the interval of CSL’s periodic wake ups
exhausting attacks in hierarchical wireless sensor networks, IEEE Sensors
1175 Journal 15 (6) (2015) 3590–3602. • α a field within the CCM nonces generated by ILOS++
[26] A. T. Capossele, V. Cervo, C. Petrioli, D. Spenza, Counteracting denial-
of-sleep attacks in wake-up-based sensing systems, in: Proceedings of • ηA,B : an estimate of the clock drift of A against B
the IEEE International Conference on Sensing, Communication and Net-
working (SECON 2016), IEEE, 2016, pp. 1–9. • θ: the frequency tolerance of the employed clocks
1180 [27] Q. Ren, Q. Liang, Secure media access control (MAC) in wireless sensor
networks: intrusion detections and countermeasures, in: Proceedings of • θη : the frequency tolerance of ηA,B
the 15th IEEE International Symposium on Personal, Indoor and Mobile
Radio Communications (PIMRC 2004), IEEE, 2004, pp. 3025–3029. 1235 • λ: a burst index - the first payload frame after a wake-up
[28] S. Zhu, S. Setia, S. Jajodia, P. Ning, An interleaved hop-by-hop authen-
1185 tication scheme for filtering of injected false data in sensor networks, in:
sequence always has burst index λ = 0, a payload frame
Proceedings of the 2004 IEEE Symposium on Security and Privacy (S&P that follows right after has burst index λ = 1, and so on
’04), IEEE, 2004, pp. 259–271.
[29] F. Ye, H. Luo, S. Lu, L. Zhang, Statistical en-route filtering of injected • τA,B : B’s last wake-up time that is known to A
false data in sensor networks, IEEE Journal on Selected Areas in Com-
1190 munications 23 (4) (2005) 839–850. • ϕ: a CSL phase - unless otherwise mentioned, measured
[30] T. Chang, T. Watteyne, K. Pister, Q. Wang, Adaptive compensation for1240 as the time between when the SHR of the frame contain-
time-slotted synchronization in wireless sensor network, International
Journal of Distributed Sensor Networks.
ing ϕ was transmitted and the sender’s next wake-up time
[31] R. Hummen, J. Hiller, H. Wirtz, M. Henze, H. Shafagh, K. Wehrle,
1195 6LoWPAN fragmentation attacks and mitigation mechanisms, in: Pro- • ωA . the wake-up counter of A - A increments ωA in lock-
ceedings of the Sixth ACM Conference on Security and Privacy in Wire- step with CSL’s periodic wake ups, even if CSL skips
less and Mobile Networks (WiSec ’13), ACM, 2013, pp. 55–66. over a wake up due to sending at that time
[32] S. S. Guclu, T. Ozcelebi, J. J. Lukkien, Dependability analysis of asyn-
chronous radio duty cycling protocols, in: Proceedings of the 25th In-1245 • ωA,B : the wake-up counter of B at time τA,B
1200 ternational Conference on Computer Communication and Networks (IC-
CCN), IEEE, 2016, pp. 1–11.
[33] X. Vilajosana, P. Tuset, T. Watteyne, K. Pister, OpenMote: open-source
prototyping platform for the industrial IoT., in: Ad Hoc Networks, Vol.
155, Springer, 2015, pp. 211–222.
1205 [34] A. Tinka, T. Watteyne, K. S. J. Pister, A. M. Bayen, A decentralized
scheduling algorithm for time synchronized channel hopping, EAI En-
dorsed Transactions on Mobile Communications and Applications 11 (1).
[35] B. Al Nahas, S. Duquennoy, V. Iyer, T. Voigt, Low-power listening goes
multi-channel, in: Proceedings of the 2014 IEEE International Confer-
1210 ence on Distributed Computing in Sensor Systems (DCOSS), IEEE, 2014,
pp. 2–9.
[36] A. Dunkels, F. Osterlind, N. Tsiftes, Z. He, Software-based on-line en-
ergy estimation for sensor nodes, in: Proceedings of the 4th Workshop on
Embedded Networked Sensors (EmNets ’07), ACM, 2007, pp. 28–32.
1215 [37] J. Eriksson, N. Finne, N. Tsiftes, S. Duquennoy, T. Voigt, Scaling RPL
to dense and large networks with constrained memory, in: Proceedings
of the International Conference on Embedded Wireless Systems and Net-
works (EWSN 2018), Junction, 2018.

14

View publication stats