---

The Field Length (L1, L2, ...) is the length of the Field Data (excluding Field Identifier and Field Length bytes).

The following fields are defined:

Table 13 - Event message format - Fields

Field numbers above 0x80 provide a link to out-of-band additional information, like for example:

• pictures accompanying the event (IP address and port number, filename);

audio or video streams

that are transmitted via a secondary channel. Note that the time fields can also be used to match events with the accompanying data.

These fields are explained in the next subclauses.

SPT: Mandatory

RCT: Mandatory

Table 14 - Event field

SPT: Optional

RCT: Mandatory

Table 15-Time event field

This field holds the timestamp on which the event occurred.

Time format is a 64 bit integer as described in RFC958 (NTP) / RFC4330 (SNTP V4), allowing easy local synchronization. Note that NTP basically uses a 32 bit counter of seconds since 1.January. 1900, so a wrap-around will occur in 2036. Due to a 136 years “precision” in guessing the correct date (either 1900, 2036, 2172, ..) suffices to re-sync for the next 136 years. This should be easily handled by the devices, but shall be taken care by a special test-case during compliance test.

This approach is independent from daylight-saving zones and independent from time-zones, as NTP returns time based on UTC, so cross-country evaluations will be easier. Such local time adoptions against UTC (e g. displaying time / entering time in human readable format) are thus left to the end­devices.

SPT: Optional

RCT: Mandatory

Table 16 - Time message field

This field holds the timestamp on which the event message is transmitted by the SPT.

This value is to be used for life-time checking of the datagrams, i.e. harden the protocol against attackers in the sense that a datagram is accepted as being valid only if it arrived at the communication partner’s end within a reasonable time (e.g. 51 h).

In addition, the difference Time event - Time message values give rises to check whether the alarm system fulfils the over-all maximum round-trip-delay times.

SPT: Optional

RCT: Optional

Table 17 - Link field - IP Address

Defines the IP Address to which the additional info will be sent to.

SPT: Optional

RCT: Optional

Table 18 - Link field - IP Port number

Defines the port number to which the additional info will be sent to.

SPT: Optional

RCT: Optional

Table 19-Link field - URL

Defines the URL to which the additional info will be sent to.

SPT: Optional

RCT: Optional

Table 20 - Link field - Filename

The filename can be used for example to identify files uploaded to a TFTP server.

The Event response message has the following format:

RCT -» SPT

Table 21 - Event response message format

This clause describes the contents of the configuration messages. For the message flow and further explanation see Clause 7.

The configuration messages are used for both commissioning methods (DTLS and ‘out-of-band’), as the messaging protocol needs the same parameters independently of how the connection was established.

Most configurable parameters are unique in the SPT for each RCT it reports to, e g.

• Connection handle;

• Device ID;

• Encryption selection;

• Session key;

• Hash;

• Path supervision.

In case the SPT reports to 2 RCTs, there will be 2 instances of each parameter, one for each connected RCT.

In case in the SPT the parameters of the RCT to which it shall connect are changed (e.g. change to another RCT), the SPT shall request new ones.

Other parameters (e.g. Time) are one value only that is used by the SPT for all RCTs it reports to.

The Connection handle request message has the following format:

SPT -» RCT

Table 22 - Connection handle request message format

This message is issued by the SPT to request a Connection handle, which is a random number. The Connection handle is created by the RCT instead of the SPT, as it has to be unique at the RCT, and the random generator of the RCT is usually of much better quality than the one of the SPTs. Both SPT and RCT use the same Connection handle.

In case the connection is broken, a next session will have a newly generated (different) Connection handle.

The Connection handle response message has the following format:

Table 23 - Connection handle response message format

This message itself and previous messages have a Connection handle with the value 0. The next message will be the first one with a valid Connection handle field.

The Device ID request message has the following format:

SPT RCT

Table 24 - Device ID request message format

This message is issued by the SPT to request a Device ID.

The following applies to allow for 2nd channel commissioning:

when the Direction and Device ID flags are set, the SPT requests the RCT Device ID, and stores this RCT Device ID as received in the reply message in NVM;

when the Direction and Device ID flags are cleared, the SPT pushes its own Device ID to the RCT.

Table 25 - Device ID request flags

The Device ID response message has the following format:Table 26 - Device ID response message format

The next message will be the first one with a valid Device ID field in the message header.

The Encryption selection request message has the following format:

SPT ROT

Table 27 - Encryption selection request message format

This message is issued during commissioning by the SPT to indicate the encryption methods it supports. See 5.5 for possible encryption methods.

Table 28 - ‘Master Encryption Selection request’ flag

The Encryption selection response message has the following format:

RCT -» SPTTable 29 - Encryption selection response message format

The Flags field holds the value 0.

The Encryption key exchange request message has the following format:

SPT <- -» RCT

Table 30 - Encryption key exchange request message format

Table 31 - ‘Master Key request’ flag

This message is issued to request an encryption key update. Both SPT and RCT can request an encryption key update. When 'Direction' flag is set (request) the Encryption key field is 0. The ‘Key Request’ flag is used only during the commission phase to exchange the new master key.

New keys are created by the RCT instead of the SPT, as they shall be generated using a cryptographically strong random number generator, and the random number generator of the RCT is usually of much better quality than the one of the SPTs.

The RCT can push a new session key to the SPT by clearing the ‘Direction’ flag. The new key is in the ‘Encryption key’ field. The SPT will then acknowledge by replying back this key in the Encryption key exchange response message.

The Encryption key exchange response message has the following format:

SPT RCT

Table 32 - Encryption key exchange response message format

The new key will become effective immediately, e.g. the next message is encrypted using the new key (in case ‘Encryption selection’ > 0). To overcome transmission errors the RCT shall keep the previous key until a next message has successfully been received, as backup.

The Hash selection request message has the following format:

SPT RCT

Table 33 - Hash selection request message format

This message is issued during commissioning by the SPT to indicate the Hash functions it supports. See 5.4 for possible hash functions.

The Hash selection response message has the following format:

RCT -» SPT

Table 34 - Hash selection response message format