machine to machine communication for wireless sensor networks · machine to machine communication...

0

Faculty of Electrical Engineering and Computer Science

Master Thesis

MACHINE TO MACHINE COMMUNICATION FOR

WIRELESS SENSOR NETWORKS

By

BALA KRISHNA SANJEEVA

For the degree Master of Science (M.Sc.) in Electronics Engineering

Thesis work carried out at the IMSAS, Universität Bremen

Supervised by:

Prof. Dr. -Ing. Gerhard Wenke

Dr. -Ing. Reiner Jedermann

Fall 2011

i

Acknowledgements

I would like to express my gratitude to Prof. Gerhard Wenke, Course Director of my

Master’s study in Hochschule Bremen who is also my supervisor for his advice and support. I

am grateful to Dr. Reiner Jedermann who is my supervisor at the IMSAS for his support and

guidance throughout the thesis work and also for providing me an opportunity to study and

work on the Intelligent Container project.

Additionally, I would like to thank Prof. Walter Lang, Director of the IMSAS. I thank

Mrs. Birgit Zich who is my Course Coordinator for all the help in official work. Special thanks

to Javier Palafox and Alexander Dannies from the IMSAS for their valuable suggestions. I

also thank the staff at the IMSAS for their help.

I would also like to thank the open source communities whose software has been

used in this thesis. I appreciate the help of several open source contributors who have

replied to me in online forums and have guided me during various stages of this thesis work.

I thank my friends who have helped me during my stay at Bremen and for the

memorable experiences we had. I thank my parents, my brother and my sister for their

constant encouragement, affection and support.

This research was supported by the German Research Foundation (DFG) as part of

the Collaborative Research Centre 637 “Autonomous Cooperating Logistic Processes” and

by the Federal Ministry of Education and Research, Germany, under reference number

01IA10001 ('The Intelligent Container').

ii

Abstract

The recent trend of automating logistical systems demands improved and reliable

monitoring of supply chains. Tracing of goods and containers has to include information

about the current temperature and other environmental conditions. This information is used

for prediction of changes in the goods quality and warehouse keeping. The goal of the

Intelligent Container Project is to develop an autonomous transport monitoring system for

perishable and sensitive goods.

This thesis work focuses on enabling communication between the gateway device

inside the container and a remote machine. The remote user can know about the changes

inside the container by accessing the gateway device or getting information from the

gateway device. The gateway device collects the data from sensors placed inside the

container that form a wireless network within the container. Imote2 which is an embedded

wireless sensor hardware board is used to set up the wireless sensor network. The work

involves programming and configuring Imote2 to set up a wireless sensor network.

The work presents the different standard communication methods used to achieve

the goal. Also, techniques to enable communication between the sensors and the gateway,

the gateway and a remote device are presented.

iii

Contents

1. INTRODUCTION .................................................................................................................. - 1 -

1.1. Wireless Sensor Networks ........................................................................................... - 1 -

1.2. Machine to Machine Communication ......................................................................... - 2 -

1.3. The Intelligent Container Project ................................................................................ - 2 -

1.4. Research Task and Objective ....................................................................................... - 4 -

1.5. Thesis Organization ..................................................................................................... - 4 -

2. HARDWARE......................................................................................................................... - 6 -

2.1. VTC 6100 ...................................................................................................................... - 6 -

2.2. IMOTE2 ........................................................................................................................ - 7 -

2.2.1. Hardware features ................................................................................................ - 7 -

2.2.2. Linux for Imote2 .................................................................................................. - 10 -

3. MACHINE TO MACHINE COMMUNICATION .................................................................... - 13 -

3.1. UMTS ......................................................................................................................... - 13 -

3.2. Virtual Private Network ............................................................................................. - 15 -

3.3. Fixed IP ....................................................................................................................... - 16 -

4. MOTE TO MOTE COMMUNICATION ................................................................................ - 18 -

4.1. Introduction to the IEEE 802.15.4 framework ........................................................... - 18 -

4.1.1. LR-WPAN components ........................................................................................ - 19 -

4.1.2. Network topologies ............................................................................................. - 19 -

4.1.3. Architecture of the IEEE 802.15.4 standard ........................................................ - 20 -

4.1.4. Addressing ........................................................................................................... - 21 -

4.1.5. Data transfer in IEEE 802.15.4 WPAN ................................................................. - 21 -

4.2. Physical Layer ............................................................................................................. - 22 -

4.2.1. Operating frequency bands ................................................................................ - 23 -

4.3. MAC Layer .................................................................................................................. - 24 -

4.3.1. Frame format ...................................................................................................... - 24 -

4.4. Adaptation layer ........................................................................................................ - 26 -

4.4.1. Protocols for data transport ............................................................................... - 28 -

4.4.2. Linux software stack for IEEE 802.15.4 communication ..................................... - 31 -

5. IMPLEMENTATION ........................................................................................................... - 32 -

iv

5.1. Mote to mote communication .................................................................................. - 32 -

5.1.1. Socket structure .................................................................................................. - 33 -

5.1.2. Socket functions .................................................................................................. - 34 -

5.1.3. Steps in communication process ........................................................................ - 37 -

5.1.4. Java on IMote2 .................................................................................................... - 40 -

5.2. Mote to machine communication ............................................................................. - 42 -

5.2.1. Socket structure .................................................................................................. - 42 -

5.2.2. Socket functions .................................................................................................. - 43 -

5.3. Machine to machine communication ........................................................................ - 47 -

5.3.1. Communication between gateway and remote machine .................................. - 47 -

5.3.2. Remote access to the gateway device ................................................................ - 52 -

6. TESTS ................................................................................................................................ - 54 -

6.1. Tests on Imote2 ......................................................................................................... - 54 -

6.1.1. Transmission and Reception operation .............................................................. - 54 -

6.1.2. Disturbance from external wireless equipments ............................................... - 56 -

6.1.3. Transmission current and transmission duration ............................................... - 57 -

6.2. Tests on VTC6100 ...................................................................................................... - 59 -

6.2.1. Communication between gateway and remote machine .................................. - 59 -

6.2.2. Remote access to the gateway device ................................................................ - 62 -

6.2.3. Key findings ......................................................................................................... - 62 -

7. CONCLUSIONS .................................................................................................................. - 63 -

7.1. Observation ............................................................................................................... - 63 -

7.2. Future suggestions ..................................................................................................... - 63 -

LIST OF REFERENCES ............................................................................................................. - 64 -

APPENDIX A: Gateway configuration ................................................................................... - 66 -

APPENDIX B: Imote2 configuration ...................................................................................... - 78 -

APPENDIX C: Programming Imote2 ...................................................................................... - 91 -

APPENDIX D: File List ............................................................................................................ - 98 -

v

List of figures

Figure 1.1: Demo of the Intelligent Container project ........................................................... - 3 -

Figure 1.2: Organization of the thesis work ........................................................................... - 5 - Figure 2.1: Front view of the gateway device ........................................................................ - 6 -

Figure 2.2: Rear view of the gateway device ......................................................................... - 6 -

Figure 2.3: Imote2 block diagram .......................................................................................... - 8 -

Figure 2.4: Photos of Imote2 processor board ....................................................................... - 8 -

Figure 2.5: Photo of the debug board .................................................................................... - 9 -

Figure 2.6: Sensor board and processor board stacked above the battery board ............... - 10 -

Figure 2.7: Organization of the 32MB flash on imote2 [9] .................................................. - 11 -

Figure 2.8: JTAG board attached to debug board ................................................................ - 12 - Figure 3.1: UMTS architecture showing interfacing of mobile technology to the internet . - 14 -

Figure 3.2: Virtual Private Network ...................................................................................... - 15 -

Figure 3.3: Fixed IP service connecting the mobile network to the internet ........................ - 17 - Figure 4.1: Star topology ...................................................................................................... - 19 -

Figure 4.2: Peer to peer topology ......................................................................................... - 20 -

Figure 4.3: Layered model for communication in LR-WPAN devices ................................... - 21 -

Figure 4.4: Data transfer to coordinator [18] ...................................................................... - 22 -

Figure 4.5: Data transfer from coordinator [18] .................................................................. - 22 -

Figure 4.6: Operating frequency bands with channels ......................................................... - 23 -

Figure 4.7: Physical layer and MAC layer format ................................................................. - 25 -

Figure 4.8: Layered model showing Adaptation Layer ......................................................... - 26 -

Figure 4.9: IPv6 frame format along with MAC and PHY layer format ................................ - 27 -

Figure 4.10: UDP frame format for IP network .................................................................... - 28 -

Figure 4.11: Mapping of UDP to IP layer .............................................................................. - 29 -

Figure 4.12: Client server connection using sockets ............................................................. - 30 - Figure 5.1: Cross compilation ............................................................................................... - 33 -

Figure 5.2: Flow diagram showing transmission of data on the transmitter mote and

reception of data on the receiver mote (using sockets) ....................................................... - 36 -

Figure 5.3: Implementation of the transmission process ..................................................... - 39 -

Figure 5.4: Steps in accessing C code from a java application ............................................. - 41 -

Figure 5.5: Flow diagram showing transmission of data from the imote and reception of

data on the gateway (using sockets) ................................................................................... - 44 -

Figure 5.6: Block of code which is part of gateway.c ........................................................... - 45 -

Figure 5.7: Implementation of the reception process and the subsequent transmission of

the data to the gateway device ............................................................................................ - 46 -

Figure 5.8: Gateway device sending email over the mobile network .................................. - 49 -

Figure 5.9: Gateway device sending SMS over the mobile network .................................... - 50 -

Figure 5.10: Relation between the programs ....................................................................... - 51 -

vi

Figure 5.11: End to end communication with devices and communication technologies ... - 53 - Figure 6.1: Wireless interface being listed ........................................................................... - 54 -

Figure 6.2: Data packets sent out from transmitter mote ................................................... - 55 -

Figure 6.3: Data packets coming in to the receiver mote .................................................... - 55 -

Figure 6.4: Debug message for normal reception of data ................................................... - 56 -

Figure 6.5: Debug message in case of interruption .............................................................. - 56 -

Figure 6.6: Determining transmission current and transmission duration .......................... - 57 -

Figure 6.7: Change in voltage level ...................................................................................... - 58 -

Figure 6.8: Measurement of transmission voltage .............................................................. - 58 -

Figure 6.9: Measurement of transmission duration ............................................................. - 59 -

Figure 6.10: Snapshot of the SMS delivered ......................................................................... - 60 -

Figure 6.11: Snapshot of the mail delivered ......................................................................... - 61 -

vii

List of tables

Table 5.1: Programs and their functionality …………………………………………………………………... -51-

Table 6.1: Test for communication between gateway and remote machine ...................... - 61 -

viii

Abbreviations and Acronyms

MEMS Micro Electro Mechanical Systems

WSN Wireless Sensor Network

M2M Machine to Machine

IMSAS Institute for Microsensors, Actuators and Systems

IEEE Institute of Electrical and Electronics Engineers

LAN Local Area Network

GPS Global Positioning System

SIM Subscriber Identity Module

UMTS Universal Mobile Telecommunication System

CPU Central Processing Unit

SRAM Static Random Access Memory

SDRAM Synchronous Dynamic Random Access Memory

USB Universal Serial Bus

JTAG Joint Test Action Group

JFFS2 Journalling Flash File System 2

GSM Global System for Mobile communications

3G Third Generation

RNC Radio Network Controller

GPRS General Packet Radio Service

SGSN Serving GPRS Support Node

GGSN Gateway GPRS Support Node

VPN Virtual Private Network

SSL Secure Sockets Layer

TCP Transmission Control Protocol

UDP User Datagram Protocol

IP Internet Protocol

ix

ISP Internet Service Provider

DHCP Dynamic Host Configuration Protocol

IETF Internet Engineering Task Force

PAN Personal Area Network

LR-WPAN Low Rate Wireless Personal Area Network

WLAN Wireless Local Area Network

WPAN Wireless Personal Area Network

FFD Full Function Device

RFD Reduced Function Device

ISM Industrial, Scientific and Medical

MAC Medium Access Control

CRC Cyclic Redundancy Check

SFD Start of Frame Delimiter

FCS Frame Check Sequence

6LOWPAN IPv6 over Low power Wireless Personal Area Network

IPv6 Internet Protocol version 6

ARM Advanced RISC Machine

PC Personal Computer

GNU GNU’s Not UNIX

VM Virtual Machine

IDE Integrated Development Environment

APN Access Point Name

SMTP Simple Mail Transfer Protocol

SMS Short Message Service

SSH Secure Shell

Machine to machine communication for wireless sensor networks ___________________________________________________________________________________________

- 1 -

1. INTRODUCTION

1.1. Wireless Sensor Networks

Sensing process is keeping track of the change in a physical quantity and a sensor is a

device that converts the physical quantity into a signal which is then read. The advancement

in the field of MEMS (Micro Electro Mechanical Systems) and miniaturization of devices has

led to development of micro sensors that can be used to detect and measure any physical

