110015978_WirelessChannelsInInceOS

WIRELESS CHANNELS IN

INCEOS

Tejas Unnikrishnan 110015978

Master of Science

Networks and Distributed System

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:………………………


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.


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.


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


v

5.5 send operation ........................................................................................................... 20

5.6 Channel query operations .......................................................................................... 22

6 IMPLEMENTATION .................................................................................................. 25

6.1 Configuration and set-up ............................................................................................ 25

6.2 The first program ....................................................................................................... 26

6.3 Inter-node channel handler (INCH) and supporting mechanisms ................................. 27

6.3.1 Tables ............................................................................................................................................ 27

6.3.2 Data structures ............................................................................................................................. 28

6.3.3 Constructors, serialisers, deserialisers and decRefs ..................................................................... 32

6.3.4 Encapsulation and de-capsulation mechanism ............................................................................ 32

6.3.5 INCH component........................................................................................................................... 33

6.3.6 sendACKPacket function ............................................................................................................... 37

6.4 publish operation ....................................................................................................... 38

6.5 connect operation ...................................................................................................... 38

6.5.1 sendConnectionChange_proc ....................................................................................................... 39

6.5.2 remoteBind_proc .......................................................................................................................... 39

6.5.3 remoteAnonymousBind_proc....................................................................................................... 39

6.5.4 remoteBindRemotely_proc .......................................................................................................... 40

6.6 disconnect operation .................................................................................................. 41

6.6.1 remoteAnonymousUnbind_proc .................................................................................................. 41

6.6.2 remoteUnbind_proc ..................................................................................................................... 41

6.6.3 remoteUnbindRemotely_proc ...................................................................................................... 41

6.7 send operation ........................................................................................................... 42

6.7.1 remote_channel_sender component ........................................................................................... 42

6.7.2 sendData ....................................................................................................................................... 43

6.8 Runtime Updates ....................................................................................................... 43

6.9 Compiler Updates ...................................................................................................... 44

6.10 InceOS Updates ......................................................................................................... 44

7 EVALUATION AND TESTING ..................................................................................... 45

7.1 Non-functional requirements - conformance .............................................................. 45

7.2 Functional requirements – conformance..................................................................... 47

7.3 Testing and screenshots ............................................................................................. 47

8 Challenges and Debugging ...................................................................................... 49

8.1 Reference counting garbage collection ....................................................................... 49

8.2 Stack sizes ................................................................................................................. 49


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


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


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


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.


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.


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].


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


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


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


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


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


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


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


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].


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]


13

Test and debug the final product

Deployment of the final implementation

Release

Figure 7: Gantt chart for the project


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


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.


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


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.


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


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


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-


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


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


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


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.


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


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


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.


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


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


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


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.


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


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


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


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.


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.


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


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.


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


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.


41

6.6 disconnect operation

The inter-node disconnect operation is an extension to the local channel disconnect

operation. Similar to connect operation, during the implementation of disconnect operation,

different types of disconnect operations.

6.6.1 remoteAnonymousUnbind_proc

Similar to the remoteAnonymousBind_proc, the remoteAnonymousUnbind_proc uses

the channel ID for disconnecting channels. The procedure takes just two parameters: chan_id

localChan and jmp_buf. The procedure begins with checking if the localChan is internode

channel, by checking its presence inside the public_channels_table. The LCN of the channel

is checked inside the bindings_table. For each matching connection entry in the

bindings_table, a connection change request is sent with UNBIND type using the

sendConnectionChange_proc. This is looped until all the connections are removed from the

bindings_table. Once all the inter-node connection information is dissolved, the local

bindings are removed by calling the channel_unbind operation. This local unbind operation

removes the connection between the localChan and its corresponding half-channel (created

during publish operation). Since this local binding is not accessible to the Insense

programmer, this connection is re-connected, to maintain the published channel information.

6.6.2 remoteUnbind_proc

Similar to remoteBind_proc, the remoteUnbind_proc uses the LCN of the channel for

inter-node operation. For disconnecting the inter-node channels, the Insense programmer

should the following operation:

disconnect “Ticker” on 2

The procedure takes three parameters: unsigned nodeAddr, StringPNTR LCN and

jmp_buf. The Insense programmer can disconnect the channels of any node using this

procedure. If the node address passed to the procedure is the address of the node on which it

is being executed, then the procedure fetches the corresponding channel ID for the LCN

specified and the calls the remoteAnonymousUnbind_proc to disconnect inter-node channels.

