3.2.6. Association Command Class, version 4

The Association Command Class version 4 introduces the capability to discover the highest security class of a target when issuing unsolicited supporting commands (unsolicited Reports and Notifications) via association groups.

3.2.6.1. Compatibility Considerations

\requirement{CC:0085.04.00.21.001}{4}

If a node supports the version 4 of this Command Class and the Multi Channel Association Command Class, it MUST support the Multi Channel Association Command Class, version 5 or newer.

3.2.6.2. Interoperability Considerations

\requirement{CC:0085.04.00.31.001}{0}

Any supporting node MUST learn the granted security classes of a destination before sending controlling or unsolicited supporting commands to a destination via association groups.

\requirement{CC:0085.04.00.32.002}{0}

The learned security class SHOULD be saved in the device after a successful learn process to prevent further learn process.

The discovery is considered to be failed if the destination node did not respond on any security class nor non-securely.

\requirement{CC:0085.04.00.31.007}{0} \requirement{CC:0085.04.00.32.003}{4}

If the discovery fails, the discovery MUST be marked as incomplete and the discovery SHOULD be attempted later.

The supporting node is allowed to use the learned security class to send unsolicited supporting commands on a level lower that its own highest security class.

\requirement{CC:0085.04.00.31.008}{4}

The learned security level can be used only to send unsolicited supporting commands or control commands (Set, see Section 3.2.5.2). The supporting node MUST NOT reply on control commands (with a Report on a Get command) on lower security class than its highest security class even if a lower security class is used for sending unsolicited supporting commands.

Commands are marked as controlling or supporting in [26].

The discovery process is the same for the discovery of control commands (Set commands, see Section 3.2.5.2) and for unsolicited supporting commands.

\requirement{CC:0085.04.00.32.001}{0}

The following discovery is RECOMMENDED:

  1. If the destination node B previously used to send a command on the sender node A’s highest level, node A MUST use this level for sending unsolicited supporting commands to node B

  2. Request the NIF and read its contents, look for S2/Supervision and S0

  3. If S2 is supported, for every granted S2 key starting from the highest:

    1. Issue the S2 encrypted controlling or unsolicited supporting command using Supervision Get encapsulation (and Multi Channel encapsulation if End Point source or destination).

    2. If receiving a Supervision Report, stop the discovery and use the current S2 Security Class for controlling or sending unsolicited supporting commands to the target NodeID.

    3. Else if no answer is returned (or S2 Nonce Reports), proceed with a lower granted S2 key.

  4. If S0 is supported, try using S0:

    1. If S2 was in the NIF :

      1. Issue the S0 encrypted controlling or unsolicited supporting command using Supervision Get encapsulation

      2. If receiving a Supervision Report, stop the discovery and use S0 as the Security Class for controlling or sending unsolicited supporting commands to the target NodeID

    2. If S2 was not in the NIF:

      1. Issue a S0 encrypted S0 Security Command Supported Get command

      2. If receiving S0 encrypted S0 Security Command Supported Report command, stop the discovery and use S0 for controlling or sending unsolicited supporting commands to the target NodeID

  5. Settle for non-secure level if no Security Class was found. Supervision encapsulation MAY be used non-securely only if it was in the NIF.

\requirement{CC:0085.04.00.33.001}{0}

A supporting node MAY use another algorithm using the following assumptions:

\requirement{CC:0085.04.00.31.003}{0}

  • A controlling node MUST NOT associate Node A to a Node B destination if Node A was not granted Node B’s highest Security Class.

Role Type Specification provides recommended timeouts when waiting for responses to Get type commands.

Further, when issuing (supporting or controlling) commands via an association group:

\requirement{CC:0085.04.00.31.004}{0}

\requirement{CC:0085.04.00.33.002}{0}

  • A supporting node MAY use Supervision encapsulation if the destination supports the Supervision Command Class

\requirement{CC:0085.04.00.31.006}{0}

  • If the destination supports the Supervision Command Class, a supporting node MUST use Supervision encapsulation to send Access Control-related reports, Access Control-related control commands and critical sensors and notifications reports (defined by the manufacturer).

\requirement{CC:0085.04.00.32.004}{0}

  • The sender SHOULD implement an algorithm to retry up to three times on no reply to a supervised command.

\requirement{CC:0085.04.00.31.005}{0}

  • A supporting node MUST NOT use Multi Command encapsulation if the destination does not support the Multi Command Command Class.