Matter Handbook

https://handbook.buildwithmatter.com
Admin
The Matter Handbook provides comprehensive guidance and answers to common questions for building and...
Tokens:5,804
Snippets:19
Trust Score:9.8
Update:1 year ago
Show doc for...
Tokens:
Raw
### Matter Commissioning Node Operational Certificate (NOC) Management Commands

Source: https://handbook.buildwithmatter.com/how-it-works/commisioning

This API documentation covers the commands used by the Commissioner to install essential certificates on the Commissionee, specifically the Root Certificate and the Node Operational Certificate, which are critical for establishing trust and secure communication within the Matter fabric.

```APIDOC
AddTrustedRootCertReq command
  - Purpose: Installs the Root Certificate on the Commissionee.
  - Parameters: (Implicitly, the trusted root certificate data generated by the ADM).
  - Usage: Precedes the installation of the Node Operational Certificate to establish a chain of trust.

AddNOC command
  - Purpose: Installs the Node Operational Certificate (NOC) on the Commissionee.
  - Parameters: (Implicitly, the NOC generated by the ADM using the CSR information).
  - Usage: Follows the Root Certificate installation, enabling the Commissionee to operate securely within the Matter fabric.
```

--------------------------------

### Matter Commissioning Network Provisioning Commands

Source: https://handbook.buildwithmatter.com/how-it-works/commisioning

This API documentation details the commands used by the Commissioner to configure the operational network for Thread or Wi-Fi Commissionees. These commands facilitate scanning for available networks, adding or updating network credentials, and connecting the device to the specified network.

```APIDOC
ScanNetworks command
  - Purpose: Initiates a scan for available networks (e.g., Wi-Fi networks) that the Commissionee can connect to.
  - Parameters: (None specified, implies a general scan).
  - Usage: Used to discover potential networks before provisioning.

AddOrUpdateWifiNetwork command
  - Purpose: Adds new Wi-Fi network credentials or updates existing ones on the Commissionee.
  - Parameters:
    - SSID: The Service Set Identifier (network name).
    - Password: The password for the Wi-Fi network.
    - Security Type: The type of security used by the network (e.g., WPA2, WPA3).
  - Usage: Provides the Commissionee with the necessary credentials to join a Wi-Fi network.

ConnectNetwork command
  - Purpose: Instructs the Commissionee to connect to a previously configured or newly added network.
  - Parameters:
    - Network ID: An identifier for the network to connect to (e.g., SSID or internal ID).
  - Usage: Finalizes the network provisioning step, allowing the Commissionee to join the operational network.
```

--------------------------------

### Matter DNS-SD Discovery Protocol

Source: https://handbook.buildwithmatter.com/how-it-works/discovery

This section details the DNS-SD based discovery mechanism for Matter commissionable nodes, particularly relevant for IP-connected devices. It specifies the service instance name, host name construction, and the types of records used to convey device information.

```APIDOC
Matter DNS-SD Discovery Protocol:
  Instance Name:
    Value: `_matterc._udp`
    Description: The standard DNS-SD instance name for Matter device discovery.
  Host Name Construction:
    Format: Built by a 48-bit MAC address or a 64-bit MAC Extended Address, expressed as a hex string.
    Example: `A5F15790B0D15F32.local.`
  Record Types:
    AAAA records: Return IPv6 addresses of the device.
    DNS-SD TXT record: Returns key/value pairs containing device information.
      Key/Value Pairs Include: Discriminator, Vendor ID, Product ID.
  Commissioning Subtypes:
    Purpose: Advertised by the node to enable filtering of results for specific attributes.
  Advertisement Behavior:
    General: Only advertised when the Commissionee may be commissioned.
    Extended Discovery: May continue advertising even when not in commissioning mode.
  Thread Devices:
    Method: Use a proxied method provided by the Thread Border Router.
    Protocol: DNS-SD Service Registration Protocol (SRP) and its Advertising Proxy.
    Mechanism: Thread devices register themselves in the SRP service, which handles mDNS traffic on their behalf.
```

--------------------------------

### Matter Device Type Definitions

Source: https://handbook.buildwithmatter.com/how-it-works/device-types

This section provides definitions for various Matter device types, categorizing them by function (e.g., content, robotics, appliances, energy). Each definition describes the device's core capabilities and typical use cases, outlining how they interact within the Matter ecosystem.

