---

The manufacturer shall use non-consecutive, randomly distributed numbers for the rest of the device ID field and guarantee uniqueness for all his delivered SPT devices.

5.2.5.3 RCT Device ID

The Device ID of the RCT is an ID that is unique within the receiver and never changed within the lifetime of a receiver. It represents the unique identity of the RCT.

The Message ID’s as used are listed in the following table:

Table 4 - Message ID overview

The Message ID of any Response is the same as the Message ID of the corresponding Command, but with bit 7 set.

This is the length of the Message Data (excluding Message ID and Message length). This field is used.

- in variable length messages (see for example 6.3.1 and 6.4.18) to check for the end of data;

to be able to determine the start of an embedded reverse command (see 5.8).

Possible padding is never considered when calculating the value of message length field.

The sequence number is used to determine if a message is missing or duplicated. Both ends have a transmit sequence number and a receive sequence number.

These two counters exist at both ends (e.g. we are speaking about 4 counters in total), whereas the RX_Sequence counters are used to realize a “state-full machine” implementation.

These counters are used to fulfil three simultaneous functions:

1. Initially, both the SPT and RCT choose their TX_seqs to be a random number, then they use it as a datagram counter, incrementing them for each sent datagram by one. The RX_seqs are the expected next TX_seqs from the other communication end-point. That is: If one did see “42" as the last TX_seq coming in from the communication partner, oneself would send out “43” as next RX_seq. As the other end does this in the same style, the TX_seq and RX_seq function as a mutual sequence control mechanism.

2. Second, they can simultaneously function as a resend-mechanism: If one detected that one missed a datagram (because for example, the incoming TX_seq is “44”, but one expected TX_seq=43) or the one got is corrupt (by checking the hash), one just resends the own old previously sent last datagram and the other side will see by the old TX_seq that one wants to get a re-transmission.

3. Being chosen randomly and being part of the encrypted data block, they rule out replay attacks.

For each connection, every message has to be acknowledged before the next new (not retransmission) message may be transmitted.

The following flags are defined:

Table 5 - Flags

Padding is required for the following two reasons:

create a message length which is a multiple of the block length of the encryption algorithm as used;

make poll and alarm messages look alike.

Padding is done using random or pseudo-random data. Random bytes are appended to the actual messages data until the total message length is one of those as specified in the next clause.

The message lengths as used fulfil the requirements as mentioned in 5.3.1 (using a 16 or 32 byte block length), and are a compromise between obfuscation of alarm events and bandwidth usage.

This results message lengths that are a multiple of 128 + 4 bytes for the Connection Handle:

132 bytes (4 bytes Connection Handle + 8 x 16 bytes);

260 bytes (4 bytes Connection Handle + 16 x 16 bytes);

etc.

The following methods of message validation are supported:

Table 6 - Hashing ID’s

RCTs have to implement all methods. However, it is permissible to configure a RCT not to accept all hash methods.

SPTs shall at least implement the default method, but can implement all methods.

The default method is 0 (SHA-256) until explicitly updated using the messages as defined in 6.4.10 and 6.4.11.

The hashing method to be used is negotiated during session initialization, using the messages as defined in 6.4.10 and 6.4.11.

The selectable hashing method allows for an upgrade of security in the future while maintaining backwards compatibility.

The hash is included in the encrypted part of the message.

Except for the Connection Handle, the entire message is encrypted. The encryption method to be used has been negotiated during Commissioning. The following methods are supported:

Table 7 - Encryption ID’s

RCTs have to implement all methods. SPTs shall at least implement the default method, but can implement all methods. The default method is 2 (AES-256) until explicitly updated using the messages as defined in 6.4.6 and 6.4.7.

The encryption key is valid only for one connection between an SPT and the RCT, e.g. the RCT shall keep track of all different keys as used by the SPTs connected to it.

The operation mode to be used with AES is CBC (Cipher Block Chaining) as specified in NIST Special Publication 800-38A (2001 edition). The IV (Initialization Vector) is all zeros.

The selectable encryption method allows for an upgrade of security in the future while maintaining backwards compatibility.

The lifetime of a key is determined by the number of transmitted packets. To ensure security, key updates are triggered regularly by the RCT every N successfully transmitted packets (using the RCT’s sequence counter as reference), with N being a value which is sent from the RCT to the SPT during the initial commissioning phase.

