Performance Evaluation of OpenWSN Operating
System on Open Mote Platform for Industrial IoT
Applications
Dragan Vasiljevi
Mtel Technical division
Mtel JSC Banjaluka
Banjaluka, Republic of Srpska, Bosnia & Herzegovina
dragan.vasiljevic@mtel.ba
Abstract - Wireless Sensor Networks (WSNs) represent one of
the key technologies in Industrial Internet of Things (IIoT)
applications. Recently, the OpenMote platform has drawn
significant attention to IIoT research community. The OpenMote
is a representative of new generation open-hardware platforms
that is particularly adapted to IIoT applications. The OpenWSN
is IoT operating system (OS) that incorporates the complete
communication protocol stack for industrial WSN. This paper
presents the OpenWSN protocol stack and results of
performance evaluation of entire OpenWSN implementation on
OpenMote hardware platform. Performance evaluation is based
on traffic generation and measurement of relevant metrics. The
selected metrics are: round-trip time, packet loss rate and
throughput.
KeywordsInternet of Things; OpenWSN; OpenMote; WSN;
6LoWPAN; IEEE802.15.4e; TSCH; Industrial IoT; 6TiSCH
I. INTRODUCTION
The Internet of Things (IoT) is technology that grows very
rapidly in recent time. It is based on concept of smart objects,
i.e. physical objects equipped with sensors and software which
enables them to monitor various parameters in its environment
and react to their changes, thus establishing the
communication between humans, computing systems and
smart objects.
WSNs are the corner stone of wide area IoT application.
WSN consists of distributed nodes capable of collecting
various information using sensors and send them via other
nodes in network towards computer systems for processing, as
well as transferring data in opposite direction. WSN provides
the interface between physical world and computer systems.
Deployment of WSN in industrial applications draws
particular attention. Common industrial WSN applications are
smart grid and home automation [1,2], condition and
performance monitoring of the industrial machines and plants,
industrial automation, environmental sensing [3,4], etc.
Recent trends in IoT activities are directed towards the
open-hardware and open-software prototyping and
development. This is recognized as an important step in terms
of standardization activities and design of new applications for
978-1-5090-2329-5/16/$31.00 2016 IEEE
Gordana Gardaevi
Faculty of Electrical Engineering
University of Banja Luka
Banjaluka, Republic of Srpska, Bosnia & Herzegovina
gordana.gardasevic@etfbl.net
IoT purposes. The OpenWSN OS and OpenMote hardware
platform are the examples of such initiative. OpenWSN OS
integrates the OpenWSN protocol stack with Free Real Time
Operating System (FreeRTOS). The OpenWSN is particularly
well suited for IIoT applications. The applications for
industrial processes require a very high reliability and
immunity to interference and multipath fading.
The corner stone of OpenWSN protocol stack is
IEEE802.15.4e Time Slotted Channel Hopping (TSCH)
protocol [5]. This protocol uses frequency channel hopping
technique which makes communication very resilient to
interference and multipath fading. IPv6 based communication,
which enables the seamless integration of WSN network to the
Internet, also suites IIoT applications. Since nodes in WSN
networks are constrained devices, for the practical realization
of reliable and high-quality industrial WSNs, the performance
evaluation of such networks is essential. The performance can
be evaluated by measuring various metrics. In this paper, the
following metrics are selected: round-trip time, packet loss
rate and throughput.
The paper is structured as follows: Section 2 gives the
overview of OpenWSN protocol stack and its main
functionalities. Section 3 describes the OpenMote-based IIoT
testbed setup and parameter settings. In Section 4, the results
of performance evaluation are presented and discussed.
Section 5 gives the conclusions and future work.
II. OPENWSN PROTOCOL STACK
The OpenWSN protocol stack is illustrated in Fig. 1 [6].
IEEE 802.15.4-2006 is implemented at physical layer. It
includes both physical and Medium Access Layer (MAC)
specifications. It has been designed primarily for Low Rate
Wireless Personal Area Networks (LR-WPAN) but soon
became de-facto standard for WSNs [7]. The main aspect of
IEEE 802.15.4 is to enable low-cost, low-speed ubiquitous
communication between nearby devices with poor underlying
infrastructure. Its basic framework assumes 10 meter
communications area at 250 kbps. IEEE 802.15.4-2006
standard's revision defines 4 different physical layers. The
OpenWSN uses the 2.4GHz worldwide ISM frequency band
with Direct-Sequence Spread Spectrum (DSSS) and Offset
Quadrature Phase-Shift Keying (O-QPSK).
IEEE 802.15.4e TSCH (Time Slotted Channel Hopping) is
used on MAC layer. It is the MAC amendment to the existing
standard 802.15.4-2006. The key element of the IEEE
802.15.4e is channel hopping, which significantly increases
the robustness against external interference and persistent
multi-path fading. Key IEEE 802.15.4 characteristics, such as
the use of Carrier Sense Multiple Access Collision Avoidance
(CSMA/CA) support for low-latencies and dynamic device
addressing and integrated support for secure communications
are still in use at this layer.
Fig. 1. OpenWSN protocol stack.
The next upper layer can be considered as Logical Link
Control (LLC) layer. uRES protocol is implemented at this
layer. This protocol is developed within OpenWSN project to
fill the gap between IEEE802.15.4e and the upper part of
protocol stack. IEEE802.15.4e specifies mechanisms for
network synchronization and channel hopping. What it does
not specify is how to use the resulting slotted organization to
efficiently transport data over multiple hops. There is a
missing mechanism which will allow each pair of neighboring
nodes to agree on cells to communicate on. With uRES, each
node in the network is able to establish two-way connections
with all neighboring nodes, i.e. to establish the logical link.
The next upper layer in OpenWSN protocol stack assumes the
capability of logical link establishment at this layer. uRES is a
partial implementation of IETF 6TiSCH (IPv6 over the TSCH
mode of IEEE 802.15.4e) standard which is still in
development phase [8].
IPv6 over Low power Wireless Personal Area Networks
(6LoWPAN) is the next upper layer in OpenWSN protocol
stack. The 6LoWPAN protocol enables the integration of IPv6
protocol in Low Rate WPAN (LR-WPAN) networks. The
6LoWPAN removes redundant fields from IPv6 and User
Datagram Protocol (UDP) protocols taking into account
characteristics of IEEE802.15.4, IPv6 and UDP protocols.
This process reduces the size of wireless packets thus enabling
IPv6 communication in such networks. Certain fields are
redundant since they have known values or are not used at all,
or can be derived from fields of IEEE802.15.4 protocol [9].
The removal of redundant field is not always sufficient to
reduce the size of IPv6 packet. Hence, the header compression
of IPv6 packet is also applied [10].
IPv6 Routing Protocol for Low-Power and Lossy
Networks (RPL) is the routing protocol responsible for packet
forwarding between nodes that are multiple hops away, as
well as for creation and maintenance of routing tables in
network nodes [11]. This is achieved by exchange of signaling
information between nodes in the network, which are used to
form and maintain Destination Oriented Acyclic Graph
(DODAG). DODAG represents the hierarchical organization
of nodes in the network. The node that is on top of that
hierarchy is called DODAG root. Each node in DODAG may
have more neighboring nodes of higher hierarchical level by
which it can reach DODAG root. One of them is called the
preferred node and is used for packet forwarding. RPL
signaling information, that are exchanged in the network, are
transferred as new type of Internet Control Message Protocol
(ICMPv6) messages.
At the transport layer, UDP and Transmission Control
Protocol (TCP) are used. HyperText Transfer Protocol
(HTTP) and Constrained Application Protocol (CoAP) are the
examples of application layer protocols. CoAP is designed for
use by constrained devices such as smart sensors in low rate
networks [12]. It enables a simplified translation into HTTP
protocol, simplified WEB integration and interactive
communication between end applications based on request-
response model.
III. IIOT TESTBED AND SETTINGS
Recently, the OpenMote platform has drawn significant
attention to research community. The OpenMote is a
representative of new generation open-hardware platforms that
is particularly adapted to the IIoT applications [13]. The
OpenMote hardware is shown in Fig. 2. It is composed of
three boards: OpenMote-CC2538, OpenBase and
OpenBattery.
Fig. 2. OpenMote hardware.
The OpenMote-CC2538 is based on TI CC2538 SoC
functionalities and has the following peripherals: step-down
DC/DC converter, two crystal oscillators at 32 MHz and
32.768 kHz, 4 LEDs, antenna connector and two buttons (one
is used to reset the board and the other enables wake up the
microcontroller from sleep modes through an interrupt). The
OpenMote-CC2538 is based on 32-bit Cortex-M3
microcontroller that runs up to 32 MHz and includes 32
Kbytes of RAM, 512 Kbytes of Flash and common peripherals
(GPIOs, ADC, timers, etc.). The radio operates at the 2.4 GHz
band and is fully compatible with IEEE 802.15.4-2006
standard.
The OpenBase is the board that serves three different
purposes: programming, debugging, and for communication
with a computer through serial port or USB. It also provides
the communication via 10/100 Mbps Ethernet network (thus
enabling the Internet connection to OpenMote-CC2538).
The OpenBattery provides the supply to all OpenMote-
CC2538 subsystems, as well as the interface with various
sensors. It includes three different digital sensors:
temperature/humidity, acceleration and light sensor.
To evaluate the performances in terms of a latency,
throughput and packet error rate, the network of 10
OpenMote-CC2538 motes is created. Nine of them are
powered by OpenBattery and one is powered by OpenBase,
and via USB emulated serial interface attached to host
computer. The host computer is running Ubuntu 14.04 LTS
with Open Visualizer (OV) installed.
OV is the software developed as a part of OpenWSN
project that resides on host computer and provides
communication and visualization functionalities. OV creates
IPv6 TUN (network TUNnel) interface (virtual IPv6 interface
tunneled trough serial port) for motes' network. This interface
enables IPv6 communication between host and mote network.
The visualization is realised through Graphical User Interface
or Web interface and provides insight into status of motes and
mote management functions (only for mote directly connected
to host), such as: declaring mote as DODAG root, viewing
routing topology if the mote is declared as DODAG root,
display operating parameters (Radio Duty Cycle (RDC),
queue status, neighbor table, IPv6 address, number of active
time slots in slotframe, etc.) and packet capturing using e.g.
Wireshark.
The mote that is directly connected to host is declared as
DODAG root. A mesh network topology used for evaluation
is illustrated in Fig. 3. Nodes are marked according to
hexadecimal values of the last byte of their IPv6 address.
Fig. 3. Mesh network topology used for evaluation.
This topology enables multiple paths from motes to
DODAG root and maximum distance of 3 hops between
DODAG root and mote. In this way, various DODAGs can be
formed. In our testbed setup, all motes are in radio-range of
each other. In order to provide the multihop communication,
the topology has to be forced in some way. This is done by
applying the specific file in OpenWSN firmware, which exact
purpose is to enable forcing certain network topology.
The packets that mote handles, sends or receives, are
placed in a queue. The default queue length for OpenWSN is
10 packets. This queue length is also used during the
experiment. If the queue is full, the mote rejects new packets.
The default timeslot duration is 15 ms. The packet size is
limited to 127 bytes on IEEE 802.15.4 layer. The
fragmentation is not supported on upper layers. Therefore, the
application layer needs to take care of fragmentation, if
needed.
The evaluation is performed by generating and recording
the traffic in motes' network, for different test cases. The
recorded traffic is later used to calculate performance metrics.
The traffic is based on queries, where DODAG root
periodically sends query packets to destination mote and waits
for reply from it. Both queries and replies are data packets
with the same payload size. Different individual tests are
created by varying different traffic parameters and OpenWSN
firmware parameters that may influence overall network
performance. The traffic parameters used in tests are: the hop
distance of queried mote, packet payload size and period
between two consecutively sent query packets the
interpacket time. OpenWSN firmware parameters used in tests
are slotframe length and number of active timeslots in
slotframe.
For each combination of parameter values used in
individual tests, the mote involved in that test is queried with
1000 query packets. Hop distances of 1, 2 and 3 hops, packet
payload sizes of 20, 30 and 40 bytes and interpacket time of
300, 600 and 1000 ms are used.
The following combination of OpenWSN firmware
parameters are selected for creation of 3 test scenarios:
Test scenario 1: slotframe length = 19 slots, number of
active timeslots in slotframe = 14 slots.
Test scenario 2: slotframe length = 9 slots, number of
active timeslots in slotframe = 5 slots.
Test scenario 3: slotframe length = 7 slots, number of
active timeslots in slotframe = 2 slots.
For each test scenario, several individual tests are
performed based on variation of traffic parameters. Each
scenario required some changes in OpenWSN firmware source
code, as well as flashing new OpenWSN firmware image into
motes.
The query data packets are ICMPv6 ECHO_REQUEST
packets sent from the host computer via TUN interface (which
is actually DODAG root interface towards host computer) to
motes' network. The packets are generated by ping6 Linux
command from Command Line Interface. The queried mote
sends back ICMPv6 ECHO_REPLY packets.
Query packets are recorded on TUN interface (and all
other packets on TUN interface as well) using Wireshark
application. Based on recorded traffic, the following
performance metrics are calculated: Round-Trip Time (RTT),
Packet Loss Rate (PLR) and throughput.
 RTT is calculated as the interval of time between the larger payload sizes for OpenWSN firmware parameter