```APIDOC
Content App:
  - Description: An application built by a Content Provider, launched by a Casting Video Player with a Content App Platform, represented as separate endpoints.

Casting Video Client:
  - Description: A client capable of launching content on a Casting Video Player (e.g., Smart Speaker, Content Provider phone app).

Video Remote Control:
  - Description: A client capable of controlling a Video Player (e.g., traditional universal remote control).

Robotic Vacuum Cleaner:
  - Description: A device capable of autonomous cleaning, with selectable cleaning modes and error state reporting.

Refrigerator:
  - Description: A device containing one or more cabinets for chilling or freezing food (e.g., refrigerators, freezers, wine coolers).

Temperature Controlled Cabinet:
  - Description: A component representing a single chilling/freezing cabinet, composed within another device type (e.g., refrigerator, freezer).

Room Air Conditioner:
  - Description: A device primarily controlling air temperature in a single room.

Laundry Washer:
  - Description: A device capable of laundering consumer items.

Dishwasher:
  - Description: A device for washing dishes, cutlery, etc., typically installed in residential homes, can be portable or permanent.

Laundry Dryer:
  - Description: A device capable of drying laundry items.

Cook Surface:
  - Description: A heating object on a cooktop or similar device, SHALL only be used when composed as part of another device type.

Cooktop:
  - Description: A cooking surface heating food via electromagnetic induction or traditional burners.

Oven:
  - Description: A device containing one or more cabinets, optionally a single cooktop, capable of heating food (e.g., ovens, wall ovens, convection ovens).

Extractor Hood:
  - Description: A device installed above a cooking surface to reduce odors by extracting or recirculating air, may include a light.

Microwave Oven:
  - Description: A device heating food/beverages using a magnetron, capable of start/stop and power level setting.

EVSE (Electric Vehicle Supply Equipment):
  - Description: A device allowing an EV to connect to mains electricity for charging/discharging (Vehicle to Grid/Home).

Water Heater:
  - Description: A device installed in properties to heat water for domestic use.

Solar Power:
  - Description: A device allowing monitoring and control of a solar panel array (including controller and inverter) by an Energy Management System.
```

--------------------------------

### Matter PICS Code Definitions for ANeatCluster

Source: https://handbook.buildwithmatter.com/certification/guides/pics-and-pixit

This API documentation defines the Protocol Implementation Conformance Statement (PICS) codes for a hypothetical 'ANeatCluster' within the Matter specification. Each code is a binary value indicating the presence or absence of specific features, attributes, commands, or events for both server and client implementations of the cluster. These codes are crucial for determining test applicability and gating individual test steps in certification.

```APIDOC
PICS Code Definitions for ANeatCluster:

ANC.S
  - Description: Device implements the ANC cluster as a server

ANC.S.F00
  - Description: Device implements ANC feature at bit 0 on the ANC server cluster

ANC.S.F01
  - Description: Device implements ANC feature at bit 1 on the ANC server cluster

ANC.S.A0000
  - Description: Device implements ANC attribute 0x0000 on the ANC server cluster

ANC.S.A0001
  - Description: Device implements ANC attribute 0x0001 on the ANC server cluster

ANC.S.C00.Rsp
  - Description: Device accepts ANC command 0x00 on the ANC server cluster

ANC.S.C01.Rsp
  - Description: Device accepts ANC command 0x01 on the ANC server cluster

ANC.S.C02.Tx
  - Description: Device generates ANC command response 0x02 on the ANC server cluster

ANC.S.E00
  - Description: Device generates ANC event 0x00 on the ANC server cluster

ANC.C
  - Description: Device supports an ANC client

ANC.C.F00
  - Description: Device ANC client is capable of understanding the feature with bit 0

ANC.C.F01
  - Description: Device ANC client is capable of understanding the feature with bit 1

ANC.C.A0000
  - Description: Device ANC client is capable of reading or subscribing to attribute 0x0000

ANC.C.A0001
  - Description: Device ANC client is capable of reading or subscribing to attribute 0x0001

ANC.C.C00.Rsp
  - Description: Device ANC client is capable of sending the command with id 0x00

ANC.C.C01.Rsp
  - Description: Device ANC client is capable of sending the command with id 0x01

ANC.C.C02.Tx
  - Description: Device ANC client understands the command response with id 0x02

ANC.C.E00
  - Description: Device ANC client understands the event with id 0x00
```

