TinyChat:A Chat System Based on TinyOS

Jin Xu E-mail: xu5@clemson.com Clemson University

Abstract
Sensor networks have become a major area of research for low power wireless embedded development. This paper takes the approach of proposing and implementing a system which goes against traditional low-duty sensor network applications. In this paper,we propose and implement TinyChat,a prototype chat system based on TinyOS.TinyChat consists of a set of functions like message,audio and le transfer.And the system runs over a multi-hop sensor network which uses TinyOS and TelosB Motes.

1 discuss the hardware platforms and the feathers of TelosB.Section 2 is the fundmental of TinyOS and nesC.In this part,we will address some important knowledge about architeture of TinyOS,structure of nesC language and analysis of components of TinyOS which is used to send and receive message in the TinyChat.Next,the design of TinyChat which addresses the idea of TinyChat and its work procedures.In the last section,conclude the work in the project and discuss the future of the application.

Hardware Platforms

Introduction

Wireless sensor network(WSN) is a new advanced technology in the network eld of computer science.Its always used in the domains of environmental monitoring, agriculture, medical care, smart buildings, factory monitoring and automation, and numerous military applications.With the developement of WSN technology,it will play an increasingly important role in our life. As we know,nowadays,the most versatile network is Internet,which is global system of interconnected computer networks that use the standard Internet Protocol Suite (TCP/IP) to serve billions of users worldwide.In most situations,Internet is open,wired and power-hungry.But in some applications,we need private,wireless and energy saving network.In this case,WSN is the best choice for the application. Along with the development of information technology,Instant Messaging (IM), a collection of technologies used for real-time text-based communication between two or more participants over the Internet, or other types of networks,uses more and more widely.Of importance is that online chat and instant messaging differs from other technologies such as e-mail due to the perceived synchronicity of the communications by the users chat happens in real-time.But until now almost all IMs run on the Internet and there is no one running on the WSN.If one want to use IM to communicate with others under some special circumstances without Internet,how to solve the problem? The objectives of this paper are to analyse the principle of communication in TinyOS and use java and nesC to implement a chat system named TinyChat on TinyOS.Section

The sensor network is comprised of TelosB[1] motes produced by Crossbow. Crossbows TelosB mote (TPR2400) is an open source platform designed to enable cutting-edge experimentation for the research community. The TPR2400 bundles all the essentials for lab studies into a single platform including: USB programming capability, an IEEE 802.15.4 radio with integrated antenna, a low-power MCU with extended memory and an optional sensor suite (TPR2420). TPR2400 offers many features, including: IEEE 802.15.4 compliant RF transceiver 2.4 to 2.4835 GHz, a globally compatible ISM band 250 kbps data rate Integrated onboard antenna 8 MHz TI MSP430 microcontroller with 10kB RAM Low current consumption 1MB external ash for data logging Programming and data collection via USB Optional sensor suite including integrated light,temperature and humidity sensor(TPR2420) The TelosB platform was developed and published to the research community by UC Berkeley. This platform delivers low power consumption allowing for long battery life as well as fast wakeup from sleep state. Though the TPR2400 is an uncertied radio platform, it is fully compatible with the open-source TinyOS distribution.

TinyOS code is statically linked with program code, and compiled into a small binary, using a custom GNU toolchain. Associated utilities are provided to complete a development platform for working with TinyOS. NesC is a systems programming language for networked embedded systems such as motes. nesC supports a programming model that integrates reactivity to the environment, concurrency, and communication. By performing whole-program optimizations and compile-time data race detection, nesC simplies application development, reduces code size, and eliminates many sources of potential bugs. The basic concepts behind nesC are: Separation of construction and composition: programs are built out of components, which are assembled (wired) to form whole programs. Components have internal concurrency in the form of tasks. Threads of control may pass into a component through its interfaces. These threads are rooted either in a task or a hardware interrupt. Specication of component behaviour in terms of set of interfaces. Interfaces may be provided or used by components. The provided interfaces are intended to represent the functionality that the component provides to its user, the used interfaces represent the functionality the component needs to perform its job. Interfaces are bidirectional: they specify a set of functions to be implemented by the interfaces provider (commands) and a set to be implemented by the interfaces user (events). This allows a single interface to represent a complex interaction between components (e.g., registration of interest in some event, followed by a callback when that event happens). This is critical because all lengthy commands in TinyOS (e.g. send packet) are non-blocking; their completion is signaled through an event (send done). By specifying interfaces, a component cannot call the send command unless it provides an implementation of the sendDone event. Components are statically linked to each other via their interfaces. This increases runtime efciency, encourages rubust design, and allows for better static analysis of programs. NesC is designed under the expectation that code will be generated by whole-program compilers. This should also allow for better code generation and analysis.

