2. Wireless channels in InceOS
i
DECLARATION
I hereby certify that this dissertation, which is 14923 words in length, has been composed by
me, that it is the record of work carried out by me and that it has not been submitted in any
previous application for a higher degree. Credit is explicitly given to others by citation or
acknowledgement. I conducted this project at The University of St Andrews from 06/2012 to
09/2012 towards fulfilment of the requirements of the University of St Andrews for the
degree of MSc under the supervision of Dr. Jonathan Lewis.
In submitting this project report to the University of St. Andrews, I give permission
for it to be made available for use in accordance with the regulations of the University
Library. I also give permission for the title and abstract to be published and for copies of the
report to be made and supplied at cost to any bona fide library or research worker, and to be
made available on the World Wide Web. I retain the copyright in this work.
Date: ………………….. Signature:………………………
3. Wireless channels in InceOS
ii
ACKNOWLEDGEMENT
Apart from the efforts of me, the success of any project depends largely on the
encouragement and guidelines of many others. I take this opportunity to express my gratitude
to the people who have been instrumental in the successful completion of this project.
I would like to show my greatest appreciation to Dr. Jonathan Lewis. I can’t say thank you
enough for his tremendous support and help. I feel motivated and encouraged every time I
attend his meeting. Without his encouragement and guidance this project would not have
materialized.
I would like to express my gratitude towards my parents for their kind co-operation and
encouragement which helped me in completion of this project.
My thanks and appreciations also go to my friends who have willingly helped me out with
their abilities.
4. Wireless channels in InceOS
iii
ABSTRACT
Wireless sensor networks (WSNs) are complex, distributed systems and are
comprised of small, battery powered and resource-constrained devices called motes. The
developers of wireless sensor network applications are often required to write low-level
programs in a concurrent environment without high-level programming support. This
development is a complex task, especially for experts of the application domain who may not
be computer scientists. Insense is a high-level, component based programming language,
developed to ease WSN application development. This language increases the level of
abstraction thereby decreasing the chances for programmer error.
Using the Insense programming language, a sensing system is modelled as a set of
components that interact via channels. In the language implementation for the Contiki
operating system, these channels can be published over the network and used to identify
services available to other WSN application components in the network. The channels
support internode communication between components hosted on different motes. InceOS is
a custom operating system developed to support efficient execution of complex Insense
programs.
This project involves developing internode channel communication support for
Insense on InceOS, similar to that of the Contiki based implementation. The Contiki based
implementation uses a Link State Advertisement (LSA) protocol for routing information
between the motes. This project will investigate different routing mechanisms available and
design and suggest a suitable routing protocol for InceOS taking space usage, power-
efficiency and reliability in account.
5. Wireless channels in InceOS
iv
TABLE OF CONTENTS
DECLARATION ...................................................................................................................i
ACKNOWLEDGEMENT....................................................................................................... ii
ABSTRACT ....................................................................................................................... iii
TABLE OF CONTENTS ....................................................................................................... iv
1 INTRODUCTION.........................................................................................................1
1.1 AIMS AND OBJECTIVES.................................................................................................2
2 CONTEXT SURVEY......................................................................................................3
2.1 INSENSE.......................................................................................................................3
2.1.1 Data Types ......................................................................................................................................3
2.1.2 Built-In Constructs ..........................................................................................................................3
2.1.3 Components and Channels.............................................................................................................4
2.2 INSENSE ON CONTIKI....................................................................................................7
2.2.1 Contiki Overview.............................................................................................................................7
2.2.2 Insense Components and Channels on Contiki...............................................................................8
2.2.3 Inter-Node Channels.......................................................................................................................9
2.3 INCEOS ........................................................................................................................9
2.4 ROUTING PROTOCOLS................................................................................................ 10
2.4.1 Link State Advertisement..............................................................................................................10
2.4.2 Ad Hoc On-Demand Distance Vector............................................................................................10
2.4.3 Dynamic Manet On Demand Routing...........................................................................................10
3 PROJECT PLAN......................................................................................................... 12
3.1 Development model .................................................................................................. 12
3.2 Plan of Action ............................................................................................................ 12
4 REQUIREMENTS ...................................................................................................... 14
4.1 Functional requirements............................................................................................ 14
4.2 Non-functional requirements ..................................................................................... 15
5 DESIGN ................................................................................................................... 16
5.1 DESIGNING INCH........................................................................................................ 16
5.2 Publish operation....................................................................................................... 16
5.3 connect operation...................................................................................................... 18
5.4 disconnect operation.................................................................................................. 19
7. Wireless channels in InceOS
vi
8.3 InceOS Bug in the delayed channel acknowledge operation ........................................ 49
8.4 Debugging with Cooja ................................................................................................ 50
9 CONCLUSION........................................................................................................... 51
9.1 Future work............................................................................................................... 51
REFERENCES ................................................................................................................... 52
APPENDICES ................................................................................................................... 53
Appendix A............................................................................................................................ 53
8. Wireless channels in InceOS
vii
TABLE OF FIGURES
Figure 1: An example of Insense select clause ..........................................................................4
Figure 2: An example of connect, disconnect and send operation ............................................4
Figure 3: An example of inter-node operations .........................................................................5
Figure 4: Inter-node channel query operations ..........................................................................6
Figure 5: Tmote Sky ..................................................................................................................7
Figure 6: Waterfall model [10] ................................................................................................12
Figure 7: Gantt chart for the project ........................................................................................13
Figure 8: Inter-node publish operation ....................................................................................17
Figure 9: Inter-node channel connect ......................................................................................19
Figure 10: Inter-node channel disconnect................................................................................20
Figure 11: Inter-node channel send..........................................................................................22
Figure 12: Inter-node channel queries .....................................................................................23
Figure 13: public_channels_table............................................................................................27
Figure 14: bindings_table ........................................................................................................28
Figure 15: InterNodeChannel struct.........................................................................................28
Figure 16: Connection struct....................................................................................................29
Figure 17: ConnectionChange struct .......................................................................................29
Figure 18: AckData struct........................................................................................................30
Figure 19: InterNodePacket .....................................................................................................30
Figure 20: InterNodePacketSP struct.......................................................................................31
Figure 21: remote_connection_unbinder struct .......................................................................31
Figure 22: Encapsulation of packet to RadioPacket ................................................................32
Figure 23: De-capsulation of packet from RadioPacket..........................................................32
Figure 24: Instantiation of INCH component ..........................................................................33
9. Wireless channels in InceOS
viii
Figure 25: channel_select operation in INCH .........................................................................34
Figure 26: channels for inter-node communication.................................................................34
Figure 27: Code size of INCH under Contiki..........................................................................45
Figure 28: Code size of INCH under InceOS ..........................................................................46
Figure 29: Size of executable under InceOS and Contiki........................................................46
Figure 30: Mote 2 running the DEMO_SENDER firmware ...................................................47
Figure 31: Mote 1 running the DEMO_RECEIVER firmware ...............................................47
Figure 32: DEMO_RECEIVER program ................................................................................48
Figure 33: DEMO_SENDER program ....................................................................................48
10. Wireless channels in InceOS
1
1 INTRODUCTION
Recently, wireless sensor network (WSN) applications have become a part of day-of-
day life. They are getting deployed everywhere, including places like offices, houses,
gardens, forests etc. A large number of applications have been automated and performing
activities that don’t require human intervention e.g. sensing temperature, humidity, smoke
etc. The WSNs are complex, distributed systems that consist of resource-constrained devices
called motes, which communicate with each other over short-range radio. Due to the resource
constrained nature of the motes, programming on them is very tricky and simpler
programming models have to be designed so that the programmers of WSN applications can
write programs with ease. These programmers may not be experts in computer science
making programming on these motes a complex and potentially error-prone task [3].
Insense [3] is a high level component based language aimed at easier development of
WSN applications. Under Insense, components are the unit concurrency and form the
fundamental building block of application. These components are single threaded, active
entities scheduled in the operating system that can communicate with other components via
synchronous channels. This semantics of synchronous channel communication in Insense
permits channels to also abstract over component synchronisation. Insense provides a high
level of abstraction to the programmer thereby reducing the programming complexity and
decreasing the chances of programmer error. Insense also relieves the programmer of having
to deal with the memory management. Insense has been implemented on the Contiki
operating system but its applications require a large set of runtime libraries for their
execution. So for this purpose, InceOS, a new operating system was designed and
implemented making InceOS more Insense friendly. As compared to Contiki, applications in
InceOS perform more efficiently using less stack space and memory [5]. A large set of
Contiki runtime libraries have been integrated into InceOS to support Insense programming
and generating lesser source code in C [5].
The remainder of this document first discusses the research goals for this project in
section 1.1. Section 2 reviews the context with a detailed explanation of Insense, a
comparison of Contiki and InceOS, the implementation of Inter-node channel handler on
Contiki and some routing algorithms for WSNs in sections 2.1, 2.2, 2.3 and 2.4 respectively.
This is followed by the project plan in section 3 which includes the development life cycle
and plan of action. Section 4 describes the requirements (both functional and non-
functional), along with design and implementation of INCH in sections 5 and 6. After the
implementation the document discusses the testing and evaluation techniques explaining the
satisfaction of the requirements and goals of the project in section 7. Section 8 discusses the
challenges faced during the implementation and debugging. Section 9 concludes the
document with conclusion and future work.
11. Wireless channels in InceOS
2
1.1 AIMS AND OBJECTIVES
The goals of this project are twofold.
The primary goal of the project is to design and develop an inter-node channel
communication for Insense applications working in InceOS, similar to the Contiki-
based implementation.
The secondary goal of the project is to analyse different network level protocols such
as Link State Advertisement with other available network level routing protocols, e.g.
Ad hoc On-Demand Distance Vector (AODV), Multi-hop routing, Dynamic MANET
On-demand (DYMO) routing over the wireless channels etc., to design and
implement an efficient routing algorithm for Insense applications.
12. Wireless channels in InceOS
3
2 CONTEXT SURVEY
2.1 INSENSE
Insense [3] is a very simple, high level, component based language for designing
wireless sensor network applications. Insense applications run on Contiki [4] or InceOS [5]
operating systems. The compiler for this language is written in Java. It compiles the Insense
language and generates a C language source code, which gets integrated into the source code
of the operating system. The entire package is flashed onto the motes [7] where the
applications run as programmed. Insense aims at reducing the complexities of programming
WSN applications such as event-driven programming, memory management and
synchronisation. Applications written in Insense are low footprint applications, which are apt
for devices with limited resources [3].
The following sub-sections summarise key aspects of Insense programming language,
2.1.1 Data Types
The Insense language supports most of the commonly known data types. These
include: integer, real, Boolean, byte and enum. Arbitrary values can be coerced into a union
of type any. Apart of these standard data types, Insense also supports six constructed types:
arrays, interfaces, functions, struct, components and channels [3].
Insense arrays are similar to those in Java but in Insense they must be initialised
during declaration with a fixed size given by a literal. Insense components are active entities
that can communicate with other components via typed channels. The type of a component is
defined by its interface which contains the names and types of its channels. The type struct
defines a custom data record. Components and channels will be discussed in much greater
detail in sections 2.1.3 below and in [3].
2.1.2 Built-In Constructs
Like most programming languages, Insense has in-built constructs for programming
conditions and loops. It has if-then-else, for supporting conditional statements. The if-then-
else construct is similar to other programming languages. The select statement provides
Insense with a powerful non-deterministic selection. This is used to non-deterministically
select data over multiple channels. An example of select clause is shown in Figure 1.
Insense supports looping behaviour with the for construct. There is no while clause
present in the Insense programming language. Insense also provides try-except construct for
supporting exception handling. The exception handling mechanism is explained in much
detail in section 2.1.3.2 below [3].
13. Wireless channels in InceOS
4
Insense has some more constructs for supporting channel behaviour, which is well
explained in the section 0. Insense has exception handling mechanism for detecting failing
connections and dealing with uncertainties. This is discussed in section 2.1.3.2.
2.1.3 Components and Channels
Components are the main building block of the Insense computational model. Insense
applications may be composed from a number of components that communicate with each
other over channels. An Insense application can be composed from Figure 1 and Figure 2,
consisting of two components myReceive_comp and mySend_comp. Components are stateful
objects and contain updatable locations, which can be accessed only via the behaviour of the
component. The behaviour is similar to a thread within the component making the component
single unit of concurrent computation. A component can create instances of other
Figure 2: An example of connect, disconnect and send operation
Figure 1: An example of Insense select clause
14. Wireless channels in InceOS
5
Figure 3: An example of inter-node operations
components. Components are created using their constructors [3].
All communication between components takes place via channels. In Insense, these
channels are typed and directional. The channels supports all the data types mentioned in
section 2.1.1. The communications over channels are synchronous and the components wait
until the communication is completed or aborted successfully [3].
The most commonly used operations used for communications over the channels are
connection, disconnection, send and receive. The connect construct initiates the
communication by connecting the output channel of one of the component to the input
channel of another component. Similarly, the disconnect construct disconnects two channels
by remove the bindings made by the specified channel and other channels [3].
The send construct sends value over the channel, supported by the channel. The
receive construct receives the sent value. These two constructs are deterministic only when an
outgoing channel is connected to single incoming channel. When an outgoing channel is
connected to multiple incoming channels, the send operation becomes non-deterministic, as a
multicast send operation is performed. The select statement explained in section 2.1.2
provides the ability to selectively receive from an output channels when it is connected to
multiple input channel [3].
Figure 1 is an example of non-deterministic select clause provided by Insense. The
component is listening to the ticker, tocker and tacker channels non-deterministically and
whenever data is received on any one of those channels, it prints the message string [3].
Figure 2 illustrates an example of the basic send, receive, connect and disconnect operation.
The channel output is connected to all the channels (ticker, tocker, and tacker) from the
component Receive defined in Figure 2. An integer value is sent to either of the ticker, tocker
and tacker channels. When the value of integer reaches 25, the output channel is disconnect
from all its bindings.
2.1.3.1 Inter-Node Channels
The four operations mentioned in section 2.1.3 also support inter-node channel
communication. Inter-node channel communication is discussed briefly below and in more
detail in [4]. These operations are
independent of whether the channels are
defined on the same device or different
devices. Channels are exposed onto the
network using the publish operation. A
string name known as local channel
name (LCN) is associated with the
channel and published to the network.
This LCN must be unique to the node
15. Wireless channels in InceOS
6
but are not required to be unique across the set of nodes [4].
Once the channel is published onto the network, it can be utilised using the extended
version of connect operation. The connect operation is extended to have a (node-address,
LCN) pair. The disconnect operation is extended similarly and channels bindings can be
unbounded. Figure 3 shows the syntax of publish and connect operations for inter-node
channels [4]. The input channel r.ticker and output channel s.output are published with LCN
as “Ticker” and “sender_output” respectively. Then they are connected using both the
anonymous and published bind operation. The last example disconnects the input channel
“Ticker” on node 2.
Insense also supports discovery of published channels on the network. The operations
in the Figure 4 allow the nodes to discover the addresses of neighbouring nodes and to
discover the information about the network topology. The method getNeighbours and
getNeighboursOf allow the node to get the information about the neighbours. The operation
getNeighbours returns an array of address for the executing node and the operation
getNeighboursOf (Address node) returns the array of address for neighbours for a particular
node. The operation getNodeAddress determines the node address from which it is executed
and the operation getNumberHops returns the minimum hop distance between the two nodes.
If no route can be found, then -1 is returned [4].
The operations getPublicChannels and getPublicChannelsOf allow the components to
discover the published channels for inter-node communication. The operation
getPublicChannels returns an array of structs representing the channels published by the
caller node and the operation getPublicChannelsOf (Address a) returns an array of structs of
published channels by the specified node. The findNodesPublishing operation uses a
Figure 4: Inter-node channel query operations
16. Wireless channels in InceOS
7
Figure 5: Tmote Sky
combination of the other channel operations and returns an array of node address that has
published channels with the given LCN, direction and type descriptor [4].
2.1.3.2 Exception Handling
Insense provides an exception model for handling uncertainties during the inter-node
channel communication. The language has a try-except clause that is similar to Java, to
handle exceptions. The four operations that may throw exceptions in Insense are publish,
send, connect and disconnect. Insense has a fixed number of exceptions that may be thrown
[4]. These exceptions are:
DuplicateLCNException: This exception is thrown by the node executing publish
operation when the specified LCN is already in use on it [3].
ChannelsUnknownException: This exception is thrown by the connect operation
when the channel name is unavailable on the remote host [3].
IncompatibleChannelsException: This exception is thrown by the connect operation
when the channel data types are incompatible [3].
NodesUnreachableException: This exception is thrown by the connect operation
when a route between source and destination nodes cannot be established. This
exception is thrown by the send operation when no routes to the destination node
could be found [3].
BindStatusUnknownException: This exception is thrown by the connect operation
when no acknowledgement for the channel binding is received back from the
destination nodes [3].
It should be noted that the NodesUnreachableException and
BindStatusUnknownException exceptions are thrown by the disconnect operation
under the same semantic interpretation as the connect operation [3].
SendStatusUnknownException: This exception is thrown by the send operation when
after a route to the destination node is available and data is sent, no acknowledgment
is received from the remote host [3].
2.2 INSENSE ON CONTIKI
2.2.1 Contiki Overview
Contiki [1] is a lightweight flexible operating system for
tiny network devices in wireless sensor networks. It is written in
C, designed especially for memory-constrained devices. This
operating system can run on a number of microcontroller
architectures, including the Texas Instruments MSP430 and
17. Wireless channels in InceOS
8
Atmel AVR. Most of the research in this work uses MSP430 microcontroller based Tmote
Sky (see Figure 5). It is an ultra-low power wireless module for sensor networks. It has
humidity, temperature and light sensors [7]. The Tmote Sky micro-controller has 48KB ROM
and 10KB RAM. [1]
The operating system is partitioned into core and loaded programs, while shared
functionalities are implemented as services. The core consists of kernel, program loader, run-
time system libraries and communication stack with device drivers for communication
hardware. These services are loosely coupled with the operating system. This enables runtime
replacement of different services or components. The operating system uses a power saving
mechanism, which puts the motes into deep sleep whenever there is no action to be
performed (i.e. all proto-threads are de-scheduled and waiting for an external event to occur).
User specific power saving mechanisms can also be introduced through implementation of
different applications or network protocols [1].
2.2.1.1 Event-Driven System
The kernel of the operating system is event-driven in nature. Event driven
programming model are quite popular for WSN application development as it uses less
memory and stack. In event driven systems, processes are allowed to continue their execution
till completion. This enables all processes to share the same limited stack resource
effectively. Also, no locking mechanisms are required, as no two processes will execute at
the same time. Multi-threading support on this event operating system is implemented using
proto-threads. This mechanism is non-pre-emptive in that the processes voluntarily yield
control and events are triggered for them to be rescheduled. The information about the proto-
threads is stored in thread structs that are passed to the functions associated with a thread
when scheduled for execution. These thread structs are used to continue the execution when
process is rescheduled for execution [1].
2.2.1.2 Pre-Emptive Multi-Threading
However, pure event driven systems has its drawbacks. A process might block the
CPU for longer duration causing starvation for other processes. This drawback is overcome in
Contiki version 2.5 with the introduction of pre-emptive multi-threading. This is
implemented as an application library and can be optionally linked with the programs that
explicitly require it [1]. However, during the implementation of INCH under Contiki, this
application library was not used.
2.2.2 Insense Components and Channels on Contiki
The Insense compiler generates C source code that is linked with the operating system
source code and its system libraries. The compiler generates a source and header file for each
component and struct declaration. All the component constructors, procedures and behaviour
are implemented as Contiki processes so that the send and receive operations can yield the
18. Wireless channels in InceOS
9
process when the operation has to block. Every channel is represented as half channel object
in the Contiki implementation [4].
The Insense compiler for Contiki generates “this” struct for each component type.
Contiki dynamically allocates memory for each component instance at runtime and stores the
component data on heap during execution. Contiki has to store component data on the heap
because all data of the program stack is lost when a Contiki process thread yields.
2.2.3 Inter-Node Channels
For inter-node channel communication, the implementation uses two main modules
from the runtime library: 1) a radio module and 2) an inter-node channel handler (INCH)
module. Both these modules provide a very high level abstraction of inter-node channel
communication services to the Insense programmer [4].
The radio module provides radio functionality to the INCH module and supports data
transfer using single-hop, best effort, unicast and best effort, local area broadcast. The INCH
module can be modelled as Insense component that provides support for all the inter-node,
inter-component communication.
All the Insense channel operations such as connect, disconnect, send, receive and publish
make use of the INCH module. All the published channels are stored in the public channels
table and all the established connection bindings are stored in the bindings table. These tables
are used by the getPublicChannels or findNodesPublishing are executed [4].
The Contiki-based implementation of INCH component has LSA-based multi-hop
routing implemented in it for route discovery. This algorithm is reviewed and compared with
other routing algorithms in much detail in section 2.4.
2.3 INCEOS
InceOS [5] is a new operating system written in C to support Insense. Unlike Contiki,
a lot of non-trivial Insense run-time libraries have been integrated into the InceOS operating
system. A lot of Insense abstractions have been integrated into the InceOS operating system.
The component and channel abstractions have been moved into the operating system thereby
simplifying and shortening the C code generated by the Insense compiler. As the component
state is maintained on the program stack in InceOS, the code generated by the compiler is
simplified even further in comparison to the Contiki implementation, which required a “this”
struct to be generated for every component type. This contributed towards smaller sizes of
InceOS executable in comparison to Contiki. [5]
As compared to Contiki, under InceOS, the programmer no longer needs to explicitly
yield control over components, as the operating system is pre-emptive. InceOS uses a round
robin scheduling mechanism and traverses through a list of schedulable components. This
pre-emption method ensures that every eligible component in the run-queue gets a fair share
19. Wireless channels in InceOS
10
of the CPU time. Components may get blocked when executing certain channel operations
and they are temporarily removed from the list of schedulable entities. Any event on the
channel of a blocked component would bring the component into execution [5]. Currently,
InceOS supports broadcast and unicast features, but it does not support any tree based routing
protocol as present in Contiki. The INCH module implemented in the Contiki is not present
in the InceOS and will be implemented as a part of this project. The radio module is directly
exposed to the programmer and routing protocols may be implemented using Insense
application programs [5]. As a part of this project, a routing protocol will be suggested to be
implemented within the INCH for route discovery.
2.4 ROUTING PROTOCOLS
2.4.1 Link State Advertisement
The Insense implementation on Contiki of INCH uses Link State Advertisement
(LSA) routing algorithm for route discovery for inter-node communication. LSA is a
proactive routing algorithm and the route is available before the information needs to be sent
[4].
In the implementation, time stamped link-state information is broadcasted
periodically to the network by the INCH components. The INCH components update their
map when newer information is received from the network. If the link-state information is not
received from a particular node for a certain link state cycles, then it is considered to be link
failure. The INCH component uses Djikstra’s algorithm and scans the link state map for
minimum hop path between itself and the destination node and sends the data to the node in
the next hop [4].
2.4.2 Ad Hoc On-Demand Distance Vector
Ad hoc on demand Distance Vector (AODV) protocol is a reactive protocol designed
for mobile ad hoc networks. AODV does not use any link state information in its memory
about other nodes. To find a route, the source node broadcasts the packets to neighbouring
nodes to search for the destination node. Once a route is established, the source sends the
data. If the source or destination moves during an active session, a new route is discovered
between the source and destination for communication [9].
AODV is well suited for fast moving mobile networks where the network topology
changes rapidly. This reactive protocol is a good choice for event driven or periodic data
driven WSN applications running on resource constrained devices [9].
2.4.3 Dynamic Manet on Demand Routing
The Dynamic MANET On-demand (DYMO) routing protocol is an extension to the
AODV routing protocol. It is more suited for MANET and provides faster routing in an on-
demand basis. It discovers unicast routes within MANET. Congested routes are avoided
using a back off mechanism. Data packets are buffered at intermediate routers in this
20. Wireless channels in InceOS
11
algorithm. This can have positive and negative effects on routing efficiency and buffer sizes
must be selected appropriately [9].
DYMO stores route information only about active sources and destinations. Since this
protocol is an extension to AODV tailored for mobile ad-hoc networks, this protocol is much
more efficient in terms of route processing. [9].
21. Wireless channels in InceOS
12
3 PROJECT PLAN
3.1 Development model
Waterfall model [10] has been identified as the software development model (see
Figure 6). The project will start with identification of requirements (research goals),
designing the system (designing the plan for implementation of INCH), implementation
(implementation on INCH) and testing (evaluating the product for satisfaction of
requirements). Future work will help in maintenance and enhancement of the project.
3.2 Plan of Action
Using waterfall model, the following milestones have been identified (Figure 7):
As a part of requirement gathering, we understand the implementation of INCH under
Contiki for Insense applications. We also identify the differences between the Contiki
and InceOS operating systems.
Design INCH for the InceOS operating system.
Implement INCH with single hop design
Test and debug the design
Investigate different routing algorithms
Requirement
definition
System and
software
design
Implementation
and unit testing
Integration and
system Testing
Maintenance
Figure 6: Waterfall model [10]
22. Wireless channels in InceOS
13
Test and debug the final product
Deployment of the final implementation
Release
Figure 7: Gantt chart for the project
23. Wireless channels in InceOS
14
4 REQUIREMENTS
This section lists high-level user requirements for development of Inter-node channel
abstraction on the InceOS operation system.
4.1 Functional requirements
Following are the functional requirements:
1. The project must design and implement Inter-node channel handler (INCH) tailored
towards InceOS operating system and provide the following functionalities to the
Insense programmer,
a. Exception handling – When operations detect certain conditions, they must
throw Exceptions to the user-level program that initiated the operation.
b. Publish – The Insense programmer must be able to publish channels with a
specified name, so the channel can be used for all the inter-node channel
operations. The name specified for publishing the channel must be unique to
the node. If the name specified has already been used to publish another
channel on this node, then a DuplicateLCNException must be thrown to the
user-level program.
c. Connect – The Insense programmer must be able to connect a local channel to
a compatible channel (in terms of direction and payload type) that has been
published on a potentially remote node. The programmer must be able to
connect two published channels on the same or different node from the same
node or potentially third-party node. The connect operation should be capable
of detecting the following exceptions:
i. If the specified name of the channel was not published by the specified
node, then a ChannelsUnknownException must be thrown.
ii. If the types of channels are found incompatible, then an
IncompatibleChannelsException must be thrown.
iii. If a route to the specified (remote) node cannot be established during
connect, then a NodesUnreachableException must be thrown.
iv. If a suitable acknowledgement of a new connection is not received
from the remote node within a certain timeout period, a
BindStatusUnknownException must be thrown.
d. Disconnect – The Insense programmer must be able to disconnect all inter-
node bindings for a local channel. The programmer must be able to disconnect
24. Wireless channels in InceOS
15
a published channel on the same node or different node. The disconnect
operation should be capable of detecting the following exceptions:
i. If the specified name of the channel was not published by the specified
node, then a ChannelsUnknownException must be thrown.
ii. If a route to the specified (remote) node cannot be established during
disconnect, then a NodesUnreachableException must be thrown.
e. Send – The Insense programmer must be able send datum over published
channels that are bound by inter-node connect operation. The inter-node
channel send operation must be capable of detecting the following exception:
i. If suitable acknowledgement for a datum sent through a valid route is
not received within a certain timeout period, a
SendStatusUnknownException is thrown.
ii. If a route to the specified (remote) node cannot be established during
disconnect, then a NodesUnreachableException must be thrown
f. The Insense programmer must be able to execute inter-node channel query
operations to discover neighbours, get published channels and find nodes that
have published channels.
2. The compiler must translate the Insense program and generate the appropriate
function in C to support multiple inter-node channels.
4.2 Non-functional requirements
Following are the non-functional requirements:
1. The INCH under Contiki operating system consumed large amount of memory and
InceOS was developed to address this issue. The inter-node channel handler
developed for InceOS should try to conserve memory, especially the code memory
(flash memory) as this was the resource most heavily used under Contiki.
25. Wireless channels in InceOS
16
5 DESIGN
5.1 DESIGNING INCH
The primary goal of this research is to design a module for inter node channel
communication on the InceOS operating system. The inter node channel communication
consists of five main operations along with three channel queries (explained in section
2.1.3.1). Under InceOS implementation, the semantics of these operations at the
programming level have been kept similar to the Contiki implementation to provide
consistency during Insense program development.
Under the Contiki implementation, the Inter-Node Channel Handler (INCH) was
modelled in Insense as single threaded component. Later, with the use of the proto-threads,
this component was later modified in C into a multi-threaded component. This enabled the
INCH component to perform multiple remote connections and send operations
simultaneously.
The INCH under InceOS is a single threaded component, handling incoming requests
from other nodes along with the sending and receiving of data. InceOS does not have support
for proto-threads. This design of INCH makes use of components for multi-threading, as
components are the unit of concurrency in InceOS. For the send operation, a sender
component is spawned from INCH to handle outgoing data and waits for ACK/timeouts.
With the introduction of a new thread (component) for handling outgoing data, multiple send
operations can be performed simultaneously.
All other inter-node operations (publish, connect, disconnect) and query mechanisms
except send operation run in the thread of the user-level component. Unlike the inter-node
implementation in Contiki, all the inter-node operations in InceOS can communicate with the
radio directly. This design decision is driven by necessity to save on space usage at runtime.
By executing publish, connect and disconnect operation in the user-level component’s thread,
multiple user-level components can execute these operations simultaneously without having
to spawn new handler components/threads for each operations as was necessary under
Contiki. This new design hopes to save on code memory and RAM as these operations no
longer requires constructors or structs (“this” instances for each operation). It is also hoped to
be more efficient in term of CPU usage as the number of schedulable entities is reduced as
compared to the Contiki implementation.
The following part explains each inter-node operation under InceOS implementation
in detail.
5.2 Publish operation
The publish operation is simplest inter node operation. As explained in section 2.1.3.1
above, the publish operation is used to declare the channels publicly over the network. This
26. Wireless channels in InceOS
17
Figure 8: Inter-node publish operation
enables other nodes in the network to discover these channels and access them. This publish
operation runs in the thread from where it was executed, i.e. user-level thread (component) or
main thread.
The publish operation responsible for two sub-operations:
Create a half-channel channel inside the INCH component and associate it with the
channel to be published from the user-level component. This half-channel channel is
of the opposite direction for the channel being published. For instance, if the channel
to be published is an OUT channel of type real, then the publish operation will create
an IN channel of type real inside INCH and connect them using the intra node
connect operation. The half-channel is used during inter-node send operation and
explained in 5.5.
Update the public_channels_table with information about this half-channel channel
created in INCH. The data structure of public_channels_table is explained in 6.3.1.1.
Once the public_channels_table has been populated successfully, the function call
returns. If the LCN was already present in the table public_channels_table, the publish
operation would throw DuplicateLCNException exception to the caller.
Figure 8 shows the design of the inter-
node channel publish operation. The
Insense program has a component c with
an OUT channel named c.output. The
following statement would publish the
channel,
publish c.output as “Out”
This operation would make a
function call to the defined procedure. This
procedure would then create the half-
channel inside INCH, associate it with the
channel to be published and make an entry
to the table public_channels_table in
INCH. In our example, the channel,
c.output would contain payload of the type
integer. Hence the typerep field has the
“Oi” value, with “O” denoting the
direction OUT and “i” denoting the
payload of the type integer.
27. Wireless channels in InceOS
18
5.3 connect operation
Once the channels are published, they can be discovered and accessed by other nodes. The
channels present on the other nodes must be connected to these channels using their LCNs
before sending any data. The intra node connect operation is extended so that the programmer
can bind the inter-node channels from an Insense program. Similar to the publish operation,
the inter-node connect operation runs in the user-level component thread. The connect
operations is responsible for three operations:
Send a ConnectionChangeRequest (CCR) packet to the receiver.
Instruct the INCH on the remote node to update its bindings_table.
If an ACK is received, update the bindings_table (see Figure 14 for details about
bindings_table) on the sender node.
Before initiating any connection change activity, the operation checks the bindings_table
if the requested change is already present. If the connection is already present, it returns with
SUCCESS, else it creates two temporary channels; one IN and one OUT, for communicating
with the radio, for sending CCR over the radio. This operation communicates with the radio
directly and sends a CCR packet on the unicast channel of radio. The radio transmits this
packet over the transmission medium intended to the receiver. The receiver radio receives
this packet and forwards it to all the channels connected to it. When the input channel on the
INCH component (inch_in) receives a CCR packet it checks whether the destined LCN is
published or not by looking up in the public_channels_table. If the LCN was published and
channels are compatible, the INCH adds the information about this connection to the
bindings_table sends an ACK back to the sender.
On a positive ACK, the connect operation updates the bindings_table on the sender with
the new binding information. If the connect operation was successful, the receiver sends a
positive ACK. If the channel on the receiver was not published, the connect operation would
throw ChannelsUnknownException. If channels were incompatible, the connect operation
would throw IncompatibleChannelsException. CCR or ACK packets may get lost due to
unreliable radio communication. Uncertainty in the connection is detected when an ACK is
not received within a certain time. In this situation, the connect operation throws a
BindStatusUnknownException.
An example of connect operation is illustrated in Figure 9. Both the sender (node A)
and receiver (node B) nodes have a published channels, “Out” and “In” respectively. When
the node A needs to bind its output channel c.output to “In” channel on node B, the following
statement is executed on node A:
connect c.output to “In” on B
28. Wireless channels in InceOS
19
Figure 9: Inter-node channel connect
This statement invokes the procedure associated with connect operation on node A. Since this
connection information is not present in bindings_table, node A creates a CCR packet and
forwards it over the radio’s unicast channel for node B. The INCH component on Node B
receives the connection change packet from its radio and identifies this as a CCR packet and
updates the bindings_table. Simultaneously, the INCH component on node B sends a CCR
ACK back to node A. Upon the receipt of the CCR ACK, the procedure updates the
bindings_table on the sender, returns SUCCESS to execution thread and completes this inter-
node operation.
5.4 disconnect operation
The intra-node channel disconnect operation is extended to provide the functionality
of the inter-node disconnect operation. The inter-node channel disconnect operation removes
the bindings information from the bindings_table. This operation runs in the user-level
execution thread.
The disconnect operation has two temporary channels: one IN and one OUT,
connected directly to the radio, for inter-node operation. In the disconnect operation, the
procedure loops around bindings_table looking up for the channel that needs to be unbound.
For each binding, it sends CCR packets to the remote node (the other node of the binding) via
the local Radio component. When the INCH on the remote node receives the CCR from its
29. Wireless channels in InceOS
20
Figure 10: Inter-node channel disconnect
Radio component, it removes the connection from its bindings_table and sends an appropriate
ACK back to the requesting node. The ACK is received by the disconnect procedure on the
source node and the binding information from its bindings_table. Once the all inter-node
channels bindings are removed from the bindings_table, the intra-node channel unbind
operation unbinds all the local bindings.
Figure 10 illustrates an example of inter-node channel disconnect operation. Both the sender
(node A) and receiver (node B) are connected over their LCNs “Out” and “In” respectively.
The disconnect operation sends a CCR packet to the node B. The CCR packet is received by
the INCH on node B and the binding information is removed from the bindings_table,
followed by the ACK being sent to node A. On receiving ACK on node A, the disconnect
procedure removes the binding information from its bindings_table, along with unbinding of
its local bindings.
5.5 send operation
The send operation allows components to send any values to other nodes. The Insense
programmer uses the same channel operation for inter-node channel send operation and intra-
30. Wireless channels in InceOS
21
node channel send operation. A high level of abstraction is provided to the Insense
programmer to perform inter-node channel communication and the programmer is unaware
of the difference between inter-node and intra-node channel send operation.
The send operation is supported by the INCH component which selectively receives
from all the channels in the incoming_halfchannels_table (which are connected to outgoing
channels in user component) created during the publish operation. The INCH performs a
special type of receive on the data channels (in the incoming_halfchannels_table) in which
the user-level component remains blocked until the ACK is received from the remote node or
a timeout has occurred.
The INCH component instantiates a sender component and yields control to the
sender component. Therefore, each send operation is executed on a different component
thread. The sender component gets a valid binding present in the bindings_table and uses that
connection information for transmitting the data. However, if there was no valid connection
present inside the bindings_table, the sender component would wait, until a connection is
bound for that LCN. When a connection is made available in the bindings_table for the
specified LCN, the sender component resumes execution with the transmission of the data
packet. This component has two channels: one IN and one OUT channel. The data is
forwarded to the Radio via the OUT channel and the sender component waits for
ACK/timeouts. When an ACK is received, a delayed acknowledgement is performed on the
incoming channel on which data was received in order to release the user-level sender
component. This completes the inter-node send operation.
Since the INCH component instantiates a separate sender component for performing
inter-node send operation, INCH component does not get blocked during inter-node send
operations. This design mechanism also allows multiple send operations to be executed
simultaneously. However, the send operation puts the user-level thread in a WAIT state, until
the delayed acknowledgement is received. The inter-node send operation can throw
SendStatusUnknownException (when the inter-node send fails for a valid binding) and
NodesUnreachableException (when the destination node is available via the routed path)
exceptions.
Figure 11 illustrates an example of send operation. Both the sender (node A) and
receiver (node B) nodes have been bound over the published channels, “Out” and “In”
respectively. Component c on node A wants to send a literal value 5 of type integer to node B
over the bound channels. The following statement sends the literal value to channel bound to
“Out” channel,
send 5 on c.output
On receiving the value 5 on one of the half-channel, INCH instantiates a sender
component. The sender component sends the value 5 to node B over its unicast channel. At
31. Wireless channels in InceOS
22
Figure 11: Inter-node channel send
the node B, the value is received by the radio and forwarded to the INCH component. The
INCH component identifies this as a data packet for channel “In” and forwards the integer to
LCN “In” inside component d. Simultaneously, INCH component sends a DATA ACK back
to node A. The sender component receives this DATA ACK and performs a delayed
acknowledgement to notify channel “Out” about the success of the send operation. Until the
receipt of this delayed acknowledgement, this execution thread (user component thread) is
blocked by the send operation.
5.6 Channel query operations
The inter node channel query operations, viz. getNeighboursOf (),
getPublicChannelsOf () and findPublishingNodes () would use the procedure
channel_query_proc () for querying channels over the radio network. All these channel query
operations would have their own procedures calling this channel_query_proc (). Similar to
the procedures in the publish and connect operations, these procedures would run in the user-
level thread. The procedure has two temporary channels; IN and OUT for communicating
directly with the radio. As the query must be broadcasted over the network to all the nodes,
the OUT channel of the procedure is connected to the broadcast channel of the radio module.
The nodes receiving a channel query packet forward the query packet from radio to the INCH
component (on the inch_in channel). The INCH processes the information from the
32. Wireless channels in InceOS
23
Figure 12: Inter-node channel queries
public_channels_table and bindings table, generates the response packet and returns the
response to the querying node. These queries can return null lists of nodes but do not throw
any exceptions.
An example of how channel_query_proc () works is illustrated in Figure 12. The node
A wishes to query the network to discover nodes for publishing channels,
publishedNodes = findPublishingNodes (In,”i”,”In”)
This statement queries the network to search for any incoming channels of type
integer and LCN name “In”. The channel_query_proc () is called from the procedure for
findPublishingNodes. The query is broadcasted over the network. The nodes receiving this
query will forward this query packet to the INCH component to check for presence of “In”
channel of type integer in the public_channels_table. The resulting set of publishedNodes is
returned back to the calling thread.
For other channel query operations, such as getNeighboursOf () and
getPublicChannelsOf (), a similar design is suggested. These operations would have their
own functions calling the channel_query_proc (). The channel_query_proc () would then
33. Wireless channels in InceOS
24
broadcast the query over the network to get the response. The getNeighbours () and
getPublicChannels () are special cases of the above query operations and will be used to
query the node on which it is executed.
34. Wireless channels in InceOS
25
6 IMPLEMENTATION
This section describes and details how the implementation of the Inter-node channel
abstraction and supporting mechanisms were undertaken for the InceOS operating system.
6.1 Configuration and set-up
The Insense compiler is written in Java. Therefore, to support the compilation process
for Insense, the entire design was implemented using the Eclipse IDE for Java. However,
Contiki and InceOS operating systems are written in C language. Since Eclipse IDE for Java
does not support development of applications in C, C/C++ Development Tooling (CDT)
plug-in was installed in Eclipse IDE.
Some mercurial repositories [6] were cloned, which consists of the following code
base:
InsenseCompilerContiki – This mercurial repository can compile Insense codes for
Contiki operating system. The compiler is written in Java language.
InsenseRuntimeContiki – This mercurial repository consists of runtime libraries
required by the Insense programs during execution. The runtime library consists of
radio modules, inter-node channel operations, standard functions and some data
structure definitions for the Contiki implementation. The runtime library is written in
C language.
InceOS – mercurial repository for InceOS operating system code and written in C
language.
InsenseCompilerInceOS – This mercurial repository compiles the Insense programs
for InceOS operating system. Similar to Contiki, this compiler is written in Java.
InsenseRuntimeInceOS – This mercurial repository contains runtime libraries
required by the Insense programs during their execution. The InceOS runtime library
does not contain functions for inter-node channel operations and as a part of this
project the inter-node channel operations will be implemented.
The Contiki operating system is not available at the above repository location and was
downloaded from its official website [2]. The latest version of Contiki is Contiki 2.6.
However for this project Contiki 2.5 was used. The Contiki operating system is written in C
language. For creating an executable that could run on the Tmote sky devices, the C source
code is compiled using a custom C compiler (MSPGCC) tailored for MSP430 micro-
controller device and made using the make tool. The version of MSPGCC used for this
project is 3.2.3. To be able to test and debug the executable on the Tmote sky devices, the
executable is flashed on the Tmote sky flash memory. The Tmote sky devices can be
35. Wireless channels in InceOS
26
connected via USB port. To enable USB detection of these Tmote sky devices on a system,
FTDI drivers were installed. InceOS firmware can loaded on Tmote sky devices to test the
application.
Alternatively, the code could be tested in the COOJA simulator, packaged along with
the Contiki operating system. For this project, all the code testing and execution was
performed on COOJA simulator. The COOJA simulator is written in Java and must be built
using the ANT build.xml file. Either Eclipse or ANT could be used for start the COOJA
simulating environment. For this project, ANT was used to start the simulator.
All the information about cloning the repositories, downloading MSPGCC and FTDI
drives is provided at [6].
6.2 The first program
To start with the implementation, an Insense dummy program implementing the
design for connect operation was written and compiled. The Insense code had the following
the implementation:
Type definitions of bindtype, ACKData and ConnectionChangeRequest (CCR)
o type bindtype is enum (BIND, UNBIND) - defines two enum named BIND and
UNBIND.
o type ACKData is struct (string s; ack_t ack_type; ack_event_t ack_event) – defines
a custom struct containing a string.
o type CCR is struct (bindtype bt; string LCN) – defines a custom struct containing a
bindtype and string.
Created two temporary channels: myUnicast and myReceive of direction OUT and IN
respectively. These channels were bound to the unicast and received channel of the
radio respectively. A timeout channel was also created.
Send the value to the radio module.
Performed a selective receive on both myReceive and timeout channel.
The generated C code had the basic function signatures, component templates,
template for selective receive, intra-node channel operations and exception handling
mechanism written in C. The tables (public_channels_table and bindings_table) cannot be
accessed from the Insense program due to the strong encapsulation by InceOS. Hence, the
generated C source code had to be modified to access these data structures. Since custom
data-types were defined in this dummy program, serialiser and deserialiser signatures and
36. Wireless channels in InceOS
27
Figure 13: public_channels_table
definitions were generated by the compiler. These functions provide support for serialising
the data before sending it over the radio and deserialising data that is received from the radio.
The entire implementation uses this generated C code as a template to implement all
other inter-node channel operations. The next sections discusses the details:
6.3 Inter-node channel handler (INCH) and supporting mechanisms
The implementation of INCH follows the design decisions for INCH explained in the
section 5. INCH is a single threaded component with the following responsibilities:
Listen to incoming requests originating from nodes.
Processes the incoming requests, with replying an ACK back to the requestor
wherever necessary.
Forward the data to and from the user component during inter-node send operation.
Update the public_channels_table and bindings_table, whenever required.
To cater the above-mentioned responsibilities, there are several data structures and
tables defined for the INCH component. All these data structures and tables needed for inter-
node channel operations are implemented in the InterNodeChannelHandler.h header file.
They are explained as follows:
6.3.1 Tables
All the tables used in the INCH are constructed using an iterable data structure. This
data structure is an abstraction written in C, in the Insense runtime system for Contiki (and
copied over to InceOS) to provide functionality similar to iterable collections in Java. The
IteratedList in C is circular list supporting insert, remove, fetch and search operations:
There are three tables implemented using this iterable data structure for INCH
operations: public_channels_table, bindings_table and incoming_halfchannels_table. These
are explained below:
6.3.1.1 public_channels_table
The public_channels_table (see
Figure 13) stores information about
published channels. Each row in the table
represents a published channel. The struct
InterNodeChannel (explained in 6.3.2.1) is
used to store each record. The published
channel information is never removed from
the INCH.
37. Wireless channels in InceOS
28
Figure 15: InterNodeChannel struct
Figure 14: bindings_table
6.3.1.2 bindings_table
The bindings_table (see Figure 14)
stores information about inter-node bindings.
Each row in the table represents a valid inter-
node connection and contains an instance of
struct Connection (explained in 6.3.2.2). The binding information is inserted during the inter-
node channel bind operation and removed when an inter-node channel unbind operation is
performed.
6.3.1.3 incoming_halfchannels_table
During the publish operation , the IN half channels created are put in the
incoming_halfchannels_table. This table is utilised by INCH for receiving data from the user-
level component. The usage of this table is explained in 6.3.5.
6.3.2 Data structures
Most of the data structures explained below are adaptations from Contiki
implementation. These are adapted in this implementation to deal with change in the node
addressing mechanism (using unsigned in InceOS as opposed byte array in Contiki) and to
cater for the new inter-node channel operation design under InceOS.
Only the data structure remote_connection_unbinder (explained in 6.3.2.7) is a new
data structure for InceOS implementation. This data structure is required when a remote
unbind operation is performed.
6.3.2.1 InterNodeChannel
This struct is used for holding information about the published channels. Each record
of public_channels_table holds one instance of InterNodeChannel data. The
InterNodeChannel struct has the five fields: chan_id localChan, chan_id dataChan,
channel_dir_t direction, StringPNTR typerep and StringPNTR LCN (see Figure 15). The first
two fields of this struct hold the channel IDs for the localChan (channel being published) and
dataChan (created during publish operation).The third field direction holds the direction
(OUT_DIR or IN_DIR) of localChan. The fourth field holds a string representation of the
38. Wireless channels in InceOS
29
Figure 16: Connection struct
Figure 17: ConnectionChange struct
payload type of the channel and direction. If the channel being is OUT of type integer, then
the typerep would hold “Oi”, O for output and i for integer. The last field LCN holds the
string representation of the local channel name. This LCN must be unique for a node. Two
inter-node channels cannot have same LCN on the same node.
6.3.2.2 Connection
This struct is used for holding information about the inter-node bindings. Each record
of the bindings_table holds one instance of Connection struct. The Connection struct has four
fields: unsigned outAddr, StringPNTR outLCN, unsigned inAddr and StringPNTR inLCN
(see Figure 16). The first and third fields hold information about the outgoing and incoming
addresses for a particular inter-node connection. The second field holds the LCN for the
outgoing channel, with the last field holding the LCN of the incoming channel. A serial ID
“SC” is specified for this struct, which is used to serialise and deserialise the connection
struct during inter-node communication.
6.3.2.3 ConnectionChange
This struct holds information about a connection change request (CCR) packet, used
during the inter-node channel connection and disconnection. A connection change request
packet generally consists of three fields: connection_change_t changeType, StringPNTR
typerep and Connection_PNTR connection (see Figure 17). The first field changeType is of
the data type connection_change_t, an enum containing two variables BIND and UNBIND.
The second field typerep is same as the typerep used in InterNodeChannel struct and holds
the typerep of the channel requesting connection change. The third field Connection_PNTR is
39. Wireless channels in InceOS
30
Figure 19: InterNodePacket
Figure 18: AckData struct
a pointer to Connection data struct that needs to be updated in the bindings_table. A serial ID
“SCC” is specified for this struct, which is used to serialise and deserialise the packet during
inter-node channel communication.
6.3.2.4 AckData
AckData struct contains information about the acknowledgement packet. The
AckData struct has three fields: ack_t ack_type, ack_event_t, ack_event and StringPNTR
inChanLCN (see Figure 18). ack_t and ack_event_t are enum that are defined for representing
different types of acknowledgement events. The third field is the LCN of the channel for
which ACK data is constructed. Acknowledgments are generally sent from the INCH to
return status of any inter-node operation (connection, disconnection or channel send
operations) to the remote node. The serial ID “SACK” is specified for this struct, which is
used to serialise and deserialise the AckData struct during inter-node channel communication.
6.3.2.5 InterNodePacket
The RadioPacket contain information about the address of remote node and the
payload. The receiver cannot determine the sender just looking at a RadioPacket. Therefore,
in a multi-hop environment, the inter-node communication would fail, as the final destination
may not have information about the original sender. For this purpose, InterNodePacket struct
was introduced. This packet contains five fields: unsigned srcAddr, unsigned destAddr, void*
srcPort, StringPNTR inLCN, AnyTypePNTR payload (see Figure 19). The first two fields
represent the original sender and final destination. The third field is a generic pointer and can
contain any required information needed for special operations. The fourth field contains the
LCN of the destination channel. The last field is an Any of the payload (user-defined struct).
In a multi-hop routing network, all packets (either connection change or data or
40. Wireless channels in InceOS
31
Figure 21: remote_connection_unbinder struct
Figure 20: InterNodePacketSP struct
acknowledgements) could be encapsulated inside the InterNodePacket during inter-node
channel communication. When an InterNodePacket is received by INCH, it can check if the
destAddr is its node address. If destAddr is its node address, then packet was destined for this
node and it can process it, else the INCH can forward the InterNodePacket to the next hop.
This is not implemented in the INCH currently, as INCH does not provide support for multi-
hop routing at the moment.
6.3.2.6 InterNodePacketSP
All the field of InterNodePacket SP are similar to InterNodePacket, except the
payload field (which is a generic pointer data). The payload field (AnyTypePNTR) of the
InterNodePacket is serialised in this struct. The size of serialised payload is also stored in this
struct (see Figure 20). The serial ID “SPI” is specified to InterNodePacketSP struct and is
used to serialise and deserialise the InterNodePacketSP during inter-node channel operations.
The payload of RadioPacket must be InterNodePacketSP for inter-node channel
communication. All other struct types will be ignored by INCH and not discarded without
processing. This struct is required so that the payload of InterNodePacket is serialised before
the InterNodePacketSP becomes payload of RadioPacket.
6.3.2.7 remote_connection_unbinder
This struct is introduced to cater remote_connection_unbinder operation. The
remote_connection_unbinder has two fields: unsigned nodeAddr and StringPNTR LCN.
nodeAddr is the address of the node on which the LCN needs to be unbound (see Figure 21).
The serial ID “RUB” is specified for this struct and is used to serialise and deserialise the
remote_connection_unbinder packet during inter-node channel operations.
41. Wireless channels in InceOS
32
Figure 23: De-capsulation of packet from RadioPacket
6.3.3 Constructors, serialisers, deserialisers and decRefs
All the structs mentioned in the above section have their own constructor, serialiser,
and deserialiser and decRef functions. The constructor for each struct constructs an instance
of the respective struct and initialises its fields with the values passed as parameters. Similar
to Contiki implementation, reference counting garbage collection is used in the INCH
implementation for InceOS. This means that assignment into variables often has to be
conducted using a DAL_assign function which modifies the reference counters. To support
garbage collection the reference count for pointer parameters are incremented (similar to
Contiki implementation). The instance returned by the constructor always has a reference
count of zero. The constructor also sets the decRef functions for each struct.
Most of the serialisers and deserialisers for the above mentioned structures were auto-
generated using Insense compiler (similar to 6.2).
6.3.4 Encapsulation and de-capsulation mechanism
As explained in sections 6.3.2.5 and 6.3.2.6, the payload of a radio packet for inter-
node channel communication is InterNodePacketSP, a serialised version of InterNodePacket.
The payload of InterNodePacket can be the data of any packet type e.g. ConnectionChange,
AckData, data etc. that is destined for other node. To support the garbage collection and to
keep track of reference counts for successful decRef execution, the encapsulation of any
packet inside RadioPacket must be performed in a particular order.
Figure 22 shows an example of encapsulation of a packet into RadioPacket. The
packet to be sent is converted to AnyTypePNTR and attached to the payload of
InterNodePacket. The payload of InterNodePacket is serialised to construct an
Figure 22: Encapsulation of packet to RadioPacket
42. Wireless channels in InceOS
33
Figure 24: Instantiation of INCH component
InterNodePacketSP. The InterNodePacketSP is converted to AnyTypePNTR before attaching
to the payload of RadioPacket.
Figure 23 shows an example of de-capsulation of data from RadioPacket. The de-
capsulation mechanism is the exact reverse of encapsulation steps. InterNodePacketSP is
retrieved from the payload of RadioPacket. The payload of InterNodePacketSP is deserialised
to construct a new InterNodePacket and the data is retrieved from its payload
It must be noted that serialising the payload of InterNodePacket does not increment
the reference count of InterNodePacket and deserialising the payload of InterNodePacketSP
constructs a new InterNodePacket having reference count zero. Hence, DAL_assign function
is used while constructing the InterNodePacket. After utilisation, DAL_decRef is used to
decrement the reference (or free the memory if reference count becomes zero). It must also be
noted that, the radio module decrement the reference count of before sending the packet over
the radio. Hence before sending the packet to the radio, the RadioPacket is constructed using
DAL_assign.
When radio receives packet from transmission medium, it increments the reference
count before sending the packet to other components. Therefore, after using the RadioPacket
in the component, the reference count of RadioPacket must be decremented.
This mechanism helps to overcome memory corruptions and memory leaks caused by
releasing memory that is still being referenced.
6.3.5 INCH component
As explained in section 5, under the Contiki implementation, the INCH component is
implemented as a multi-threaded component with the use of proto-threads for handling each
request. This design used a lot of flash memory for program code due to necessitating many
thread and data structure constructor functions, a concern for memory constrained devices.
As per the new design, the INCH is designed as a single threaded component handling
incoming requests only. All outgoing requests run in the user-level threads. The INCH
component implementation has a constructor and behaviour to maintain the semantics of
InceOS component implementation. The INCH component code was implemented by
modifying the component template generated in the first program (see 6.2) and writing C
code in the template to implement the inter-node channel operations and supporting
mechanisms.
The constructor of the INCH is called during the instantiation of the INCH
component. The INCH component is instantiated before any of the user components are
43. Wireless channels in InceOS
34
created (see Figure 24). A stack size of 256 bytes is allocated to INCH component for its
execution. There are three channels that are created during instantiation of INCH: inch_in,
inch_out and timeOutChan (see Figure 26). The inch_in channel is an incoming channel
bound to the received_comp channel, on which radio component sends received data to local
components on the same node. The inch_out is an outgoing channel bound to the
unicastSend_comp channel of radio component, on which data is sent to a remote node using
the unicast primitive. The inch_in channel receives requests/data from the radio, while the
inch_out sends ACKs back to other nodes.
The behaviour of the INCH selectively receives on different channels. The length of
the select struct is set to length of the incoming_halfchannels_table plus two (see Figure 25)
and populated with all the incoming half-channels created during the publish operation along
with the inch_in and timeOutChan.
The channels listening on INCH can be categorised into three different categories:
Figure 25: channel_select operation in INCH
Figure 26: channels for inter-node communication
44. Wireless channels in InceOS
35
The INCH listens to the timeOutChan channel created during the instantiation of
INCH component for periodic ticks (every 5 seconds). This timeOutChan makes sure that all
incoming half-channels are being listened to by the INCH behaviour for inter-node channel
send operations. The timeOutChan receives a value every 5 seconds and the selective receive
operation is restarted. If any channel was published during this period, the INCH will also be
listening to it now.
The INCH listens to all the half-channels of direction IN created during the publish
operation. These half-channels receive data from user-level components. When any data is
received on one of the half-channels, INCH spawns a sender component to handle outgoing
data send operation. This sender component takes care of sending data and receiving ACK
back from the receiving node (see section 6.7). The data is converted to AnyTypePNTR so
that it can be attached to payload of InterNodePacket, as described in 6.3.4. The
implementation using AnyTypePNTR can send data of different data types such as Integer,
Real, Boolean, Unsigned or any pointer data type. To prevent multiple send operations on the
same half-channel two guards are set; one guard on the user component channel and one of
the half-channel in the INCH.
The INCH listens to all these channels in ACK_AFTER mode (see Figure 25). In the
ACK_AFTER mode, the boolean in_ack_after field of channel struct is set to true. When
in_ack_after is set to true the channel which sent data is not acknowledged immediately. The
sender channel needs to be acknowledged explicitly and the user component gets blocked,
until it is acknowledged. Only after processing the received ACK, the half-channel is
acknowledged. The half-channel is removed from the incoming_halfchannels_table
temporarily. This makes sure that the INCH is not listening to the half-channel indicating a
pending inter-node send operation. Only after processing the received ACK, the half-channel
is added back to incoming_halfchannels_table.
The INCH also listens on inch_in channel for incoming requests/data coming from
other nodes. Since inch_in is connected to the radio’s received_comp channel, the inch_in
channel accepts RadioPackets only. As described in 6.3.4, the payload of RadioPacket should
be InterNodePacketSP struct. No other RadioPacket payload types are processed by the
INCH for inter-node channel operations. The request/data packets are encapsulated inside the
payload of the InterNodePacket. The inch_in processes the following types of requests:
Connection change request (CCR) – The INCH on a node can receive CCR if any
node wants to bind or unbind one of its channels with this node’s channel. The INCH also
receives connection change requests for connecting channels remotely (explained in section
6.5.4). If the payload of the InterNodePacket is ConnectionChange, then the INCH has
received a CCR. See section 6.5 and 6.6 for details about how a CCR is generated.
45. Wireless channels in InceOS
36
The INCH component first checks if the channel on which a connection change is
requested is published on that node. If the channel was not published, it sends back an ACK
with ChannelsUnknownException. If the channel was present in the public_channels_table,
the INCH component processes the received CCR. The INCH component checks for the
typerep of CCR to identify it’s a general CCR or a remote connection request. Generally, the
typerep of CCR contains the typerep of the channel that initiated the CCR.
If the CCR is for unbinding connection, the connection, if present in the
bindings_table is removed from there. If the CCR is for binding a connection, the connection
is inserted into the bindings_table. But before inserting the connection, the INCH checks if
the LCN on which the connection needs to be bound is published or not, by checking its
presence in the public_channels_table. If it is not published, ChannelsUnknownException is
sent back to the requestor. If the channel was published, INCH checks if the channels
interested in the binding other are compatible or not. Compatibility is check by comparing
the typerep of the published channel on the INCH and typerep in the ConnectionChange.
Compatibility of the channels is defined as follows:
One of the channels in the connection must be incoming and other must be outgoing.
The direction is the first character of the typerep string (typerep [0]). If both of the channels
in the connection have same direction, the INCH replies with an ACK consisting of
IncompatibleChannelsException. The payload type for the both the channels in the
connection must be same. If the payload types are different, the INCH replies with an ACK
consisting of IncompatibleChannelsException.
However, for a remote channel connection, the typerep is “*” and INCH uses this
condition to identify a remote connection request. Remote connection request is a special
type connection request, where a node requests channels to be bound to two other nodes. For
any other connection or disconnection requests, the typerep contains the typerep of the
channel initiating the connection change. For a remote connection request, the INCH
component has to send another CCR to the node participating in the binding. The requestor of
remote connection does not check for direction of channels during construction of the
connection. It always assumes the first pair of node and its channel are outgoing, while
second pair of node and its channel are incoming. The INCH on the node receiving a remote
connection request checks if the instance of connection to be changed is valid. It validates if
the channel specified as outgoing is really present in its public_channels_table with direction
outgoing. If a match is found, a connection change request is sent to the node participating in
the binding. If no match was found, the connection change is reversed (the incoming and
outgoing parameters of the connection are swapped), and this connection is sent to the other
node. This other node receives a general CCR and it processed as explained below.
If the bind or unbind connection change is successful, we send an acknowledgement
with successful ack event. The function to send ACK is explained in section 6.3.6.
46. Wireless channels in InceOS
37
Remote connection unbind requests: When an Insense programmer wishes to
disconnect a certain channel on a different node, the remote unbind remotely operation is
executed. This operation sends remote connection unbind request to the specified node. If the
payload of the InterNodePacket is remote_connection_unbinder, then it means that the INCH
received a remote connection unbind request. See section 6.6 for details on how a
remote_connection_unbinder packet is constructed and sent. When the INCH receives a
remote_connection_unbinder packet, it calls the remoteUnbind operation on that node for that
channel. remoteUnbind_proc operation is explained in section 6.6.2. The remoteUnbind
operation removes all the inter-node connections for the channel specified in the
remote_connection_unbinder packet.
Acknowledgements: If the payload of InterNodePacket is AckData, then it means
INCH has received an ACK. Since INCH does not send any requests (request to remote
nodes are sent by the procedures invoked by the user-level components), it does not have to
wait for acknowledgements. All acknowledgement packets (AckData struct) received on
inch_in are discarded and not processed.
Data packets: All other types of InterNodePacket payloads other than the three
mentioned above received by the inch_in channel are considered to be data packets.
InterNodePacket contains a field that identifies the destination channel’s LCN. The
corresponding half-channel created during publish operation is fetched from the
public_channels_table. Ideally, the half-channel should be outgoing channel. The data packet
is retrieved from the payload of InterNodePacket and send over the half-channel. Since the
half channel is connected only to the user component channel (published with the LCN), the
user component receives the data immediately. The implementation uses the abstraction
provided by AnyType and supports all types of data types such as Integer, Unsigned, Real,
Boolean, Byte and any user-defined data structures. The ACK is sent back to the sender
component in an AckData struct and specifies the send status to be delivered to the user-level
component that originally sent the datum.
6.3.6 sendACKPacket function
The sendACKPacket function sends acknowledgements to nodes requesting
connection changes or sending data. Generally, sending of ACK completes an inter-node
operation on that node. The function is called mainly from the INCH behaviour as INCH is
primarily responsible for dealing with requests.
The function has six parameters: jmp_buf *ex_handler, unsigned remoteAddr, void
*srcPort, ack_t ack_type, ack_event_t ack_event and StringPNTR LCN. The first parameter
is the address where the function should jump, in case of exceptions. The second parameter is
the address of the node to which AckData needs to be sent. The third parameter is a generic
pointer can hold any data. In our implementation we mostly use it to hold the LCN of the
channel for the request was made. The ack_t and ack_event_t are enum that define different
47. Wireless channels in InceOS
38
types of acknowledgement. The last parameter, LCN, is the name of the channel on which the
AckData needs to be sent to.
This function constructs an AckData struct and sends it over the radio to the
remoteAddr node by encapsulating it inside RadioPacket using the method mentioned in the
section 6.3.4. There is no timer maintained before sending ACKs.
6.4 publish operation
The publish operation publishes the local channels and exposing them to other nodes
for inter-node channel communication. The publish operation is supported by the
publishChannelAs_proc procedure. The primary functionality of the procedure is to add
details of the published channel into the public_channels_table. The procedure takes five
parameters as input: chan_id localChan, channel_dir_t direction, StringPNTR localLCN,
StringPNTR typerep and jmp_buf (to support exception handling). The localChan is the
channel from the user component that is being published. The direction and typerep hold the
information about the direction and payload type of the channel being published. The third
parameter localLCN is the local name of the channel. The other nodes can use this LCN to
identify the channel for inter-node channel communication.
When the procedure is invoked, it first checks for existence of localLCN in the
public_channels_table. The searchList procedure from the IteratedList library is used to
search through the public_channels_table. If the localLCN already exists,
DuplicateLCNException is thrown and function exits. The Insense programmer must use
another LCN for publishing the channel. If localLCN is unique to that node, then the
procedure creates a corresponding channel (halfChannel) of the opposite direction. If the
published channel was outgoing, an incoming channel would be created and vice versa. The
procedure binds the localchan with halfChannel (for inter-node send operations). Since
public_channels_table records are of InterNodeChannel struct type, an instance of
InterNodeChannel and inserted into the public_channels_table using the insertElement
procedure of IteratedList library. The constructed InterNodeChannel stores the following
values in this instance: localchan, halfChannel, direction of the new channel, typerep of
published channel and localLCN.
6.5 connect operation
The connect operation is an extension to the local channel connection operation.
During the implementation, different types of inter-node channel communications were
identified. They are remoteAnonymousBind_proc, remoteBind_proc and
remoteBindRemotely_proc. Since all these functions required sending CCRs to other nodes, a
procedure sendConnectionChange_proc was implemented, to reuse the code.
48. Wireless channels in InceOS
39
6.5.1 sendConnectionChange_proc
The sendConnectionChange_proc has five parameters: unsigned remoteAddr,
connection_change_t changeType, StringPNTR typerep, Connection_PNTR conn and
jmp_buf (to support exception handling). Regardless of the changeType of CCR type; BIND
or UNBIND, this procedure searches the bindings_table for inter-node binding information.
For the BIND request, the procedure proceeds if the conn is not present in the bindings_table.
For an unbind request, the procedure proceeds if the conn is present in the bindings_table.
The procedure creates two channels, myUnicast (OUT direction) and myReceive (IN
direction) connected to radio component’s unicast and received channel respectively. A
timeout channel is also created so that the procedure does not get blocked waiting for an
ACK. The procedure takes care of two activities:
1) The procedure sends ConnectionChange packets to remoteAddr via unicast channel of
radio component. The ConnectionChange is constructed using changeType, typerep
and conn. The encapsulation of ConnectionChange packets into RadioPacket is done
using the mechanism specified in section 6.3.4. The INCH on the remote node
handles this CCR and replies with an ACK.
2) After sending request to other node, the procedure waits for ACK or timeout. When
the acknowledgement is received, it is de-capsulated from the RadioPacket and
AckData is processed. If it’s a successful ACK, the connection is inserted (for BIND
request) or removed (for UNBIND request) from the table. The remote node will send
negative acknowledgements if the channel on which connection change is requested is
not published on the remote node (throws ChannelsUnknownException) or if the
channels to be bound are not compatible (throws IncompatibleChannelsException). If
ACK is not received within the timeout period, BindStatusUnknownException is
thrown from the procedure.
6.5.2 remoteBind_proc
The remoteBind_proc uses the LCN of the local channel to connect inter-node
channel. This procedure takes five parameters: StringPNTR localLCN, unsigned remoteAddr,
StringPNTR remoteLCN, StringPNTR typerep and jmp_buf (to support exception handling).
The remoteBind_proc constructs a connection using the localChan, remoteAddr and
remoteLCN. The sendConnectionChange_proc is called for sending CCR over the radio,
listening to ACKs and updating the bindings_table.
6.5.3 remoteAnonymousBind_proc
If the Insense programmer wishes to bind channels over the radio anonymously (i.e.
without publishing the channel), the Insense compiler makes a call to
remoteAnonymousBind_proc procedure. Connecting anonymously means connecting inter-
node channels without specifying LCN. The Insense programmer uses the channel ID for
connecting inter-node channels. However, the remoteLCN must be specified as channels on
49. Wireless channels in InceOS
40
the remote node. For connecting inter-node channels without publishing them, the Insense
programmer can write the following Insense code:
connect s.output to “Ticker” on 1
OR
connect “Ticker” on 1 to s.output
The compiler generated C code for the above two operations are same. The procedure
takes five parameters: chan_id localChan, unsigned remoteAddr, StringPNTR remoteLCN,
StringPNTR typerep and jmp_buf (to support exception handling). This procedure uses the
channel ID of the localChan that needs to be connected over the radio. Even when connecting
channels anonymously, the local channel is published. The Insense programmer is not aware
of its published status, but the information is stored in the public_channels_table. The LCN of
the channel is the string representation of the channel ID. To prevent multiple publish for the
same channel during multiple remoteAnonymousBind_proc requests, the procedure has a
guard, which checks for the presence of local channel in the public_channels_table. If local
channel is not present in the table, the local channel is published using the string
representation of the channel ID. The localChan, LCN and typerep are used to construct an
instance of InterNodeChannel, thereby publishing the channel. Now that the channel has an
LCN (published anonymously), the remoteBind_proc is called for sending CCR over the
radio.
6.5.4 remoteBindRemotely_proc
When the Insense programmer wishes to connect two channels of remote nodes, the
remoteBindRemotely_proc is called. The Insense programmer uses the following statement
to connect channels remotely.
connect “sender_output” on 1 to “Ticker” on 2
This procedure has five parameters: unsigned srcAddr, StringPNTR srcLCN,
unsigned destAddr, StringPNTR destLCN and jmp_buf (to support exception handling). If
one of address specified is its node address, the procedure constructs a connection object with
the node address (inAddr if LCN is of incoming direction, outAddr if LCN is outgoing) and
calls sendConnectionChange_proc to handle with this change request.
If neither of the nodes are its executing node’s address, the procedure constructs a connection
with srcAddr as incoming and destAddr as outgoing. Since the executing node is not aware of
the typerep of the channels to be bound, the typerep is set to the “*” (wild character). This
unique typerep helps the INCH on the remote node realise that the packet sent is a remote
connection request packet. The INCH on the srcAddr deals with the typerep as explained in
section 6.3.5. The sendConnectionChange_proc receives ACK with/without exceptions or
timeouts.
