Chapter 4 - Part 5

Discover Gateway

In the previous lesson, we examined operational discovery, and continuing the principles of learning the Matter protocol, we intend to teach the topic of operational discovery in this lesson.

Gateway discovery

A gateway may initiate the setup process by discovering gateways on the network. This may be done using the GitHub discovery described in this section.

With gateway discovery, a gateway, after interacting with a user, may discover gateways on the network and obtain a list of information for each of them, which may include vendor ID, product ID, and device name. A gateway with a user interface, such as a TV set, thermostat, or video player, may display a list of discovered items for the user to choose from. Once selected, Gateway may use the User Directed Commissioning Protocol with Gateway to indicate that the User has selected it to set up Gateway. Therefore, the records of the GitHub discovery service enable a form of the “doorbell” protocol to allow GitHub to request startup.

Examples

The following examples simulate the theme GitHub ads that exist on the network. Examples are shown using the dns-sd command-line test tool and the avahi command-line test. The dns-sd command line test tool is included in all versions of macOS. It installs as a DOS command with Bonjour for Windows and is available on Linux by installing the mDNSResponder package. The avahi command-line testing tool from the Avahi project is available for most Linux distributions.

Consider a device on Wi-Fi that uses the MAC address of the 48-bit device B75AFB458ECD as its hostname. DNS-SD records for can be set as follows:

or

Common TXT key/value pairs

TXT records provided during Gateway, Operational, and Gateway discovery may contain the following optional key/value pairs common to each discovery method:

The optional SII key indicates the SLEEPY_IDLE_INTERVAL node. This key may optionally be provided by a node to override defaults. If the key is not included or is invalid, the node querying the service record MUST use the default SED parameter value. The SII value is an unsigned integer with units of milliseconds and 

must be encoded as a variable-length decimal number in ASCII encoding, omitting leading zeros. SII value should not exceed 3600000 (1 hour per millisecond)

For example: SII=5300 to override the initial retry interval value to 5.3 seconds.

The optional SAI key indicates the SLEEPY_ACTIVE_INTERVAL node. This key may optionally be provided by a node to override SED defaults. If the key is not included or is invalid, the service record query node MUST use the default MRP parameter value. The SAI value is an unsigned integer with units of milliseconds and must be encoded as a variable-length decimal number in ASCII encoding, omitting leading zeros. SAI value should not exceed 3600000 (1 hour per millisecond)

Example: SAI=1250 to override the active retry interval value to 1.25 seconds

The optional T key indicates whether the node supports TCP. This key may optionally be provided by a node that does not support TCP. If the key is not included or is invalid, the node querying the service record MUST assume the default value of T=0, indicating that TCP is not supported. The T key, if present, must have one of two valid values: '0' to indicate “TCP is not supported ”, or “1 ” to indicate “TCP is supported”.

Example: T=1 for TCP announcement supported by advertising node.

Message frame format

This section describes the encoding of the Matter message format. The Matter message format provides flexible support for various communication paradigms, including secure unicast sessions, multicast group messaging, and session creation. The process of encrypting Matter messages is the same in all communication modes and assumes that symmetric keys are shared between communicating parties. Unencrypted messages are only used for protocols that initiate secure messages, such as session establishment.

Matter messages are used by Matter applications as well as the Matter protocol stack itself to transfer application-specific data and/or commands. The Protocol section of a Matter message contains the Protocol Identifier and the Protocol Opcode, which specify both the semantic meaning of the message and the structure of any associated application payload data. Matter messages also carry an Exchange Identifier that associates the message with a specific exchange taking place between two nodes. Finally, certain types of Matter messages can convey information that acknowledges receipt of a previous message. It is used as part of the Message Reliability Protocol to provide guaranteed delivery of messages over unreliable transmission.

The structure of Matter messages is as follows:

Note: The sign [] indicates that the field is optional.

The message payload in a Matter message must contain the protocol message in the following format:

Description of the message header field

• Message length (16 bits)
• Message flags (8 bits)
• Session ID (16 bits)
• Security flags (8 bits)
• message counter (32 bits)
• source node ID (64 bits) destination node ID
• message plugin variable

Description of the footer part of the message

• Checking the integrity of the message (variable length) is done in this part.

Protocol header field description

• flag exchange (8 bits)
• Protocol Opcode (8 bits)
• exchange ID (16 bits)
• Protocol ID (16 bits)
• protocol vendor ID (16 bits)
• Confirmed message counter (32 bits)
• Secure extensions (variable)
• program load (variable length)

Message size requirements

Support for IPv6 fragmentation is not mandatory in Matter, and the expected MTU supported is 1280 bytes, which is the minimum IPv6 requirement. Therefore, all messages, including transport headers, must fit within that minimum IPv6 MTU. This message size limit should apply to UDP transport. A message received via UDP that exceeds this message size limit will not be processed. Messages sent over TCP or BTP over BLE transport may exceed the message size limit if both nodes are capable of supporting a larger message size.

In this lesson, we got acquainted with the topic of Gateway and learned its various examples. In the next section, we will discuss the topic of message counters and the details of this issue. Stay with us.