Figure 1. Telosb Block Diagram.

TinyOS and NesC

TinyOS[5] is a free and open source component-based operating system and platform targeting wireless sensor networks (WSNs). TinyOS is an embedded operating system written in the nesC programming language as a set of cooperating tasks and processes. It is intended to be incorporated into smartdust. TinyOS started as a collaboration between the University of California, Berkeley in co-operation with Intel Research and Crossbow Technology, and has since grown to be an international consortium, the TinyOS Alliance. TinyOS applications are written in nesC[3], a dialect of the C language optimized for the memory limits of sensor networks. Its supplementary tools are mainly in the form of Java and shell script front-ends. Associated libraries and tools, such as the NesC compiler and Atmel AVR binutils toolchains, are mostly written in C. TinyOS is completely non-blocking: it has one stack. Therefore, all I/O operations that last longer than a few hundred microseconds are asynchronous and have a callback. To enable the native compiler to better optimize across call boundaries, TinyOS uses nesCs features to link these callbacks, called events, statically. While being nonblocking enables TinyOS to maintain high concurrency with one stack, it forces programmers to write complex logic by stitching together many small event handlers. To support larger computations, TinyOS provides tasks, which are similar to a Deferred Procedure Call and interrupt handler bottom halves. A TinyOS component can post a task, which the OS will schedule to run later. Tasks are non-preemptive and run in FIFO order. This simple concurrency model is typically sufcient for I/O centric applications, but its difculty with CPU-heavy applications has led to the development of a thread library for the OS, named TOSThreads.

3.1

Radio Communication

Radio communication is used to provide mote-mote communication in TinyOS. TinyOS provides a number of

 AMReceiverC - Provides the following interfaces: Receive, Packet, and AMPacket. AMSenderC - Provides AMSend, Packet, AMPacket, and PacketAcknowledgements as Acks.

3.2

Serial Communication

Figure 2. The structure (components and their wiring) of a simple application, Blink.

interfaces to abstract the underlying communications services and a number of components that provide (implement) these interfaces. All of these interfaces and components use a common message buffer abstraction,called message t[4],which is implemented as a nesC struct (similar to a C struct).There are a number of interfaces and components that use message t as the underlying data structure. Lets take a look at some of the interfaces of the communications system: Packet - Provides the basic accessors for the message t abstract data type. This interface provides commands for clearing a messages contents, getting its payload length, and getting a pointer to its payload area. Send - Provides the basic address-free message sending interface. This interface provides commands for sending a message and canceling a pending message send. The interface provides an event to indicate whether a message was sent successfully or not. It also provides convenience functions for getting the messages maximum payload as well as a pointer to a messages payload area. Receive - Provides the basic message reception interface. This interface provides an event for receiving messages. It also provides, for convenience, commands for getting a messages payload length and getting a pointer to a messages payload area. AMPacket - Similar to Packet, provides the basic AM accessors for the message t abstract data type. This interface provides commands for getting a nodes AM address, an AM packets destination, and an AM packets type. Commands are also provides for setting an AM packets destination and type, and checking whether the destination is the local node. AMSend - Similar to Send, provides the basic Active Message sending interface. The key difference between AMSend and Send is that AMSend takes a destination AM address in its send command. A number of components implement the basic communications and active message interfaces. Lets take a look at some of the components:

Serial communication is used to provide PC-mote communication in TinyOS.Sending an AM packet to the serial port in TinyOS is very much like sending it to the radio.The TinyOS serial stack follows the same programming model as the radio stack. There is a SerialActiveMessageC for turning the stack on and off (mote processors often cannot enter their lowest power state while the serial stack is on), and generic components for sending and receiving packets. As the serial stack is a dedicated link, however, it does not provide a snooping interface, and it does not lter based on the destination address of the packet. These are the serial communication components and their radio analogues: Serial SerialActiveMessageC SerialAMSenderC SerialAMReceiverC Radio ActiveMessageC AMSenderC AMReceiverC

Table 1. analogues between serial and radio components

Design

TinyChat is a set of software tools for supplying the services over the wireless sensor network.These services include sending and receiving messages,audio chat and le transfer. Messages:After build the connection between the server and client,client can send messages to other clients which have connected the server or receive messages from others. Audio: After build the connection,client can send audio stream to other client or receive audio stream from others. File transfer: After build the connection,client can send les to other clients

4.1

Architecture

In TinyChat,we use Client-Server architecture in our design.A computer with a TelosB mote plays the role of serverand rest of computers with motes are clients. All the motes in the system build a multi hop network by Collect Tree Protocol(CTP)[2] and communicate with each others.The client will get the data from user and put the data

