Remote UART Protocol

Remote UART Protocol

The goal of the Remote UART protocol and its implementations is to abstract from the underlying network topology of a wireless sensor network testbed. Messages sent to a sensor node using the Remote UART protocol will be transparently passed to the application as if it was received through a real UART.

Implementations

Currently, there are two implementations of the Remote UART protocol:

• Wiselib implementation (see remote_uart.h and remote_uart_message.h under wiselib.testing/util/wisebed_node_api/ in the Wiselib sources)
• Java implementation in https://github.com/itm/netty-handlerstack/tree/master/protocol-collection

Packet Format

0:     COMMAND_TYPE (1 Byte)
1:     SEQUENCE_NUMBER (1 Byte)
2-9:   DESTINATION (8 Byte)
10-17: SOURCE (8 Byte)
18:    PAYLOAD_SIZE (1 Byte)
19-n:  PAYLOAD

Command Types

60: REMOTE_UART_MESSAGE
61: REMOTE_UART_SINK_REQUEST
62: REMOTE_UART_SINK_RESPONSE
63: REMOTE_UART_SET_SINK
64: REMOTE_UART_KEEP_ALIVE

• If a packet is of a type other than REMOTE_UART_MESSAGE the field SEQUENCE_NUMBER must be ignored by all implementations.
• The sender of a packet must only increment SEQUENCE_NUMBER if the packet sent is of type REMOTE_UART_MESSAGE.
• If a packet is of type REMOTE_UART_SET_SINK or REMOTE_UART_SINK_RESPONSE then the field PAYLOAD must always be empty, i.e. it must contain 0 bytes.
• If a packet is of type REMOTE_UART_SET_SINK then the fields SOURCE and DESTINATION may contain arbitrary bytes that must be ignored by every implementation.

When a node A is booting then he will flood the network after a random backoff between 0 and 1 second with a packet of type REMOTE_UART_SINK_REQUEST. Then, if a node B receives this packet and B is a sink it will route a packet of type REMOTE_UART_SINK_RESPONSE to the requesting node A using an arbitrary routing protocol that is scenario-specific and chosen by the application programmer. If this packet is then received by the requesting node A then, starting from this point in time, all data written to the node A's UART will be forwarded to the sink using packets of type REMOTE_UART_MESSAGE.

To keep alive a "connection" between sink and source the source must send a packet of type REMOTE_UART_KEEP_ALIVE one minute after the last the regular communication between source and sink and repeat this periodically every minute. This must only happen if there's no other communication between sink and source in between. The purpose of this mechanism is to allow the gateway machine to which the sink is connected to listen to every packet received by the sink to be able to, e.g., learn about the absence or presence of individual nodes even if they're not actively communicating currently.

It depends on the routing protocol chosen by the application programmer if the loss of a route between sink and source can be detected or fixed.

Remote UART provides a stream-based interface, meaning that layers above must care about framing and deframing of individual packets e.g., by using the ProtocolDleStxEtx framing protocol.

Rahmenformat (iSense)

If Remote UART is used on iSense nodes the iSense packet type must be 105: PLOT.