Packetizer Protocol

From TinyWiki

The Packetizer protocol is used to transmit data packets over the serial connection between a mote and a PC-class device. Packetizer uses start and stop bytes to mark the boundaries of the packet, and uses escape bytes to ensure that the start and stop bytes don't appear in the middle of the packet. Packetizer supports acknowledgements at the link layer.

This protocol is inspired by RFC 1663.

Contents 1 Frame Format 1.1 Sync Byte 1.2 Packet Type 1.3 Packet Cookie 1.4 Data 1.5 CRC 1.6 Sync Byte 1.7 Escape Byte 2 Reading a Frame 3 Writing a Frame

Frame Format

This frame format is used in both directions.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Sync Byte   |  Packet Type  | Packet Cookie | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |              CRC              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sync Byte

126: This is the only value ever present in this field.

The Sync Byte is used to separate packets. There must be at least one Sync Byte between any two packets.

Packet Type

64: This indicates that the packet is an ACK for another packet. The Data field must be empty.

65: This indicates that the packet should be ACKed by the other side. This is normally used when the packet is going from the PC to the Mote.

66: This indicates that the packet should not be ACKed. This is normally used when the packet is going from the Mote to the PC.

255: This is used to inform the sender that the receiver has received a packet with an unknown type. If any type other than these four is received, the receiver must respond by sending back a packet of type (255). The Data field of this packet must contain only the value of the unknown packet type that was just received. When receiving a packet of type (255), the receiver learns that it had previously sent a packet with a type that the peer does not understand. It learns the number of that type by reading the Data field.

Packet Cookie

This field must be different for each packet sent. It is used to match data packets to ACK packets. Therefore, the ACK for a packet must contain the same packet cookie of the packet it is acknowledging.

Data

This field contains the payload of the packet.

CRC

This 2-byte field is calculated over the entire frame, excluding the first Sync Byte.

Sync Byte

A second Sync Byte is used to indicate the end of the frame.

Escape Byte

125: All portions of this frame, except the Sync Bytes, will be "character-stuffed". If the Sync Byte (126) or the Escape Byte (125) appears anywhere in the packet, it will be replaced with the Escape Byte (125), followed by the Sync or Escape Byte XORed with 0x20. These values are (94) and (93) respectively.

Reading a Frame

The peer starts in the WAIT state;

In the WAIT state, a peer continually watches for a Sync Byte. Once one is read, the host enters the READ state.

In the READ state, the peer reads one byte. If the byte is an Escape Byte (125), the peer enters the ESCAPED state. If the byte is a Sync Byte, the peer processes the frame and returns to the WAIT state. Otherwise, the byte is placed into the next available buffer space. If the buffer is now full, the peer silently throws away the packet and returns to the WAIT state. If there is space remaining, the peer remains in the READ state.

In the ESCAPED state, the peer reads one byte. If the byte is a Sync Byte, it is an error and the peer returns to the WAIT state. Otherwise, the byte is XORed with 0x20 and then saved into the buffer. If the buffer becomes full, the peer silently throws away the packet and returns to the WAIT state. Otherwise, it returns to the READ state.

In the PROCESSING state, the peer computes the CRC and compares it to the last two bytes in the buffer. If the CRCs do not match, the frame is discarded and the peer returns to the WAIT state. If the CRCs match, the peer examines the packet type. If the packet type is (65), the peer enqueues an ACK packet with that sequence number, and then enters the SYNC state. If the packet type is (64), the peer does nothing. If the packet type is unknown, the peer places a packet with type (255) into the send queue, and saves the unknown packet type into the data field of this new packet.

The peer then passes the payload to the upper layer and returns to the WAIT state.

Writing a Frame

The peer starts in the IDLE state.

Upon receipt of a packet from the upper layer, the peer adds the correct packet type (65 when going from PC to Mote, 66 when going from the Mote to PC) and an incremented sequence number to the beginning of the frame. The peer then computes the CRC over the frame and saves it to the end. The peer then enters the SYNC state.

In the SYNC state, the peer sends the Sync Byte and then enters the WRITE state.

In the WRITE state, the peer reads the next byte from the buffer. If the byte equals the Sync Byte (126), or the Escape Byte (125), then the peer saves the byte, sends the Escape Byte (125), and enters the WRITE_ESCAPED state. Otherwise, the peer sends the byte. If this is the last byte, the peer enters the SYNC_COMPLETE state.

In the WRITE_ESCAPED state, the peer XORs the saved byte with 0x20 and then writes it. The purpose of the XOR is to remove the escaped byte from the datastream. It will be undone by the receiving peer. The peer then returns to the WRITE state.

In the SYNC_COMPLETE state, the peer sends the Sync Byte and returns to the IDLE state.

Gilman Tolle

March 25th, 2005