To enforce security, a key exchange is to be triggered by the RCT at least once a week or at least every 2¹⁶ = 65536 successful packets (whichever comes first).

In addition to that regular pattern, both RCT and SPT can invoke additional key exchanges.

To avoid RCT and SPT getting out of synchronisation when an alarm message is triggered exactly in between an on-going session key exchange action, the RCT shall maintain the old session key until the first successful transmission of a packet with the new session key is acknowledged.

The timeouts (after which a message will be retried) will increase with each retry as defined in RFC793.

In addition to RFC793, the resulting time-out value is upper-bound by the reporting time of the ATP plus/minus an evenly randomly distributed time offset of 10 %.

NOTE RFC793 defines a learning algorithm, which tries to adapt to the available network capacity. To do so, it tries to calculate a best-guess of the network’s round-trip-delay time, consisting of 90 % the time of the previously used time-out value plus 10 % the round-trip-delay time of the last packet. Times a (safety) factor of 2, this value is used as the next time-out value.

The intention is to adapt to the congestion state of the network: The more the network is congested, the larger the timeout value grows, trying to avoid a flooding of the RCT in case of a network congestion.

To avoid too long a delay of a retry, this principle is upper-bound by a maximum time-out value.

Especially in case of an invent which could still lead to all SPTs trying to re-send to their RCT in parallel, the upper limit defined by the reporting time of the ATP is changed by an evenly distributed random component.

The random component shall be based on a (pseudo)random number generator which assures randomly distributed outputs from all SPTs, even if they generate the value at the same moment of time, e.g. by taking the SPT’s Device ID into the random number calculation.

The version number in the message header is an unsigned numerical byte value, indicating the version of the protocol actually being used.

It defaults to “1”, representing the first version of this protocol implementation. SPT and RCT shall mutually agree upon the protocol version to be used during the commissioning phase. The RCT may be configured to require a specified set of protocol versions and to refuse to communicate using other versions.

To allow for an RCT to send commands to an SPT without depending on properties of the network environment in between (e.g. any forwarding- or adopted firewall rules, especially on the side of the SPTs networking equipment), a mechanism for packing reverse commands into response messages is implemented.

The approach taken is to ‘piggy-pack’ an embedded reverse command in the response message. This is indicated by the flag in the header of the response message (see 5.2.9).

The Message ID and the Message Data will be added to the message as follows:

Table 8 - Reverse commands

The Message Length of the response data shall be used to determine the start position of the Embedded reverse command message.

It is still possible for an RCT to send commands asynchronously (without waiting for a poll), however, depending on the network environment this command may not reach the SPT.

The following values are used by the protocol until the variables are explicitly set by the corresponding configuration messages.

Table 9 - Initial values

6 Message types

This clause defines the messages as used in this protocol. Note that the examples show only the Message Data; Header, Message ID and Message length are not shown in the message overviews.

This clause describes the format of the poll message and its reply. A configuration message is used to negotiate the Poll Rate during commissioning. This configuration message is described in 6.4.12. The Poll Message itself does not include the Heartbeat interval time.

Path supervision works on heartbeat traffic from the SPT to the RCT.

Any other message can implicitly function as Poll Message, e.g. the polling device can reset its ‘poll interval’ timer upon sending any message, and the poll monitoring device can reset its ‘timeout’ timer upon reception of any valid message from the other end.

The Poll message has the following format:

SPT <- RCT

Table 10 - Poll message SPT -> RCT

This message is sent by the polling device in case no messages have been sent for the heartbeat interval time as negotiated by the Path supervision request/response messages (6.4.12/6.4.13) during connection setup.

The Poll response message has the following format:

RCT <- SPT

Table 11 - Poll response RCT <- -> SPT

The (alarm) event message shall always contain the actual event data. Next to this mandatory information the protocol provides the option to transmit additional information. To maintain the link between event and additional data, this data is all transmitted within one message.

To achieve this, the event message is divided into fields, each accompanied by their own length indicator.

Rationale:

fields like ‘link’ are variable length, hence the 'length’-bytes;

• to maintain a uniform format no distinction has been made between variable and fixed length fields.

The Alarm event message has the following format:

SPT RCT

Table 12 - Event message format - SPT -> RCT