into the TinyOS messages and then send them to the TelosB mote by serial port,and then the mote will transfer the messages to its neighbour,which will forward the message until the message arrive at server.The server will transfer the message to destination client.After receive all the messages of data,the destination client will unpack the messages ,combine them together and process the data.

CTP receives a data frame with a gradient value lower than its own, then this indicates that there is an inconsistency in the tree. CTP tries to resolve the inconsistency by broadcasting a beacon frame, with the hope that the node which sent the data frame will hear it and adjust its routes accordingly. If a collection of nodes is separated from the rest of the network, then they will form a loop whose ETX increases forever. CTPs second mechanism is to not consider routes with an ETX higher than a reasonable constant. The value of this constant is implementation dependent. The CTP data frame format is as follows: Field deni-

Figure 3. TinyChat architecture.

4.2

Collect Tree Protocol

CTP is a tree-based collection protocol. Some number of nodes in a network advertise themselves as tree roots. Nodes form a set of routing trees to these roots. CTP is address-free in that a node does not send a packet to a particular root; instead, it implicitly chooses a root by choosing a next hop. Nodes generate routes to roots using a routing gradient. The CTP protocol assumes that the data link layer provides four things: Provides an efcient local broadcast address. Provides synchronous acknowledgments for unicast packets. Provides a protocol dispatch eld to support multiple higher-level protocols. Has single-hop source and destination elds. CTP uses expected transmissions (ETX) as its routing gradient. A root has an ETX of 0. The ETX of a node is the ETX of its parent plus the ETX of its link to its parent. This additive measure assumes that nodes use link-level retransmissions. Given a choice of valid routes, CTP SHOULD choose the one with the lowest ETX value. CTP represents ETX values as 16-bit xed-point real numbers with a precision of hundredths. Routing loops are a problem that can emerge in a CTP network. Routing loops generally occur when a node choose a new route that has a signicantly higher ETX than its old one, perhaps in response to losing connectivity with a candidate parent. If the new route includes a node which was a descendant, then a loop occurs. CTP addresses loops through two mechanisms. First, every CTP packet contains a nodes current gradient value. If

Figure 4. CTP data frame. tions are as follows: P: Routing pull. The P bit allows nodes to request routing information from other nodes. If a node with a valid route hears a packet with the P bit set, it SHOULD transmit a routing frame in the near future. C: Congestion notication. If a node drops a CTP data frame, it MUST set the C eld on the next data frame it transmits. THL: Time Has Lived. When a node generates a CTP data frame, it MUST set THL to 0. When a node receives a CTP data frame, it MUST increment the THL. If a node receives a THL of 255, it increments it to 0. ETX: The ETX routing metric of the single-hop sender. When a node transmits a CTP data frame, it MUST put the ETX value of its route through the single-hop destination in the ETX eld. If a node receives a packet with a lower gradient than its own, then it MUST schedule a routing frame in the near future. origin: The originating address of the packet. A node forwarding a data frame MUST NOT modify the origin eld. seqno: Origin sequence number. The originating node sets this eld, and a node forwarding a data frame MUST NOT modify it. collect id: Higher-level protocol identier. The origin sets this eld, and a node forwarding a data frame MUST NOT modify it.

 data: the data payload, of zero or more bytes. A node forwarding a data frame MUST NOT modify the data payload. The CTP routing frame format is as follows:

Figure 5. CTP route frame. The elds are as follows: P: Same as data frame. C: Congestion notication. If a node drops a CTP data frame, it MUST set the C eld on the next routing frame it transmits. parent: The nodes current parent. metric: The nodes current routing metric value. When a node hears a routing frame, it MUST update its routing table to reect the address new metric. If a nodes ETX value changes signicantly, then CTP SHOULD transmit a broadcast frame soon thereafter to notify other nodes, which might change their routes. The parent eld acts as a surrogate for the single-hop destination eld of a data packet: a parent can detect when a childs ETX is signicantly below its own. When a parent hears a child advertise an ETX below its own, it MUST schedule a routing frame for transmission in the near future.

Conclusion

Acknowledgements References
[1] CrossBow. TelosB Datasheet. Crossbow Technology,Inc. [2] R. Fonseca, O. Gnawali, K. Jamieson, S. Kim, P. Levis, and A. Woo. TEP123:The Collection Tree Protocol, 2006. [3] D. Gay, P. L. Matt Welsh, E. Brewer, R. von Behren, and D. Culler. The nesc language:a holistic approach to networked embedded systems. Technical report, 2003. [4] P. Levis. TEP111:messaget , 2006. [5] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo1, D. Gay, J. Hill, M. Welsh, E. Brewer, and D. Culler. Tinyos: An operating system for sensor networks. Technical report, 2003.