If the node address specified is a remote node, then the remoteUnbindRemotely_proc

procedure is called.

6.6.3 remoteUnbindRemotely_proc

When the Insense programmer wishes to disconnect channels of a remote node, the

remoteUnbindRemotely_proc is called from the remoteUnbind_proc. The procedure takes

three parameters: unsigned nodeAddr, StringPNTR LCN and jmp_buf. The LCN is the local

name of the channel of the node address specified. The procedure uses

remote_connection_unbinder struct to send a remote connection unbind request. But before

sending remote unbind request, the node on which the procedure is executed checks if any of

its channels is connected to the specified LCN. If any connection is found for that LCN, the


42

connection change request is sent (sendConnectionChange_proc) and the connection

information is removed from the bindings_table. Once the presence of specified node and its

LCN are removed from the bindings_table, the procedure constructs a

remote_connection_unbinder packet using the steps mentioned in 6.3.4 and sends it over the

radio. Similar to the sendConnectionChange_proc, the procedure has three channels:

myUnicast, myReceive and timeOutChan, performing exactly the same functions. The

procedure waits on ACK/timeout. As explained in 6.3.5, the INCH deals with this

remote_connection_unbinder packet and sends an ACK. When the ACK is received, the

procedure exits. No changes are made to bindings_table on the node on which the procedure

is executed after an acknowledgement for remote_connection_unbinder packet is received.

6.7 send operation

As explained in the design of inter-node send operation (section 5.5), the inter-node

send operation runs is a separate component thread instantiated by the INCH component.

When the Insense programmer writes local channel send operation to any channel that

contains inter-node bindings, the data might be received on the half-channel by the INCH’s

behaviour. Upon receipt of data, the INCH behaviour creates a new component for sending

the data over the radio. This makes sure that INCH is not blocked during inter-node channel

operations. The INCH also removes the half-channel temporarily from the

incoming_halfchannels_table to prevent multiple send requests on that half-channel. The

sender component is explained below.

6.7.1 remote_channel_sender component

The remote_channel_sender component is constructed using a parameterised

constructor. The constructor takes three parameters: chan_id dataChan, StringPNTR inLCN

and AnyTypePNTR data. The dataChan is the channel ID of the half-channel on which INCH

received data. The inLCN is the LCN of the channel on which data was sent by the Insense

programmer. The sender component receives data as AnyTypePNTR object. INCH accepts

all types of data and converts the data into AnyTypePNTR and passes into the constructor of

the component.

The sender component has three channels: sender_in, sender_out and timeOutChan.

The sender_in and sender_out communicate with the radio component and are connected to

the unicast and received channel of the radio. They send and receive RadioPackets. The

behaviour of the sender component checks for bindings associated to the channel on which

data was sent. The sender component selects the first connection matching the inLCN. If no

connection for the inLCN exists, the component waits indefinitely. When the inLCN is

connected to any inter-node channel on other rode, the loop breaks. Whenever a connection is

matched, the sendData (explained below) procedure is called. This procedure sends the data

over the radio and waits for ACK/timeout


43

After sending data over the radio, the sender component acknowledges the channel

send operation, thereby unblocking the user component. The half-channel is inserted back

into the incoming_halfchannels_table to listen for more data send operations.

6.7.2 sendData

The sendData procedure is similar to the sendConnectionChange_proc. But instead of

encapsulating ConnectionChange packet, this procedure encapsulates the AnyType data into