quantities.

Advancements in semiconductor technology has made computers faster, cheaper

and better aided with more memory and space. Chips that are released nowadays have

more computation capability when compared to their predecessors. Processor chips are

used in almost every application ranging from a simple mobile phone to an industrial robot.

Recent trends in wireless communication have made a great impact on the way we

communicate. Wireless technology is used for many applications and the extent to which

this technology can be exploited is limited only by human’s imagination.

The coming together of sensing, computation and wireless technology along with

miniaturization has helped to realize wireless sensor networks. Wireless sensor networks

are a growing research field with numerous practical applications being realized in wide

range of fields. The components in a WSN (wireless sensor network) include two or more

embedded device with sensors and a wireless mechanism between these devices.

Examples of the applications of wireless sensor networks include but not limited to [1],

Environmental monitoring: detecting pollution, hazardous gas levels or forest fires.

Industrial applications: machine control, tracking, waste water treatment etc.

Military applications: battle field surveillance.

Machine to machine communication for wireless sensor networks

__________________________________________________________________________________

- 2 -

Structural monitoring: identifying defects in structures like bridges, roads, buildings

etc.

1.2. Machine to Machine Communication

The concept of automatic communication between machines which are autonomous

(machines that can operate without human intervention) is referred to as machine to

machine communication [20] or M2M communication. The generalization of telemetry is

commonly termed as machine to machine communication.

The concept of telemetry or remote measurements has existed for a long time.

Advancements in technology have led to usage of machines that can communicate with

other machines and get the necessary information with minimal or no human interference.

Machine to machine communication can happen between machines that are very near or

the distance between them is very short. An example of this type would be sensors in a

wireless sensor network that transmit or receive data between them.

Communication between machines where the distance between them is very long is

common nowadays. Weather monitoring is an example where temperature and wind speed

is recorded at a distant weather station and the information is then transmitted using

satellite or mobile communication.

Remote access or direct access to real time data is the main goal behind machine to

machine communication when the machines are separated by a very large distance. The

need for remote access is to know the distant events or happenings. This is achieved by

wired or wireless networks connecting the machines.

In this thesis work, machine to machine communication refers to the communication

between the gateway device and the user who wants access to the gateway without direct

physical access. This is achieved by using mobile telephone network.

1.3. The Intelligent Container Project

Recent developments in embedded systems and wireless sensor networks have

offered many benefits which can be exploited to use them in many different areas. Use of


__________________________________________________________________________________

- 3 -

sensors for tracking and sensing applications is quite common nowadays. Wireless sensor

networks for logistics tracking are an area of study in itself. The work in progress in IMSAS is

the development of an Intelligent Container system.

The following paragraph is taken from the Intelligent Container website [2].

“The Microsystems Center Bremen developed in cooperation with ComNets and the

LogDynamicsLab the 'intelligent Container' as an autonomous transport monitoring system

for perishable and sensitive goods. The systems links technologies from the fields of RFID,

sensor networks and software agents to provide a permanent and freight-specific

supervision of each transport package along the supply chain. Local pre-processing of

sensor information reduces costs for external mobile communication. A quality prediction

model runs on an embedded processor platform that is integrated into the container, truck

or semi-trailer. If a risk for the quality of loaded freight items is detected, the autonomous

supervision system sends a warning message to the transport operator. “

Figure 1.1: Demo of the Intelligent Container project

The idea here is to establish a sensor network within the container where physical

measurable quantities like temperature and heat are measured by the sensors. The sensors

send this data to a gateway device. The gateway in turn has to be remotely accessed and the

readings are to be analyzed for prediction of the quality of goods transported in the

container.


__________________________________________________________________________________

- 4 -

1.4. Research Task and Objective

The objective of the thesis is to implement an end to end communication for the

project. This involves implementing embedded solutions for establishing a wireless sensor

network where the sensors can talk to each other. The sensor used is Imote2. The work is to

test the possibility of using Imote2 to set up a wireless sensor network. The sensed data in

turn has to be transmitted to a remote user where the scenario involves communication

between the gateway device and a remote terminal. VTC6100 is used as a gateway device.

Apart from implementation, tests have to be carried out to check for interruptions in the

communication process.

This is achieved by understanding the communication methodologies used at

different stages. The communication mechanism is realized by using open source software

from various sources. The operating system used in the embedded devices is LINUX which is

an open source operating system. Major part of the work involved testing out open source

software for a specific task and writing code on top of this software to achieve automation

and desired functionality.

1.5. Thesis Organization

Chapter 1 is the Introduction that gave the reader an idea about the thesis work.

Chapter 2 is an overview of the hardware used that is the gateway device and the Imote2

sensor. Chapter 3 presents the communication technologies and mechanisms to realize

machine to machine communication. Chapter 4 is a description about the IEEE 802.15.4

framework which is the radio stack that is used to achieve communication between the

sensors. It also gives an idea about the upper communication layers. Chapter 5 is about the

Implementation and Chapter 6 deals with the tests performed. Chapter 7 is the conclusion

part that marks an end to the thesis work with observations and recommendations for

future work.


__________________________________________________________________________________

- 5 -

Figure 1.2: Organization of the thesis work

Introduction

• Introduction to the thesis work

Hardware

• Gateway device and sensor node

Machine to Machine communication

• UMTS, VPN and Fixed IP

Mote to mote communication

• IEEE 802.15.4 framework and upper layers

Implementation

• Details about the implementation

Tests

• Test Results and evaluation

Conclusion

• Observation and future suggestions


__________________________________________________________________________________

- 6 -

2. HARDWARE

This chapter discusses about the hardware used to achieve the communication

process. VTC 6100 is used as the gateway device and Imote2 is used as the sensor board.

2.1. VTC 6100

The VTC6100 manufactured by NEXCOM is used as the gateway device inside the

container. The device is designed for use in vehicles. It has a powerful processor and an

inbuilt RAM and hard disk. USB slots and serial ports are provided for interfacing sensors and

other devices. It comes with antenna holes for wireless LAN and GPS. A SIM socket is

provided for using UMTS modules [3]. The operating system used on VTC6100 is Debian

Linux.

Figure 2.1: Front view of the gateway device

Figure 2.2: Rear view of the gateway device


__________________________________________________________________________________

- 7 -

The VTC 6100 can operate in temperatures between -30 °C to 60 °C and is suitable for

the container environment. The configuration of the VTC 6100 for UMTS/mobile

communication is described in Appendix A.

The need for VTC6100 as a gateway device inside the container arises because there

has to be a local pre processing of data before the information or the readings can be

accessed in an understandable form by a lay man. Moreover the provision for web interface

and running programs in higher level languages exists in such a device.

2.2. IMOTE2

Imote2 is used as the wireless sensor node platform in this thesis work. In this

section, the hardware features of the Imote2 are described. The Imote2 platform consists of

the radio processor board, the sensor board, the battery board and the debug board [4].

2.2.1. Hardware features

2.2.1.1. Imote2 radio processor board

The Imote2 processor board is the main component which has the CPU and an inbuilt

radio. The processor used is PXA271 based on XScale which is manufactured by Intel and is

an implementation of the ARM architecture. The processor can be used for low power

operation operating at a low voltage of 0.85 volt and a low frequency of 13 MHz (can be

scaled up to 416 MHz). The CPU with 256kB SRAM, 32MB SDRAM and 32MB FLASH memory

chips are included in a single package on the board. Many I/O options are integrated in the

processor which enables to interface external devices. Below is the block diagram of the

Imote2 processor board.


__________________________________________________________________________________

- 8 -

Figure 2.3: Imote2 block diagram

The Imote2 processor board comes integrated with a radio transceiver CC2420 from

Chipcon and an antenna. The radio is IEEE 802.15.4 standard compliant [5]. Details about the

radio standard used will be discussed in chapter 4.

The photos of the Imote2 board are shown below. The top view shows connectors for

attaching sensor board and the bottom view shows connectors for attaching the debug or

the battery board.

Figure 2.4: Photos of Imote2 processor board


__________________________________________________________________________________

- 9 -

Also, a reset button can be seen on the top view, and a USB connector on the bottom

view for connecting the board to the PC by means of a USB cable.

2.2.1.2. Imote2 sensor board

The sensor board is designed to connect to the Imote2 processor board through the

connectors provided on both the boards. The ITS400 sensor board is a multi-sensor board

designed for applications in wireless sensor networks.

The sensor suite comprises of,

LIS3L02DQ 3d 12 bit ±2g accelerometer from ST

High Accuracy, ±0.3°C SHT15 temperature/humidity sensor from Sensiron

TAOS TSL2651Light Sensor

Maxim MAX1363 4 Channel General Purpose A/D for quick prototyping

Tmp175 Digital Temperature Sensor with two-wire interface from TI

2.2.1.3. Imote2 interface board

The IIB2400 interface board is used for debugging through JTAG and also for code

loading. It is connected to the Imote2 processor board through the advanced connectors.

The use of this board for loading code is described in Appendix B.2.

Figure 2.5: Photo of the debug board


__________________________________________________________________________________

- 10 -

2.2.1.4. Imote2 battery board

Three primary AAA cells can be used with the battery board for powering the Imote2.

It comes with a mechanical switch for manual power off.

Figure 2.6: Sensor board and processor board stacked above the battery board

2.2.2. Linux for Imote2

When Imote2 is shipped from Crossbow, it comes with a .NET framework which is

proprietary. Since the processor is powerful and a whole lot of applications can be

performed on Imote2 by exploiting all its features, an operating system can be used. The

choice of operating system is Linux since it is open source, driven by open source

communities and is suitable for embedded applications. Previously, images for imote2 were

available on sourceforge [6] which used the original Intel filesystem, an older kernel and a

bootloader [7]. Now the images for imote2 are available through openembedded [8].

Openemebedded is one of the build frameworks for embedded linux. Openembedded uses

bitbake as the tool for building linux kernel and file system. Using openembedded for

building the kernel and the filesystem is described in Appendix B.1.


__________________________________________________________________________________

- 11 -

2.2.2.1. Organization of the 32MB Flash

Division of the 32MB flash on the Imote2 is as shown below. It consists of three components.

Figure 2.7: Organization of the 32MB flash on imote2 [9]

Boot loader

Boot loader is a program that loads the main operating system of a computer or an

embedded device. The process of starting an operating system is known as booting. Here

BLOB is used as the boot loader for imote2 [10]. BLOB is the boot loader for arm platforms. It

is able to load the kernel from the flash. It initializes the hardware, memory and CPU. It

provides command line for the kernel and also aids in flashing a fresh kernel or filesystem.

Using JTAG programming, BLOB is flashed onto the imote2 which will be described in the

Appendix.

Kernel

The Linux kernel which is configured for imote2 is flashed. The linux kernel can be

obtained from the official kernel website [11] where mainline kernels are hosted. At the


__________________________________________________________________________________

- 12 -

time of carrying out this thesis work, the IEEE 802.15.4 framework standard (which will be

discussed in chapter 3) was not available with mainline kernel versions. The implementation

of IEEE 802.15.4 framework on Linux kernel was carried out separately by the linux -zigbee

project [12]. Since the kernel image obtained through openemebedded uses the kernel

source tree from linux-zigbee project, openemebedded is used to build the kernel image.

The kernel size is less than 2MB. If it is more than the allocated size on the flash, it may lead

to filesystem corruption.

Filesystem

JFFS2 or Journalling Flash File System version 2 is used with flash memory devices.

JFFS2 incorporates compression and wear leveling. The filesystem image is obtained using

the openembedded build.

2.2.2.2. Flashing images using JTAG

The process of transferring images like bootloader on to an embedded device is

known as flashing. The communication interface used for flashing is JTAG. The flashing

process was done on a PC running Windows XP. For other operating systems, the steps may

vary. For this, the Jflashmm utility, FTDI USB drivers and giveio.sys device driver is used along

with the Imote2 main board, the debug board, Wiggler compatible JTAG programmer board

with the JTAG cable and two USB mini cables. Detailed steps for flashing images are

described in Appendix B.2.

Figure 2.8: JTAG board attached to debug board


__________________________________________________________________________________

- 13 -

3. MACHINE TO MACHINE COMMUNICATION

Three things have to be taken care of when connecting to a ‘mobile device’ or a

‘machine on the move’. First one is the means of communication. Next is the issue of

security. Lastly there is a need of a mechanism to remotely connect to it from anywhere.

In the context of the Intelligent Container Project, using Ethernet connection or

WLAN to communicate to the outside world is ruled out inside the container. The possible

solution is to use a mobile network by using the services of a mobile service company. This

chapter gives an overview of the mobile service used and the means to connect to the

gateway device remotely in a secure way.

3.1. UMTS

Mobile phone communication and associated technologies has grown tremendously

with more and more people opting for mobile phones to talk and for other uses. Voice

signals were transferred over the air in the first generation mobile phone systems.

Improvements in digital technology led the analog signal to be converted in to digital

streams of data in the second generation mobile phone systems. Text messaging was offered