moment of transmission of query and the moment of reception settings used in this test scenario.
of reply for that particular query on TUN interface. Results are
then averaged over all packets received in individual test. PLR TABLE I. PLR FOR TEST SCENARIO 1
is calculated as the rate between number of query packets for
which replies are never received, and total number of sent Hop count
Payload size
query packets, expressed in percentage. The throughput is 20 bytes 30 bytes 40 bytes
calculated as the rate between the total number of payload bits 1 0.14% 0% 0.7%
of correctly received reply packets and the time period 2 0.3% 0.9% 0.9%
between the moment the first query packet sent and the last
reply packet correctly received at TUN interface, expressed in 3 1.26% 3.6% 10.7%
bits per second.
TABLE II. THROUGHPUT [KB/S] FOR TEST SCENARIO 1
IV. RESULTS AND PERFORMANCE ANALYSIS Payload size
Hop count
20 bytes 30 bytes 40 bytes
The results of initial tests show that the maximum payload
size in packet depends on number of hops to destination mote. 1 0.53 0.80 1.06
The experimental results show that the maximum payload size 2 0.53 0.79 1.06
is 59 bytes for 1 hop, 49 for 2 hops and 46 for 3 hops. Larger 3 0.53 0.77 0.95
payload sizes cause packet to be larger than 127 bytes and thus
rejected by mote. Accordingly, the evaluation is performed for
packet payload sizes of 20, 30 and 40 bytes. Fig. 5 illustrates RTT variations for the first 100 queries,
for test scenario 1. The RTT variations follow specific pattern
A. Test scenario 1 which periodically repeats. The packet from mote, that needs
Here, hop distances of 1, 2 and 3 hops, packet payload to be transmitted to other mote, waits for time slot in slot
sizes of 20, 30 and 40 bytes and interpacket time of 300 ms frame that is dedicated to communication between those
are selected. motes. The maximum waiting time corresponds to slotframe
length. In this case, the slotframe length is 19 slots, and with
This scenario resulted in DODAG root RDC of 19,90% at the 15 ms duration per timeslot, we obtain the total of 285 ms,
the beginning of tests and slowly increasing to 25,77% at the which corresponds to the variations in RTT. The Open WSN
end of tests. RDC is calculated by each mote in network and currently implements timeslot scheduling algorithm according
collected by OV only from DODAG root. Fig. 4 illustrates the to Minimal 6TiSCH Configuration, i.e. the schedule is static.
average RTT. Table 1 shows PLR and Table 2 shows the A node learns the schedule from the Enhanced Beacon (EB)
throughput in [kb/s] for test scenario 1. and doesn't change it afterwards [14,15]. If there are enough
timeslots in slotframe, the same timeslot will be reserved for
communication between two motes in consecutive slotframes.
The packet waiting for that timeslot would have always the
same waiting time in case that packet arrival rate is the same
as slotframe length (timeslot repetition rate). In this test
scenario, the packet arrives at interval of 300 ms and dedicated
timeslot repeats at 285 ms. As a consequence, the packet
waiting time periodically changes, in portions of time
difference between interpacket time and slotframe length, in
this case 15 ms. These changes produce the RTT pattern
illustrated in Fig. 5.