--------------------------------

### Matter Commissionable Node Advertisement Behavior

Source: https://handbook.buildwithmatter.com/how-it-works/discovery

This section outlines the expected advertisement behavior of Matter devices based on their primary function. It specifies whether a device should automatically announce its presence for commissioning or if it should refrain from doing so for safety or control reasons.

```APIDOC
Matter Device Advertisement Behavior:
  Primary Device Function: Locks and barriers access devices
    Automatic Announcement: No
    Reason: Automatic unprovisioned advertising of devices such as locks isn't safe.
  Primary Device Function: Most control originates from fabric (e.g., switch or light bulb)
    Automatic Announcement: Yes
    Reason: Expected behavior for devices primarily controlled by the fabric.
  Primary Device Function: Most control does not originate from fabric (e.g., dishwasher or refrigerator)
    Automatic Announcement: No
    Reason: Devices whose primary control does not originate from the fabric should not start advertising automatically.
```

--------------------------------

### Matter Operational Discovery DNS-SD Specifications

Source: https://handbook.buildwithmatter.com/how-it-works/discovery

Details the DNS-SD service type and instance naming convention for Matter operational discovery, where a commissioned node is identified. This process uses IP-based DNS-SD.

```APIDOC
Service Type: _matter._tcp.
Instance Name Format: <64-bit Fabric ID (hex)>-<64-bit Node ID (hex)>.local.
Example Instance Name: 2906C908D115D362-8FC7772401CD0696.local.
```

--------------------------------

### Matter Commissioning Regulatory Configuration Commands

Source: https://handbook.buildwithmatter.com/how-it-works/commisioning

This API documentation describes the command used by the Commissioner to configure regulatory information on the Commissionee during the Matter commissioning process. This includes setting location and country code.

```APIDOC
SetRegulatoryConfig command
  - Purpose: Configures regulatory information on the Commissionee.
  - Parameters:
    - Location: Specifies the device's location (e.g., indoor, outdoor, both).
    - Country Code: Sets the country code for regulatory compliance.
  - Usage: Executed by the Commissioner to ensure the Commissionee adheres to regional regulations.
```

--------------------------------

### Matter Commissioner Discovery DNS-SD Specifications

Source: https://handbook.buildwithmatter.com/how-it-works/discovery

Describes the DNS-SD service type, instance naming, and data exchange for Commissioner Discovery, allowing Commissionees to find and select Commissioners. This process also uses IP-based DNS-SD.

```APIDOC
Service Type: _matterd._udp
Instance Name Format: <48-bit MAC Address (hex)>.local. OR <64-bit MAC Extended Address (hex)>.local.
Example Instance Name: A5F15790B0D15F32.local.
Returned Records:
  - AAAA records: IPv6 addresses
  - TXT record: Key/value pairs including Discriminator, Vendor ID, Product ID.
  - Commissioning subtypes: For filtering results.
```

--------------------------------

### Matter Subscription Interaction API

Source: https://handbook.buildwithmatter.com/how-it-works/interaction-model

Defines the process for an Initiator to subscribe to periodic updates of an Attribute or Event from a Target, including the request, response, and associated operational restrictions.

```APIDOC
Subscription Interaction:
  Purpose: Allows an Initiator (Subscriber) to receive periodic Report Data Actions from a Target (Publisher).

  Subscribe Request Action:
    Direction: Initiator -> Target
    Description: Initiates a subscription for periodic updates.
    Contains:
      - Min Interval Floor: Minimum interval (duration) between reports.
      - Max Interval Ceiling: Maximum interval (duration) between reports.
      - Attribute Reports: List of Attributes requested for reporting.
      - Event Reports: List of Events requested for reporting.
    Flow:
      1. Target responds with a Report Data Action (Primed Published Data).
      2. Initiator acknowledges with a Status Response Action.
      3. Target sends a Subscribe Response Action upon successful acknowledgment.

  Subscribe Response Action:
    Direction: Target -> Initiator
    Description: Concludes the subscription process, confirming the negotiated parameters.
    Includes:
      - Subscription ID: An integer identifying the established subscription.
      - Min Interval: The final, negotiated minimum interval between reports.
      - Max Interval: The final, negotiated maximum interval between reports.

  Subscribe Restrictions:
    - Unicast-only: Both Subscribe Request Action and Subscribe Response Action must be unicast.
    - Consistent Subscription ID: All Report Data Actions within a Subscription Interaction must carry the same Subscription ID.
    - Termination by Subscriber: Subscriber can terminate by responding to a Report Data Action with an INACTIVE_SUBSCRIPTION status code.
    - Termination by Publisher: Publisher can terminate by simply stopping sending periodic Report Data Actions if the Subscriber does not receive a Report Data Action within the maximum negotiated interval.
```