during this time.

Deployment of third generation systems started from 2002 and is still continuing

[13]. Connecting to the internet was made possible during this period. Broadband services

led to increased usage of the allocated spectrum and a lot of developments are being made

even today to reuse the spectrum and improve the services. UMTS (Universal Mobile

Telecommunication System) is based on GSM (Global System for Mobile communications)

and is a 3G (Third Generation) technology which is popular and is deployed rapidly

throughout the world. Third generation mobile technology or UMTS offers services that are

fast, ranging between 6 Mbps uplink speed to 14 Mbps downlink speed.

Figure 3.1 shows the underlying architecture of the UMTS phone network when

mobile technology is interfaced to the internet. The base station and the RNC (Radio

Network Controller) form the radio access network. The data or traffic from the mobile

phone is picked up by the base station. Then the RNC passes the data packets to the UMTS


__________________________________________________________________________________

- 14 -

core network. The packet switched network came into picture during the implementation of

GPRS (General Packet Radio Service) in the GSM system.

Figure 3.1: UMTS architecture showing interfacing of mobile technology to the internet

The SGSN (Serving GPRS Support Node) and the GGSN (Gateway GPRS Support Node)

act as interface connecting and delivering data packets to and from the mobile network and

internet.

When the mobile device is on the move, the connection to the internet is maintained

without any loss of service by the mobile network. This is achieved by the technique of

handover where the flow of traffic is routed to a new base station. The base stations cover a

certain range and once a base station finds out that the mobile device is approaching a

distance where it cannot continue its service, it signals the adjacent or the next base station

to handle the communication. The device is now covered by the next base station and the

services are maintained.

Security is taken care off in the UMTS by means of a removable chip called the SIM

(Subscriber Identity Module) card. This chip contains information about the account

information and the subscriber’s identity. Also the information on the SIM card enables a

mobile phone to talk to a proper and legitimate network.


__________________________________________________________________________________

- 15 -

Privacy is offered by means of the cryptographic schemes implemented in the SIM

where the transmissions are encrypted. It is difficult to eavesdrop and thus privacy is

maintained.

3.2. Virtual Private Network

The advantage of using VPN (virtual private network) is that data packets cannot be

accessed by users who are unauthorized. Virtual Private Networks are used by many users

and companies to remotely connect to machines or PC’s. Before the advent of VPN, users or

companies used to lease a private telephone line for connecting different machines in order

to have a secure communication path.

In this thesis work, OpenVPN [14] is used to connect to the gateway device in a

secure way. OpenVPN is open source software that offers security services over the internet.

SSL (Secure Sockets Layer) which is a cryptographic protocol is used as the basis for

OpenVPN. SSL is positioned between the application layer and the transport layer where it

performs data compression and data encryption. Encrypted data packets are then

encapsulated in to the transport layer protocols like TCP (Transmission Control Protocol) or

UDP (User Datagram Protocol). This packet is then sent over the internet. At the receiver

end, the same cryptographic standard is used to decrypt and release the data.

Figure 3.2: Virtual Private Network

Figure 3.2 is a representation of the working of a virtual private network. A VPN

tunnel is created on the internet which connects a user and a remote server which the user


__________________________________________________________________________________

- 16 -

wants to access. The data packets moving in the VPN tunnel are normal data packets which

includes encrypted header. The router or firewall does not block these data packets.

Encrypted algorithms run at both the ends. When using VPN for remote access,

authentication is provided in the form of user name and passwords.

3.3. Fixed IP

The gateway device inside the container is on the move and it has to be remotely

accessed. But remotely connecting to the device is not possible since mobile network

operators assign a variable, changing IP address. Also, network operators restrict or block

from accessing mobile devices by running a firewall or similar application.

IP addresses are a means of identifying a computer or a machine that runs IP. IP

address for a computer is analogous to a residential address of a person. Since the advent of

internet, many devices have been and are being connected to the internet and this has led

to shortage of IP addresses. IP addresses are allocated by the ISP’s (Internet Service

Provider). The ISP’s register for a certain number of IP addresses.

Dynamic IP address is assigned by means of the DHCP (Dynamic Host Configuration

Protocol) [15]. DHCP was created by the IETF for allocating dynamic IP address. As the

machine or a computing device which has IP enabled on it moves from one place to the

other, the ISP’s allocate a new IP address based on the current location of the device or a

machine. This is necessary because the machine or the device has to be connected to the

network without loss of a service. Mobile devices or ‘machines on the move’ need not have

access to the internet always. Since mobile networks offer dial up service, it enables them to

reuse the IP address and offer the IP address for a specific duration.

In order to achieve bidirectional communication, there is a need for a fixed IP address

or a static IP on the device. This is achieved by means of using services from a fixed IP

provider. There are many fixed IP services providers and the need for a fixed IP is growing as

controlling machines remotely has grown. The fixed IP providers register certain IP addresses

for their private use. On a subscription fee or a contract, these fixed IP providers allocate a

static IP for a user who wants his machine or computer to have a static IP.


__________________________________________________________________________________

- 17 -

The fixed IP service provider chosen for this study work is mdex [16]. mdex is a

company from Germany that provides fixed IP and other related services. Using the services

of mdex, it is possible to connect to the remote device.

Figure 3.3: Fixed IP service connecting the mobile network to the internet

Also the pricing of the services offered by mdex is relatively cheap with a 12 month

contract costing around 48 Euros (which equals 4 Euros per month) [17]. The pricing is for

mdex services and not for the mobile services. The mobile usage price will depend on the

amount of data transferred.

As seen from the Figure 3.3, the fixed IP service connects two private networks, the

internet and the mobile network by allocating fixed IP addresses at each ends. The remote

user uses OpenVPN and connects to one of the servers of mdex over the internet. A static IP

is allocated at the user’s end. A VPN tunnel is created between the user’s terminal and the

mdex server. At the gateway side, the mobile network is configured to access mdex server

and a static IP is assigned to the gateway. The mdex services link the user with the gateway

device.

Another alternative to fixed IP services is to register for a public IP for the gateway

device from a service provider. In this case, the IP address is permanently allocated to the

registered device and the gateway device can be identified by its IP address. But this service

costs much more and is very expensive.


__________________________________________________________________________________

- 18 -

4. MOTE TO MOTE COMMUNICATION

This chapter presents to the reader the communication standard used to achieve

communication between Imote2 sensor nodes. IEEE 802.15.4 standard is described followed

by the lower layers. Then upper layers are discussed.

4.1. Introduction to the IEEE 802.15.4 framework

Wireless communication between devices like laptops and PDA’s is something of

which we are aware of. A PAN (Personal Area Network) can be formed between these

devices where one may act as the router and the other devices act as the end devices. This

concept of networking has been extended to very low power consuming embedded devices.

The network formed by such devices is termed as the Low Rate Wireless Personal Area

Network (LR -WPAN). A standard has been specified by IEEE for networking such devices and

is known as the IEEE 802.15.4 standard. This standard was first released in 2003 and a

modified standard was released in 2006 with amendments [18].

A question may arise as to why need another standard when there is Bluetooth,

WLAN (IEEE 802.11) or related communication technologies that does the same task. The

reason is that WLAN has a longer physical range ranging up several hundred meters.

Bluetooth has very high data transfer capability and very high power consumption. Wiring

and usage of cables comes into picture when we want the sensors to be wired. The need for

IEEE 802.15.4 standard implementation comes in when we don’t need to transfer data of

high bandwidth and the power consumption is very low.

The general characteristics of IEEE 802.15.4 standard are:

Data transfer rates ranging from 20 kbps to 250 kbps.

Communication range up to 10 meters.

Suited for embedded devices with low power requirements.

Network topology of peer to peer or star operation.


__________________________________________________________________________________

- 19 -

4.1.1. LR-WPAN components

Devices that form a network in a LR-WPAN may be of the following types:

4.1.1.1. Full function device (FFD)

This device acts as the coordinator. This device can talk to other devices within the

PAN and also can communicate with another FFD which is part of another PAN.

4.1.1.2. Reduced function device (RFD)

This device can be termed as the end device that can only talk to a FFD.

4.1.2. Network topologies

The IEEE 802.15.4 LR-WPAN can be set up either as a star network or a peer to peer

network depending on the applications intended for.

4.1.2.1. Star topology

The figure below shows the star topology formation. A FFD acts a PAN coordinator

and starts the WPAN. Other RFD’s add to the network. A FFD from another WPAN can also

join this network.

Figure 4.1: Star topology


__________________________________________________________________________________

- 20 -

4.1.2.2. Peer to peer topology

Here each device can communicate with another device within its range. Usually such

a formation demands that most of the devices are of FFD type. The figure below shows a

peer to peer network formation with multiple nodes where each node represents a device.

Figure 4.2: Peer to peer topology

4.1.3. Architecture of the IEEE 802.15.4 standard

The architecture of the IEEE 802.15.4 standard is defined in terms of layers similar to

the OSI model. The standard defines the lower two layers, the Physical layer and the MAC

layer. Upper layers are not defined in this standard. Several proprietary standards like

Zigbee, Wireless HART and MiWi define the upper layers that make use of the 802.15.4

standard for their lower layers. The application layer provides the intended functionality.


__________________________________________________________________________________

- 21 -

Figure 4.3: Layered model for communication in LR-WPAN devices

4.1.4. Addressing

The nodes that are part of the IEEE 802.15.4 networks can be identified by a 64 bit

address or a short address that is 16 bits long. The short address is assigned by the

coordinator that starts the PAN network. The short address is valid only for the time period

when the network is active.

4.1.5. Data transfer in IEEE 802.15.4 WPAN

4.1.5.1. Data transfer to a coordinator

The figure below summarizes the data transfer activity from a end device to a

coordinator. The device simply sends the data and the coordinator sends an

acknowlegement.


__________________________________________________________________________________

- 22 -

Figure 4.4: Data transfer to coordinator [18]

4.1.5.2. Data transfer from a coordinator

When the coordinator wants to send data to a device, the coordinator waits for the

device for data request. It sends an acknowledgement and then transfers the data it has

stored intended for the appropriate device. The device then sends an acknowledgement for

the data received.

Figure 4.5: Data transfer from coordinator [18]

4.2. Physical Layer

The physical layer is the bottom most layer in the standard. The functions of the

physical layer are,

Bringing the radio transceiver up and down

Assessing the channels

Data transmission

Data reception


__________________________________________________________________________________

- 23 -

4.2.1. Operating frequency bands

The operating frequency bands and the number of channels assigned for each band is

shown below. The physical layer operates in the ISM band (industrial, scientific and Medical

band) which is a license free band. The frequency band is defined for

868 to 868.8 MHz in Europe.

902 to 928 MHz in the United States.

2400 to 2483.5 MHz for the whole world.

Several channels are defined for each frequency band. Channel 0 for Europe, Channels 1

to 10 for the United States with a spacing of 2 MHz and Channels 11 to 26 for the rest of the

world with a spacing of 5 MHz.

Figure 4.6: Operating frequency bands with channels


__________________________________________________________________________________

- 24 -

The radio channels defined for IEEE 802.15.4 standard share the radio frequency with

802.11 (WiFi). This leads to overlap with the 802.11 channels leading to disturbance of

802.15.4 traffic as 802.11 has a significantly high output power when compared to 802.15.4.

4.3. MAC Layer

The Medium Access Control Layer handles access to the physical radio medium. The

MAC layer computes the cyclic redundancy check (CRC) for incoming frames. It checks for

transmission errors and discards the frame if the CRC in the transmitted packet does not

match the CRC computed by the receiver. Also the MAC layer sends acknowledgements for

each of the received frames.

The functions of the MAC layer are,

Associating to a PAN

Disassociating from a PAN

Providing reliable link between two MAC entities

Managing the physical layer

Providing services to higher layers

4.3.1. Frame format

IEEE 802.15.4 standard specifies a format or protocol for the packet transmissions.

This format contains both the physical layer and the MAC layer part.

4.3.1.1. Physical layer format

The physical layer format contains,

Preamble – used to synchronize the sender and receiver

SFD (start of frame delimiter) – denotes the start of frame

Length – length denotes the number of bytes that will follow. The maximum length is 127

bytes.


__________________________________________________________________________________

- 25 -

4.3.1.2. MAC layer format

The MAC layer format contains,

Frame control – tells receiver how to interpret the rest of the header, whether it needs to be

acknowledged or not.

Sequence number - used to associate acknowledgement with the data packet.

Addressing fields – address details of the sender and the receiver as well as PAN details of

sender and receiver.

Security header – optional field which contains data for security related processing.

Data – actual data to be delivered and can be between 86 and 116 bytes long. Depending on

the optional MAC layer fields used, the maximum size of the data is determined. The

structure of data field is not specified by 802.15.4 standard and is left for higher layers to

define it.

FCS (frame check sequence) – contains CRC which the MAC layer uses for checking incoming

data packets.

Figure 4.7: Physical layer and MAC layer format


__________________________________________________________________________________

- 26 -