a RadioPacket. This procedure uses the sender components’ channels (sender_in, sender_out

and timeOutChan. The data is sent to the radio through the sender_out channel. The

procedure selectively listens to the sender_in and timeOutChan. The sender_in waits for the

ACK sent by the receiving node. If a successful ACK was received, the procedure returns a

GENERAL_SUCCESS_EVENT to the behaviour of the sender component. For a negative

acknowledgement, SendStatusUnknownException is returned to the behaviour. For timeouts,

a BindStatusUnknownException is returned to the behaviour.

6.8 Runtime Updates

The following files were created / edited under the InsenseRuntimeInceOS

implementation.

InterNodeChannelData.c – contains constructors for data structures described in

6.3.2.

InterNodeChannelData.h – contains structure definitions for 6.3.2

InterNodeChannelHandler.c – contains the implementation for the INCH

component (section 6.3.5)

InterNodeChannelHandler.h – type definition of INCH component

InterNodeChannelHandlerPublish.c – definition of publishChannelAs_proc

procedure (described in 6.4)

InterNodeChannelHandlerRemoteAnonymousBind.c – definition of

remoteAnonymousBind_proc procedure (described in section 6.5.3)

InterNodeChannelHandlerRemoteAnonymousUnbind.c - definition of

remoteAnonymousUnbind_proc procedure (described in section 6.6.1)

InterNodeChannelHandlerRemoteBind.c - definition of remoteBind_proc

procedure (described in section 6.5.2)

InterNodeChannelHandlerRemoteBindRemotely.c - definition of

remoteBindRemotely_proc procedure (described in section 6.5.4)


44

InterNodeChannelHandlerRemoteUnbind.c - definition of remoteUnbind_proc

procedure (described in section 6.6.2)

InterNodeChannelHandlerRemoteUnbindRemotely.c - definition of

remoteUnbindRemotely_proc procedure (described in section 6.6.3)

InterNodeChannelHandlerSendConnectionChange.c - definition of

remoteSendConnectionChange_proc procedure (described in section 6.5.1)

InterNodeChannelHandlerSender.c - definition of sender component (described in

section 6.7.1)

InterNodeChannelHandlerSender.h – type definition of sender component

InterNodeChannelHandlerTableSearch.c – contains functions related to Table

search operations. Added searchChannelTableForDataChan,

searchChannelTableForLocalChan to search for dataChan and localChan in the

public_channels_table.

GlobalObjects.c – instantiate the INCH component.

6.9 Compiler Updates

The inter-node channel communication functions were made available to the Insense

programmer by updating the Insense compiler for InceOS. The following files were updated

so that the compiler could generate appropriate function call to access the inter-node channel

communication abstraction -

SyntaxAnalyser.java

Publish.java

Connect.java

Disconnect.java

CompilationUnit.java

6.10 InceOS Updates

To support the new implementation, few changes were in the InceOS operating

system source code. The following files were updated -

channel.c – added functions to access channel attributes (get_channel_pntr,

get_channel_typesize, channel_contains_pointers)

channel.h – added new function declaration from channel.c file


45

7 EVALUATION AND TESTING

The primary goal of the project is to design and develop an Inter-node channel

handler for InceOS operating system. The requirements discussed in the section 4 were

identified to achieve the primary goal. In this chapter we evaluate the design and

implementation discussed in section 5 and 6, to check for its conformance with the

requirements.

7.1 Non-functional requirements - conformance

The Contiki implementation of INCH occupied a large amount of space and this was

one of main concerns during the Contiki implementation phase. The Contiki inter-node

channel implementation did however include more functionality than was implemented for

InceOS during this project. In order to make a fair comparison of code sizes of both

implementations, the Contiki implementation was paired back to provide only the

functionality provide by the InceOS implementation. Figure 27 shows the sizes of different

Inter-node channel handler files. The total size of files required by INCH occupied 6958

bytes of memory under the Contiki implementation. However, due to dependency of code in

the Contiki INCH, it couldn’t be paired back completely to the status of the INCH

implementation under InceOS. The code for multi-hop routing has not been commented out,

but the code related to Public channel queries was commented out. Under the InceOS

implementation, the files required to perform the same inter-node operation occupies 5946

bytes of memory. This is 1 kB less space utilisation as compared to the Contiki

Figure 27: Code size of INCH under Contiki


46

implementation..

We can also compare a certain INCH operation to verify the memory consumption.

For connect operation, the Contiki implementation used 6846 bytes of memory (aggregate of

file for connect operation) while the InceOS implementation uses 3856 bytes of memory.

This show that the code sizes of inter-node connect operation uses approximately 44% less

memory. Therefore, we can see that the implementation of INCH under InceOS has reduced

the space utilisation on Tmote sky devices considerably.

Figure 29 shows the size of executable for a publish_connect_disconnect program

under Contiki implementation. The executable uses 47444 bytes of memory for Contiki. For

the same example, the size of executable was 31684 bytes of memory under InceOS

(approximately 33% less memory consumption compared to Contiki). Under the new

implementation even the size of the executable is lesser compared to the previous

implementation.

Figure 28: Code size of INCH under InceOS

Figure 29: Size of executable under InceOS and Contiki


47

Under the new implementation, along with the code size, the utilisation of the

memory (heap) has also reduced considerably. Under the Contiki implementation, the INCH

was modelled as multi-threaded component which spawned protothreads to handle different

outgoing and incoming requests. Under the InceOS implementation, most of the requests are

executed in the user component thread. Since most of the operations provided by INCH can

run concurrently and are executed in the user-level component thread, this implementation

has less number of schedulable entities. This decreases the number of context switches

required between various schedulable entities as compared to Contiki implementation.

Moreover, InceOS being a light weight operating system compared to Contiki provides faster

processing.

7.2 Functional requirements – conformance

As discussed in sections 5and 6, an inter-node channel handler and supporting

mechanisms were designed and implemented for InceOS that can publish, connect and

disconnect inter-node channels. The Insense programmer can also send data over the inter-

node channels. The next section has screenshots that validates conformance of functional

requirements.

7.3 Testing and screenshots

An Insense application which has inter-node publish, connect and send operations was

simulated on Cooja. The simulation was executed with two nodes, where the one of the nodes

issues request and sends data to the other node. Both the nodes have their own published

channels. Mote 1 is loaded with the DEMO_RECEIVER firmware (see Figure 31) and mote

2 is loaded with the DEMO_SENDER firmware (see Figure 30). The DEMO_RECEIVER

Figure 31: Mote 1 running the DEMO_RECEIVER

firmware

Figure 30: Mote 2 running the DEMO_SENDER

firmware


48

and DEMO_SENDER programs are shown in Figure 33 and Figure 32. Please refer

Appendix A for extended logging information.

Figure 32: DEMO_RECEIVER program Figure 33: DEMO_SENDER program


49

8 CHALLENGES AND DEBUGGING

Writing applications for WSN devices are tricky because of its resource constrained

nature. During the implementation of inter-node channel operations and supporting

mechanisms, numerous challenges were faced. This section explains the challenges faced

during the implementation.

8.1 Reference counting garbage collection

The INCH uses the reference counting garbage collection mechanism provided by

InceOS for freeing memory. If a wrong value was passed to the garbage collector, it would

interpret the value as a valid address at which to garbage collect and starts trawling through

memory, freeing up resources that may still be used by components or the operating system.

This leads to seemingly illogical program behaviour, making it very tricky to find the bug.

Another problem encountered during the implementation was failure to call the

garbage collector. This was an oversight and later rectified. Failure to call garbage collector

led to memory leaks and the mote quickly ran out of memory.

8.2 Stack sizes

During the creation of a component, InceOS dynamically allocates components’

program stacks on the heap. The InceOS compiler calculates how much stack space to

reserve and generates this value at compile time. However, since the INCH, radio and sender

component were implemented in C directly, it was difficult to estimate the stack sizes before

the implementation. A printStackSize procedure was used to determine the size of the stack

that was used by a component at runtime. But at the beginning of the project, the stack sizes

were specified incorrectly. This resulted I stack overflow where program code could over-

write any location in RAM resulting in seemingly illogical program behaviour that led to

horrendous debugging sessions.

Unfortunately, a bug was detected rather late in the implementation and was not

rectified by the time of submission. When sending data between 2 remote channels it was

detected that only one datum was successfully being sent and received after a remote binding

was established. Any INCH operation executed after such a successful send operation,

resulted in seemingly illogical program behaviour, pointing towards potential memory

corruption or stack over-flow. However, the source of this problem could not be traced,

leading to the presence of a bug in the send operation.

8.3 InceOS Bug in the delayed channel acknowledge operation

There was a problem with the channel acknowledge receive operation in the operating

system. The delayed channel acknowledge receive operation was not working properly due to

an incomplete implementation. The implementation was later completed and the bug thereby

removed.


50

8.4 Debugging with Cooja

The debugger in Cooja did not work properly and the only way to debug the

implementation was using printf statements in the code. When debugging stack overflow or

other memory issues, the addition of some variables for debugging and a print statement can

change the behaviour of the program to using different amounts of stack and heap memory.

This makes tracking down the bugs extremely difficult.


51

9 CONCLUSION

In this project, an Inter-node channel communication mechanism has been designed

and implemented for InceOS. The Insense programmer can write code that sends and receives

data on channels that abstract over any underlying radio communication taking place to

deliver the data. The design and implementation are discussed in detail in sections 5 and 6.

The implementation supports the following operations:

Publishing component channels to the network

Connecting and disconnecting published channels

Sending data over the connected channels and,

Handling exceptions caused by unreliable radio transmissions.

The design and implementation of the Inter-node Channel Handler and supporting

mechanisms for InceOS is shown to use roughly 3.5 kB less code memory (Flash memory)

on the motes than a Contiki implementation with a similar functionality. Flash memory was

the resource being utilised most by the Contiki implementation. A simple test program that

uses inter-node channel communication on InceOS is shown to use 16 kB less of flash

memory compared to the same program compiled for Contiki as discussed in section 7.1.

This means that the project has successfully managed to make more memory available for

Insense programs on InceOS while providing similar high-level inter-node communication

abstractions as provided on Contiki.

9.1 Future work

Although the INCH on InceOS performs all the above operations successfully, few

bugs exist in the code (as explained in 8.2). As part of future work, this implementation must

be debugged. Moreover, the INCH on InceOS lacks inter-node channel query operations and

multi-hop routing. These features can be implemented as part of future work. The AODV or

DYMO routing protocol can be implemented for supporting multi-hop routing as they are

suitable for resource constrained devices. This future work should be evaluated for memory

utilisation as, the current INCH on InceOS utilises less memory (in terms of code size and

heap) as compared to the INCH on Contiki (discussed in 7.1). With the successful

implementation for multi-hop routing, the INCH should be tested and evaluated for inter-

node channel operations between multiple nodes.


52

REFERENCES

[1] A. Dunkels, B. Gronvall, and T. Voigt, "Contiki - a lightweight and flexible operating

system for tiny networked sensors," presented at Proceedings of The First IEEE Workshop on

Embedded Networked Sensors, Tampa, Florida, 2004

[2] Download Contiki (2012, May 28). [Online]. Available: http://www.contiki-

os.org/download.html

[3] Dearle, A., Balasubramaniam, D., Lewis, J., and Morrison,R. (2008). A component-based

model and language for wireless sensor network applications. In COMPSAC ’08:

Proceedings of the 2008 32nd Annual IEEE International Computer Software and

Applications Conference, pages 1303–1308, Washington, DC, USA. IEEE Computer

Society. Paper that introduces Insense to the world.

[4] Dearle, A., Lewis, J., . (2011). High-level abstractions for programming self-managing

wireless sensor network applications. Techical Report.

[5] Harvey, P., Dearle, A., Lewis, J. and Sventek, J.. (2012). Channel and Active Component

Abstractions for WSN Programming: A Language Model with Operating System Support. 1st

International conference on Sensor Networks, Rome, Italy, 2012.

[6] Insense (2012, May 28). [Online]. Available: http://insense.cs.st-

andrews.ac.uk/downloads/

[7] Moteiv corporation, tmote Sky - Low Power Wireless Sensor Module, Edition of book,

San Francisco: Moteiv Corporation, 2006, p. 1-28.

[8] Qicksilver Mercurial Repository (2012, August 05). [Online]. Available:

http://quicksilver.hg.cs.st-andrews.ac.uk

[9] Raghuvanshi, A.S.; Tiwari, S.; , "DYMO as routing protocol for IEEE-802.15.4 enabled

Wireless Sensor Networks," Wireless Communication and Sensor Networks (WCSN), 2010

Sixth International Conference on , vol., no., pp.1-6, 15-19 Dec. 2010

[10] Sommerville, I. Software Engineering'. 2004: Addison Wesley.

http://www.contiki-os.org/download.html

http://www.contiki-os.org/download.html

http://insense.cs.st-andrews.ac.uk/downloads/

http://insense.cs.st-andrews.ac.uk/downloads/

http://quicksilver.hg.cs.st-andrews.ac.uk/


53

APPENDICES

Appendix A

This appendix has the log for inter-node channel publish, connect and send operations. The

simulation had 2 nodes executing connect, send and receive operations The first column is

the timestamp of the execution in milliseconds. The second column is the node ID (1 or 2).

The third column is the logged messaged from the mote device. Node 2 is the sender and

node 1 is the receiver.

422 ID:1 InceOS lives ...

449 ID:1 Malloc space is 9331

460 ID:1 sensor: now wait for incoming

471 ID:1 Listening to input

727 ID:2 InceOS lives ...

754 ID:2 Malloc space is 9331

765 ID:2 sensor: now wait for incoming

861 ID:1 InterNodeChannelHandler: Value received is 5

864 ID:1 Got value 5

866 ID:1 Listening to input

921 ID:1 InterNodeChannelHandler: Value received is 5

110015978_WirelessChannelsInInceOS

Documents

Transcript of 110015978_WirelessChannelsInInceOS