--------------------------------

### Matter SDK Read Transaction Actions

Source: https://handbook.buildwithmatter.com/how-it-works/interaction-model

Defines the core actions involved in a Matter SDK Read Transaction, including the initial request, the data report, and the final status acknowledgment. These actions facilitate reading attribute and event data from a target node.

```APIDOC
Read Request Action:
  Direction: Initiator -> Target
  Purpose: Queries a Target node for specific attributes or events.
  Parameters:
    - Attribute Requests: A list of zero or more Paths to the Target's requested Attributes.
    - Event Requests: A list of zero or more Paths to the Target's requested Events.
  Output: Triggers the Target to assemble a Report Data Action.
  Restrictions: Unicast-only; Paths may not target a Group of Nodes.

Report Data Action:
  Direction: Target -> Initiator
  Purpose: Responds to a Read Request Action with the requested information.
  Parameters:
    - Attribute Reports: A list of zero or more reported Attributes requested in the Read Action Request.
    - Event Reports: A list of zero or more reported Events.
    - Suppress Response: A flag that determines whether the status response to this action should be suppressed.
    - Subscription ID: If this report is part of a subscribing transaction, an integer used to identify the subscription transaction.
  Restrictions: Unicast-only; Paths may not target a Group of Nodes.

Status Response Action:
  Direction: Either Target -> Initiator or Initiator -> Target
  Purpose: Acknowledges the receipt of reported data or indicates an operation failure.
  Parameters:
    - status: A field indicating operation success or a failure code.
  Usage:
    - Sent by the Initiator after receiving requested data, unless 'Suppress Response' flag is set in Report Data Action.
    - The read/report query is finished once this action is sent by the Initiator, or if Report Data Action is received with 'Suppress Response' enabled.
  Restrictions: Unicast-only; cannot be generated as a response to a groupcast.
```

--------------------------------

### Matter Speaker Control API

Source: https://handbook.buildwithmatter.com/how-it-works/device-types

Defines the API for controlling speaker functionality, including volume and mute/unmute states, using Matter clusters and attributes. It specifies the use of the On/Off cluster for mute/unmute and the Level cluster for volume adjustment, highlighting the need for a dedicated endpoint to avoid conflicts with other functionalities.

```APIDOC
Speaker Device Type Control:
  - Mute/Unmute Control:
    - Cluster: On/Off cluster
    - Attribute: OnOff (boolean)
    - Values:
      - TRUE: Volume on (not muted)
      - FALSE: Volume off (muted)
  - Volume Level Control:
    - Cluster: Level cluster
  - Endpoint Requirement:
    - A dedicated endpoint SHALL be used for speaker control to differentiate from other On/Off cluster uses (e.g., power control).
```

--------------------------------

### Matter Interaction Model Path Structure

Source: https://handbook.buildwithmatter.com/how-it-works/interaction-model

Defines the two primary structures for constructing a Path in the Matter Interaction Model. A Path specifies the precise location of an Attribute, Event, or Command within a Node's Data Model hierarchy, enabling targeted interactions. Paths can address individual nodes or groups, and support wildcard operators for flexible targeting of multiple instances.

```text
<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID>        <cluster> <attribute | event | command>
```

--------------------------------

### Invoke Transactions Protocol Specification

Source: https://handbook.buildwithmatter.com/how-it-works/interaction-model

This specification details the structure and behavior of Invoke Transactions, including the Untimed and Timed variants. It outlines the direction, purpose, parameters, and restrictions for each action involved in the transaction flow.