4.4. Adaptation layer

Upper layers are not defined in the IEEE 802.15.4 standard. Several proprietary

standards define the upper layers that make use of the 802.15.4 standard for their lower

layers. In this thesis work, 6lowpan (IPv6 over low power wireless personal area networks)

standard defined for embedded low power devices is made use of.

A need for an open standard for embedded low power devices led the Internet

Engineering Task force (IETF) to develop a specification called 6lowpan with the aim being

connecting embedded devices to the internet [19]. In this thesis, the standard is used to

enable communication between the motes and not to connect to the internet.

Figure 4.8: Layered model showing Adaptation Layer


__________________________________________________________________________________

- 27 -

The main functions of the adaptation layer is,

Managing the MAC layer

Header compression

Routing data from source to destination

The maximum transmission capacity for IPv6 is 1280 bytes. As the transmission capacity

for IEEE 802.15.4 standard is 127 bytes, header compression is necessary to confirm to the

802.15.4 standard [20].

Figure 4.9: IPv6 frame format along with MAC and PHY layer format


__________________________________________________________________________________

- 28 -

4.4.1. Protocols for data transport

On top of the IP layer, transport protocols reside. Applications make use of these

transport protocols to communicate or perform tasks. There are two transport protocols

that are very widely used.

Transport Control Protocol (TCP)

User Datagram Protocol (UDP)

Reliable transport service is provided by the TCP as this includes acknowledgement

mechanisms and other functionalities. TCP is pretty complex to implement as it includes

several fields.

UDP is simple to implement and it does not guarantee the delivery of data and the

data may arrive out of order at the destination. The figure below shows the UDP header

along with the data for IP networking. It contains information about the source and

destination, fields for length and checksum. In context of LR-WPAN’s, UDP is taken in to

consideration as it is easy to implement. The source port and destination port will be

replaced by source and destination address along with the PAN address for LR-WPAN’s. UDP

is preferred because dropping of packets is not an issue in LR-WPAN’s as the data is

transferred continuously sometimes with a delay of less than a second.

Figure 4.11 shows how application programs rely on UDP for communication and the

mapping of UDP to the IP layer.

Figure 4.10: UDP frame format for IP network


__________________________________________________________________________________

- 29 -

Figure 4.11: Mapping of UDP to IP layer

4.4.1.1. Sockets

Sockets use the standard UNIX file descriptors to communicate between different

devices in a network. Sockets can be said to be a connection that exists between two pieces

of software. Today, much of the application software and web based applications rely on

sockets for networking. The Berkeley socket library which originated with UNIX operating

system almost two decades ago is the standard that is being used for most of the network

programming these days[21] .Sockets in a way provide abstraction and give users the means

to access underlying communication protocols. A socket is analogous to a mailbox.


__________________________________________________________________________________

- 30 -

Figure 4.12: Client server connection using sockets

The above figure shows a client server model where connection is established using

sockets.

There are two types of sockets, stream sockets and datagram sockets. Stream sockets

use the TCP and datagram sockets use the UDP. Stream sockets achieve a high level of data

transmission quality and the data is transmitted in an order. Datagram sockets are termed

connectionless and the data may arrive out of order. Speed is the reason for using datagram

sockets as there is no need to keep track of the sent data.

This concept of networking two different applications or programs in the internet

domain has been extended to LR-WPAN’s. Open source developers have developed libraries

that use the concept of sockets for networking sensors. The related code is hosted in the

linux-zigbee project [12] as part of user space applications. As part of this thesis, programs

are developed for sending data and for receiving data. These programs make use of the

standard sockets library and header files that are hosted in the linux-zigbee project. The

sockets created are of type datagram.


__________________________________________________________________________________

- 31 -

4.4.2. Linux software stack for IEEE 802.15.4 communication

The code for IEEE 802.15.4 standard is hosted in the linux zigbee project. At the time

of writing this thesis work the code related to Physical layer was available in the mainline

kernel [11]. The MAC layer and the user space application related to adaptation layer are

available from the git repository hosted on the linux zigbee project website. The aim of the

project is to run upper layer protocols over IEEE 802.15.4 standard.


__________________________________________________________________________________

- 32 -

5. IMPLEMENTATION

This chapter deals with the implementation of the communication process. The

implementation is carried out in three steps. Communication between the imote nodes is

achieved first. Secondly, the communication between the receiver imote and the gateway

device is realized. Finally, the communication between the gateway device and the remote

terminal is carried out. For the purpose of explanation and ease of understanding the term

‘machine’ is used for devices other than the imote. ‘Machine’ here may refer to the gateway

device and remote terminals. Imote is also a machine and will be referred to as ‘mote’

henceforth.

5.1. Mote to mote communication

The IEEE 802.15.4 framework and the higher layer specification were described in the

previous chapter. This topic describes the way how data is transmitted and received through

the motes by adapting the IEEE 802.15.4 standard.

Two programs, one for sending and the other for receiving data are developed. These

programs make use of the standard libraries that are provided in the C programming

language. The header files used are provided as part of the user space applications

developed as part of the linux zigbee project. Sockets are used as an interface for

communicating.

Since Imote2 is based on the ARM architecture, cross compilation is necessary.

Embedded devices like Imote2 are resource constrained and the architecture does not

support hosting development environments. A host machine like a PC is used for generating

code for IMote2. Since the architecture of the host machine and Imote2 are different, a

cross compiler is used on the host machine that compiles the code and generates an

executable file for the target machine. This executable file can be run on the Imote2. For this

purpose an ARM GNU/Linux toolchain from Codesourcery [22] is used as the cross compiler

toolchain. Figure 5.1 is a representation of the cross compilation process. A program written

in C is compiled against a cross compiler and the executable file is generated. This file cannot


__________________________________________________________________________________

- 33 -

be run on the host machine. It is transferred to the embedded device, in this case Imote2

and the file is executed.

Figure 5.1: Cross compilation

The protocol used for data transport to enable communication between motes is

UDP (User Datagram Protocol) and datagram sockets are used to achieve this. The previous

chapter gave an introduction to UDP and sockets. The following sections describe the socket

structure which is a data structure that defines the property of socket used, and also the

various socket functions that are used in the code is explained. The structures and functions

are part of the header files defined in the C programming language.

5.1.1. Socket structure

sockaddr_ieee802154

sockaddr_ieee802154 is a structure that holds the address family, addressing type, pan id

and the short address.


__________________________________________________________________________________

- 34 -

Declaration:

struct sockaddr_ieee802154 tx;

Assignment:

tx.family = AF_IEEE802154

tx.addr.addr_type = IEEE802154_ADDR_SHORT;

tx.addr.pan_id = strtol((XXX, NULL, 16));

tx.addr.short_addr = strtol((YYYY, NULL, 16));

Here XXX and YYYY are to be replaced with string value that identifies the PAN ID and

the short address. The function ‘strtol’ is used to perform a string to long conversion as it is

simple to input a string than a long integer.

5.1.2. Socket functions

The socket functions listed below are used in the programs developed. These

functions are mainly used for creation of sockets, connection and data transfer. The

functions that are implemented in the programs are italicized and a brief description is

provided.

socket()

socket(PF_IEEE802154, SOCK_DGRAM, 0) – creates endpoint for communication using

domain defined for ieee802154 standard, of type datagram socket and default protocol.

bind()

bind(sock, (struct sockaddr *)&tx, sizeof(tx))– associates an address to the socket created.

Here the data structure specifies the address to be associated with and the size of the

address. The address used here will be the source address.


__________________________________________________________________________________

- 35 -

connect()

connect(sock, (struct sockaddr *)&tx, sizeof(tx))– used to connect to a remote host. The

data structure specifies the remote host address and its size to which the created socket

connects to.

send()

send(sock,buf,len,0)– sends data of specified length.

select()

select(sock + 1, &rf, &wf, &xf, NULL) – used to check sockets if they have data ready to be

sent, data ready to be written or if an exception has occurred.

read()

read(rd, &buf, sizeof(buf))– read data of specified length.

Figure 5.2 summarizes the various functions used and how they are used to achieve

the transmission and reception process. The left hand side diagram is for transmission and

the right hand side diagram is for reception.


__________________________________________________________________________________

- 36 -

Transmitter mote Receiver mote

Figure 5.2: Flow diagram showing transmission of data on the transmitter mote and reception of data on the receiver mote (using sockets)

socket socket

bind bind

connect connect

read from file

select send

read

write to file

establish connection

send data


__________________________________________________________________________________

- 37 -

5.1.3. Steps in communication process

To start the communication between motes, the device driver is loaded first. This

brings the radio chip up. Before bringing the radio up the sensor board is attached to

the processor board and the sensor modules related to temperature are loaded.

iz is a user space utility for WPAN services. ´´iz add wpan-phy0´´ will create a radio

interface for PHY object.

Then a distinct hardware address is set.

The interface ´´wpan0´´ is brought up.

The above steps are repeated on the other sensor nodes by setting different

hardware addresses.

On the imote that is going to be used as a coordinator, the coordinator is started.

Here lease is a file that stores the address of the other mote. Here the coordinator is

started by setting the debug level, using interface wpan0 on PAN address 888 and

channel 15. Here s which is set to 1 is the 16 bit address of the coordinator.

root@imote2:/ # modprobe cc2420

root@imote2:/ # ifconfig wpan0 up

root@imote2:/ # iz add wpan-phy0

root@imote2:/ # ip link set wpan0 address ca:fe:ca:fe:ca:fe:ca:fe


__________________________________________________________________________________

- 38 -

The other sensor nodes have to be associated to this network. During attachment, a

short address is assigned by the coordinator mote to the other sensor nodes. Once

the address is received, the nodes are ready to send the data to the coordinator.

Receive program executable is started on the receiver. The receive program accepts

the PAN ID, the receiver short address and the transmitter short address as the

inputs as shown below.

Transmit program executable is started on the transmitter. The transmit program

accepts the PAN ID, the transmitter short address allocated by the coordinator and

the receiver short address as the inputs as shown below.

Figure 5.3 is a logical representation with different communication layers showing the

transmission process within the imote2. The physical layer implementation is done at the

hardware level in the CC2420 radio chip. Sensor drivers when loaded acquire data from the

sensor board. The readings are stored in a file. The send/receive program when run

sends/receives the data through the radio. The various layers and the relation between

them are shown in the figure. Finally data is passed over the air through the antenna.

root@imote2:/ # rm lease

root@imote2:/ # touch lease

root@imote2:/ # izcoordinator -d 1 -l lease -i wpan0 -p 0x888 -s 1 -c 15

root@imote2:/ # iz assoc wpan0 888 1 15 short

root@imote2:/ # ./receive 888 0001 8001

root@imote2:/ # ./transmit 888 8001 0001


__________________________________________________________________________________

- 39 -

The receiver side follows a similar approach except that the data is received finally

where the communication process starts from the antenna and ends at the upper layer, the

other way around. The data packets flow during transmission and reception process is

described in the ‘TESTS’ chapter.

Figure 5.3: Implementation of the transmission process


__________________________________________________________________________________

- 40 -

5.1.4. Java on IMote2

Java is tested on imote2 to show the possibility of running an application program that

uses high level language as part of future developments or extensions to the present work. It

is necessary because dynamic loading of code or applications in the form of bundles can be

done using Java environment where applications can be remotely managed. However

Imote2 is resource constrained and normal Java installations can’t be done on Imote2. So

the approach is to have a java virtual machine that runs on embedded environments.

JAMVM [23] was chosen for this due to its small size and also it is specially developed for

embedded devices. There is also the need for a set of standard libraries that the VM can run

against. GNU Classpath [24] was considered. The steps in installing and setting the path are

described in Appendix C.2.

Simple java programs were tested on the mote. Since most of the code related to

transmission and reception process is written in C, there is a need to access the underlying C

code from java. This section describes the steps in running a C code from a java class.

The transmit program written in C which is the native implementation is accessed by a

java class. A class file is the byte code implementation of the actual java program as the class

file can be run on any platforms. Below are the steps in running a java class on imote2. Here

java native interface is used to access the underlying C code.

A program is written in java using a standard IDE like eclipse. A native method is

declared in the program. The program will load a library that implements the native

code.

On compilation, a class file will be created.

Using javah utility, a header file is created. For using javah, JDK should be installed on

the host machine.

Then the C program is written with the inclusion of the header file called jni.h.

The C program is cross compiled and a shared library is created from the object file.

The class file and the shared library file is transferred to imote2.

The shared library file is placed in the classpath location and the java program is

executed using JAMVM.


__________________________________________________________________________________

- 41 -

Figure 5.4 is a representation of the process for the transmitting part. Similar

approach is followed for the receiver application. The java source code, related native C

code and the header file can be found in the Appendix section.

Figure 5.4: Steps in accessing C code from a java application


__________________________________________________________________________________

- 42 -

5.2. Mote to machine communication

This topic deals with the communication approach used between the receiver mote

and the gateway device. The term ‘machine’ refers to the gateway device.