Fig. 4. Average RTT for test scenario 1.

There are no significant differences in RTT regarding

different payload sizes for 1 hop. The same situation appears
for 2 hops. Also, there are no significant differences in RTT
between 1 and 2 hops. The differences appear at hop 3. RTT
for 40 bytes payload size shows significant deviation
compared to 20 and 30 bytes payload size. At the same time,
PLR is also significantly increased. Such high PLR is typically
caused by mote queue overflow. This indicates that
interpacket time of 300ms might be too small (the packets are
sent too frequently) for distances of 3 and more hops, and Fig. 5. RTT variations for the first 100 queries for test scenario 1.
 In this test scenario, the key contribution to RTT value
comes from the influence of slotframe length.
B. Test scenario 2
In this scenario, hop distances of 1, 2 and 3 hops, packet
payload size of 20 bytes and interpacket time of 300 ms are
used.
This scenario resulted in DODAG root RDC of 18,34% at
the beginning of tests and slowly increasing to 19,19% at the
end of tests. Fig. 6 illustrates the average RTT. Table 3 shows
PLR and Table 4 shows the throughput in [kb/s] for test
scenario 2.
Fig. 6. Average RTT for test scenario 2.
TABLE III. PLR FOR TEST SCENARIO 2
Hop count Payload size: 20 bytes
1 0.2%
2 0.7%
3 0.3%
TABLE IV. THROUGHPUT [KB/S] FOR TEST SCENARIO 2
Hop count Payload size: 20 bytes
1 0.53
2 0.53
3 0.53
PLR is low and the throughput is the same as for test
scenario 1. However, RTT is significantly lower. The main
reason is that slotframe length is reduced from 19 to 9
timeslots. This significantly reduces the time that packet is
waiting for dedicated timeslot. RTT variations also follow a
typical pattern as for test scenario 1.
C. Test scenario 3
Here, hop distances of 1, 2 and 3 hops, packet payload size
of 20 bytes and interpacket times of 300, 600 and 1000 ms are
used.
This scenario resulted in DODAG root RDC of 11,15% at
the beginning of tests and slowly increasing to 13,47% at the
end of tests. Fig. 7 illustrates the average RTT. Table 5 shows
PLR and Table 6 shows the throughput in [kb/s] for test
scenario 3.
Fig. 7. Average RTT for test scenario 3.
TABLE V. PLR FOR TEST SCENARIO 3
Hop count Payload size: 20 bytes
1 0% (interpacket time 300 ms)
2 0.2% (interpacket time 600 ms)
3 0% (interpacket time 1000 ms)
TABLE VI. THROUGHPUT [KB/S] FOR TEST SCENARIO 3
Hop count Payload size: 20 bytes
1 0.53 (interpacket time 300 ms)
2 0.27 (interpacket time 600 ms)
3 0.16 (interpacket time 1000 ms)
In this test scenario, the queue overflow happens for 2 and
3 hops and 300 ms interpacket time, and 3 hops and 600 ms
interpacket time. PDR is very low for these tests, and queue
overflow didnt happen. This can be explained by the fact that
only 2 active timeslots are available. Two motes cant have
dedicated time slot now. Additionally, two active timeslots are
shared among all motes and used for data traffic, as well as for
transmission of EBs and data link-layer packets for uRES
protocol. Data link-layer packets are used for logical link
establishment between motes and have the higher priority than
data traffic packets. When these packets are transferred, one or
both active time slots become occupied for some period of
time. Depending on duration of that period and interpacket
time of data traffic, the queue overflow may happen. The
probability of queue overflow is higher if the mote is more
hops away. In order to achieve longer distances, it is necessary
to increase the interpacket time. The increase in interpacket
time significantly decreased the throughput.
In this test scenario, the initial RTT is low due to reduction
in slotframe length, but RTT increases with the number of
hops. Fig. 8 illustrates RTT variations for the first 100 queries
in this test scenario. Here, RTT variations do not follow the
typical pattern as in test scenario 1. With only two available
timeslots in slotframe, is not possible to reserve a certain
timeslot for communication between two motes in consecutive
slotframes. Instead, two active timeslots are shared among all
motes which cause random packet waiting time for the free
timeslot, hence random RTT variations. There is a competition
with other motes for available timeslot at each hop the packet
travels. That explains the increase in RTT with the number of
hops.
root. The PDR is low in all test scenarios, assuming that there
is no packet queue overflow. This indicates that OpewWSN
OS and OpenMote platform have high reliability, which is
particularly suitable for industrial applications.
In order to correctly apply the OpenWSN protocol stack in
IIoT, the first step is to analyze the network size, traffic
patterns and requirements in terms of throughput, latency and
power consumption. Then, the appropriate scheduling
algorithm should be chosen and particularly purpose-built.
With these prerequisites, the values for slotframe length and
number of active timeslots will satisfy requirements and
should be implemented in firmware.
As a conclusion, the preliminary experimantal results show
that OpenWSN protocol stack requires the trade-off between
latency, throughput, reliability and power consumption. As a
future work, different settings will be tested, with more
parameters included. Additionally, OpenWSN OS and Contiki
OS performances will be compared.