```APIDOC
Invoke Transactions Protocol:

1. Untimed Invoke Transaction:
   a. Invoke Request Action (Direction: Initiator -> Target)
      - Purpose: Initiates an untimed command invocation on a Target Node.
      - Parameters:
        - Invoke Requests: A list of paths to Cluster Commands, including optional arguments (Command Fields).
        - Timed Request: A flag indicating if this action is part of a Timed Invoke Transaction (false for untimed).
        - Suppress Response: A flag indicating whether the Invoke Response Action should be suppressed.
        - Interaction ID: An integer used for matching the Invoke Request Action to the Invoke Response Action.
      - Restrictions:
        - May be groupcast, but in this case, the 'Suppress Response' flag MUST be set.
        - Paths in 'Invoke Requests' may contain Groups and wildcards (only on the Endpoint field).
        - If groupcast, the transaction terminates with no response.

   b. Invoke Response Action (Direction: Target -> Initiator)
      - Purpose: Finalizes an untimed Invoke Transaction by providing command results.
      - Parameters:
        - Invoke Responses: A list of command responses or status for every invoke request sent.
        - Interaction ID: An integer used for matching the Invoke Response Action to the Invoke Request Action.

2. Timed Invoke Transaction:
   a. Timed Request Action (Direction: Initiator -> Target)
      - Purpose: Starts a timed transaction, defining a validity period for subsequent actions.
      - Parameters:
        - Timeout: The duration (in milliseconds) for which this transaction may remain open.
      - Acknowledgment: The Target MUST acknowledge with a Status Response Action. The Initiator proceeds upon receiving a Status Response Action reporting no errors.
      - Restrictions: Unicast-only.

   b. Invoke Request Action (Direction: Initiator -> Target)
      - Purpose: Same as the Untimed Invoke Request Action, but within a timed context.
      - Parameters: (Same as Untimed Invoke Request Action)
      - Restrictions: Unicast-only. Supports paths with Groups and wildcards.

   c. Invoke Response Action (Direction: Target -> Initiator)
      - Purpose: Same as the Untimed Invoke Response Action, but within a timed context.
      - Parameters: (Same as Untimed Invoke Response Action)
      - Restrictions: Unicast-only. Does NOT support wildcard usage in paths.
```

--------------------------------

### Matter Bluetooth Low Energy (BLE) Discovery Protocol

Source: https://handbook.buildwithmatter.com/how-it-works/discovery

This section describes the BLE-based discovery mechanism for Matter commissionable nodes. It details the advertising roles, frequencies, and channels used by the Commissionee and the scanning behavior of the Commissioner.

```APIDOC
Matter BLE Discovery Protocol:
  Commissionee Role:
    Implements: Generic Access Profile (GAP) peripheral interface.
    Advertises: Uncommissioned state periodically.
    Advertisement Frequency:
      First 30 seconds: High frequency (20 to 60 milliseconds intervals).
      After 30 seconds: Low frequency (150 to 1500 millisecond intervals).
    Behavior after Commissioning: Must stop BLE advertisement when commissioned to its first fabric.
  Commissioner Role:
    Scan Type: Passive scan (does not issue scan requests).
    Scan Channels: BLE advertising channels 37 (2402 MHz), 38 (2426 MHz), and 39 (2480 MHz).
    Note: BLE is not used for operational discovery.
```

--------------------------------

### Matter Commissionable Node Advertisement Data Fields

Source: https://handbook.buildwithmatter.com/how-it-works/discovery

This section specifies the mandatory and optional data fields that a commissionable Matter node advertises during discovery. These fields are crucial for identifying and provisioning the correct device during the commissioning process.

```APIDOC
Matter Advertisement Data Fields:
  Discriminator:
    Length: 12 bit
    Required: Yes
    Description: Mandatory field crucial for provisioning the correct device, especially when multiple identical devices are present.
  Vendor ID:
    Length: 16 bit
    Required: No
    Description: Optional identifier for the device vendor.
  Product ID:
    Length: 16 bit
    Required: No
    Description: Optional identifier for the device product.
  Extended data:
    Length: variable
    Required: No
    Description: May be used to encode custom vendor-specific information.
```

--------------------------------

### Matter Write Transactions API (Untimed and Timed)

Source: https://handbook.buildwithmatter.com/how-it-works/interaction-model

Describes the mechanisms for an Initiator to write (change) Attribute values on a Target, covering both immediate (untimed) and time-constrained (timed) transaction types.