The communication between the receiver and the gateway device is carried out using

socket communication. The imote is connected to the gateway through a USB cable. The USB

cable can carry network traffic. This communication between two devices is similar to two

devices communicating through an Ethernet cable. Here datagram sockets are employed for

data transmission.

5.2.1. Socket structure

sockaddr_in

sockaddr_in is a structure that holds the address family, port number, address and the size.

The structure is named gateway and holds the property of the gateway device. This is the

standard structure used for the internet family.

Declaration:

struct sockaddr_in gateway;

Assignment:

gateway.sin_family=AF_INET;

gateway.sin_addr.s_addr=inet_addr("192.168.0.200");

gateway.sin_port=htons(4000);

The function ‘htons’ is used for conversion between host byte order and network

byte order. It is necessary because in a network the most significant bit is loaded first (also

called big endian) and is helpful if the host machine or device uses a different byte order

than that of the network.


__________________________________________________________________________________

- 43 -

5.2.2. Socket functions

The socket functions listed below are used in the program developed. The functions

that are implemented in the programs are italicized and a brief description is provided.

socket()

socket(AF_INET, SOCK_DGRAM, 0) – creates endpoint for communication using domain

defined for IP (internet) standard, of type datagram socket and default protocol.

bind()

bind(sockt,(struct sockaddr *)&gateway,length)– associates an address to the socket

created. Here the data structure specifies the address to be associated with and the size of

the address. The address used here will be the address of the gateway.

sendto()

sendto(sockt,buf,strlen(buf),0,(const struct sockaddr *)&gateway,length) – sends data to

the specified address, in this case the address of the gateway device on the specified port.

recvfrom()

recvfrom(sockt,buf,strlen(buf),0,(struct sockaddr *)&imote,&imotelen) – receives data from

the imote on the specified port.

Figure 5.5 summarizes the various functions used and how they are used to achieve

the communication process. The left hand side diagram is for transmission and the right

hand side diagram is for reception. The communication channel is across the USB cable. The

logic is such that the program running on the gateway accepts a limiting temperature as the

input value. If the received temperature exceeds the limiting value, then a shell script is

triggered by the program which sends an email to the end user. The port used for

communication through the USB cable should not be blocked by a firewall or similar

application.


__________________________________________________________________________________

- 44 -

Receiver imote Gateway

Figure 5.5: Flow diagram showing transmission of data from the imote and reception of data on the gateway (using sockets)

The executable ‘gateway’ is started on the gateway device. It accepts the limiting

temperature as the input as shown below.

Figure 5.7 is a logical representation of the reception process of the imote2 where

the communication between the various layers is shown. The process starts from the

antenna and ends with the receive program. Then the data received through the receive

socket

sensor data

sendto()

socket

recvfrom()

Check if

temperature >

temp_limit

Trigger mail

yes

no

USB cable

root@vtc6100:/ # ./gateway 25.5


__________________________________________________________________________________

- 45 -

program is passed to the gateway device by means of another program. The communication

channel is through IP running over the USB cable.

Figure 5.6: Block of code which is part of gateway.c that receives the temperature reading and checks if the temperature has exceeded the limit

while (1)

{

n = recvfrom

(sockt,buf,strlen(buf),0,(struct sockaddr *)&imote,&imotelen);

if (n < 0) error("recvfrom");

write(1,"\nReceived temperature: ",22);

write(1,buf,n);

t = strtod(buf, 0);

if (t > temp)

send_mail(t);

}

void send_mail(double cel)

{

int i;

float f;

f = (float)cel/1000;

char c[10];

FILE *q = NULL;

char *files = "sensor_reading";

size_t len = 0;

q = fopen(files, "w");

if(q == NULL) {

printf("Error opening file\n");

}

len = sizeof(float);

fwrite(c,len,1,q);

fclose(q);

printf("Written to file\n");

i = system("./send_mail");

}


__________________________________________________________________________________

- 46 -

Figure 5.7: Implementation of the reception process and the subsequent transmission of the data to the gateway device


__________________________________________________________________________________

- 47 -

5.3. Machine to machine communication

This topic describes the way how communication is achieved between the remote

terminal and the gateway device inside the container. The gateway device that is tested is

VTC6100. Linux runs on it. Two scenarios have to be taken into consideration when the

communication has to be achieved. The first one is the one way communication where the

gateway device sends information or data to a remote device. The second scenario is when a

remote user wants to access the gateway device and to take control of it.

5.3.1. Communication between gateway and remote machine

This topic deals with one sided communication where the gateway device sends

information to a remote device. Using a SIM card from a mobile operator (T-mobile),

VTC6100 is connected to the mobile network. File configuration on VTC is described in

Appendix A.1.

The SIM card is inserted into the socket provided in the gateway device.

On typing “lsusb”, the usb modem will be detected with the associated port number.

The ppp software which is a point to point application program is installed and

configuration files are created.

Appropriate entries are written in the files with the username, password and the

service provider’s APN (Access point name).

Connection to the mobile network is enabled by typing a command part of the ppp

utility.

To disassociate from the mobile network the below command is typed on the

terminal.

root@vtc6100:/ # pon tmobile

root@vtc6100:/ # poff tmobile


__________________________________________________________________________________

- 48 -

To check if the internet access is possible, any external website can be pinged.

Now that the gateway device is able to access the mobile phone network, a warning or

an alert mechanism can be set up on the gateway device to notify the end user in case of

exceeding temperature. Two types of alert mechanism were implemented on the gateway

device. The first one is an email alert where email is sent to the end user and the second one

is an SMS alert where am SMS is sent to the end user.

5.3.1.1. Email alert mechanism

Email alert mechanism is achieved by setting up a mail transfer agent on the gateway

machine. ssmtp, a simple mail transfer agent that uses SMTP (Simple Mail Transfer Protocol)

is tested on the gateway device. The advantage of ssmtp being that external email accounts

can be used to relay mails from linux system. An external email service is used as a smart

host to send mail from the gateway device.

ssmtp package is installed on the gateway device. The steps are described in

Appendix A.5.

A configuration file is created with the details of the email account which is used to

relay mail.

A shell script is written to automate the email sending in case of exceeding

temperature.

The below command is an example used in the shell script which sends email.

Here the command mail is used to send mail to an email_id ‘[email protected]’ with the

subject ‘Temperature exceeded’ with the message written in the file ‘message_mail’.

As described previously in the section “Mote to Machine communication”, the

program ‘gateway.c’ checks if the temperature has exceeded the limit that is set. If the

temperature has exceeded, it runs the shell script ‘send_mail’. The mail can be sent to any

root@vtc6100:/ # mail -s 'Temperature Exceeded' [email protected] < message_mail


__________________________________________________________________________________

- 49 -

email id. The mail is sent over the mobile network. The Figure 5.8 is a representation of the

process.

Figure 5.8: Gateway device sending email over the mobile network

5.3.1.2. SMS alert mechanism

Short message service (SMS) is one of the most common and popular text

communication methods used in mobile phones and related mobile devices. In this thesis

work, open source software called ‘gammu’ which is used to control mobile phones is tested

on the gateway device [25].

Gammu utility is downloaded and installed on the gateway machine. The steps are

described in Appendix A.4.

The port is identified and a configuration file is created.

A shell script is written to automate the SMS sending in case of exceeding

temperature.

The below command is an example used in the shell script which sends SMS.

Here ‘gammu’ is the SMS utility, ‘sendsms’ is the command in gammu to send the message

to the phone_number ‘XXXXYYYY’ and ‘TEXT’ is a keyword.

root@vtc6100:/ # echo „Temperature exceeded‟| gammu sendsms TEXT XXXXYYYY


__________________________________________________________________________________

- 50 -

The program ‘gateway.c’ is modified to run a shell script that sends an SMS instead of

an email. Related shell script is written that uses the gammu utility to send an SMS in case of

exceeding temperature.

Figure 5.9: Gateway device sending SMS over the mobile network

Figure 5.10 summarizes the whole process with the devices and the programs. The

code ‘mote2gw.c’ does the function of both receiving readings from transmitter mote as

well as sending readings to the gateway device through USB cable. The code

‘gateway_mail.c’ and ‘gateway_sms.c’ send mail and SMS respectively. They inherit the

same logic as that of ‘gateway.c’. Table 5.1 lists the codes used to achieve the desired

functionality. It is actually the executables or binaries that do the actual job.


__________________________________________________________________________________

- 51 -

Figure 5.10: Relation between the programs

Code Device Functionality

transmit.c Transmitter mote

Transmits sensor readings to receiver mote

receive.c Receiver mote

Receives sensor readings from transmitter mote

mote2gw.c Receiver mote

Receives sensor readings from transmitter mote and sends the readings to gateway device

gateway.c Gateway Receives sensor readings from receiver mote and checks if temperature has exceeded

gateway_mail.c Gateway Receives sensor readings from receiver mote and checks if temperature has exceeded, triggers

send_mail.sh

gateway_sms.c Gateway Receives sensor readings from receiver mote and checks if temperature has exceeded, triggers

send_sms.sh

send_mail.sh Gateway Shell script to send email

send_sms.sh Gateway Shell script to send SMS

Table 5.1: Programs and their functionality


__________________________________________________________________________________

- 52 -

5.3.2. Remote access to the gateway device

Steps in accessing the gateway device are summarized below which are explained in

detail in the Appendix A.2:

Access point is set up on the mobile device by configuring the SIM card which

uses the mobile network to connect to the internet.

Internet access point is set up on a local machine by using a VPN (OpenVPN).

To connect to the mobile network with a static IP the below command is typed on

the terminal of the gateway device.

To disassociate from the network, the below command is typed which terminates

the fixed IP service as well as the mobile service.

The remote user uses OpenVPN and connects to the mdex network. By using the

credentials provided my mdex, he/she can access the gateway device.

Web server is provided on the gateway device, due to which the user can access

the gateway device by means of a browser and get direct access to real time data.

The Figure 5.11 below shows the end to end communication with the devices and the

communication mechanisms used at different stages. The sensors communicate using the

IEEE 802.15.4 standard. The USB communication is used to transfer data to the gateway

device. UMTS/3G mobile technology connects the gateway device to the outside world. By

means of fixed IP service a remote user can connect to the gateway through the internet.

root@vtc6100:/ # pon mdex

root@vtc6100:/ # poff mdex


__________________________________________________________________________________

- 53 -

Figure 5.11: End to end communication with devices and communication technologies


__________________________________________________________________________________

- 54 -

6. TESTS

This chapter deals with the various tests performed on the Imote2 and the VTC 6100

to check for data transmission and explore other possibilities.

6.1. Tests on Imote2

This section deals with the tests performed on imote2. Radio transmission is tested

first followed by possible disruptions to transmission.

6.1.1. Transmission and Reception operation

When the radio chip is brought up, the 802.15.4 wireless interface can be seen by

typing the command “ifconfig”.

Figure 6.1: Wireless interface being listed

The third entry that is seen is for the wireless personal area network with the 64 bit

hardware address. This confirms that the radio chip is detected and that a wireless interface

is ready to form or join a network. Transmission and reception operation is started as

described in section 5.1.3. Multiple tries are sometimes necessary during association to the

WPAN started by the coordinator. The task of automating transmission and reception

root@imote2:/# ifconfig

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:16436 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

usb0 Link encap:Ethernet HWaddr DE:68:61:8C:45:A1

inet addr:192.168.0.202 Bcast:192.168.0.255 Mask:255.255.255.0

inet6 addr: fe80::dc68:61ff:fe8c:45a1/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1




RX bytes:8832 (8.6 KiB) TX bytes:5757 (5.6 KiB)

wpan0 Link encap:UNSPEC HWaddr CA-FE-CA-FE-CA-FE-CA-FE-00-00-00-00-00-00-00-00

UP BROADCAST RUNNING NOARP MTU:127 Metric:1






__________________________________________________________________________________

- 55 -

operation during start up may lead to delay or a hang up during booting.

To test the data transmission that is to see if the sensor readings are actually being

transmitted and received, sniffer like application is used. A sniffer is software that can

intercept the traffic that passes on a network. For this purpose, the open source software

application ‘tcpdump’ was used. Since tcpdump is run on the imote2, cross compilation is

necessary which will be discussed in the appendix section. The below figure shows the

packets sniffed on the transmitting imote2. The sensor readings are captured every ten

seconds and are transmitted. The packets being sent out are shown with the timestamp, the

hexadecimal address with the data length and actual data.

Figure 6.2: Data packets sent out from transmitter mote

Figure 6.3: Data packets coming in to the receiver mote

Figure 6.3 shows the packets sniffed on the imote2 that receives data. The packets

coming in are shown with the timestamp, the hexadecimal address with the data length and

actual data.

root@imote2:/home# ./tcpdump -i wpan0

tcpdump: WARNING: wpan0: no IPv4 address assigned

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on wpan0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

12:01:07.584548 Out ethertype Unknown (0x00f6), length 22:

0x0000: 3235 3030 300a 25000.


0x0000: 3235 3030 300a 25000.


