Transport Layer specification

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (opens new window).

Overview

The Transport layer is responsible for the end-to-end communication between the End Device and the Gateway or between End Devices. It provides a Network Join Protocol, a reliable protocol for acknowledged communication and an unreliable protocol that allows for unacknowledged packet transmission.

List of protocols:

ID	Protocol
0	Network Join protocol
1	Service Discovery protocols
2	Reliable protocols
3	Unreliable protocols
4	Generic Broadcast protocol
5	Mailbox Protocol

Network Join protocol (ID 0)

This protocol defines the transport layer header for the Network Management protocol messages. The messages MUST be no longer than one packet and communication is best effort (unacknowledged).

Transport Protocol header (THdr) structure:

THdr 1 byte	Payload 0-60 bytes

THdr

The THdr is defined as follows:

Reserved [7:3]	Payload Type [2:0]

Payload header:

PHdr	Description
0	Join Request
1	Join Response
2	Gateway Discovery Request
3	Gateway Discovery Response
4-7	Reserved

Service Discovery protocol (ID 1)

This protocol defines the transport layer header for the Service Discovery protocol.

Data structure:

THdr 1 byte	Message 0-60 bytes

Type Header (THdr)

The Type Header (THdr) is defined as follows:

Reserved [7:5]	Protocol ID [4:0]

Reliable protocol (ID 2)

This protocol defines reliable data communication between the End Device and the Gateway or two End Devices. All data is acknowledged and data is retransmitted if ACK is not received.

Data structure:

THdr 1 byte	TSeq 2 bytes	Payload 0-58 bytes

The Reliable Protocol allows for data being sent in both directions on the same connection. There MUST only be one packet in transit between the sender and receiver at any given point time. Once a connection is established, both sides can keep sending data. Both sides MUST acknowledge the reception of data by setting the ACK flag, and when no more data is to be sent, both sides MUST indicate this by setting the FIN flag on the connection.

Transport header (THdr)

The contents of the THdr field consists of the Application Protocol number and the control flags for connection control such as connection establishment, acknowledgement, abort and disconnect:

ACK [7]	RST [6]	SYN [5]	FIN [4]	App Protocol ID [3:0]

The Application protocol ID field is used to describe the payload.

The following table describes the Transport Header flags in detail:

Flag	Description
FIN	Indicates that the sending side wants to end the connection
SYN	Indicates the intention to establish a connection
RST	Used to perform an "abortive release" or to inform the sender of a SYN that connection cannot be established
ACK	Indicates that the sequence number in the TSeq field has been received

Connection setup is done by setting the SYN flag. If the sender wants to send only one packet, then it will set both the SYN+FIN flag indicating to the receiver that this is the first and last packet. Should the sender want to send data segmented in multiple packets, then the sender MUST set the SYN flag in the first packet and the FIN flag in the last packet.

When the receiver receives a packet with SYN flag set, it MUST return a packet with the ACK (acknowledge) flag set and TSeq set the sending sequence number. At this stage, the connection is considered an "open" connection. If the receiver (eg. Gateway) has no data to return to the sender, it MUST set the App protocol (THdr) to 0 to indicate to the sender that there is no data coming. If the receiver (eg. Gateway) have data for the sender (eg. Device), it MUST set the App protocol (THdr) accordingly. In case there is no data to return to the sender or that this is the last data packet from receiver, it MUST set the FIN flag to let the sender know that no more data is coming. In case the receiver wants to send data segmented in multiple packets, it MUST set the ACK flag in the first packet (to ACK the SYN from the sender) and the FIN flag in the last packet. The sender (eg. Device) MUST return an ACK packet for each packet received. The sequence number (TSeq) is kept the same number throughout a connection. A connection with data segmented in multiple packets is called a stream.

This table summarises the valid flags combinations used in connection setup, transmission and teardown:

Host	THdr App Protocol ID	THdr Flags	Description
Sender	>0	SYN	First data packet in a stream
Sender	>0	SYN+FIN	First and last packet.
Sender	0	ACK	Ack. reception of TSeq.
Sender	0	ACK+FIN	Ack. reception of TSeq. No data to send.
Receiver	0	ACK+FIN	Ack. reception of TSeq. No return data. Last packet.
Receiver	>0	ACK	Ack. reception of TSeq. Returned data is in "App Protocol" format, first in a sequence of packets.
Receiver	>0	ACK+FIN	Ack. reception of TSeq. Returned data is in "App Protocol" format. Last packet.
Receiver	>0		Data is in "App Protocol" format.
Receiver	>0	FIN	Data is in "App Protocol" format. Last packet.

Frame Sequence Number (TSeq)

The Sequence Number MUST be incremented on every connection. This is important for several reasons: AES encrypted data must be different on every transmission. If data is the same, the only thing that changes is the Sequence Number, thus creating a different encryption output each time. This prevent replay attacks.

The Network Server keeps track of two Sequence Number counters for each End Device; One ingress counter and one egress counter. Sequence numbers MUST be successive. They are used for retransmission purposes, in case of lost frames.

Unreliable protocol (ID 3)

The unreliable protocol is unacknowledged. This means that the sender does not know if the data-gram has been lost or reached it's target. It is very energy-efficient as it allows a device to just send data and go back to sleep, without waiting on a acknowledge that is has reached it's target.

Transport layer header and payload:

THdr 1 byte	Payload 0-59 bytes

THdr

Reserved [7:4]	App Protocol ID [3:0]

The Application protocol ID field is used to describe the payload.

Generic Broadcast protocol (ID 4)

The Generic Broadcast protocol is unreliable best effort protocol. The sender does not know if the data-gram has reached it target or whether it has been lost. This protocol can be used to distribute the same data to many devices at the same time, provided that they are listening.

Protocol header structure:

THdr 1 byte	Message 60 bytes

THdr

Reserved [7:4]	App Protocol ID [3:0]

Mailbox protocol (ID 5)

The Mailbox protocol is a secure mechanism that allows for messages to be sent to battery constrained or sleepy devices.

Type Header (THdr)

The Type Header (THdr) is defined as follows:

Reserved [7:6]	Proprietary extentions [5]	Command [4:1]	Direction [0]