```APIDOC
Write Transactions:
  Purpose: Enables an Initiator to modify Attribute values on a Target.

  Untimed Write Transaction:
    Write Request Action:
      Direction: Initiator -> Target
      Description: Requests an immediate write operation.
      Provides:
        - Write Requests: A list of tuples, each containing a Path and the data to write.
        - Timed Request: A flag indicating if this is part of a Timed Write Transaction (false for untimed).
        - Suppress Response: A flag to suppress the Status Response Action.
      Restrictions:
        - Groupcast: May be groupcast if 'Suppress Response' flag is set (to prevent network flooding).
        - Path Wildcards: Paths in 'Write Requests' may contain Groups or wildcards (only on the Endpoint field).

    Write Response Action:
      Direction: Target -> Initiator
      Description: Concludes the untimed write transaction.
      Carries:
        - Write Responses: A list of paths and error codes for each Write Request.

  Timed Write Transaction:
    Purpose: Adds a time-bound window for the subsequent Write Request Action.

    Timed Request Action:
      Direction: Initiator -> Target
      Description: Initiates a timed transaction, setting a validity window.
      Contains:
        - Timeout: Duration (in milliseconds) for which the transaction remains open and subsequent actions are considered valid.
      Flow:
        1. Target acknowledges with a Status Response Action.
        2. Initiator sends a Write Request Action upon successful acknowledgment.
      Restrictions:
        - Unicast-only: Must be unicast.

    Write Request Action:
      Description: Same as the Write Request Action described for Untimed Write Transaction.
      Restrictions:
        - Unicast-only: Must be unicast within a Timed Write Transaction.

    Write Response Action:
      Description: Same as the Write Response Action described for Untimed Write Transaction.
      Restrictions:
        - Unicast-only: Must be unicast within a Timed Write Transaction.
```

--------------------------------

### Public Observer Node API Endpoints

Source: https://handbook.buildwithmatter.com/guides/dcl

Details of public Observer Nodes (ONs) providing API access to the Distributed Compliance Ledger (DCL) for both Main-Net and Test-Net environments. These nodes offer REST, RPC, and gRPC interfaces with specified URLs and port numbers.

```APIDOC
Main-Net Public Observer Nodes:
  - Host Owner: The Alliance
    Region: US, EU
    Web User Interface: https://webui.dcl.csa-iot.org
    URL for API: on.dcl.csa-iot.org
    REST Port: 443
    RPC Port: 26657
    gRPC Port: 8443
  - Host Owner: TrustAsia
    Region: CN
    Web User Interface: https://main-net.trustasia.com
    URL for API: on.main-net.trustasia.com
    REST Port: 443
    RPC Port: 26657
    gRPC Port: 8443
  - Host Owner: Tuya
    Region: CN
    Web User Interface: N/A
    URL for API: on-dcl.tuyacn.com
    REST Port: 1317
    RPC Port: 26657
    gRPC Port: 9090

Test-Net Public Observer Nodes:
  - Host Owner: The Alliance
    Region: US, EU
    Web User Interface: https://testnet.iotledger.io
    URL for API: on.test-net.dcl.csa-iot.org
    REST Port: 443
    RPC Port: 26657
    gRPC Port: 8443
  - Host Owner: TrustAsia
    Region: CN
    Web User Interface: https://test-net.trustasia.com
    URL for API: on.test-net.trustasia.com
    REST Port: 443
    RPC Port: 26657
    gRPC Port: 8443
  - Host Owner: Tuya
    Region: CN
    Web User Interface: N/A
    URL for API: on-dcl-testnet.tuyacn.com
    REST Port: 1317
    RPC Port: 26657
    gRPC Port: 9090
```

--------------------------------

### Matter IPv6 Multicast Address Structure

Source: https://handbook.buildwithmatter.com/how-it-works/thread

Defines the format of a Matter IPv6 Multicast address, which allows simultaneous control of several Matter Nodes. This address is constructed based on the IPv6 Unicast prefix and includes the Fabric ID and Group ID, ensuring multicast scope within a specific Matter Fabric.

```APIDOC
Matter IPv6 Multicast Address Format:

FF35:0040:FD<Fabric ID>00:<Group ID>

Construction Details:
- Bits 0-11: 0xFF3 (Fixed prefix)
- Bits 12-15: 0x05 (Scope: site-local)
- Bits 16-23: 0x00 (Reserved)
- Bits 24-31: 0x40 (Indicates a 64-bit long prefix)
- Bits 32-39: 0xFD (Designates a ULA prefix)
- Bits 40-95: Fabric ID (56 bits)
- Bits 96-103: 0x00 (Fixed value)
- Bits 104-119: Group ID (16 bits)
```
Tokens:
Raw