0x0000: 3235 3530 300a 25500.


0x0000: 3237 3530 300a 27500.


0x0000: 3236 3530 300a 26500.


0x0000: 3236 3030 300a 26000.


0x0000: 3236 3030 300a 26000.

root@imote2:/home# ./tcpdump -i wpan0

tcpdump: WARNING: wpan0: no IPv4 address assigned

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on wpan0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

12:01:08.474466 In ethertype Unknown (0x00f6), length 22:

0x0000: 3235 3030 300a 25000.


0x0000: 3235 3030 300a 25000.


0x0000: 3235 3530 300a 25500.


0x0000: 3237 3530 300a 27500.


0x0000: 3236 3530 300a 26500.


0x0000: 3236 3030 300a 26000.


0x0000: 3236 3030 300a 26000.


__________________________________________________________________________________

- 56 -

6.1.2. Disturbance from external wireless equipments

The 802.15.4 network operates in the frequency band of 2.4 MHz. The WiFi (802.11)

operates in the same frequency range. It is possible for the receiver imote2 to encounter

transmission from a different device and intercept it. The external devices may be

transferring data with a huge data length. This may lead to buffer overflow in the radio chip

if the length of the data is more than 127 bytes. Figure 6.4 shows the debug message in case

of a normal reception of data. Here the PAN address used is 777 which is the PAN address

used for WPAN.

Figure 6.4: Debug message for normal reception of data

Figure 6.5: Debug message in case of interruption

[ 869.740981] cc2420 spi3.0: fifop interrupt received

[ 869.745520] ieee802154_subif_rx()

[ 869.745683] parse_frame_start: 8861 dsn86

[ 869.745717] parse_frame_start(): ACKNOWLEDGE required

[ 869.745757] parse_frame_start(): src IEEE802154_FC_INTRA_PAN

[ 869.745788] parse_frame_start(): src PAN address 0777

[ 869.745818] parse_frame_start(): dst PAN address 0777

[ 869.745848] parse_frame_start(): dst SHORT address 0001

[ 869.745880] parse_frame_start(): got src non-NONE address

[ 869.745910] parse_frame_start(): src IEEE802154_ADDR_SHORT

[ 869.745948] ieee802154_wpans_rx() frame 1

[ 869.746025] ieee802154_subif_frame Getting packet via slave interface wpan0

[ 869.746115] net wpan0: ACK requested, however AACK not supported.

[ 869.752659] got frame, type 804, dev c1fbc000

[ 869.752737] ieee802154_rcv 32 37 30 30 30 0a 27000.

[ 869.755085] cc2420 spi3.0: RXFIFO: 0 17 59

[ 869.761828] cc2420 spi3.0: sfd interrupt received

[ 1478.510292] cc2420 spi3.0: fifop interrupt received

[ 1478.515141] ieee802154_subif_rx()

[ 1478.515295] parse_frame_start: 3441 dsnb4

[ 1478.515330] parse_frame_start(): src addr_type is NONE

[ 1478.515365] parse_frame_start(): src IEEE802154_FC_INTRA_PAN

[ 1478.515398] parse_frame_start(): src PAN address 899c

[ 1478.515428] parse_frame_start(): dst PAN address 899c

[ 1478.515460] parse_frame_start(): dst hardware addr

[ 1478.515497] ieee802154_wpans_rx() frame 1

[ 1478.515587] ieee802154_subif_frame Getting packet via slave interface wpan0

[ 1478.515740] got frame, type 804, dev c1fbc000

[ 1478.515800] ieee802154_rcv 76 dd f4 51 3e 84 50 db d3 7a 62 0c d5 e7 3e 58

v..Q>.P..zb...>X

[ 1478.515845] ieee802154_rcv 74 57 9b 6f e3 e6 a5 76 41 53 9a aa 47 5d ee ce

tW.o...vAS..G]..

[ 1478.515884] ieee802154_rcv 1e de c2 07 0a 63 c1 07 e5 da ba 35 f1 13 c1 a1

.....c.....5....

[ 1478.515923] ieee802154_rcv ab 85 7b 2f c2 b7 04 57 08 69 39 25 b0 ca 35 0b

