TinyOS 2.0 Host-Level Protocols
From TinyWiki
Contents |
Current TinyOS 1.1 protocols
The Packetizer Protocol is a binary protocol for transferring messages over a serial link. It provides acknowledegements, but no protocol numbering or typing.
The Serial Forwarder Protocol is a binary protocol for transferring messages over a TCP connection. It provides no acknowledegements, and only provides protocol typing at connection establishment.
The TOSSIM Protocol is a binary protocol for
- transferring messages between simulated motes and clients.
- transferring commands and events between the simulator and simulator control programs.
It provides acknowledgements and multiplexing between one kind of tunneled mote message and simulator commands. It supports communication with a single simulated mote (mote ID 0) or all motes, though the protocol could be used to communicate with any mote.
Desired Features of TinyOS 2.0 Protocols
Protocol Multiplexing
The problem with many current TinyOS host-layer messaging protocols is that they do not support multiplexing. The header doesn't contain a type field. Only one type of message can be sent over the link.
The Packetizer protocol, between the host and the mote, only supports passing one type of packet -- whatever the TOS_Msg is for the platform.
The Serial Forwarder protocol can send the packet type at the beginning of the connection, but then requires that all packets be of that type for the rest of the time.
The TOSSIM protocol does support multiplexing, because it is used to transfer messages to and from the simulated application as well as to and from the simulator itself, but this protocol is very specific to TOSSIM and is not used anywhere else.
I propose that the TinyOS 2.0 host-level protocols should all support multiplexing.
Module Decomposition
In the current TinyOS protocol scheme, processes that handle sensor network messages are the last stop. The normal flow starts at a mote, moves through a chain of transparent Serial Forwarders, and stops at a Java application that communicates with the terminal, GUI, or database.
Under this scheme, there is no way to decompose a network stack into layered components that cross the boundaries of a single process. For example, we want one process to act as a routing component, selecting an outgoing link or modifying a packet based on application-level data and its own internal state. A second process may want to send a packet to that routing component. Currently, this second process must be within the process boundary of the first, because there is no API for a process to re-export a message interface.
The TinyOS 2.0 host-layer protocols should support messaging between host processes. A single process should be able to "provide" a link interface, in addition to being able to "use" a link interface.
TCP Links
Process-to-process message transfer should take place over TCP links. TCP works for processes on the same machine just as well as it works for processes on different machines. Each link interface provided by a process should be implemented as a TCP server, and each link interface used by a process should be implemented as a TCP client.
TOSSIM currently supports a control link for each simulator, which is also used for transferring some simulated mote messages. I suggest that TOSSIM should be modified so that it provides two separate TCP link interfaces for each simulated mote (simulated radio and simulated serial). This change would allow a richer interaction between the simulator, host processes, and mote processes.
The question then arises: which protocol should we use to transfer messages over the TCP link?
- Write our own framing protocol.
- Use Java RMI (rules out TOSSIM and heterogeneous clients, so it's probably a bad idea)
- Use some other standard TCP protocol for messaging (any ideas?)
Discovery Service
It's hard to form a network out of a bunch of TCP port numbers. Therefore, processes that provide link interfaces should be able to give a meaningful name to an interface, and register the name-port mapping with a discovery server at a known location. This will allow client modules to connect with server modules by name instead of by number. This will also allow client modules to enumerate available link interfaces, for human consumption.
The discovery service should run as a separate process on a known TCP port, communicating over a defined protocol. This protocol should probably be in the web-service style, using XML over HTTP. We could also look into DNS-Service Discovery, which already provides a service for registering and looking up name to address:port mappings, and has the benefit of being an Internet standard.
Web Services
TCP ports provide for the most flexible method of interconnecting heterogeneous processes that are interested in mote data. However, TCP ports don't generally pass firewalls. HTTP does, but unfortunately, processes that work within the standard port 80 URL namespace must run within a single webserver. To support outside clients of an integrated gateway application running in a webserver, we should define a method for accessing mote data through HTTP URLs. The format of the messages over this protocol may be similar to the format used over TCP connections.
We should also look into providing a standard XML-based protocol. XML over HTTP is supported by many different clients, and would increase the range of potential participants in our sensor network. Many languages already have the ability to read and write XML. That seems like one of the benefits of using XML an an interchange format. If we write mig classes, only people who use Java can use them. Everyone else has to parse the bytes themselves. If we write translators to XML, then anyone who can parse XML can use the data.
An XML tool would be able to fully translate all nested messages, not just TOS_Msgs. Picture a graph like this:
/-- type x -- struct TOS_Msg_15.4 -- type q -- struct MHMsg ... Host-Mote -- type y -- struct Link_Config_Msg \-- type z -- struct Debug_Msg
If the gateway had this graph of structures, types, and type fields within each structure, it could recursively decode the entire contents of a packet into XML. If there is ever an unspecified header, the decoding would of course have to stop and dump the rest into the XML file as binary, for later decoding.
Messages over XML/HTTP may correspond 1-1 with sensor network messages, as described above, but this is certainly not required. Middleware authors may also want to export web service interfaces that are derived from mote data but do not exactly reflect the mote message structures. This should be encouraged.
Proposed TinyOS 2.0 Protocols
Host-Mote Binary Protocol, over a serial link
Host-Host Text Protocol, over TCP
Host-Discovery Server Protocol over XML/HTTP
Host-Host Protocols over HTTP, and URL Naming Scheme