[1]
[2]
[3]
Fig. 8. RTT variations for the first 100 queries for test scenario 3.
[4]
V. CONCLUSIONS
Results presented in this paper show that performances of
the OpenWSN protocol stack depend on numerous factors, [5]
where many of them are opposed to each other. The slotframe
length is the factor that highly affects RTT. By reducing the [6]
slotframe lengthm we canreduce the RTT, but this will lower
the number of available active timeslots as well. However, the
reduction in available active timeslots below certain number, [7]
such as in test scenario 3, affects the overall network
performance and 6TiSCH scheduling algorithm, which itself
requires active timeslots for LLC data packet transfer. This [8]
leads to increase of RTT and decrease in throughput with
number of hops (i.e. larger networks). With currently
[9]
implemented minimal 6TiSCH scheduling, the increase in
slotframe length and available timeslots does not significantly
[10]
improve the network throughput, as it would be expected, and
does not reduce the RTT due to its static scheduling. With [11]
large number of available active timeslots, the dynamic
scheduling algorithm is needed in order to adapt the timeslot [12]
assignment to different traffic patterns. More active time slots
in slotframe increases RDC and power consumption. To [13]
reduce the power consumption, it is necessary to decrease the [14]
number of active timeslots and increase slotframet length.
However, this leads to low throughput especially in case of [15]
large network with many hops between motes and DODAG
REFERENCES
Y. Zhang, X. Li, S. Zhang and Y. Zhen, "Wireless sensor network in
smart grid: Applications and issue," Information and Communication
Technologies (WICT), 2012 World Congress on, Trivandrum, 2012, pp.
1204-1208. doi: 10.1109/WICT.2012.6409258.
M. EL Brak, S. EL Brak, M. Essaaidi and D. Benhaddou, "Wireless
Sensor Network applications in smart grid," 2014 International
Renewable and Sustainable Energy Conference (IRSEC), Ouarzazate,
2014, pp. 587-592. doi: 10.1109/IRSEC.2014.7059881.
M. Bal, "Industrial applications of collaborative Wireless Sensor
Networks: A survey," 2014 IEEE 23rd International Symposium on
Industrial Electronics (ISIE), Istanbul, 2014, pp. 1463-1468.
doi: 10.1109/ISIE.2014.6864830.
X. Shen, Z. Wang and Y. Sun, "Wireless sensor networks for industrial
applications," Intelligent Control and Automation, 2004. WCICA 2004.
Fifth World Congress on, 2004, pp. 3636-3640, Vol.4.
doi: 10.1109/WCICA.2004.1343273.
Low-Rate Wireless Personal Area Networks (LR-WPANs), Amendment
1: MAC sublayer, IEEE 802.15.4e, April 2012.
T. Watteyne at al: OpenWSN: a standards-based low-power wireless
development environment, Transactions on Emerging
Telecommunications Technologies, vol. 23, Issue 5, pp. 480-493, Aug.
2012.
Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless Personal Area Networks
(WPANs), IEEE 802.15.4, Sept. 2006.
T. Watteyne,M. Palattella, L. Grieco, Using IEEE802.15.4e TSCH in
an IoT context:Overview, Problem Statement and Goals, IETF Internet-
Draft, March 2015.
Transmission of IPv6 Packets over IEEE 802.15.4 Networks, IETF RFC
4944, September 2007.
Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based
Networks, IETF RFC 6282, Sept. 2011.
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks, IETF
RFC 6550, March 2012.
The Constrained Application Protocol (CoAP), IETF RFC 7252, Jun
2014.
OpenMote, Official Web site, http://www.openmote.com .
OpenWSN project, Official Web site of the project,
https://openwsn.atlassian.net/wiki/display/OW/Home
X. Vilajosana, K. Pister, Minimal 6TiSCH Configuration, IETF
Internet-Draft, Feb. 2016.