..{/...W.i9%..5.

[ 1478.515962] ieee802154_rcv 47 20 52 31 c1 43 30 96 35 76 76 a3 17 6c 42 f8 G

R1.C0.5vv..lB.

[ 1478.516001] ieee802154_rcv 56 9e 23 f2 6f 43 5f e9 f9 d8 63 ee 91 26 bb 73

V.#.oC_...c..&.s

[ 1478.516039] ieee802154_rcv e2 80 ca 64 3d 58 58 59 17 2a 08 18 58 ef d6

...d=XXY.*..X..

[ 1478.518679] cc2420 spi3.0: RXFIFO: 0 126 22

[ 1478.519959] cc2420 spi3.0: sfd interrupt received


__________________________________________________________________________________

- 57 -

The above figure shows the debug message in case the receiver intercepts a packet

not intended for it. Here the PAN address is different from 777. Usually, this leads to

overflow of the radio buffer. Also, it was found that the radio driver code needed some

correction at the physical layer as it was found that the receiver was missing the

transmission window period and not receiving any packets when there is a buffer overflow.

This is overcome by using the development kernel tree from the linux zigbee project where

corrections to radio transmission code are done as described in Appendix B.1. The solution

to unwanted packet interception is to find the best possible channel that is not used by

other sensor networks or devices.

6.1.3. Transmission current and transmission duration

Figure 6.6: Determining transmission current and transmission duration

The Imote2 is connected to power supply and a one ohm resistor is placed between

the mote and the power supply as shown in Figure 6.6. Oscilloscope probes are used to

determine the voltage flow across the circuit. The voltage flow appeared to be almost

constant during normal operation of Imote2. Once transmission program was run, there

appeared to be change in the voltage flow. The data transmitted during transmission

operation was the temperature value in milli degree centigrade with a delay of one second

between each transmission. A difference in voltage value at the resistor was observed

indicating the transmission operation. Figure 6.7 is one such measured sample showing the

change in voltage level.


__________________________________________________________________________________

- 58 -

Figure 6.7: Change in voltage level

By further examination of the obtained sample, the current consumption for

transmitting data is determined. Since a one ohm resistor is used, the voltage measured in

volts is equal to the current in amperes (Ohm’s law: Voltage = Current x Resistance). Figure

6.8 shows the voltage measurement for the sample and from the reading obtained, it was

around 67.7 mV. So the current consumed for transmission operation is nearly 67.7 mA. The

transmission duration for the same sample was found to be nearly 13.1 ms as shown in

Figure 6.9.

Figure 6.8: Measurement of transmission voltage


__________________________________________________________________________________

- 59 -

Figure 6.9: Measurement of transmission duration

6.2. Tests on VTC6100

Tests are performed on the gateway device to check if bidirectional communication is

possible. The first test is to check if the gateway transfers data to a remote machine. The

second test is to check for remote access.

6.2.1. Communication between gateway and remote machine

SMS script was enabled in case of exceeding temperature. SMS is sent to a phone

from the gateway device and Figure 6.10 shows the message that is delivered. If SMS

sending mechanism has to be enabled on the machine, then the mobile internet connection

should not be enabled on the gateway. The device for SIM cannot act as a phone and a

modem at the same time.


__________________________________________________________________________________

- 60 -

Figure 6.10: Snapshot of the SMS delivered

The mobile service is started on the gateway device. To know if the mobile service is

enabled the command ‘ifconfig’ is typed on the terminal. A ppp entry has to show up

confirming that the service is up. Now, the user should be able to ping external sites and

should be able to get a response.

A shell script was written and automated to send mail every ten minutes to an email

address using exim4 as the mail transfer agent. It was found that several email hosting

service providers block the mail if the source of the mail is from a dynamic IP address

considering it to be spam. This was confirmed by checking the system log for the mail. The

solution to this was to have a static IP for the gateway and so mdex service was run on the

gateway device. Having a static IP enabled the mail to be delivered to the recipient. Table 6.1

shows the testing done on the gateway device. In the table, there are two reasons listed in

case of disassociation or disruption. ‘halted’ means that it was stopped deliberately and

‘unknown’ is when the cause is not known. From the table, except for the first entry, the

communication process is relatively stable lasting more than a day. A script or program can

be written to restart the mobile service in case of disassociation to achieve autonomy. Later


__________________________________________________________________________________

- 61 -

ssmtp was used to relay mail as described in section 5.3.1.1. An external account was used

as the smart host and the mail was delivered using only the mobile service.

Date Test timings Duration Reason for disassociation

01-June-2011 12:20 to 14:58 2hours, 38 minutes unknown

01-June-2011 15:28 to 18:50 3 hours, 22 minutes halted



07-June-2011 11:37 to 24 hours, 26 minutes unknown

08-June-2011 12:03


10-June-2011 12:42


14-June-2011 14:49

Table 6.1: Test for communication between gateway and remote machine

Figure 6.11: Snapshot of the mail delivered


__________________________________________________________________________________

- 62 -

6.2.2. Remote access to the gateway device

The steps discussed in the Appendix section are followed and the remote connection

is tested. When the user pings from a local terminal to the gateway device, he can expect a

response. Remote login can then be done to the gateway device by using SSH.

As long as the gateway device is connected to the mdex network, the remote user

can access the gateway device by means of OpenVPN. Usually, the web page of the gateway

device is accessed.

6.2.3. Key findings

The key findings are summarized below:

The UMTS module provided in the VTC6100 cannot send SMS when it is used to

connect to the internet.

Email is delivered via smart host using the services of mobile internet.

Remote access is possible as long as the gateway device is connected to the Fixed IP

server. The remote access is done by using OpenVPN connection on the remote

machine.


__________________________________________________________________________________

- 63 -

7. CONCLUSIONS

7.1. Observation

This thesis work mainly focused on two things. The first one is the use of Imote2 as

sensor hardware to set up a wireless sensor network. It was proved that Imote2 can be used

to set up a wireless sensor network. Related code written to send sensor readings is found to

be working. The development kernel source tree from the linux zigbee project has

corrections for radio transmission. Also the sensor board can be interfaced with the gateway

device by means of USB and related code was developed to transfer the data to gateway

device.

The second aspect is the means of communication between the gateway device and

a remote machine. Alert mechanisms such as sending SMS and Email in case of exceeding

parameters like temperature were set up on the gateway device and are found to be reliable

and working. This task is automated and the end user can chose the best alert mechanism

that fits his need. Remote access to the gateway device is shown to be possible.

Though the thesis is titled ‘Machine to machine communication for wireless sensor

networks’, the bulk of research and time was spent on setting up wireless sensor network

and making the Imote2 work. Limitations of time led to less work being done on connecting

to the gateway device remotely where accessing through a web browser and web based

programming play a key role.

7.2. Future suggestions

Automation needs to be done to set up a wireless sensor network automatically. Also

warning or alert mechanism tested in this work can be extended to include other sensors

like TelosB. While connecting to the gateway device remotely, web server is activated on the

gateway device. The end user sees the happenings inside the container that is the

temperature and humidity variation through an internet browser. Considerable work can be

done in this area. Also testing of the whole set up can be done in a real container

environment and when the container is on the move with food being transported.


__________________________________________________________________________________

- 64 -

LIST OF REFERENCES

[1] Bhaskar Krishnamachari: Networking Wireless Sensors: Cambridge University Press,

2005

[2] Homepage of the intelligent container project: http://www.intelligentcontainer.com

[Last accessed: 25-June-2011]

[3] Datasheet of VTC6100: http://www.nexcom.com/Products/mobile-computing-

solutions/in-vehicle-pc/noseries/vehicle-telematics-computer-vtc-6100


[4] Imote2_Hardware_Reference_Manual_7430-0409-01_A.pdf

[5] Datasheet of CC2420: http://focus.ti.com/lit/ds/symlink/cc2420.pdf


[6] Homepage of imote2-linux on sourceforge:

http://sourceforge.net/projects/imote2-linux/ [Last accessed: 25-June-2011]

[7] Intel mote2 community on yahoo groups:

http://tech.groups.yahoo.com/group/intel-mote2-community/message/3837


[8] Imote2 project on openembedded: http://openembedded.org/index.php/IMote2


[9] IMote2 related research at the University of Washington:

http://ubi.cs.washington.edu/wiki/index.php/IMote2 [Last accessed: 25-June-2011]

[10] Homepage of BLOB: http://www.lartmaker.nl/lartware/blob/


[11] Home page of the Linux Kernel source: http://www.kernel.org/


http://www.intelligentcontainer.com/

http://www.nexcom.com/Products/mobile-computing-%20%20%20%20%20%20solutions/in-vehicle-pc/noseries/vehicle-telematics-computer-vtc-6100

http://www.nexcom.com/Products/mobile-computing-%20%20%20%20%20%20solutions/in-vehicle-pc/noseries/vehicle-telematics-computer-vtc-6100

http://focus.ti.com/lit/ds/symlink/cc2420.pdf

http://sourceforge.net/projects/imote2-linux/

http://tech.groups.yahoo.com/group/intel-mote2-community/message/3837

http://openembedded.org/index.php/IMote2

http://ubi.cs.washington.edu/wiki/index.php/IMote2

http://www.lartmaker.nl/lartware/blob/

http://www.kernel.org/


__________________________________________________________________________________

- 65 -

[12] Home page of the linux-zigbee project:

http://sourceforge.net/apps/trac/linux-zigbee/ [Last accessed: 25-June-2011]

[13] Andrew S. Tanenbaum; David J. Wetherall: Computer Networks, Fifth Edition:

Pearson, 2011

[14] Homepage of OpenVPN: http://openvpn.net/ [Last accessed: 25-June-2011]

[15] Dynamic Host Configuration Protocol: http://www.ietf.org/rfc/rfc2131.txt


[16] Homepage of mdex fixed ip: http://www.mdex.de/en/products/fixedip/


[17] Price list for mdex fixed ip services: http://www.mdex.de/en/products/price-list/


[18] IEEE std. 802.15.4 - 2003: Wireless Medium Access Control (MAC) and Physical Layer

(PHY) specifications for Low Rate Wireless Personal Area Networks (LR-WPANs):

http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf


[19] Transmission of IPv6 Packets over IEEE 802.15.4 Networks:

http://tools.ietf.org/html/rfc4944 [Last accessed: 25-June-2011]

[20] Jean-Philippe Vasseur; Adam Dunkels: Interconnecting Smart Objects with IP:

Morgan Kaufmann, 2010

[21] Brian “Beej Jorgensen” Hall; Beej's Guide to Network Programming: Using Internet

Sockets: Version 3.0.14:

http://beej.us/guide/bgnet/output/print/bgnet_A4_2.pdf [Last accessed: 25-June-2011]

[22] Download page for Sourcery G++ lite:

http://www.codesourcery.com/sgpp/lite/arm/portal/release1803


[23] Homepage of JAMVM: http://jamvm.sourceforge.net/ [Last accessed: 25-June-2011]

[24] Homepage of GNU Classpath:

http://www.gnu.org/software/classpath/classpath.html [Last accessed: 25-June-2011]

[25] Gammu project: http://wammu.eu/ [Last accessed: 25-June-2011]

http://sourceforge.net/apps/trac/linux-zigbee/

http://openvpn.net/

http://www.ietf.org/rfc/rfc2131.txt

http://www.mdex.de/en/products/fixedip/

http://www.mdex.de/en/products/price-list/

http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf

http://tools.ietf.org/html/rfc4944

http://beej.us/guide/bgnet/output/print/bgnet_A4_2.pdf

http://www.codesourcery.com/sgpp/lite/arm/portal/release1803

http://jamvm.sourceforge.net/

http://www.gnu.org/software/classpath/classpath.html

http://wammu.eu/


__________________________________________________________________________________

- 66 -

APPENDIX A A.1. Configuring the gateway to access mobile network

This section describes the steps in connecting VTC 6100 to the mobile network.

For the modem to work ‘wvdial’ utility is needed, wvdial is an intelligent PPP dialer.

wvdial utility is installed by typing the below command on a Debian machine.

On installing wvdial, some files are created in the /etc/ppp directory which needs to

be configured. In the /etc/ppp folder a new file called ‘chat’ is created with the

following entry.

Note: “internet.service_provider” is replaced with the appropriate service link depending on

the SIM and the service opted for.

The file is saved.

A new file is created in the /etc/ppp/peers directory with the following entry.

debian:/#apt-get install wvdial

SAY "START\n"

ABORT BUSY

SAY "ABORT\n"

ECHO OFF

'' ATZ

'' AT+CGDCONT=1,"ip","internet.service_provider "'

#SAY "DIAL"

OK ATD*99#

SAY 'CONNECT'


__________________________________________________________________________________

- 67 -

Note: The file is named as per the service provider’s name. For a T-mobile connection, the

file is named as tmobile. The ‘username’ and ‘password’ are to be replaced with the

appropriate entries. This information will be given by the mobile service provider.

The file is saved.

The command ‘pon’ is typed followed by the name of the file.

An entry called ppp0 will be created as shown below and on pinging a reply is

expected.

/dev/ttyUSB3

460800

idle 7200

lock

crtscts

modem

noauth

replacedefaultroute

defaultroute

user username

password password

connect "/usr/sbin/chat -V -f /etc/ppp/chat"

noipdefault

usepeerdns

novj

debian:/#pon tmobile


__________________________________________________________________________________

- 68 -

To disassociate from the network poff is typed.

debian:/#poff

root@vtc6100:/# ifconfig

ppp0 Link encap:Point-to-Point Protocol

inet addr:xx.xx.xx.xx P-t-P:10.64.64.64 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1






__________________________________________________________________________________

- 69 -

A.2. Configuring the gateway for Fixed IP service

This topic deals with the steps to configure VTC for having a static IP when connecting to the

mobile network. It is assumed that ‘wvdial’ is installed and the gateway device is able to

connect to a mobile network

In the /etc/ppp folder a new file called chat_mdex is created with the following entry.

The file is saved.

A new file called mdex in the /etc/ppp/peers directory is created with the following

entry. For the username, password and other details, information provided by mdex

is used.

SAY "START\n"

ABORT BUSY

SAY "ABORT\n"

ECHO OFF

'' ATZ

'' AT+CGDCONT=1,"ip"," xxxx"'

#SAY "DIAL"

OK ATD*99#

SAY 'CONNECT'


__________________________________________________________________________________

- 70 -

The file is saved.

To connect to the mobile network with static IP, the following command is typed.

On typing ‘ifconfig’, an entry is created with fixed IP.

debian:/#pon mdex

/dev/ttyUSB3

460800

idle 7200

lock

crtscts

modem

noauth

replacedefaultroute

defaultroute

user username

password password

connect "/usr/sbin/chat -V -f /etc/ppp/chat_mdex"

noipdefault

usepeerdns

novj


__________________________________________________________________________________

- 71 -

Now, the fixed IP service is active on the mobile device and can be confirmed by

pinging any external sites.

To turn the modem off, the below command is issued.

debian:/#poff

root@vtc6100:/# ifconfig

ppp0 Link encap:Point-to-Point Protocol

inet addr:xx.xx.xx.xx P-t-P:10.64.64.64 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1




RX bytes:14913 (14.5 KiB) TX bytes:16564 (16.1 KiB)


__________________________________________________________________________________

- 72 -

A.3. Accessing the gateway from a local PC

This topic lists the steps in order to connect to the gateway.

The local machine can be a PC with Windows XP or Windows Vista running on it.

Administrator privileges are necessary when configuring.

OpenVPN client is installed on the PC. The client software was from mdex. (It was

preconfigured to use mdex settings). OpenVPN client that is available on the internet

as free software cannot be used. This requires the configuration files to be edited if it

is not from the vendor.

The client is run as administrator.

Figure A.1: OpenVPN1

An icon appears at the right hand side of the taskbar. It is right clicked and then

connected.


__________________________________________________________________________________

- 73 -


A window appears asking for username and password. This information will be

provided by mdex. The appropriate credentials are used to log in.


Once credentials are established, the icon turns green indicating that the fixed IP

service is available.


Now the gateway device can be accessed. For this the gateway device should be

connected to the mobile network with static IP.


__________________________________________________________________________________

- 74 -

A.4. Enabling SMS on the gateway machine

This section describes the steps to be followed in order to enable SMS alert mechanism on

the VTC6100.

A message sending utility for sending SMS from a Linux Machine is installed.

‘Gammu’ is installed on the gateway machine.

Gammu is available as a debian package and the below command is run on the

terminal to install gammu utility.

This will install gammu and associated libraries on the machine.

A file is created in /etc directory by the name ‘gammurc’. This will be the

configuration file for sending SMS.

The following entry is created in the file ‘gammurc’.

The file is saved.

To check, if the configuration is correct the command ‘gammu - -identify’ is typed on

the terminal. It has to list out the SIM properties as shown below.

debian:/#apt-get install gammu

#Configuration file for gammu SMS sending utility

[gammu]

port=/dev/ttyUSB3

connection=at


__________________________________________________________________________________

- 75 -

Now that the SMS utility is enabled, SMS can be sent by typing the following

command on the terminal. ‘XXXXYYYY’ is the phone number to which the message

has to be delivered.

debian:/# gammu --identify

Device : /dev/ttyUSB3

Manufacturer : Sierra Wireless, Inc.

Model : unknown (MC8790V)

Firmware : K1_1_1_9AP

debian:/# gammu sendsms TEXT XXXXYYYY


__________________________________________________________________________________

- 76 -

A.5. Enabling email service on the gateway machine

This section describes the steps to be followed in order to enable email alert mechanism on

the VTC6100.

An email transfer agent is installed on the gateway device. ‘ssmtp’ is installed on the

gateway device.

ssmtp is available as a debian package and the below command is run on the

terminal to install ssmtp utility.

This will install ssmtp and associated libraries on the machine.

The configuration file for ssmtp is edited with the details of the email account.

The following entry is added to the file ‘ssmtp.conf’.

Here, ‘username’ and ‘password’ is replaced with the actual username and password whose

mail is used to relay. In the fourth entry, ‘email_provider’ and ‘port_number’ are to be

replaced with actual entries depending on the mail service provider.

debian:/#apt-get install ssmtp

#Configuration file for ssmtp to relay mail

AuthUser=username

AuthPass=password

FromLineOverride=YES

mailhub=smtp.email_provider.com:port_number

UseSTARTTLS=YES

debian:/# vi /etc/ssmtp/ssmtp.conf


__________________________________________________________________________________

- 77 -

The file is saved.

Email relaying can be tested by sending mail from the command line

debian:/# echo „hello„ | mail –s „Test„ [email protected]


__________________________________________________________________________________

- 78 -

APPENDIX B B.1. Using OpenEmbedded for building kernel and the file system

The following packages and their dependencies are installed:

aptitude

install

sed

wget

cvs

subversion

git-core

coreutils

unzip

texi2html

texinfo

docbook-utils

gawk

python-pysqlite2

diffstat

help2man

make

gcc

build-essential

g++

desktop-file-utils

chrpath

apt-get

libxml2-utils

xmlto

python-psyco

apr

docbook

A directory structure is created at the top of the filesystem.

debian$ cd imote


__________________________________________________________________________________

- 79 -

A directory by the name build is created inside the imote directory.

A directory by the name conf is created in the build directory.

At the time of writing this document, bitbake was available at the below link.

http://download.berlios.de/bitbake/bitbake-1.10.2.tar.gz.

bitbake is downloaded and the package is unzipped.

The directory is renamed from bitbake-1.10.2 to bitbake.

Git is used to obtain openembedded. Git is a revision control system and can be used

to keep track of changes and update the latest changes.

OpenEmbedded is cloned inside the imote directory.

A new directory called openembedded will be created.

To update openembedded.,

The configuration file is copied.

debian:/imote/$ cd build

debian:/imote/build/$ cd conf

debian:/imote/ $ tar –xjvf bitbake-1.10.2.tar.gz

debian:/imote/ $ git clone git://git.openembedded.org/openembedded

debian:/imote/openembedded/ $ git pull - - rebase

debian: $ cd imote/

debian: /imote/ $ cp openembedded/conf/local.conf .sample build/conf/local.conf

debian:/imote/ $ vi build/conf/local.conf


__________________________________________________________________________________

- 80 -

The following three entries are very important and should be written in the local.conf

file.

The environmental path variable is set for openembedded and BitBake.

To build,

This will take several hours to build. This command will build both the kernel and the

file system. After the build has finished the images are found in the location shown

below.

The modules can also be found as a tar file which can be extracted.

BBFILES = "/imote/openembedded/recipes/*/*.bb"

DISTRO = "angstrom-2010.x"

MACHINE = "imote2"

debian:$ export BBPATH=/imote/build:/imote/openembedded

debian:$ export PATH=/imote/bitbake/bin:$PATH

debian:/imote/$ bitbake imote2- image

debian:/imote2/build/tmp/deploy/glibc/images/imote2# ls

Angstrom-imote2-image-glibc-ipk-2010.7-test-20110125-imote2.rootfs.jffs2

Angstrom-imote2-image-glibc-ipk-2010.7-test-20110125-imote2.rootfs.tar

Angstrom-imote2-image-glibc-ipk-2010.7-test-20110125-imote2-testlab

imote2-image-imote2.jffs2

imote2-image-imote2.tar

modules-2.6.33+2.6.34+r0+gitr3a70ef2d40d829a2ca8321475977f0f019997ab1-r0-imote2.tgz

zImage-2.6.33+2.6.34+r0+gitr3a70ef2d40d829a2ca8321475977f0f019997ab1-r0-imote2.bin

zImage-imote2.bin


__________________________________________________________________________________

- 81 -

Alternatively, the kernel source tree from the linux zigbee project can be cloned in a local machine.

The source tree for the linux kernel from the linux zibee project is cloned using git.

This will clone the stable kernel which corresponds to an older version. To get the latest

version, a checkout has to be done.

This will clone the development tree. Now, the kernel can be compiled. The development tree

holds the latest code with modifications and has an improved performance in terms of radio

transmission as far as wireless transmission for imote2 is concerned. The openembedded build is

necessary as we can obtain a file system that corresponds to the latest kernel.

debian:$ git clone git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee/kernel

debian:$ git checkout –b devel origin/devel


__________________________________________________________________________________

- 82 -

B.2. Flashing images on to the Imote2

B.2.1. Flashing the Boot Loader

Blob is used as the boot loader, the boot loader for ARM platforms. Blob is able to

boot a kernel from flash. This entire flashing process was done on a PC running Windows XP.

For other operating systems, the steps may vary.

The BIOS setting of the host PC is changed, ECP is enabled for the parallel port.

FTDI USB drivers are downloaded and installed on the host PC. This allows direct

access of a USB device through a DLL. (Needed to recognize the debug board)

The folder Jflashmm is copied to the host PC.

giveio.sys is installed. This file is present in the Jflashmm directory.

The giveio.sys file is copied to C:\WINDOWS\system32\drivers directory.

This driver is installed by navigating to the Control Panel.

The PC is restarted.

The JTAG cable is attached to the JTAG board.

The jumper positions on the JTAG board is set as follows:

The JTAG cable of the JTAG board is connected to the imote2 debug board.

The main imote2 processor board is combined with the debug board.

The PC and the JTAG board is connected with a mini USB cable.

Also, the PC and the imote2 processor board is connected with a mini USB cable.

The Imote2 is switched on by pressing the reset button.

Command prompt on the PC is opened and the JFlashmm executable file is run.

C:\imote2\Jflashmm > JFlashmm.exe bulbcx16 blob P 0 WIG

TDO_SEL left

PWD_SEL left

nRST right

nTRST right


__________________________________________________________________________________

- 83 -

The above command runs the file by taking in the inputs. Here bulbcx16 refers to the

file which defines the target system platform, blob is the image to be flashed. P means that

the flash memory has to be programmed and verified. 0 is the start address and WIG stands

for the Wiggler cable.

The timing between flashing of blob and start of imote2 is very important. The above

process is time consuming and should be done with patience and care. Below is the output

of the command for a failed installation.

C:\imote2\jflashmm2>JFlashmm.exe bulbcx16 blob P 0 WIG

JFLASH Version 5.01.003

COPYRIGHT (C) 2000 - 2003 Intel Corporation

PLATFORM SELECTION:

Processor= PXA27x

Development System= Mainstone

Data Version= 1.00.001

error, failed to read device ID

check cables and power

ACT: 1111 1111111111111111 11111111111 1

EXP: **** 1001001001100101 00000001001 1

failed to read device ID for this Platform


__________________________________________________________________________________

- 84 -

Below is the output for an installation that is successful.

C:\imote2\jflashmm2>JFlashmm.exe bulbcx16 blob P 0 WIG

JFLASH Version 5.01.003

COPYRIGHT (C) 2000 - 2003 Intel Corporation

PLATFORM SELECTION:

Processor= PXA27x

Development System= Mainstone

Data Version= 1.00.001

PXA27x revision C5

Failed to read the Flash ID. Retrying 4 more times…

Found flash type: 28F256L18B

Unlocking block at address 0

Erasing block at address 0





Starting programming

Using BUFFER programming mode...

Writing flash at hex address 12069, 97.66% done

Programming done

Starting Verify

Verifying flash at hex address 124d2, 99.17% done

Verification successful!


__________________________________________________________________________________

- 85 -

The boot loader if flashed can be found out by connecting the imote2 along with the

debug board to the PC through a USB cable through the COM port.

B.2.2. Flashing kernel and the filesystem

The debug board and the imote2 board are attached together.

The debug board is connected to the PC using a USB cable.

On Windows XP, there is an application by the name Hyper terminal.

The Hyper terminal is opened.

Figure B.1:Flashing1

If a driver for the debug board is installed on the PC, then a new port will be

visible.


__________________________________________________________________________________

- 86 -

Figure B.2: Flashing2

The following parameters are set as shown below.

(bits per second – 115200, databits – 8, parity – none, stopbits – 1, Flowcontrol –

none)

Figure B.3: Flashing 3


__________________________________________________________________________________

- 87 -

The reset button of the imote2 is pressed. This will start the boot loader.


The process is stopped by pressing any key.

Once blob is flashed into the imote2, flashing of kernel and the filesystem can be

done by using commands given by blob. The flashing process is done by using the commands

´´xdownload´´ and ´´fwrite´´. Before flashing, the images of kernel and filesystem have to be

kept ready on the PC.

Below are the steps shown for flashing a filesystem.

´´xdownload ramdisk´´ is issued.


__________________________________________________________________________________

- 88 -


The filesystem image is chosen and the image is transfered by setting the

transmission protocol as ´´1K Xmodem´´.

FigureB.6: Flashing6

This transfer process for filesystem will take about one hour or so.


__________________________________________________________________________________

- 89 -


Once transfer is finished, blob tells that it has received the filesystem.


The command ´´fwrite 0xa0500000 0x00240000 0xXXXXXXXX`` is issued to flash

the image on the imote2 .


__________________________________________________________________________________

- 90 -


The kernel image is flashed in a similar way except that we use use different

addresses while using fwrite. Blob can also be flashed in case a new version of

blob is needed.

Summary:

For blob,

For kernel,

For filesystem,

blob> xdownload blob

blob> fwrite 0xa0200000 0x00000000 0x00040000

blob> xdownload kernel

blob> fwrite 0xa0008000 0x00040000 0x00200000

blob> xdownload ramdisk

blob> fwrite 0xa0500000 0x00240000 0xXXXXXXXX


__________________________________________________________________________________

- 91 -

APPENDIX C C.1. Cross Compilation on a host Machine

The IA32 GNU/Linux Installer ( Sourcery G++ Lite for ARM GNU/Linux ) from the

Codesourcery website ( www.codesourcery.com) is downloaded.

The downloaded package will be in the form of a bin file.

E.g.: arm-2010.09-50-arm-none-linux-gnueabi.bin

The package is copied and placed in a directory of the host machine.

The following script is executed. A graphic installer comes up.

After execution of the above script, on screen dialogs appear.

As per requirements, selections are made and the installation is finished.

The installed toolchain’s directory is added to the PATH system variable.

If the package is installed in the /root directory, then the following command is run.

Now an ARM cross compiler tool chain is set up.

debian:/home $/bin/sh /home/bsanjeeva/arm-2010.09-50-arm-none-linux-gnueabi.bin

debian:/home $export PATH=/root/CodeSourcery/Sourcery_G++_Lite/bin: $PATH


__________________________________________________________________________________

- 92 -

Cross compiling a C program

The program:

<hello.c> =

Cross compiling:

Here:

arm-none-linux-gnueabi-gcc ----- cross compiler

hello.c ----- C program

hello ----- executable file

The executable file hello is copied to the target machine and run.

#include <stdio.h>

void main()

{

Printf(“Hello World\n”),

}

debian:/home$arm-none-linux-gnueabi-gcc hello.c -o hello

root@imote2:/ #. /hello

Hello World


__________________________________________________________________________________

- 93 -

C.2. Installing Java on Imote2

On imote2 we have package management application like the opkg. So we will find

the suitable ipk packages and install them using opkg. For this, ipk packages from the

Angstrom distribution website are downloaded. The packages required are,

classpath-common_0.97.2-r8.1_armv5te.ipk

file_4.21-r0.1_armv5te.ipk

classpath-minimal_0.97.2-r3.1_armv5te.ipk

classpath-minimal-dev_0.97.2-r3.1_armv5te.ipk

jamvm_1.5.2-r3.6_armv5te.ipk

The packages are copied to the imote2 and installed using opkg in the order as listed

above.

After all the packages have been installed, the bootpath and library path is set for the

classpath and the virtual machine.

root@imote2:/# opkg install package_name.ipk

root@imote2:/# export

BOOTCLASSPATH='/usr/share/jamvm/classes.zip:/usr/share/classpath/glibj.zip'

root@imote2:/# export LD_LIBRARY_PATH='/usr/lib/classpath'


__________________________________________________________________________________

- 94 -

Testing a java class file against JAMVM may lead to an error as shown below:

This is beacuse jamvm can work against classpath_0.98 or later versions. So we have to take

the latest classpath source and cross compile it.

Cross Compliling ClassPath:

The classpath tar package from the gnu website is downloaded. The latest version is

obtained.

The tar package is extracted.

The PATH is set to point to the cross compiler (ARM toolchain)

The following sets of commands are run from inside of the extracted directory.

debian: / $ ./configure --host=arm-linux --prefix=/usr --disable-gtk-peer -

-disable-gconf-peer --disable-plugin --disable-qt-peer

debian: / $ make

debian: / $ make DESTDIR=$PWD/install_here install

root@imote2:/home# jamvm test

Exception in thread "main" java.lang.NoClassDefFoundError: test

<<No stacktrace available>>

Caused by: java.lang.ClassNotFoundException: test not found in

java.lang.ClassLoader$1{urls=[], parent=null}

at java.net.URLClassLoader.findClass(URLClassLoader.java:529)

at java.lang.ClassLoader.loadClass(ClassLoader.java:341)

at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)

at java.lang.ClassLoader.loadClass(ClassLoader.java:293)


__________________________________________________________________________________

- 95 -

This will create a set of files in a folder called called install_here inside the

extracted classpath directory.

Inside the directory install_here,a archive called glibj.zip will be found in the

usr/share/classpath directory.

This glibj.zip confirms to the latest version. Now this zipped file is transferred to

the imote 2 and the installed glibj.zip found in /usr/share/classpath directory is

replaced with the new one.

Now, any java class file can be executed on Imote2.

root@imote2:/home# jamvm test

test: Hello World


__________________________________________________________________________________

- 96 -

C.3. Packet Sniffer for WPAN on imote2

The latest source files for libpcap and tcpdump is got from http://www.tcpdump.org.

The environmental variable PATH is set pointing at the location of the cross compiler.

The files are extracted.

Firstly, libpcap is cross compiled and then tcpdump.

Cross Compiling libpcap:

Cross Compiling tcpdump:

This will create an executable file by the name ´´tcpdump´´ within the tcpdump-4.1.1

directory.

The executable file is copied to the imote2.

$ tar -zxvf libpcap-1.1.1.tar.gz

$ cd libpcap-1.1.1/

$ CC= arm-none-linux-gnueabi-gcc ac_cv_linux_vers=2 ./configure --

host=arm-linux --with-pcap=linux

$ make

$ cd ..

$ tar zxvf tcpdump-4.1.1.tar.gz

$ cd tcpdump-4.1.1/

$ CC= arm-none-linux-gnueabi-gcc ac_cv_linux_vers=2 ./configure --

host=arm-linux --with-pcap=linux

$ make

$ scp tcpdump root@imote2_address:path to save


__________________________________________________________________________________

- 97 -

After logging in to the imote2; the permissions for the executable file is changed. The

wireless PAN service is started.

Now packets that are incoming and outgoing for the WPAN service can be seen.

$ chmod 777 tcpdump

$. /tcpdump –i wpan0


__________________________________________________________________________________

- 98 -

APPENDIX D File List

This section provides a list of the source codes, executables and configuration files

used and developed as part of the thesis. A folder called Thesis_M2M contains the folders

and the files listed below.

Folder Sub Folder File name Description

Gateway_VTC6100 tmobile tmobile configuration file for tmobile

chat_tm chat file for tmobile

mdex mdex configuration file for mdex

chat_mdex chat file for mdex

OpenVPN mdex_fixed.ip_openvpn:release.exe openvpn executable software

gammu gammurc configuration file for SMS

Imote2 Images JFlashmm JFlashmm utility for flashing bootloader

Openembedded Images Images obtained from openembedded build

Openembedded final images Images after applied changes

Applications jamvm jamvm executables

tcpdump tcpdump executable

Code C transmit.c Transmits sensor readings to receiver mote

receive.c Receives sensor readings from transmitter mote

mote2gw.c Receives sensor readings from transmitter mote and sends the readings to gateway device

gateway.c Receives sensor readings from receiver mote and checks if temperature has exceeded

gateway_mail.c Receives sensor readings from receiver mote and checks if temperature has exceeded, triggers send_mail.sh

gateway_sms.c Receives sensor readings from receiver mote and checks if temperature has exceeded, triggers send_sms.sh

ieee802154.h Header file for user space application

libcommon.h Header file for user space application

java Transmit.c Native program in C for transmission

Transmit.h Header file

Transmit.java Java file that calls Transmits.C

shell scripts sms Shell script and associated files to send SMS

email Shell script and associated files to send email

executables contains the list of executable programs

machine to machine communication for wireless sensor networks · machine to machine communication...

Documents