From f34c07fd6cf227cb760035a315a749b39a539b92 Mon Sep 17 00:00:00 2001 From: sammachin Date: Tue, 30 Jan 2024 14:07:04 +0000 Subject: [PATCH] =?UTF-8?q?Deploy=20preview=20for=20PR=204=20=F0=9F=9B=AB?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- pr-preview/pr-4/404.html | 2 +- pr-preview/pr-4/alliance/howwework/index.html | 26 ++++++++--------- pr-preview/pr-4/alliance/index.html | 26 ++++++++--------- .../pr-4/alliance/membership/index.html | 26 ++++++++--------- pr-preview/pr-4/alliance/resources/index.html | 26 ++++++++--------- pr-preview/pr-4/alliance/whatwedo/index.html | 26 ++++++++--------- pr-preview/pr-4/categories/index.html | 26 ++++++++--------- .../pr-4/howitworks/attestation/index.html | 26 ++++++++--------- .../pr-4/howitworks/commisioning/index.html | 26 ++++++++--------- .../connectivitytransports/index.html | 26 ++++++++--------- .../pr-4/howitworks/datamodel/index.html | 26 ++++++++--------- .../pr-4/howitworks/devicetypes/index.html | 26 ++++++++--------- .../pr-4/howitworks/discovery/index.html | 28 +++++++++---------- pr-preview/pr-4/howitworks/fabric/index.html | 26 ++++++++--------- pr-preview/pr-4/howitworks/index.html | 26 ++++++++--------- pr-preview/pr-4/howitworks/index.xml | 2 +- .../howitworks/interactionmodel/index.html | 26 ++++++++--------- pr-preview/pr-4/howitworks/roles/index.html | 26 ++++++++--------- .../pr-4/howitworks/security/index.html | 26 ++++++++--------- pr-preview/pr-4/howitworks/thread/index.html | 26 ++++++++--------- .../pr-4/howitworks/whatismatter/index.html | 26 ++++++++--------- pr-preview/pr-4/index.html | 24 ++++++++-------- pr-preview/pr-4/index.xml | 2 +- pr-preview/pr-4/sdk/index.html | 26 ++++++++--------- pr-preview/pr-4/specification/index.html | 26 ++++++++--------- pr-preview/pr-4/tags/index.html | 26 ++++++++--------- 26 files changed, 302 insertions(+), 302 deletions(-) diff --git a/pr-preview/pr-4/404.html b/pr-preview/pr-4/404.html index 988c4dd..adaffb8 100644 --- a/pr-preview/pr-4/404.html +++ b/pr-preview/pr-4/404.html @@ -1 +1 @@ -404 Page not found

Error

Woops. Looks like this page doesn't exist ¯\_(ツ)_/¯.

Go to homepage

Page not found!

\ No newline at end of file +404 Page not found

Error

Woops. Looks like this page doesn't exist ¯\_(ツ)_/¯.

Go to homepage

Page not found!

\ No newline at end of file diff --git a/pr-preview/pr-4/alliance/howwework/index.html b/pr-preview/pr-4/alliance/howwework/index.html index 1fd3e60..0ace25c 100644 --- a/pr-preview/pr-4/alliance/howwework/index.html +++ b/pr-preview/pr-4/alliance/howwework/index.html @@ -1,20 +1,20 @@ -How We Work - Matter

How We Work

Working Groups

The Alliance has a number of Working Groups responsible for each of the different standards that we manage.

Matter is one such Working Group, the WG is governed by a Steering Committee. The SC manages overall activities, priorities, scope & budget of the Working Group.

Beneath the Matter Working Group are 3 Sub Groups:

Marketing and Product Sub Group

The Marketing and Product Sub Group (MPSG) is responsible for capturing use cases, identifying functional/non-functional requirements, and producing marketing requirements documents (MRDs) for hand-over to the Technical Sub Group. They also develop branding, positioning and external communications materials relating to Matter.

Technical Sub Group

The Technical Sub Group (TSG) develops the technical aspects of the Matter from the requirements given to them and takes this through specification release. -The Matter TSG also has an active Software Development Tiger Team who maintain and develop the open source Matter SDK.

Certification Sub Group

The Certification Sub Group (CSG) develops methods to test for specification conformance, from test cases & scripts, to test events leading up to specification release.

Tiger Teams

Additionally each Sub Group forms a number of Tiger Teams to focus on a specific topic or item and feed this work up into the sub group. Some teams are ongoing, others are formed for the purpose of a specific deliverable and then dissolved.

Joining

Membership of each working group is open to a member company holding participant or promoter level membership. Once a member company has formally joined a WG then employees of that company can participate in the sub groups and tiger teams.

- - - - - - - - +The Matter TSG also has an active Software Development Tiger Team who maintain and develop the open source Matter SDK.

Certification Sub Group

The Certification Sub Group (CSG) develops methods to test for specification conformance, from test cases & scripts, to test events leading up to specification release.

Tiger Teams

Additionally each Sub Group forms a number of Tiger Teams to focus on a specific topic or item and feed this work up into the sub group. Some teams are ongoing, others are formed for the purpose of a specific deliverable and then dissolved.

Joining

Membership of each working group is open to a member company holding participant or promoter level membership. Once a member company has formally joined a WG then employees of that company can participate in the sub groups and tiger teams.

+ + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/alliance/index.html b/pr-preview/pr-4/alliance/index.html index c9bfefe..9820719 100644 --- a/pr-preview/pr-4/alliance/index.html +++ b/pr-preview/pr-4/alliance/index.html @@ -1,17 +1,17 @@ -The Alliance - Matter

The Connectivity Standards Alliance

Our wide-ranging global membership is on a mission. That mission is to ignite creativity and collaboration in the Internet of Things, by developing, evolving, and promoting universal open standards that enable all objects to securely connect and interact. We believe all objects can work together to enhance the way we live, work, and play. Learn more

The Alliance is the owner of the Matter specification and its associated marks. We are responsible for the continued development of the specification, the certification of products, and the promotion of Matter.

The Alliance is a member driven organization. The majority of the work on Matter is done by members with the support of their companies, and the Alliance employs a relatively small full time staff to facilitate, co-ordinate and support this work.

- - - - - - - - +The Alliance

The Connectivity Standards Alliance

Our wide-ranging global membership is on a mission. That mission is to ignite creativity and collaboration in the Internet of Things, by developing, evolving, and promoting universal open standards that enable all objects to securely connect and interact. We believe all objects can work together to enhance the way we live, work, and play. Learn more

The Alliance is the owner of the Matter specification and its associated marks. We are responsible for the continued development of the specification, the certification of products, and the promotion of Matter.

The Alliance is a member driven organization. The majority of the work on Matter is done by members with the support of their companies, and the Alliance employs a relatively small full time staff to facilitate, co-ordinate and support this work.

+ + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/alliance/membership/index.html b/pr-preview/pr-4/alliance/membership/index.html index 12928b5..ce8eddb 100644 --- a/pr-preview/pr-4/alliance/membership/index.html +++ b/pr-preview/pr-4/alliance/membership/index.html @@ -1,18 +1,18 @@ -Membership - Matter

Membership

Join The Alliance

Work with the world’s most innovative companies to create, evolve, and promote universal open standards that connect all IoT devices – regardless of country, network, brand, or function – for a unifying wireless experience that inspires new possibilities for people everywhere.

Membership at a Glance

Curious about which level is right for your company? Below is an overview of the four types of membership available:

Associate Members use standards-based IoT products but do not directly build or manufacture them. To join at the Associate level and certify white-label products, a company must partner with an Alliance Participant or Promoter member through our Certification Transfer Program.

Adopter Members use existing, approved specifications to build products. Adopters can access completed, approved standards documents, certify products through Alliance certification programs, and use Alliance technology logos and trademarks for certified products.

Participant Members contribute to and develop standards they will later adopt and use. Participants can access Alliance Working Groups, are hands-on in developing specifications, and gain early access to draft specifications and testing, with the opportunity to develop and get to market faster.

Promoter Members contribute to, develop, and adopt Alliance standards and enjoy all other member-level benefits. Promoters help lead the Alliance with final approval on all standards, hold a seat on the Alliance Board of Directors, and may lead and participate in Board Committees.

Learn more about how you can join us today!

- - - - - - - - +Membership

Membership

Join The Alliance

Work with the world’s most innovative companies to create, evolve, and promote universal open standards that connect all IoT devices – regardless of country, network, brand, or function – for a unifying wireless experience that inspires new possibilities for people everywhere.

Membership at a Glance

Curious about which level is right for your company? Below is an overview of the four types of membership available:

Associate Members use standards-based IoT products but do not directly build or manufacture them. To join at the Associate level and certify white-label products, a company must partner with an Alliance Participant or Promoter member through our Certification Transfer Program.

Adopter Members use existing, approved specifications to build products. Adopters can access completed, approved standards documents, certify products through Alliance certification programs, and use Alliance technology logos and trademarks for certified products.

Participant Members contribute to and develop standards they will later adopt and use. Participants can access Alliance Working Groups, are hands-on in developing specifications, and gain early access to draft specifications and testing, with the opportunity to develop and get to market faster.

Promoter Members contribute to, develop, and adopt Alliance standards and enjoy all other member-level benefits. Promoters help lead the Alliance with final approval on all standards, hold a seat on the Alliance Board of Directors, and may lead and participate in Board Committees.

Learn more about how you can join us today!

+ + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/alliance/resources/index.html b/pr-preview/pr-4/alliance/resources/index.html index 8e28f26..03f2457 100644 --- a/pr-preview/pr-4/alliance/resources/index.html +++ b/pr-preview/pr-4/alliance/resources/index.html @@ -1,18 +1,18 @@ -Resources - Matter

Resources

Resources for Members

If you are already a member of the Alliance, here are some helpful links found in Causeway (you’ll need to log in with your member credentials).

New Member Orientation

Subgroups

Tools

- - - - - - - - +Resources

Resources

Resources for Members

If you are already a member of the Alliance, here are some helpful links found in Causeway (you’ll need to log in with your member credentials).

New Member Orientation

Subgroups

Tools

+ + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/alliance/whatwedo/index.html b/pr-preview/pr-4/alliance/whatwedo/index.html index c8ec96a..8846afb 100644 --- a/pr-preview/pr-4/alliance/whatwedo/index.html +++ b/pr-preview/pr-4/alliance/whatwedo/index.html @@ -1,18 +1,18 @@ -What We Do - Matter

What We Do

Develop

We create, evolve, and manage IoT technology standards through a well-established, collaborative process. We empower companies with practical, usable assets and tools to ease and accelerate development, freeing them to focus on new areas of IoT innovation.

Certify

Our strong certification programs help Members avoid unnecessary development cycles, ensure compliance, and validate interoperability. Certification and our stamp of approval tell the world they can buy and use Alliance-certified products and platforms with confidence.

Promote

We are allies for a connected future. Our membership, spanning the globe and the IoT value chain, actively seeks to promote the benefits of global, open standards, the value of the IoT to customers and consumers, and to break down the barriers to broad access and adoption of IoT technologies and solutions.

- - - - - - - - +What We Do

What We Do

Develop

We create, evolve, and manage IoT technology standards through a well-established, collaborative process. We empower companies with practical, usable assets and tools to ease and accelerate development, freeing them to focus on new areas of IoT innovation.

Certify

Our strong certification programs help Members avoid unnecessary development cycles, ensure compliance, and validate interoperability. Certification and our stamp of approval tell the world they can buy and use Alliance-certified products and platforms with confidence.

Promote

We are allies for a connected future. Our membership, spanning the globe and the IoT value chain, actively seeks to promote the benefits of global, open standards, the value of the IoT to customers and consumers, and to break down the barriers to broad access and adoption of IoT technologies and solutions.

+ + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/categories/index.html b/pr-preview/pr-4/categories/index.html index fdabfb5..445a930 100644 --- a/pr-preview/pr-4/categories/index.html +++ b/pr-preview/pr-4/categories/index.html @@ -1,18 +1,18 @@ -Categories - Matter

category :: -Categories

    - - - - - - - - +Categories
    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/attestation/index.html b/pr-preview/pr-4/howitworks/attestation/index.html index 71c6a03..e76bb3c 100644 --- a/pr-preview/pr-4/howitworks/attestation/index.html +++ b/pr-preview/pr-4/howitworks/attestation/index.html @@ -1,19 +1,19 @@ -Attestation - Matter

    Attestation

    Certified Devices are Devices that have gone through the Connectivity Standards Alliance (Alliance) Matter Certification Process.

    During the commissioning process, a device cryptographically proves (attests) to the commissioner that:

    • it is a genuine product
    • it is a product that passed Matter compliance tests and has been thus certified by CSA.

    In order to accomplish those goals, the device carries:

    • A Device Attestation Certificate (DAC) that conveys device’s manufacturer ID (VID) and product ID (PID). The DAC chains up to a set of trusted roots, approved by CSA members.
    • A securely-stored, private key associated with the public key stored in the DAC that proves the device owns this unique certificate.
    • Certificate declaration is a statement cryptographically signed by CSA that states that a tuple (VID,PID) has passed Matter compliance tests.

    During the development phase, the manufacturer is able test their Devices without the full Attestation process. Testers should be explicitly informed that the Device is under testing, and it hasn’t yet been certified and launched. Once a manufacturer enters a production phase, the ecosystem of the provisioner should enforce all Attestation requirements.

    Attestation uses a Public Key Infrastructure (PKI) that leverages Root Certificate Authorities and Intermediate Certificates, in a similar way to the widely adopted server authentication certificates used for SSL/TLS. This process is called the Device Attestation Certificate Chain.

    Device Attestation PKI

    The DAC is a X.509 v3 certificate. The first version of X.509 was published in 1988 by ITU-T. The X.509 v3 with Public Key Infrastructure Certificate and Certificate Revocation List (CRL) used by Matter is specified by RFC5280. It contains:

    • Public Key
    • Issuer
    • Subject
    • Certificate Serial Number
    • Validity, where expiration can be indeterminate
    • Signature
    • Vendor ID and Product ID are attributes of the MatterDACName in the DAC subject.

    The DAC is unique per device and associated with the unique attestation key pair within the product. It is issued by a CA associated with the Device manufacturer.

    The DAC’s signature is validated against the Product Attestation Intermediate Certificate (PAI), which is also issued by a PAA. However, a vendor might choose to create one PAI per product (PID-specific), group of products, or for all its products.

    At the root of the chain of trust, the Product Attestation Authority (PAA) Certificate Authority (CA) public key validates signatures from the PAI. Note that the Matter trust store is federated and the set of PAA certificates trusted by commissioners is maintained in a central trusted database (the Distributed Compliance Ledger). Entry of a PAA within the trusted set requires meeting a certificate policy managed by the Alliance.

    Matter Attestation Public Key Infrastructure

    The PAI is also a X.509 v3 certificate that includes:

    • Public Key
    • Issuer
    • Subject
    • Certificate Serial Number
    • Validity, where expiration can be indeterminate
    • Signature
    • Vendor ID and Product ID (optionally) are attributes of the MatterDACName in the DAC subject.

    Lastly, the PAA is the root certificate in the chain and it is self-signed. It includes:

    • Signature
    • Public Key
    • Issuer
    • Subject
    • Certificate Serial Number
    • Validity

    Additional Attestation Documents & Messages

    The attestation process has several documents and messages. The following items are a brief overview of their function and composition. The image below aids in the understanding of their hierarchy.

    Attestation Document Hierarchy

    Certification Declaration (CD)

    The CD allows the Matter device to prove its compliance with the Matter protocol. Whenever the Matter Certification Processes finishes, the Alliance creates a CD for the device type so the Vendor might include it in the firmware. The CD includes among other information:

    • VID
    • PID (one or more)
    • Server Category ID
    • Client Category ID
    • Security Level
    • Security Information
    • Certification Type (development, provisional, or official)
    • Signature

    Firmware Information (optional)

    The Firmware Information contains the CD Version Number and one or more digests of components in the firmware, such as the OS, filesystem, bootloader. The digests may be either a hash of the software components or a hash of the signed manifests of the software components.

    The vendor might as well choose to include in Firmware Information only the “hash-of-hashes” of its components, instead of an array of individual hashes.

    Firmware Information is an optional element in the Attestation Process and applicable when a vendor has a secure boot environment which handles the Attestation key pair.

    Attestation Information

    Message sent from the Commissionee to the Commissioner. The Attestation Information combines a TLV containing the Attestation Elements and a Attestation Signature. -Attestation Elements

    This is a TLV containing:

    • Certificate Declaration
    • Timestamp
    • Attestation Nonce
    • Firmware Information (optional)
    • Vendor Specific information (optional)

    Attestation Challenge

    Out-of-band challenge derived during Passcode Authenticated Session Establishment (PASE)/ Certificate Authenticated Session Establishment (CASE) session establishment and used to further secure the procedure and avoid replayed signatures. Comes from either CASE session, PASE session or a resumed CASE session.

    Attestation TBS (to be signed)

    Message containing the Attestation Elements and Attestation Challenge.

    Attestation Signature

    Signature of the Attestation TBS, signed using the Device Attestation Private Key.

    Attestation Procedure

    The Commissioner is responsible for attesting the Commissionee. It executes the following steps:

    1. Commissioner generates a random 32 byte attestation nonce. In cryptography jargon, a nonce (number used once) is a random number generated in the cryptographic procedure and meant to be used once.
    2. Commissioner sends the nonce to the Commissionee and requests the Attestation Information.
    3. DUT generates the Attestation Information and signs it with the Attestation Private Key.
    4. Commissioner recovers the DAC and PAI certificate from the Device, and looks up the PAA certificate from its Matter trust store.
    5. Commissioner validates the Attestation Information. These are the conditions for validation:
      • DAC certificate chain must be validated, including revocation checks on the PAI and PAA.
      • VID on the DAC matches the VID on the PAI.
      • The Attestation Signature is valid.
      • Nonce in Device Attestation Elements matches the nonce provided by the Commissioner.
      • Certificate Declaration Signature is valid using one of the Alliance’s well-known Certification Declaration signing keys.
      • Firmware Information (if present and supported by Commissioner) matches an entry in the Distributed Compliance Ledger.
      • Additional VID/PID validations also take place between the Device Basic Information Cluster, Certification Declaration and the DAC.

    This content was originally published on the Google Developer Site

    - - - - - - - - +Attestation Elements

    This is a TLV containing:

    Attestation Challenge

    Out-of-band challenge derived during Passcode Authenticated Session Establishment (PASE)/ Certificate Authenticated Session Establishment (CASE) session establishment and used to further secure the procedure and avoid replayed signatures. Comes from either CASE session, PASE session or a resumed CASE session.

    Attestation TBS (to be signed)

    Message containing the Attestation Elements and Attestation Challenge.

    Attestation Signature

    Signature of the Attestation TBS, signed using the Device Attestation Private Key.

    Attestation Procedure

    The Commissioner is responsible for attesting the Commissionee. It executes the following steps:

    1. Commissioner generates a random 32 byte attestation nonce. In cryptography jargon, a nonce (number used once) is a random number generated in the cryptographic procedure and meant to be used once.
    2. Commissioner sends the nonce to the Commissionee and requests the Attestation Information.
    3. DUT generates the Attestation Information and signs it with the Attestation Private Key.
    4. Commissioner recovers the DAC and PAI certificate from the Device, and looks up the PAA certificate from its Matter trust store.
    5. Commissioner validates the Attestation Information. These are the conditions for validation:
      • DAC certificate chain must be validated, including revocation checks on the PAI and PAA.
      • VID on the DAC matches the VID on the PAI.
      • The Attestation Signature is valid.
      • Nonce in Device Attestation Elements matches the nonce provided by the Commissioner.
      • Certificate Declaration Signature is valid using one of the Alliance’s well-known Certification Declaration signing keys.
      • Firmware Information (if present and supported by Commissioner) matches an entry in the Distributed Compliance Ledger.
      • Additional VID/PID validations also take place between the Device Basic Information Cluster, Certification Declaration and the DAC.

    This content was originally published on the Google Developer Site

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/commisioning/index.html b/pr-preview/pr-4/howitworks/commisioning/index.html index 26e193a..b4d6e61 100644 --- a/pr-preview/pr-4/howitworks/commisioning/index.html +++ b/pr-preview/pr-4/howitworks/commisioning/index.html @@ -1,18 +1,18 @@ -Commissioning - Matter

    Commissioning

    Commissioning in Matter refers to the process of assigning Fabric credentials to a new device or app. The Commissioner is the device or app that does the Commissioning process. The Commissionee is the new device or app that needs to be provisioned into the Fabric.

    At a high-level, the commissioning flow can be broken down into multiple stages:

    Commissioning Flow - High Level

    1 Device discovery

    Prior to start of the Commissioning flow, the Commissionee must start advertising itself. The Commissionee may advertise itself using any of the three Commissionable Discovery methods. The Commissionee must also provide the onboarding payload.

    2 Connect to device (PASE)

    Once the Commissioner has seen the advertisement and matches up the Discriminator, the Commissioner uses the passcode from the onboarding payload to do Passcode Authenticated Session Establishment (PASE) to connect to the device. This is the method to securely establish keys that both devices will be able to use to establish communication. At this step, the Commissioner also arms a fail-safe. A fail-safe provides a way to roll back the device to its original state if commissioning doesn’t complete successfully.

    3 Get Commissionee information

    The Commissioner reads all the descriptors from the Commissionee. The DescriptorCluster is on endpoint 0 of the device and describes all the other endpoints. Commissioner also reads the Basic Information Cluster which includes information like the Vendor ID, Product ID, Product Name and the Serial Number. At this step, the Commissioner also reads the device type of the Commissionee which helps drive the UX on the Commissioner side.

    4 Regulatory config

    The Commissioner configures regulatory information on the Commissionee using the SetRegulatoryConfig command. Regulatory information includes information like configuring the location (indoor/outdoor/both) of the device or setting up the country code.

    5 Commissionee attestation

    The goal of the Commissionee attestation procedure is to determine whether a device has been certified and is a genuine Matter device. Commissioner extracts the Device Attestation Certificate (DAC) and the Product Attestation Intermediate (PAI) certificate from the Commissionee. These certificates contain the Vendor ID, Product ID and Attestation Public Key. Once the certificates are received, the Commissioner does a challenge request that should be signed by the Attestation Private Key and uses that to establish the authenticity of the Commissionee.

    6 Certificate Signing Request (CSR)

    The Commissioner sends a Certificate Signing Request (CSR) to the Commissionee. The Commissionee creates a unique operational key pair that will be used in a Certificate Authenticated Session Establishment (CASE) later. The Commissionee returns the resulting CSR information back to the Commissioner.

    7 Add Node Operational Certificate (NOC)

    The Commissioner uses the CSR information received from the Commissionee and passes it to the Administrative Domain Manager (ADM) to generate a trusted Node Operational Certificate (NOC). The Commissioner installs the Root Certificate on the Commissionee using the AddTrustedRootCertReq command and then installs the Node Operational Certificate using the AddNOC command.

    8 Network provisioning

    The Commissioner configures the operational network on the Commissionee. This step is needed for Thread or Wi-Fi devices. This step is not needed for Ethernet Devices where the device is already connected to the network. It uses ScanNetworks, AddOrUpdateWifiNetwork and ConnectNetwork commands.

    9 Operational discovery

    Once the newly commissioned node is connected to the network, the Commissioner uses Operational Discovery to find the node on the operational network. Operational discovery is the process by which commissioned nodes are found on the operational network using DNS-SD. If the Commissionee is a Wi-Fi device, it will use mDNS to discover the device.

    Operational discovery helps the Commissioner and other Nodes in the network know which IP address and port the Commissionee is using.

    10 CASE session establishment

    Once the newly commissioned node has been discovered, a CASE session is established between the Commissioner and the device. This session is initiated by the Commissioner and is responded to by the device. In this step, operational certificates are exchanged and a shared trust is established by validating they’re in the same logical fabric.

    11 Commissioning complete

    The Commissioner uses CASE to send the CommissioningComplete command to the newly commissioned device. This is the last step in the commissioning process. CommissioningComplete also automatically disarms the fail-safe timer. Once commissioning is successfully completed, the device operates like any other Node on the operational network.

    This content was originally published on the Google Developer Site

    - - - - - - - - +Commissioning

    Commissioning

    Commissioning in Matter refers to the process of assigning Fabric credentials to a new device or app. The Commissioner is the device or app that does the Commissioning process. The Commissionee is the new device or app that needs to be provisioned into the Fabric.

    At a high-level, the commissioning flow can be broken down into multiple stages:

    Commissioning Flow - High Level

    1 Device discovery

    Prior to start of the Commissioning flow, the Commissionee must start advertising itself. The Commissionee may advertise itself using any of the three Commissionable Discovery methods. The Commissionee must also provide the onboarding payload.

    2 Connect to device (PASE)

    Once the Commissioner has seen the advertisement and matches up the Discriminator, the Commissioner uses the passcode from the onboarding payload to do Passcode Authenticated Session Establishment (PASE) to connect to the device. This is the method to securely establish keys that both devices will be able to use to establish communication. At this step, the Commissioner also arms a fail-safe. A fail-safe provides a way to roll back the device to its original state if commissioning doesn’t complete successfully.

    3 Get Commissionee information

    The Commissioner reads all the descriptors from the Commissionee. The DescriptorCluster is on endpoint 0 of the device and describes all the other endpoints. Commissioner also reads the Basic Information Cluster which includes information like the Vendor ID, Product ID, Product Name and the Serial Number. At this step, the Commissioner also reads the device type of the Commissionee which helps drive the UX on the Commissioner side.

    4 Regulatory config

    The Commissioner configures regulatory information on the Commissionee using the SetRegulatoryConfig command. Regulatory information includes information like configuring the location (indoor/outdoor/both) of the device or setting up the country code.

    5 Commissionee attestation

    The goal of the Commissionee attestation procedure is to determine whether a device has been certified and is a genuine Matter device. Commissioner extracts the Device Attestation Certificate (DAC) and the Product Attestation Intermediate (PAI) certificate from the Commissionee. These certificates contain the Vendor ID, Product ID and Attestation Public Key. Once the certificates are received, the Commissioner does a challenge request that should be signed by the Attestation Private Key and uses that to establish the authenticity of the Commissionee.

    6 Certificate Signing Request (CSR)

    The Commissioner sends a Certificate Signing Request (CSR) to the Commissionee. The Commissionee creates a unique operational key pair that will be used in a Certificate Authenticated Session Establishment (CASE) later. The Commissionee returns the resulting CSR information back to the Commissioner.

    7 Add Node Operational Certificate (NOC)

    The Commissioner uses the CSR information received from the Commissionee and passes it to the Administrative Domain Manager (ADM) to generate a trusted Node Operational Certificate (NOC). The Commissioner installs the Root Certificate on the Commissionee using the AddTrustedRootCertReq command and then installs the Node Operational Certificate using the AddNOC command.

    8 Network provisioning

    The Commissioner configures the operational network on the Commissionee. This step is needed for Thread or Wi-Fi devices. This step is not needed for Ethernet Devices where the device is already connected to the network. It uses ScanNetworks, AddOrUpdateWifiNetwork and ConnectNetwork commands.

    9 Operational discovery

    Once the newly commissioned node is connected to the network, the Commissioner uses Operational Discovery to find the node on the operational network. Operational discovery is the process by which commissioned nodes are found on the operational network using DNS-SD. If the Commissionee is a Wi-Fi device, it will use mDNS to discover the device.

    Operational discovery helps the Commissioner and other Nodes in the network know which IP address and port the Commissionee is using.

    10 CASE session establishment

    Once the newly commissioned node has been discovered, a CASE session is established between the Commissioner and the device. This session is initiated by the Commissioner and is responded to by the device. In this step, operational certificates are exchanged and a shared trust is established by validating they’re in the same logical fabric.

    11 Commissioning complete

    The Commissioner uses CASE to send the CommissioningComplete command to the newly commissioned device. This is the last step in the commissioning process. CommissioningComplete also automatically disarms the fail-safe timer. Once commissioning is successfully completed, the device operates like any other Node on the operational network.

    This content was originally published on the Google Developer Site

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/connectivitytransports/index.html b/pr-preview/pr-4/howitworks/connectivitytransports/index.html index 44ec3cd..1dcbe52 100644 --- a/pr-preview/pr-4/howitworks/connectivitytransports/index.html +++ b/pr-preview/pr-4/howitworks/connectivitytransports/index.html @@ -1,8 +1,8 @@ -Connectivity Transports - Matter

    Connectivity Transports

    In principle, any IPv6-bearing network is suitable for Matter deployment, subject to supporting a few core IPv6 standards. In the current version of the specification, we focus on three link layer technologies: Ethernet, Wi-Fi and Thread. We restrict the specification to the above so that the specification can suitably cover provisioning of these link layers, and so that the amount of testing in certifica­tion is suitably bounded.

    Matter treats networks as shared resources: it makes no stipulation of exclusive network owner­ship or access. As a result, it is possible to overlay multiple Matter networks over the same set of constituent IP networks. @@ -15,14 +15,14 @@ For commissioning, Wi-Fi devices may use the BLE method of discovery and conveying of network credentials or the device may already be connected to the IP network via an existing proprietary method.

    Thread

    Thread is a low power 802.15.4 mesh-based radio protocol designed for IP transport. There are a number of additional considerations when using Thread for a Matter device which are explained on the dedicated Thread page of this site. In order for a device that uses Thread to be Matter certified, the manufacturer must first obtain Thread certification for the device from the Thread Group. When a device uses Thread, it must also use BLE for Discovery and Commissioning in order to provision the Thread network credentials to the device.

    Bluetooth

    Bluetooth Low Energy (BLE) is used in Matter as part of the discovery and commissioning stage as a method for passing the credentials of the Wi-Fi or Thread network that the device will use for operational communication. BLE is required where a device uses Thread and optional for Wi-Fi. -BLE cannot be used as the sole transport technology for a Matter Device.

    - - - - - - - - +BLE cannot be used as the sole transport technology for a Matter Device.

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/datamodel/index.html b/pr-preview/pr-4/howitworks/datamodel/index.html index 99b3d3d..1932428 100644 --- a/pr-preview/pr-4/howitworks/datamodel/index.html +++ b/pr-preview/pr-4/howitworks/datamodel/index.html @@ -1,21 +1,21 @@ -The Device Data Model - Matter

    The Device Data Model

    Devices in Matter have a well-defined data model (DM), which is a hierarchical modeling of a Device’s features. At the top level of this hierarchy there is a Device.

    Devices and Endpoints

    All Devices, including smartphones and home assistants, are composed of Nodes. A Node is a unique identifiable and addressable resource in a network that a user can perceive as functionally whole. Network communication in Matter originates and terminates at a Node.

    Nodes are a collection of Endpoints. Each Endpoint encloses a feature set. For instance, an Endpoint might relate to a lighting functionality, while another relates to motion detection, and another deals with utilities such as Device OTA.

    Devices Nodes and Endpoints

    Node Roles

    A Node role is a set of related behaviors. Each Node may have one or more roles. Node roles include:

    • Commissioner: A Node that performs Commissioning.
    • Controller: A Node that can control one or more Nodes. Examples include the Google Home app (GHA), Google Assistant, and the Google Nest Hub (2nd gen). Some device types, such as the On/Off Light Switch, have the Controller role.
    • Controlee: A Node that can be controlled by one or more Nodes. Most device types can be a - - Controlee, except for some device types which have the Controller role, such as the On/Off Light Switch. The On/Off Light Switch can only be a Controller. It cannot be a Controlee.
    • OTA Provider: A Node that can provide OTA software updates.
    • OTA Requestor: A Node that can request OTA software updates.

    Clusters

    Within an Endpoint a Node has one or more Clusters. These are another step in the Device hierarchy, as they group specific functionality such as a on/off cluster on a smart plug, or a level control cluster on a dimmable light Endpoint.

    A Node may also have several Endpoints, each creating an instance of the same functionality. For example, a light fixture may expose independent control of individual lights or a power strip may expose control of individual sockets.

    ### Attributes At the last level we’ll find Attributes, which are states held by the node, such as the current level attribute of a level control cluster. Attributes may be defined as different data types such as uint8, strings or arrays.

    Nodes, Endpoints, Attributes and Commands

    Commands

    Besides Attributes, Clusters also have Commands, which are actions that may be performed. They are the equivalent in Matter’s DM of a remote procedure call. Commands are verb-like, such as lock door on a Door Lock cluster. Commands may generate responses and results; in Matter, such responses are also defined as Commands, going in the reverse direction.

    ### Events Lastly, Clusters may also have Events, which can be thought of as a record of past state transitions. While Attributes represent the current states, events are a journal of the past, and include a monotonically increasing counter, a timestamp and a priority. They enable capturing state transitions, as well as data modeling that is not readily achieved with attributes.

    A sample of the hierarchy of Matter Devices interaction model

    The Endpoint 0 is reserved for the Utility Clusters. Utility Clusters are specific Clusters that enclose servicing functionality on an Endpoint, such as discovery, addressing, diagnostics and software update. On the other hand, the Application Clusters support primary actions such as on/off or temperature measurement.

    Device Types

    Altogether, which Cluster combinations should be included as a device manufacturer plans a new Device?

    The Matter specification requires that the device implement or extend one or more Device Types. A Device Type is a collection of mandatory and optional Clusters that define the top-level attributes of a physical Device, such as Dimmable Light, Door Lock, or Video Player.

    The Device Types are not specified by the Matter specification main document, but by an accompanying document: the Device Library. Similarly, all Application Clusters are defined in the Application Cluster Library. These three documents can be found on the Connectivity Standards Alliance (Alliance) website.

    Each Endpoint implementing a Device Type must implement the mandatory Clusters that define that Device Type. In addition to the mandatory Clusters, the Endpoint may implement additional Clusters, including one or more of the Device Type’s optional Clusters, or even Clusters that aren’t part of the Device Type.

    Clients and Servers

    Clusters might be either a Client Cluster or a Server Cluster. While a Server is stateful and holds Attributes, Events and Commands, a Client is stateless and its responsibility is to initiate Interactions with a remote Server Cluster, thus performing:

    • reads from and writes to its remote Attributes.
    • reads of its remote Events.
    • invocation of its remote Commands.

    While the DM is hierarchical within a Node, the relationship between Nodes is not. Nodes in Matter do not have vertical controller/peripheral or leader/follower relationships. On the contrary, the relationship is horizontal: Any Cluster may be either Server or Client. Thus a Node may be both Server and Client with regards to different Clusters and functionalities.

    For instance, we may have two table lamps: Node A and Node B. Both nodes implement an On/Off Light Device Type. This Device Type includes an On/Off Server Cluster that controls their respective physical light outputs.

    But, as typical table lamps do, our physical devices will also include an On/Off Light Switch Device Type for their local on/off switches. This Device Type must implement an On/Off Client Cluster so it may control the Server Clusters.

    Client and Server Clusters

    In this sample, the On/Off Client Cluster on Node A is changing the attributes of the On/Off Server Cluster on Node A and Node B, while the Node B’s Client Cluster is only changing the Server Cluster on Node B itself.

    In the next section we’ll detail how Client and Server Clusters interact: the Interaction Model.

    Descriptor Cluster

    As the name implies, the Descriptor Cluster Server provides introspection information. It describes the Endpoint enumerating its:

    • Server Clusters.
    • Client Clusters.
    • Device Types.
    • Additional Endpoints, known as Parts. -Every Device Type requires the implementation of Descriptor Clusters. The Root Device Type is defined on Endpoint 0. Reading its Descriptor Cluster will provide the client the visibility to traverse the full tree of available Endpoints and perform applicable operations.

    The Commissioner or Controlling device such as a phone or hub can use the information found on the Descriptor Cluster to model the Device (light, switch, pump, thermostat), and specific features implemented by that particular instance of the Device, showing the correct UI to the user.

    Server Clusters

    The ServerList Attribute lists the Cluster Servers in the Endpoint.

    Client Clusters

    The ClientList Attribute lists the Cluster Clients in the Endpoint.

    Device Type List

    The DeviceTypeList Attribute is a list of Device Types supported by the Endpoint, along with its respective revisions. It must contain at least one Device Type.

    Parts List

    The PartsList contains the list of Endpoints used for implementing this Device Type.

    The PartsList of Endpoint 0 (Root Node) contains all the Endpoints of the device apart from itself (Endpoint 0).

    The PartsList of other Endpoints will usually be empty. For example, a Temperature Sensor mandates a Temperature Measurement Server Cluster and nothing else.

    Other device types might be composed in a tree structure of more than one Device Type instance. For example, a Video Player Device type can be composed of TV, Video Player, Speaker and different Content App Device Types, each on a different Endpoint.

    This content was originally published on the Google Developer Site

    - - - - - - - - +Every Device Type requires the implementation of Descriptor Clusters. The Root Device Type is defined on Endpoint 0. Reading its Descriptor Cluster will provide the client the visibility to traverse the full tree of available Endpoints and perform applicable operations.

    The Commissioner or Controlling device such as a phone or hub can use the information found on the Descriptor Cluster to model the Device (light, switch, pump, thermostat), and specific features implemented by that particular instance of the Device, showing the correct UI to the user.

    Server Clusters

    The ServerList Attribute lists the Cluster Servers in the Endpoint.

    Client Clusters

    The ClientList Attribute lists the Cluster Clients in the Endpoint.

    Device Type List

    The DeviceTypeList Attribute is a list of Device Types supported by the Endpoint, along with its respective revisions. It must contain at least one Device Type.

    Parts List

    The PartsList contains the list of Endpoints used for implementing this Device Type.

    The PartsList of Endpoint 0 (Root Node) contains all the Endpoints of the device apart from itself (Endpoint 0).

    The PartsList of other Endpoints will usually be empty. For example, a Temperature Sensor mandates a Temperature Measurement Server Cluster and nothing else.

    Other device types might be composed in a tree structure of more than one Device Type instance. For example, a Video Player Device type can be composed of TV, Video Player, Speaker and different Content App Device Types, each on a different Endpoint.

    This content was originally published on the Google Developer Site

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/devicetypes/index.html b/pr-preview/pr-4/howitworks/devicetypes/index.html index ed1056f..dde79bb 100644 --- a/pr-preview/pr-4/howitworks/devicetypes/index.html +++ b/pr-preview/pr-4/howitworks/devicetypes/index.html @@ -1,8 +1,8 @@ -Supported Device Types - Matter

    Supported Device Types

    In order to be certified a Matter device must conform to one of the approved device types.

    As of Matter 1.2 the following types are certifiable.

    On/Off Light

    The On/Off Light is a lighting device that is capable of being switched on or off by means of a bound controller device such as an On/Off Light Switch or a Dimmer Switch. In addition, an on/off light is also capable of being switched by means of a bound occupancy sensor.

    Dimmable Light

    A Dimmable Light is a lighting device that is capable of being switched on or off and the intensity of its light adjusted by means of a bound controller device such as a Dimmer Switch or a Color Dim­ mer Switch. In addition, a Dimmable Light device is also capable of being switched by means of a bound occupancy sensor or other device(s).

    Color Temperature Light

    A Color Temperature Light is a lighting device that is capable of being switched on or off, the inten­ sity of its light adjusted, and its color temperature adjusted by means of a bound controller device such as a Color Dimmer Switch.

    Extended Color Light

    An Extended Color Light is a lighting device that is capable of being switched on or off, the intensity of its light adjusted, and its color adjusted by means of a bound controller device such as a Color Dimmer Switch or Control Bridge. The device supports adjustment of color by means of hue/satura­ tion, enhanced hue, color looping, XY coordinates, and color temperature. In addition, the extended color light is also capable of being switched by means of a bound occupancy sensor.

    On/Off Plug in Unit

    An On/Off Plug-in Unit is a device that is capable of being switched on or off by means of a bound controller device such as an On/Off Light Switch or a Dimmer Switch. The On/Off Plug-in Unit is typ­ ically used to control a conventional non-communicating light by switching its mains connection. Other appliances can be controlled this way as well.

    Dimmable Plug in Unit

    A Dimmable Plug-In Unit is a device that is capable of being switched on or off and have its level adjusted by means of a bound controller device such as a Dimmer Switch or a Color Dimmer Switch. The Dimmable Plug-in Unit is typically used to control a conventional non-communicating light through its mains connection using phase cutting.

    Pump

    A Pump device is a pump that may have variable speed. It may have optional built-in sensors and a regulation mechanism. It is typically used for pumping fluids like water.

    On/Off Light Switch

    An On/Off Light Switch is a controller device that, when bound to a lighting device such as an On/Off Light, is capable of being used to switch the device on or off.

    Dimmer Switch

    A Dimmer Switch is a controller device that, when bound to a lighting device such as a Dimmable Light, is capable of being used to switch the device on or off and adjust the intensity of the light being emitted.

    Color Dimmer Switch

    A Color Dimmer Switch is a controller device that, when bound to a lighting device such as an Extended Color Light, is capable of being used to adjust the color of the light being emitted.

    Control Bridge

    A Control Bridge is a controller device that, when bound to a lighting device such as an Extended Color Light, is capable of being used to switch the device on or off, adjust the intensity of the light being emitted and adjust the color of the light being emitted. In addition, a Control Bridge device is capable of being used for setting scenes.

    Pump Controller

    A Pump Controller device is capable of configuring and controlling a Pump device.

    Generic Switch

    A generic switch can be either momentary or latching in state, with multiple positions.

    The Generic Switch device type and the On/Off Light Switch device type both convey information about interactions with a switch to another device.

    • The On/Off Light Switch will send On/Off/Toggle commands from its On/Off (client) cluster to a device implementing the On/Off (server) cluster to control the on/off functionality of that device. An On/Off Light Switch device can also implement Groups and Scenes clusters and thus send group and scene commands. Basically, it is targeted at directly sending control commands to other devices. The binding table is used to tell the device where to send the commands.
    • The Generic Switch device type will send updates of attributes (for Latching Switch only) and events to subscribed parties which implement the Switch client cluster, as indications of inter­ action with the switch - leaving the interpretation (e.g. which device should be actuated because of the interaction) to the subscribed party. So it can be compared to a sensor-type device.

    This allows a more comprehensive controller to combine the information from the switch with other inputs or information sources (e.g. time of day, user presence) to determine which control commands (e.g. on/off, scene recall, attribute change) are sent to other devices in the network.

    Contact Sensor

    The Contact Sensor is a device that reports a boolean state, typically open/closed.

    Light Sensor

    A Light Sensor device is a measurement and sensing device that is capable of measuring and reporting the intensity of light (illuminance) to which the sensor is being subjected.

    Occupancy Sensor

    An Occupancy Sensor is a measurement and sensing device that is capable of measuring and reporting the occupancy state in a designated area.

    Temperature Sensor

    A Temperature Sensor device reports measurements of temperature.

    Pressure Sensor

    A Pressure Sensor device measures and reports the pressure of a fluid.

    Flow Sensor

    A Flow Sensor device measures and reports the flow rate of a fluid.

    Humidity Sensor

    A humidity sensor (in most cases a Relative humidity sensor) reports humidity measurements.

    On/Off Sensor

    An On/Off Sensor is a measurement and sensing device that, when bound to a lighting device such as a Dimmable Light, is capable of being used to switch the device on or off.

    Smoke CO Alarm

    A Smoke CO Alarm device is capable of sensing smoke, carbon monoxide or both. It is capable of issuing a visual and audible alert to indicate elevated concentration of smoke or carbon monoxide. @@ -15,14 +15,14 @@ A Casting Video Player has basic controls for playback (play, pause, etc.) and keypad input (up, down, number input), and is able to launch content. For example, a Casting Video Player can be a smart TV device, a TV Set Top Box, or a content streaming device that provides input to another device like a TV or computer monitor.

    Speaker

    This feature controls the speaker volume of the device. To control unmute/mute, the On/Off cluster SHALL be used. A value of TRUE for the OnOff attribute SHALL represent the volume on (not muted) state, while a value of FALSE SHALL represent the vol­ume off (muted) state. For volume level control, the Level cluster SHALL be used. -A dedicated endpoint is needed because the On/Off cluster can also be used for other purposes, such as for power control.

    Content App

    A Content App is usually an application built by a Content Provider. A Casting Video Player with a Content App Platform is able to launch Content Apps and represent these apps as separate end­ points.

    Casting Video Client

    A Casting Video Client is a client that can launch content on a Casting Video Player, for example, a Smart Speaker or a Content Provider phone app.

    Video Remote Control

    A Video Remote Control is a client that can control a Video Player, for example, a traditional universal remote control.

    Robotic Vacuum Cleaner

    A robotic vacuum cleaner is a device capable of autononomous cleaning, the cleaning mode may be selected from a number of predefined options and the device should report back any error states.

    Refrigerator

    A refrigerator represents a device that contains one or more cabinets that are capable of chilling or freezing food. Examples of consumer products that MAY make use of this device type include refrigerators, freezers, and wine coolers.

    Temperature Controlled Cabinet

    A Temperature Controlled Cabinet only exists composed as part of another device type. It repre­sents a single cabinet chilling or freezing food in a refrigerator, freezer, wine chiller or other simi­lar device.

    Room Air Conditioner

    A Room Air Conditioner is a device with the primary function of controlling the air temperature in a single room.

    Laundry Washer

    A Laundry Washer represents a device that is capable of laundering consumer items. Any laundry washer product may utilize this device type.

    Dishwasher

    A dishwasher is a device that is generally installed in residential homes and is capable of washing dishes, cutlery, and other items associate with food preparation and consumption. The device can be permanently installed or portable and can have variety of filling and draining methods.

    - - - - - - - - +A dedicated endpoint is needed because the On/Off cluster can also be used for other purposes, such as for power control.

    Content App

    A Content App is usually an application built by a Content Provider. A Casting Video Player with a Content App Platform is able to launch Content Apps and represent these apps as separate end­ points.

    Casting Video Client

    A Casting Video Client is a client that can launch content on a Casting Video Player, for example, a Smart Speaker or a Content Provider phone app.

    Video Remote Control

    A Video Remote Control is a client that can control a Video Player, for example, a traditional universal remote control.

    Robotic Vacuum Cleaner

    A robotic vacuum cleaner is a device capable of autononomous cleaning, the cleaning mode may be selected from a number of predefined options and the device should report back any error states.

    Refrigerator

    A refrigerator represents a device that contains one or more cabinets that are capable of chilling or freezing food. Examples of consumer products that MAY make use of this device type include refrigerators, freezers, and wine coolers.

    Temperature Controlled Cabinet

    A Temperature Controlled Cabinet only exists composed as part of another device type. It repre­sents a single cabinet chilling or freezing food in a refrigerator, freezer, wine chiller or other simi­lar device.

    Room Air Conditioner

    A Room Air Conditioner is a device with the primary function of controlling the air temperature in a single room.

    Laundry Washer

    A Laundry Washer represents a device that is capable of laundering consumer items. Any laundry washer product may utilize this device type.

    Dishwasher

    A dishwasher is a device that is generally installed in residential homes and is capable of washing dishes, cutlery, and other items associate with food preparation and consumption. The device can be permanently installed or portable and can have variety of filling and draining methods.

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/discovery/index.html b/pr-preview/pr-4/howitworks/discovery/index.html index 90695ad..7c0383f 100644 --- a/pr-preview/pr-4/howitworks/discovery/index.html +++ b/pr-preview/pr-4/howitworks/discovery/index.html @@ -1,21 +1,21 @@ -Discovery - Matter

    Discovery

    Commissionable discovery

    Commissionable discovery happens before Commissioning and refers to the process of discovering and identifying a commissionable Node. There are three methods through which a commissionable Node may advertise itself:

    • Bluetooth low energy (BLE)
    • DNS-SD on an any IP network the Node is connected to

    In either method, the commissionable node advertises information as shown in the table below.

    FieldLengthRequired
    Discriminator12 bitYes
    Vendor ID16 bitNo
    Product ID16 bitNo
    Extended datavariableNo

    As per the Matter specification, Vendor ID and Product ID are not required but can be included. The Discriminator is mandatory and is crucial during the commissioning process to provision the correct device, in case multiple identical devices are connected at the same time. Extended data may be used to encode custom vendor-specific information.

    Many devices will advertise for a short period of time (~3-15 mins) after power-up. Other devices must not start advertising either because their primary control does not originate from the fabric or because automatic unprovisioned advertising of devices such as locks isn’t safe. This table summarizes the behavior.

    Primary Device FunctionAutomatic Announcement
    Locks and barriers access devicesNo
    Most control originates from fabric. For example, switch or light bulb.Yes
    Most control does not originate from fabric. For example, dishwasher or refrigerator.No

    Bluetooth Low Energy

    In this mode of advertisement, the Commissioner will see BLE advertisements. The Commissionee must implement a Generic access profile (GAP) peripheral interface and advertise its uncommissioned state periodically. For the first 30 seconds after a device is turned on the advertisement frequency must be high, at 20 to 60 milliseconds intervals.

    After 30 seconds, the device must advertise at a low frequency, at 150 to 1500 millisecond intervals. When commissioned to its first fabric, the device must stop its BLE advertisement.

    The Commissioner does not need to issue scan requests. It should do a passive scan on the three BLE advertising channels: 37 (2402 MHz), 38 (2426 MHz) and 39 (2480 MHz). These channels are picked from regions in the spectrum with minimal overlap with Wi-Fi Channels, minimizing interference cross-radio interference.

    BLE is not used for operational discovery.

    DNS-SD

    In this case the Commissionee will be discovered by its domain name service - service discovery (DNS-SD) advertisements that contain information on services rendered by the nodes. See RFC 6762 for more information about DNS-SD. This is a common method of device discovery when:

    The Commissionee is connected to Ethernet and thus has physical access to an unencrypted network medium. +Discovery

    Discovery

    Commissionable discovery

    Commissionable discovery happens before Commissioning and refers to the process of discovering and identifying a commissionable Node. There are two methods through which a commissionable Node may advertise itself:

    • Bluetooth low energy (BLE)
    • DNS-SD on an any IP network the Node is connected to

    In either method, the commissionable node advertises information as shown in the table below.

    FieldLengthRequired
    Discriminator12 bitYes
    Vendor ID16 bitNo
    Product ID16 bitNo
    Extended datavariableNo

    As per the Matter specification, Vendor ID and Product ID are not required but can be included. The Discriminator is mandatory and is crucial during the commissioning process to provision the correct device, in case multiple identical devices are connected at the same time. Extended data may be used to encode custom vendor-specific information.

    Many devices will advertise for a short period of time (~3-15 mins) after power-up. Other devices must not start advertising either because their primary control does not originate from the fabric or because automatic unprovisioned advertising of devices such as locks isn’t safe. This table summarizes the behavior.

    Primary Device FunctionAutomatic Announcement
    Locks and barriers access devicesNo
    Most control originates from fabric. For example, switch or light bulb.Yes
    Most control does not originate from fabric. For example, dishwasher or refrigerator.No

    Bluetooth Low Energy

    In this mode of advertisement, the Commissioner will see BLE advertisements. The Commissionee must implement a Generic access profile (GAP) peripheral interface and advertise its uncommissioned state periodically. For the first 30 seconds after a device is turned on the advertisement frequency must be high, at 20 to 60 milliseconds intervals.

    After 30 seconds, the device must advertise at a low frequency, at 150 to 1500 millisecond intervals. When commissioned to its first fabric, the device must stop its BLE advertisement.

    The Commissioner does not need to issue scan requests. It should do a passive scan on the three BLE advertising channels: 37 (2402 MHz), 38 (2426 MHz) and 39 (2480 MHz). These channels are picked from regions in the spectrum with minimal overlap with Wi-Fi Channels, minimizing interference cross-radio interference.

    BLE is not used for operational discovery.

    DNS-SD

    In this case the Commissionee will be discovered by its domain name service - service discovery (DNS-SD) advertisements that contain information on services rendered by the nodes. See RFC 6762 for more information about DNS-SD. This is a common method of device discovery when:

    The Commissionee is connected to Ethernet and thus has physical access to an unencrypted network medium. The Commissionee has joined the Wi-Fi or Thread network by any out-of-band means. The Commissionee was already commissioned to another fabric and has joined the Wi-Fi/Thread network. In this case the Commissionee can’t use BLE advertisements or create a Soft AP. Thus all secondary fabrics are provisioned through this method. -Thread devices don’t directly use DNS-SD, but instead use a proxied method provided by the Thread Border Router. This method is defined by the DNS-SD Service Registration Protocol and its Advertising Proxy. Thread devices register themselves in the SRP service typically provided by a Thread Border Router. This service handles mDNS traffic on behalf of each registered Thread node without burdening the Thread network with additional traffic generated by these protocols.

    The DNS-SD instance name for device discovery is _matterc._udp and the host names are built by either a 48-bit MAC address or a 64-bit MAC Extended Address, expressed as a hex string such as A5F15790B0D15F32.local.. Generally this record is only advertised when the Commissionee may be commissioned. However, it may also continue advertising when not in commissioning mode. That behavior is named extended discovery.

    After discovery, IPv6 addresses are returned in the AAAA records and key/value pairs are returned in the DNS‑SD TXT record. The key/value pair contains information such as the Discriminator, Vendor ID, and Product ID. The node also advertises commissioning subtypes, which enables filtering of results to find only Commissionees that match a particular attribute.

    Operational discovery

    Operational discovery is the process of discovering and identifying a commissioned node. Operational discovery only happens through the IP-based DNS-SD method. The node instance name will be composed of the 64 bit compressed Fabric ID and 64 bit Node ID. These IDs in hexadecimal are then concatenated with a hyphen, such as in 2906C908D115D362-8FC7772401CD0696.local.. Operational discovery shares the same target host name as DNS-SD Device Discovery.

    The DNS-SD service type is _matter._tcp. Although _tcp naming is used, the device might use other transports such as UDP.

    This content was originally published on the Google Developer Site

    - - - - - - - - +Thread devices don’t directly use DNS-SD, but instead use a proxied method provided by the Thread Border Router. This method is defined by the DNS-SD Service Registration Protocol and its Advertising Proxy. Thread devices register themselves in the SRP service typically provided by a Thread Border Router. This service handles mDNS traffic on behalf of each registered Thread node without burdening the Thread network with additional traffic generated by these protocols.

    The DNS-SD instance name for device discovery is _matterc._udp and the host names are built by either a 48-bit MAC address or a 64-bit MAC Extended Address, expressed as a hex string such as A5F15790B0D15F32.local.. Generally this record is only advertised when the Commissionee may be commissioned. However, it may also continue advertising when not in commissioning mode. That behavior is named extended discovery.

    After discovery, IPv6 addresses are returned in the AAAA records and key/value pairs are returned in the DNS‑SD TXT record. The key/value pair contains information such as the Discriminator, Vendor ID, and Product ID. The node also advertises commissioning subtypes, which enables filtering of results to find only Commissionees that match a particular attribute.

    Operational discovery

    Operational discovery is the process of discovering and identifying a commissioned node. Operational discovery only happens through the IP-based DNS-SD method. The node instance name will be composed of the 64 bit compressed Fabric ID and 64 bit Node ID. These IDs in hexadecimal are then concatenated with a hyphen, such as in 2906C908D115D362-8FC7772401CD0696.local.. Operational discovery shares the same target host name as DNS-SD Device Discovery.

    The DNS-SD service type is _matter._tcp. Although _tcp naming is used, the device might use other transports such as UDP.

    This content was originally published on the Google Developer Site

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/fabric/index.html b/pr-preview/pr-4/howitworks/fabric/index.html index 7957816..ff447b2 100644 --- a/pr-preview/pr-4/howitworks/fabric/index.html +++ b/pr-preview/pr-4/howitworks/fabric/index.html @@ -1,18 +1,18 @@ -The Fabric - Matter

    The Fabric

    The Matter spec uses sophisticated methods for encrypting and decrypting information, as well as safe mechanisms for assuring a Node’s identity and sharing cryptographic credentials.

    Whenever a set of Devices in a network shares the same security domain, and thus allows secure communication between Nodes, this set is called a Fabric. Devices within a fabric share the same Certificate Authority (CA) top-level certificate (Root of Trust) and a 64-bit identifier named Fabric ID, unique within the context of that CA.

    Thus the commissioning process is the assignment of the Fabric credentials to a new Node so it may communicate with other Nodes in the same Fabric.

    Operational credentials

    The Root of Trust is set on a Node under commissioning by the Commissioner, typically a device with some type of GUI, such as a smartphone, hub or computer, after receiving it from an Administrative Domain Manager (ADM), which will often be an ecosystem that acts as a Trusted Root Certificate Authority (CA).

    The Commissioner has access to the CA. Thus it requests the Node Operational Credentials from the CA on behalf of the node being commissioned or Commissionee. The credentials are made of two parts:

    Node Operational Identifier (or Operational Node ID) is a 64-bit number that uniquely identifies every Node in the Fabric.

    Node Operational Certificate (NOC) is the set of credentials that Nodes use to communicate and identify themselves within a Fabric. They are generated by the Node Operational Certificate Signing Request (NOCSR) process.

    NOCSR is a procedure that runs on Node being commissioned. It binds several cryptographical elements, then sends them to the Commissioner, who requests the CA ecosystem for its corresponding NOC. This diagram depicts this dependency tree and the order by which some operations occur.

    NOC Generation Dependencies

    While understanding each cryptographic element is important for SDK development, it is outside of this document’s scope to fully analyze their role and implications. What’s important to note is that:

    • NOCs are issued by the CA ecosystem on real-world production fabrics.
    • NOCs are cryptographically bound to the unique Node Operational Key Pair (NOKP).
    • NOKP is generated by the node being commissioned during the commissioning process.
    • The NOCSR information sent to the ecosystem includes the Node Operational Public Key, but the Node Operational Private Key is never sent to the Commissioner or to the CA.
    • The NOCSR process uses inputs from the Attestation Procedure, signing the CSRSR information, and thus validating the request for the CA to generate a trusted NOC.

    The Attestation procedure is a process used by the Commissioner to certify that:

    • The Device has gone through Matter certification.
    • The Device is indeed is what it claims to be: it cryptographically proves its Vendor, Product ID and other manufacturing information.

    Multi-Admin

    Nodes may also be commissioned on more than one Fabric. This property is often referred to as multi-admin. For instance, we may have a Device commissioned to both the manufacturer’s Fabric and a cloud ecosystem’s Fabric, with each Fabric handling a different set of encrypted communications and operating independently.

    As several Fabrics may coexist, a Device might have several sets of Node operational credentials. However, the Node’s Data Model is shared: the Cluster Attributes, Events, and Actions are common between Fabrics. Thus, although Thread and/or Wi-Fi credentials are set during the commissioning process, they are part of the Networking Operational Cluster, being shared between all the Fabrics and part of the node’s DM, not the Fabric credentials.

    This content was originally published on the Google Developer Site

    - - - - - - - - +The Fabric

    The Fabric

    The Matter spec uses sophisticated methods for encrypting and decrypting information, as well as safe mechanisms for assuring a Node’s identity and sharing cryptographic credentials.

    Whenever a set of Devices in a network shares the same security domain, and thus allows secure communication between Nodes, this set is called a Fabric. Devices within a fabric share the same Certificate Authority (CA) top-level certificate (Root of Trust) and a 64-bit identifier named Fabric ID, unique within the context of that CA.

    Thus the commissioning process is the assignment of the Fabric credentials to a new Node so it may communicate with other Nodes in the same Fabric.

    Operational credentials

    The Root of Trust is set on a Node under commissioning by the Commissioner, typically a device with some type of GUI, such as a smartphone, hub or computer, after receiving it from an Administrative Domain Manager (ADM), which will often be an ecosystem that acts as a Trusted Root Certificate Authority (CA).

    The Commissioner has access to the CA. Thus it requests the Node Operational Credentials from the CA on behalf of the node being commissioned or Commissionee. The credentials are made of two parts:

    Node Operational Identifier (or Operational Node ID) is a 64-bit number that uniquely identifies every Node in the Fabric.

    Node Operational Certificate (NOC) is the set of credentials that Nodes use to communicate and identify themselves within a Fabric. They are generated by the Node Operational Certificate Signing Request (NOCSR) process.

    NOCSR is a procedure that runs on Node being commissioned. It binds several cryptographical elements, then sends them to the Commissioner, who requests the CA ecosystem for its corresponding NOC. This diagram depicts this dependency tree and the order by which some operations occur.

    NOC Generation Dependencies

    While understanding each cryptographic element is important for SDK development, it is outside of this document’s scope to fully analyze their role and implications. What’s important to note is that:

    The Attestation procedure is a process used by the Commissioner to certify that:

    Multi-Admin

    Nodes may also be commissioned on more than one Fabric. This property is often referred to as multi-admin. For instance, we may have a Device commissioned to both the manufacturer’s Fabric and a cloud ecosystem’s Fabric, with each Fabric handling a different set of encrypted communications and operating independently.

    As several Fabrics may coexist, a Device might have several sets of Node operational credentials. However, the Node’s Data Model is shared: the Cluster Attributes, Events, and Actions are common between Fabrics. Thus, although Thread and/or Wi-Fi credentials are set during the commissioning process, they are part of the Networking Operational Cluster, being shared between all the Fabrics and part of the node’s DM, not the Fabric credentials.

    This content was originally published on the Google Developer Site

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/index.html b/pr-preview/pr-4/howitworks/index.html index c42c616..d0308f6 100644 --- a/pr-preview/pr-4/howitworks/index.html +++ b/pr-preview/pr-4/howitworks/index.html @@ -1,17 +1,17 @@ -How It Works - Matter

    How It Works

    This section goes into detail about how Matter works. Click through the links in the sidebar to learn more about Matter roles, device types, connectivity transports, and more. You can download the Matter specification directly from the Connectivity Standards Alliance’s website for the most detail.

    - - - - - - - - +How It Works

    How It Works

    This section goes into detail about how Matter works. Click through the links in the sidebar to learn more about Matter roles, device types, connectivity transports, and more. You can download the Matter specification directly from the Connectivity Standards Alliance’s website for the most detail.

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/index.xml b/pr-preview/pr-4/howitworks/index.xml index 6f9b120..12c37de 100644 --- a/pr-preview/pr-4/howitworks/index.xml +++ b/pr-preview/pr-4/howitworks/index.xml @@ -6,7 +6,7 @@ Lighting On/Off Light Dimmable Light Color Temperature Light Extendded Color Lig Devices and Endpoints All Devices, including smartphones and home assistants, are composed of Nodes. A Node is a unique identifiable and addressable resource in a network that a user can perceive as functionally whole. Network communication in Matter originates and terminates at a Node.Connectivity Transportshttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/connectivitytransports/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/connectivitytransports/In principle, any IPv6-bearing network is suitable for Matter deployment, subject to supporting a few core IPv6 standards. In the current version of the specification, we focus on three link layer technologies: Ethernet, Wi-Fi and Thread. We restrict the specification to the above so that the specification can suitably cover provisioning of these link layers, and so that the amount of testing in certifica­tion is suitably bounded. Matter treats networks as shared resources: it makes no stipulation of exclusive network owner­ship or access.Interaction Modelhttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/interactionmodel/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/interactionmodel/Concepts The Data Model (DM) of a Node isn’t relevant if we can’t perform operations on them. The Interaction Model (IM), defines a Node’s DM relationship with the DM of other Nodes: a common language for communication between DMs. Nodes interact with each other by: -Reading and Subscribing to Attributes and Events Writing to Attributes Invoking Commands Whenever a Node establishes an encrypted communication sequence with another Node, they constitute an Interaction relationship.Discoveryhttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/discovery/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/discovery/Commissionable discovery Commissionable discovery happens before Commissioning and refers to the process of discovering and identifying a commissionable Node. There are three methods through which a commissionable Node may advertise itself: +Reading and Subscribing to Attributes and Events Writing to Attributes Invoking Commands Whenever a Node establishes an encrypted communication sequence with another Node, they constitute an Interaction relationship.Discoveryhttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/discovery/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/discovery/Commissionable discovery Commissionable discovery happens before Commissioning and refers to the process of discovering and identifying a commissionable Node. There are two methods through which a commissionable Node may advertise itself: Bluetooth low energy (BLE) DNS-SD on an any IP network the Node is connected to In either method, the commissionable node advertises information as shown in the table below. Field Length Required Discriminator 12 bit Yes Vendor ID 16 bit No Product ID 16 bit No Extended data variable No As per the Matter specification, Vendor ID and Product ID are not required but can be included.The Fabrichttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/fabric/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/fabric/The Matter spec uses sophisticated methods for encrypting and decrypting information, as well as safe mechanisms for assuring a Node’s identity and sharing cryptographic credentials. Whenever a set of Devices in a network shares the same security domain, and thus allows secure communication between Nodes, this set is called a Fabric. Devices within a fabric share the same Certificate Authority (CA) top-level certificate (Root of Trust) and a 64-bit identifier named Fabric ID, unique within the context of that CA.Commissioninghttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/commisioning/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/commisioning/Commissioning in Matter refers to the process of assigning Fabric credentials to a new device or app. The Commissioner is the device or app that does the Commissioning process. The Commissionee is the new device or app that needs to be provisioned into the Fabric. diff --git a/pr-preview/pr-4/howitworks/interactionmodel/index.html b/pr-preview/pr-4/howitworks/interactionmodel/index.html index 7759351..86e0342 100644 --- a/pr-preview/pr-4/howitworks/interactionmodel/index.html +++ b/pr-preview/pr-4/howitworks/interactionmodel/index.html @@ -1,8 +1,8 @@ -Interaction Model - Matter

    Interaction Model

    Concepts

    The Data Model (DM) of a Node isn’t relevant if we can’t perform operations on them. The Interaction Model (IM), defines a Node’s DM relationship with the DM of other Nodes: a common language for communication between DMs.

    Nodes interact with each other by:

    • Reading and Subscribing to Attributes and Events
    • Writing to Attributes
    • Invoking Commands

    Whenever a Node establishes an encrypted communication sequence with another Node, they constitute an Interaction relationship. Interactions may be composed of one or more Transactions, and Transactions are composed of one or more of Actions which can be understood as IM-level messages between Nodes.

    Hierarchy of Interaction Model

    Several Actions are supported on Transactions, such as a Read Request Action that requests an Attribute or Event from another Node, or its response, the Report Data Action, which carries the information back from the server to the client.

    Initiators and Targets

    The Node that initiates a Transaction is the Initiator, while the Node that responds is the Target. Typically the Initiator is a Client Cluster and the Target is a Server Cluster. However, there are exceptions to this pattern, such as in the Subscription Interactions analyzed further down in this section.

    Groups

    Nodes in Matter may belong to a Group. A Group of Devices is a mechanism for addressing and sending messages to several Devices in the same Action simultaneously. All Nodes in a Group share the same Group ID, a 16-bit integer.

    To accomplish group-level communication (Groupcast), Matter leverages IPv6 Multicast messages, and all Group members have the same Multicast address.

    Paths

    Whenever we want to interact with an Attribute, Event, or Command, we must specify the Path for this interaction: the location of an Attribute, Event or Command in the Data Model hierarchy of a Node. The caveat is that paths may also use Groups or Wildcard Operators to address several Nodes or Clusters simultaneously, aggregating these Interactions and thus decreasing the number of actions.

    This mechanism is important to enhance the responsiveness of communications. For example, when a user wants to shut down all lights, a voice assistant can establish a single interaction with several lights within a Group instead of a sequence of individual Interactions. If the Initiator creates individual Interactions with each light, it can generate human-perceptible latency in Device responsiveness. This effect causes the multiple Devices to react to a command with visible delays between them. This is often referred to as “popcorn effect”.

    A Path in Matter can be assembled using one of the options below:

    <path> = <node> <endpoint> <cluster> <attribute | event | command>
@@ -16,14 +16,14 @@
 Bob sends the response to Alice (and Eve).
 Eve holds the second intercepted message for a later replay. Since Bob never received the original second intercepted message from Alice, it will accept it. This message represent a security breach when the message encodes a command such as “open lock”.
 To prevent these types of attacks, Timed Actions set a maximum Transaction timeout at the start of the Transaction. Even if Eve manages to execute the first six steps of the attack vector, it will not be able to replay the message on step 7 due to an expired timeout on the Transaction.
    Timed Transactions increase the complexity and number of Actions. Thus they are not recommended for every Transaction, but only the critical operations on Devices that have control over physical or virtual security and privacy assets.
    SDK abstractions
    The sections Read Transactions, Write Transactions, and Invoke Transactions provide a high-level overview of the Interaction Model Actions performed by the SDK.
    The developer creating a product that uses the Matter SDK typically does not perform calls to execute Actions directly; the Actions are abstracted by SDK functions that will encapsulate them into an Interaction. However, understanding IM Actions is important to provide the engineer a good proficiency on the capabilities of Matter, as well as fine control over the SDK implementation.
    Read Transactions
    Read Transaction
    One of the first use cases when interacting with Nodes in Matter is the reading of an Attribute from another Node, such as a temperature value from a sensor. In such Interactions, the first Action that must be performed is the Read Request Action.
    Read Request Action
    Direction: Initiator -> Target
    In this Action the Initiator queries a Target providing:
    • Attribute Requests: a list of zero or more of the Target’s Attributes. This list is composed of zero or more Paths to the Target’s requested Attributes.
    • Event Requests: list of zero or more Paths to the Target’s requested Events.
-After the Read Request Action is received by the Target it will assemble a Report Data Action with the requested information.
    Read Transaction
    After the Read Request Action is received by the Target it will assemble a Report Data Action with the requested information.
    Report Data Action
    Direction: Target -> Initiator
    In this Action the Target responds with:
    • Attribute Reports: a list of zero or more of the 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, it must include an integer used to identify the subscription transaction.
    Status Response Action
    Direction: either Target -> Initiator or Initiator -> Target
    Once the Initiator receives the requested data, by default it must generate a Status Response Action. This action is sent from the Initiator, acknowledging the receipt of the reported data. If the flag Suppress Status Response is set, the Initiator must not send the Status Response Action.
    Once the Status Response Action is sent by the Initiator, or a Report Data Action is received by the Initiator with the Suppress Response flag enabled, the read/report query is finished.
    The Status Response Action simply contains a status field that will either acknowledge operation success or present a failure code.
    Read Restrictions
    The Read Request Action and Report Data Action are Unicast-only. Moreover, the Paths of these requests may not target a Group of Nodes.
    The Status Response Action is Unicast-only and can’t be generated as a response to a groupcast.
    Subscription Transaction
    Subscribe Request Action
    Direction: Initiator -> Target
    In addition to a singular Read Request Action, an Initiator may also subscribe to periodic updates of an Attribute or Event. Thus the same Report Data Action can be generated as a result of periodic data updates that follow a Subscription Transaction.
    A Subscription Interaction creates a relationship between two Nodes, in which the Target periodically generates Report Data Actions to the Initiator. The Initiator is the Subscriber and the Target is the Publisher.
    Subscription Transaction
    A Subscribe Request Action contains:
    • Min Interval Floor: the minimum interval between reports.
    • Max Interval Ceiling: the maximum interval between reports.
    • Attribute Reports: a list of zero or more of the reported Attributes requested in the Read Action Request.
    • Event Reports: a list of zero or more reported Events.
    After the Subscribe Request, the Target responds to the Initiator with a Report Data Action containing the first batch of reported data: the Primed Published Data.
    The Initiator then acknowledges the Report Data Action with a Status Response Action sent to the Target. Once the Target receives a Status Response Action reporting no errors, it sends a Subscribe Response Action.
    The Target will subsequently send Report Data Action periodically at the negotiated interval and the Initiator will respond to those Actions until the subscription is lost or cancelled.
    Subscribe Response Action
    Direction: Target -> Initiator
    This is the last Action on the Subscription Transaction and concludes the process. It includes:
    • Subscription ID: a integer that identifies the subscription.
    • Min Interval: the final, determined minimum interval between reports.
    • Max Interval: the final, determined maximum interval between reports.
    Subscribe Restrictions
    • The Subscribe Request Action and the Subscribe Response Action are Unicast-only actions.
    • All Report Data Actions in a Subscription Interaction must have the same Subscription ID.
    • If the Subscriber does not receive a Report Data Action within the maximum negotiated interval between Actions, the subscription will be terminated.
    • As a consequence of the previous rule, the Publisher may terminate a Subscription Interaction by simply stopping sending periodic Report Data Actions.
    • The Subscriber may terminate the Subscription Interaction by responding to a Report Data Action with an INACTIVE_SUBSCRIPTION status code.
    Write Transactions
    In the last section we discussed the reading interactions of Attributes and Events. In this section we’ll discuss the writing of Attributes, which is the change of an Attribute value on a Cluster such as Level.
    Untimed Write Transaction
    Write Request Action
    Direction: Initiator -> Target
    Similar to the Read Request Action, in this Action the Initiator provides the Target with:
    • Write Requests: a list of one or more tuples containing Path and data.
    • Timed Request: a flag that indicates whether this Action is part of a Timed Write Transaction.
    • Suppress Response: a flag that indicates whether the Response Status Action should be suppressed.
    Untimed Write Transaction
    Write Response Action
    Direction: Target -> Initiator
    After the Target receives the Write Request Action it will finalize the transaction with a Write Response Action that carries:
    • Write Responses: a list of paths and error codes for every Write Request sent on the Write Request Action.
    Untimed Write Restrictions
    The Write Request Action may be a groupcast, but in this case the Suppress Response flag must be set. The rationale is that otherwise the network might be flooded by simultaneous responses from every member of a group.
    To enable this behavior, the Path used in the Write Requests list may contain Groups and alternatively they may contain wildcards, but only on the Endpoint field.
    Timed Write Transaction
    Timed write transactions add a few steps to untimed write transactions.
    Timed request action
    Direction: Initiator -> Target
    A Initiator starts the Transaction sending this Action that contains:
    • Timeout: how many milliseconds this transaction may remain open. During this period the next action sent by the Initiator will be considered valid.
    Once the Timed Request Action is received, the Target must acknowledge the Timed Request Action with a Status Response Action. Once the Initiator receives a Status Response Action reporting no errors, it will send a Write Request Action.
    Write Request Action
    Same as the previously described Write Request Action.
    Write Response Action
    Same as the previously described Write Response Action.
    Timed Write Restrictions
    The Timed Request Action, the Write Request Action and the Write Response Action are unicast-only.
    Invoke Transactions
    Invoke Transactions are used for invoking one or more Cluster Commands on a Target Node. It is similar to remote procedures calls made to a command defined in the Cluster.
    In a similar way of Write Transactions, Invoke Transactions support Timed and Untimed Transactions. Please refer to the Timed and Untimed Actions section for further information on Timed Transactions.
    Untimed Invoke Transaction
    Invoke Request Action
    Direction: Initiator -> Target
    Similar to the Read Request Action and Write Request Action, in this Action the Initiator provides the Target with:
    • Invoke Requests: a list of paths to Cluster Commands, as well as optional arguments to the commands, named Command Fields.
    • Timed Request: a flag that indicates whether this action is part of a Timed Invoke Transaction.
    • Suppress Response: a flag that indicates whether the Invoke Response Action should be suppressed.
    • Interaction ID: an integer used for matching the Invoke Request Action to the Invoke Response Action.
    Untimed Invoke Transaction
    Invoke Response Action
    Direction: Target -> Initiator
    After the Target receives the Invoke Request Action it will finalize the transaction with an Invoke Response Action that carries:
    • Invoke Responses: a list of command responses or status for every invoke request sent.
    • Interaction ID: a integer used for matching the Invoke Response Action to the Invoke Request Action.
    Untimed Invoke Restrictions
    The Invoke Request Action may be a groupcast, but in this case the Suppress Response flag must be set. The rationale is that otherwise the network might be flooded by simultaneous responses from every member of a group.
    To enable this behavior the Path used in the Invoke Requests list may contain Groups and alternatively they may contain wildcards, but only on the Endpoint field. Moreover, if the Action is groupcast, this transaction terminates with no response.
    Timed Invoke Transactions
    Similar to Timed Write Transactions, Timed Invoke Transactions also start with the Timed Request Action.
    Timed Request Action
    Direction: Initiator -> Target
    A Initiator starts the Transaction sending this Action that contains:
    • Timeout: how many milliseconds this transaction may remain open. During this period the next action sent by the Initiator will be considered valid.
    Once the Timed Request Action is received, the Target must acknowledge the Timed Request Action with a Status Response Action. Once the Initiator receives a Status Response Action reporting no errors, it will send a Invoke Request Action.
    Timed Invoke Transaction
    Invoke Request Action
    Same as the previously described Invoke Request Action.
    Invoke Response Action
    Same as the previously described Invoke Response Action
    Timed Invoke Restrictions
    All invoke commands may be called on a Timed Interaction. The Timed Request Action, the Invoke Request Action and the Invoke Response Action are Unicast-only and thus can’t be used as groupcast on Timed Invoke Transactions.
    The Invoke Request Action supports the usage of paths with Groups, as well as wildcards, but the Invoke Response Action does not support wildcard usage.
    This content was originally published on the Google Developer Site
    - - - - - - - - +After the Read Request Action is received by the Target it will assemble a Report Data Action with the requested information.

    Read Transaction

    After the Read Request Action is received by the Target it will assemble a Report Data Action with the requested information.

    Report Data Action

    Direction: Target -> Initiator

    In this Action the Target responds with:

    • Attribute Reports: a list of zero or more of the 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, it must include an integer used to identify the subscription transaction.

    Status Response Action

    Direction: either Target -> Initiator or Initiator -> Target

    Once the Initiator receives the requested data, by default it must generate a Status Response Action. This action is sent from the Initiator, acknowledging the receipt of the reported data. If the flag Suppress Status Response is set, the Initiator must not send the Status Response Action.

    Once the Status Response Action is sent by the Initiator, or a Report Data Action is received by the Initiator with the Suppress Response flag enabled, the read/report query is finished.

    The Status Response Action simply contains a status field that will either acknowledge operation success or present a failure code.

    Read Restrictions

    The Read Request Action and Report Data Action are Unicast-only. Moreover, the Paths of these requests may not target a Group of Nodes.

    The Status Response Action is Unicast-only and can’t be generated as a response to a groupcast.

    Subscription Transaction

    Subscribe Request Action

    Direction: Initiator -> Target

    In addition to a singular Read Request Action, an Initiator may also subscribe to periodic updates of an Attribute or Event. Thus the same Report Data Action can be generated as a result of periodic data updates that follow a Subscription Transaction.

    A Subscription Interaction creates a relationship between two Nodes, in which the Target periodically generates Report Data Actions to the Initiator. The Initiator is the Subscriber and the Target is the Publisher.

    Subscription Transaction

    A Subscribe Request Action contains:

    • Min Interval Floor: the minimum interval between reports.
    • Max Interval Ceiling: the maximum interval between reports.
    • Attribute Reports: a list of zero or more of the reported Attributes requested in the Read Action Request.
    • Event Reports: a list of zero or more reported Events.

    After the Subscribe Request, the Target responds to the Initiator with a Report Data Action containing the first batch of reported data: the Primed Published Data.

    The Initiator then acknowledges the Report Data Action with a Status Response Action sent to the Target. Once the Target receives a Status Response Action reporting no errors, it sends a Subscribe Response Action.

    The Target will subsequently send Report Data Action periodically at the negotiated interval and the Initiator will respond to those Actions until the subscription is lost or cancelled.

    Subscribe Response Action

    Direction: Target -> Initiator

    This is the last Action on the Subscription Transaction and concludes the process. It includes:

    • Subscription ID: a integer that identifies the subscription.
    • Min Interval: the final, determined minimum interval between reports.
    • Max Interval: the final, determined maximum interval between reports.

    Subscribe Restrictions

    • The Subscribe Request Action and the Subscribe Response Action are Unicast-only actions.
    • All Report Data Actions in a Subscription Interaction must have the same Subscription ID.
    • If the Subscriber does not receive a Report Data Action within the maximum negotiated interval between Actions, the subscription will be terminated.
    • As a consequence of the previous rule, the Publisher may terminate a Subscription Interaction by simply stopping sending periodic Report Data Actions.
    • The Subscriber may terminate the Subscription Interaction by responding to a Report Data Action with an INACTIVE_SUBSCRIPTION status code.

    Write Transactions

    In the last section we discussed the reading interactions of Attributes and Events. In this section we’ll discuss the writing of Attributes, which is the change of an Attribute value on a Cluster such as Level.

    Untimed Write Transaction

    Write Request Action

    Direction: Initiator -> Target

    Similar to the Read Request Action, in this Action the Initiator provides the Target with:

    • Write Requests: a list of one or more tuples containing Path and data.
    • Timed Request: a flag that indicates whether this Action is part of a Timed Write Transaction.
    • Suppress Response: a flag that indicates whether the Response Status Action should be suppressed.

    Untimed Write Transaction

    Write Response Action

    Direction: Target -> Initiator

    After the Target receives the Write Request Action it will finalize the transaction with a Write Response Action that carries:

    • Write Responses: a list of paths and error codes for every Write Request sent on the Write Request Action.

    Untimed Write Restrictions

    The Write Request Action may be a groupcast, but in this case the Suppress Response flag must be set. The rationale is that otherwise the network might be flooded by simultaneous responses from every member of a group.

    To enable this behavior, the Path used in the Write Requests list may contain Groups and alternatively they may contain wildcards, but only on the Endpoint field.

    Timed Write Transaction

    Timed write transactions add a few steps to untimed write transactions.

    Timed request action

    Direction: Initiator -> Target

    A Initiator starts the Transaction sending this Action that contains:

    • Timeout: how many milliseconds this transaction may remain open. During this period the next action sent by the Initiator will be considered valid.

    Once the Timed Request Action is received, the Target must acknowledge the Timed Request Action with a Status Response Action. Once the Initiator receives a Status Response Action reporting no errors, it will send a Write Request Action.

    Write Request Action

    Same as the previously described Write Request Action.

    Write Response Action

    Same as the previously described Write Response Action.

    Timed Write Restrictions

    The Timed Request Action, the Write Request Action and the Write Response Action are unicast-only.

    Invoke Transactions

    Invoke Transactions are used for invoking one or more Cluster Commands on a Target Node. It is similar to remote procedures calls made to a command defined in the Cluster.

    In a similar way of Write Transactions, Invoke Transactions support Timed and Untimed Transactions. Please refer to the Timed and Untimed Actions section for further information on Timed Transactions.

    Untimed Invoke Transaction

    Invoke Request Action

    Direction: Initiator -> Target

    Similar to the Read Request Action and Write Request Action, in this Action the Initiator provides the Target with:

    • Invoke Requests: a list of paths to Cluster Commands, as well as optional arguments to the commands, named Command Fields.
    • Timed Request: a flag that indicates whether this action is part of a Timed Invoke Transaction.
    • Suppress Response: a flag that indicates whether the Invoke Response Action should be suppressed.
    • Interaction ID: an integer used for matching the Invoke Request Action to the Invoke Response Action.

    Untimed Invoke Transaction

    Invoke Response Action

    Direction: Target -> Initiator

    After the Target receives the Invoke Request Action it will finalize the transaction with an Invoke Response Action that carries:

    • Invoke Responses: a list of command responses or status for every invoke request sent.
    • Interaction ID: a integer used for matching the Invoke Response Action to the Invoke Request Action.

    Untimed Invoke Restrictions

    The Invoke Request Action may be a groupcast, but in this case the Suppress Response flag must be set. The rationale is that otherwise the network might be flooded by simultaneous responses from every member of a group.

    To enable this behavior the Path used in the Invoke Requests list may contain Groups and alternatively they may contain wildcards, but only on the Endpoint field. Moreover, if the Action is groupcast, this transaction terminates with no response.

    Timed Invoke Transactions

    Similar to Timed Write Transactions, Timed Invoke Transactions also start with the Timed Request Action.

    Timed Request Action

    Direction: Initiator -> Target

    A Initiator starts the Transaction sending this Action that contains:

    • Timeout: how many milliseconds this transaction may remain open. During this period the next action sent by the Initiator will be considered valid.

    Once the Timed Request Action is received, the Target must acknowledge the Timed Request Action with a Status Response Action. Once the Initiator receives a Status Response Action reporting no errors, it will send a Invoke Request Action.

    Timed Invoke Transaction

    Invoke Request Action

    Same as the previously described Invoke Request Action.

    Invoke Response Action

    Same as the previously described Invoke Response Action

    Timed Invoke Restrictions

    All invoke commands may be called on a Timed Interaction. The Timed Request Action, the Invoke Request Action and the Invoke Response Action are Unicast-only and thus can’t be used as groupcast on Timed Invoke Transactions.

    The Invoke Request Action supports the usage of paths with Groups, as well as wildcards, but the Invoke Response Action does not support wildcard usage.

    This content was originally published on the Google Developer Site

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/roles/index.html b/pr-preview/pr-4/howitworks/roles/index.html index 0f75595..2d6054e 100644 --- a/pr-preview/pr-4/howitworks/roles/index.html +++ b/pr-preview/pr-4/howitworks/roles/index.html @@ -1,18 +1,18 @@ -Roles - Matter

    Roles

    An important note is that while these definitions explain the distinct roles as defined in the Matter specification, in many cases, the products in users’ homes have the ability to take on different roles or serve in multiple roles at once.

    Matter Device

    A smart home hardware product that supports Matter, so that it can be connected to and controlled by a Matter Controller. Examples: light bulbs, switches, sensors, thermostats, blinds, door locks, bridges, and media devices.

    Matter Fabric

    Matter Devices are connected together on a virtual network within the home called a Matter Fabric, a private virtual network over which Matter Devices, Admins, and Controllers communicate with each other. Matter Fabrics can span across the Wi-Fi, Thread, and Ethernet physical networks within the home. Matter Devices can be connected to one or more Fabrics at a time, each managed by a Matter Administrator. Sometimes Matter Fabrics are referred to as “services” by smart home apps and platforms.

    Matter Commissioner

    A device or application that is used as a tool to set up a Matter Device, in other words bring it into a Matter Fabric. Commissioners first verify the device’s authenticity and then assign network credentials as needed. A platform, device vendor, or other Matter-enabled app, mobile OS, smart speaker, or display may all provide a Matter Commissioner. A Commissioner can be an independent tool or part of a device or system that includes other roles such as Administrator or Controller.

    Matter Administrator

    A device or application that creates, maintains, and manages security and privileges for all devices on the Fabric it administers. Administrators can be a physical device like a hub or software like an app. Matter’s Multi-Admin feature which allows Devices to connect to multiple smart home platforms simultaneously, is a reference to connecting Devices to multiple Matter Administrators, and thus to multiple Fabrics.

    Matter Controller

    As the name suggests, a Matter Controller is an entity that can control Matter devices the user has connected to it. Matter Controller functionality can be built into many types of hardware devices like phones, always-powered smart home hubs that provide local and remote control, smart switches and buttons, or even mobile apps. There can be multiple Matter Controllers on a Fabric to provide redundancy and/or convenient controls for users.

    It’s important to note that in most cases, a Matter Controller is exclusive to the company that provides it. For instance, a smart speaker with a Matter Controller from Smart Home Platform A can be used to control Matter devices through the Platform A app, voice control, or other interfaces. But if you want to use Platform B to control Matter devices, you’ll need to have one of Platform B’s Controllers. An exception to this is devices such as switches, buttons, sensors, etc that can be commissioned as third-party Controllers onto a Fabric.

    With Matter’s Multi-Admin features, you can connect Matter devices to multiple platforms if you have a Matter Controller for each platform in your home.

    Matter Controller is the technical term for this role, though note that many smart home platforms colloquially refer to their devices that contain Matter Controllers as “hubs” (see below).

    Matter Bridge

    A Matter Bridge translates from one protocol to another, allowing non-Matter smart home devices (such as those using Zigbee or Z-Wave) to connect to a Matter Fabric via the Bridge. This allows consumers to use their non-Matter smart home devices along with their new Matter devices to continue growing their unified smart home.

    A Matter Bridge is a different role than a Controller. A bridge serves as an intermediary for Matter and non-Matter devices. However, Bridges may be built into a number of devices like smart home “hubs” that also serve as Matter Controllers. For a deeper dive read Why Bridging Matters.

    This content was first published on the Alliance website as a blog

    - - - - - - - - +Roles

    Roles

    An important note is that while these definitions explain the distinct roles as defined in the Matter specification, in many cases, the products in users’ homes have the ability to take on different roles or serve in multiple roles at once.

    Matter Device

    A smart home hardware product that supports Matter, so that it can be connected to and controlled by a Matter Controller. Examples: light bulbs, switches, sensors, thermostats, blinds, door locks, bridges, and media devices.

    Matter Fabric

    Matter Devices are connected together on a virtual network within the home called a Matter Fabric, a private virtual network over which Matter Devices, Admins, and Controllers communicate with each other. Matter Fabrics can span across the Wi-Fi, Thread, and Ethernet physical networks within the home. Matter Devices can be connected to one or more Fabrics at a time, each managed by a Matter Administrator. Sometimes Matter Fabrics are referred to as “services” by smart home apps and platforms.

    Matter Commissioner

    A device or application that is used as a tool to set up a Matter Device, in other words bring it into a Matter Fabric. Commissioners first verify the device’s authenticity and then assign network credentials as needed. A platform, device vendor, or other Matter-enabled app, mobile OS, smart speaker, or display may all provide a Matter Commissioner. A Commissioner can be an independent tool or part of a device or system that includes other roles such as Administrator or Controller.

    Matter Administrator

    A device or application that creates, maintains, and manages security and privileges for all devices on the Fabric it administers. Administrators can be a physical device like a hub or software like an app. Matter’s Multi-Admin feature which allows Devices to connect to multiple smart home platforms simultaneously, is a reference to connecting Devices to multiple Matter Administrators, and thus to multiple Fabrics.

    Matter Controller

    As the name suggests, a Matter Controller is an entity that can control Matter devices the user has connected to it. Matter Controller functionality can be built into many types of hardware devices like phones, always-powered smart home hubs that provide local and remote control, smart switches and buttons, or even mobile apps. There can be multiple Matter Controllers on a Fabric to provide redundancy and/or convenient controls for users.

    It’s important to note that in most cases, a Matter Controller is exclusive to the company that provides it. For instance, a smart speaker with a Matter Controller from Smart Home Platform A can be used to control Matter devices through the Platform A app, voice control, or other interfaces. But if you want to use Platform B to control Matter devices, you’ll need to have one of Platform B’s Controllers. An exception to this is devices such as switches, buttons, sensors, etc that can be commissioned as third-party Controllers onto a Fabric.

    With Matter’s Multi-Admin features, you can connect Matter devices to multiple platforms if you have a Matter Controller for each platform in your home.

    Matter Controller is the technical term for this role, though note that many smart home platforms colloquially refer to their devices that contain Matter Controllers as “hubs” (see below).

    Matter Bridge

    A Matter Bridge translates from one protocol to another, allowing non-Matter smart home devices (such as those using Zigbee or Z-Wave) to connect to a Matter Fabric via the Bridge. This allows consumers to use their non-Matter smart home devices along with their new Matter devices to continue growing their unified smart home.

    A Matter Bridge is a different role than a Controller. A bridge serves as an intermediary for Matter and non-Matter devices. However, Bridges may be built into a number of devices like smart home “hubs” that also serve as Matter Controllers. For a deeper dive read Why Bridging Matters.

    This content was first published on the Alliance website as a blog

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/security/index.html b/pr-preview/pr-4/howitworks/security/index.html index cea5bf5..3d826ab 100644 --- a/pr-preview/pr-4/howitworks/security/index.html +++ b/pr-preview/pr-4/howitworks/security/index.html @@ -1,8 +1,8 @@ -Security & Privacy - Matter

    Security & Privacy

    Matter was created with security and privacy as key design tenets and provides @@ -12,14 +12,14 @@ and infrastructure that Matter devices operate in is needed

    Confidentiality & Integrity

    Matter uses the highest possible level of civilian cryptographic standards for network communications to ensure that unauthorized entities cannot easily access or tamper with data communicated between Matter devices

    Proof of identity

    Required for Matter devices with cryptographic certificates so data is shared only between known Matter entities

    Open standard

    Enables anyone to inspect the template for Matter interactions between legitimate Matter nodes

    Minimizing data

    Data shared within Matter interactions is minimized, thereby reducing the potential for inadvertent leakage of information

    Defined purpose

    Data shared between Matter nodes is strictly for a defined purpose, namely, for the specific operations of devices as required by the Matter protocol

    ### Privacy preserving mechanisms -Encryption to ensure that messages or identities of communicating parties are not in cleartext on the network

    - - - - - - - - +Encryption to ensure that messages or identities of communicating parties are not in cleartext on the network

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/thread/index.html b/pr-preview/pr-4/howitworks/thread/index.html index 3463881..1e63584 100644 --- a/pr-preview/pr-4/howitworks/thread/index.html +++ b/pr-preview/pr-4/howitworks/thread/index.html @@ -1,19 +1,19 @@ -Thread - Matter

    Thread

    Low Power

    Some Matter Nodes are wired and have energy budgets that allow them to keep their radios continuously on. Other types of Nodes such as sensors have requirements to run for years on a battery, operating their radios on low-power networks such as Thread. The proxy architecture, along with Thread Sleepy End Devices, allows full-powered Nodes to provide both network-level and application-level functionality that insulates their child Nodes from energy-intensive transactions.

    A fundamental aspect of Matter is that it works both on high-throughput network mediums such as Wi-Fi and Ethernet, but also on low-latency, low-bandwidth, such as Thread. If all Multicast packets from Wi-Fi were bridged into Thread, we’d overburden the network, and potentially flood it. Thread’s goal is to enable IPv6 in low-power, low-latency mesh networking, not high-bandwidth data transfer. While Thread’s ICMPv6 pings in a local network are typically under few tens of milliseconds RTT, its total bandwidth is limited to 250 kbps at the IEEE 802.15.4 PHY. With packet retransmissions and overhead, the typical max bandwidth is around 125 kbps. In other words, orders of magnitude less than Wi-Fi.

    Frames on the IEEE 802.15.4 PHY are 127 bytes, but the largest (and typical) maximum transmission unit (MTU) of IPv6 packets in Thread is 1280 bytes. Thus IPv6 packets often need to be split into several PHY frames. This process is defined by RFC 4944.

    To learn more, refer to IPv6 Addressing in the Thread Primer on openthread.io.

    Border Routers

    So how can Nodes coexist on both transport mediums while in the same fabric? Although both networks share application-level Matter credentials, they don’t share the same link technology. In this scenario, the network needs a Thread Border Router (BR) to enable connectivity. BRs are Stub IPv6 Routers.

    Stub Routers enable connectivity between stub networks and regular networks. A Stub Network is a “last-mile” network that provides outer connectivity to its members, but doesn’t serve as a transit network path between other networks. Typically, Matter Stub Networks are Thread-based. Refer to RFC draft for further information on stub networks.

    BRs therefore have the responsibility of being the link between the Stub Network and the Adjacent Infrastructure Network, which is the local Wi-Fi or Ethernet network. They forward only the packets that are relevant to the Thread network.

    This process is accomplished by assigning different IPv6 prefixes to Thread and Adjacent Infrastructure Networks. Thus the BR only forwards unicasts to or from the Thread IPv6 prefix.

    Border Routers are also responsible for:

    • automatically configuring IPv6 prefixes and routes for both the Thread and Adjacent Infrastructure Networks so that hosts on either side of the Thread Border router can communicate.
    • publishing mDNS DNS-SD discovery packets on behalf of Thread Nodes, so they can be discovered on the adjacent infrastructure network.

    To learn more, refer to the Border Router guide on openthread.io.

    IPv6 Multicast

    Group messages are also important as they allow simultaneous control of several Matter Nodes through Multicast. In order to route this traffic into the Thread network, both Matter and Thread implement the Unicast Prefix-based IPv6 Multicast Addressing Scheme defined by RFC 3306.

    This method allows the selection of the destination Nodes of a Multicast packet based on their shared IPv6 Unicast prefix.

    For example, a Matter Multicast address might look like this: -FF35:0040:FD<Fabric ID>00:<Group ID>

    This Table details how this address is constructed:

    BitsDescription
    12 bits0xFF3
    4 bits0x05 Scope: site-local
    8 bits0x00 reserved
    8 bits0x40 Indicates a 64-bit long prefix
    8 bits0xFD Designates a ULA prefix
    56 bitsFabric ID
    8 bits0x00
    16 bitsGroup ID

    More information can be found in the Multicast section of the Thread Primer and on the RFC itself.

    When IPv6 Multicast Addresses are formed, they also include the upper 56-bits of the Fabric ID. The important implication is that the scope of Multicast is within a Fabric, while Unicast addresses are shared between Fabrics. Nodes with many fabrics can potentially have several Multicast addresses defining overlapping Node Groups scoped at each fabric.

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

    This Table details how this address is constructed:

    BitsDescription
    12 bits0xFF3
    4 bits0x05 Scope: site-local
    8 bits0x00 reserved
    8 bits0x40 Indicates a 64-bit long prefix
    8 bits0xFD Designates a ULA prefix
    56 bitsFabric ID
    8 bits0x00
    16 bitsGroup ID

    More information can be found in the Multicast section of the Thread Primer and on the RFC itself.

    When IPv6 Multicast Addresses are formed, they also include the upper 56-bits of the Fabric ID. The important implication is that the scope of Multicast is within a Fabric, while Unicast addresses are shared between Fabrics. Nodes with many fabrics can potentially have several Multicast addresses defining overlapping Node Groups scoped at each fabric.

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/howitworks/whatismatter/index.html b/pr-preview/pr-4/howitworks/whatismatter/index.html index d238b12..6a846e9 100644 --- a/pr-preview/pr-4/howitworks/whatismatter/index.html +++ b/pr-preview/pr-4/howitworks/whatismatter/index.html @@ -1,18 +1,18 @@ -What is Matter - Matter

    What is Matter

    Matter has the goal of being an interoperable standard that fosters technology adoption and innovation, gradually replacing proprietary protocols for smart home ecosystems.

    Matter is implemented by an open source SDK that contains not only the implementation of the specification but also a rich set of examples and interoperable code. The core Matter protocol fits on the top three layers in the context of OSI, meaning it can run over any type of IPv6 transport and network. While control and other operational communication are performed over IPv6, Bluetooth Low Energy (BLE) may be employed to commission new devices.

    The Matter Network Stack

    Matter is flexible and interoperable. It builds upon years of challenges and successes of low power 802.15.4 networks as well as Wi-Fi smart home devices. Like Thread, Matter builds atop IPv6. It includes strong cryptography, a well-defined modeling of Device Types and their data, and the support for multiple ecosystem administrators.

    Matter also supports bridging of other Smart Home technologies such as Zigbee, Bluetooth Mesh and Z-Wave. This means that devices based on these protocols may be operated as if they were Matter devices through a Bridge, which is a member device of both a Matter network and the other, bridged, IoT technologies.

    There is a dual advantage to Bridges. The devices that use other protocols gain access to technologies and ecosystems that target native Matter devices. Meanwhile Matter will leverage mature technologies with large installed user bases to create a true web of connected things.

    This content was originally published on the Google Developer Site

    - - - - - - - - +What is Matter

    What is Matter

    Matter has the goal of being an interoperable standard that fosters technology adoption and innovation, gradually replacing proprietary protocols for smart home ecosystems.

    Matter is implemented by an open source SDK that contains not only the implementation of the specification but also a rich set of examples and interoperable code. The core Matter protocol fits on the top three layers in the context of OSI, meaning it can run over any type of IPv6 transport and network. While control and other operational communication are performed over IPv6, Bluetooth Low Energy (BLE) may be employed to commission new devices.

    The Matter Network Stack

    Matter is flexible and interoperable. It builds upon years of challenges and successes of low power 802.15.4 networks as well as Wi-Fi smart home devices. Like Thread, Matter builds atop IPv6. It includes strong cryptography, a well-defined modeling of Device Types and their data, and the support for multiple ecosystem administrators.

    Matter also supports bridging of other Smart Home technologies such as Zigbee, Bluetooth Mesh and Z-Wave. This means that devices based on these protocols may be operated as if they were Matter devices through a Bridge, which is a member device of both a Matter network and the other, bridged, IoT technologies.

    There is a dual advantage to Bridges. The devices that use other protocols gain access to technologies and ecosystems that target native Matter devices. Meanwhile Matter will leverage mature technologies with large installed user bases to create a true web of connected things.

    This content was originally published on the Google Developer Site

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/index.html b/pr-preview/pr-4/index.html index 9800c26..6cdf6a0 100644 --- a/pr-preview/pr-4/index.html +++ b/pr-preview/pr-4/index.html @@ -1,15 +1,15 @@ -Welcome - Matter
    navigation

    Welcome

    Welcome to the Matter Handbook. This handbook is here to help make building and shipping devices with Matter easier by providing answers to common questions. Inside, you’ll find information on everything from getting started with the Working Groups, the basics of Matter, navigating the SDK, and more.

    In the spirit of openness, we’ve tried to capture as much information here as possible. That includes links to resources that are only available to members of the Connectivity Standards Alliance. If you’re not a member and you find yourself clicking through to many of those password-protected areas, we encourage you to consider joining the Alliance to work with us there. If you’re a member of the media and have more questions, we encourage you to take a look at our Newsroom or reach out to press@csa-iot.org.

    This handbook is compiled from contributions from our member volunteers. If you have suggestions, edits, or comments, either raise an issue or submit a PR on the GitHub Repository.

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/index.xml b/pr-preview/pr-4/index.xml index fa99641..3c6c6a6 100644 --- a/pr-preview/pr-4/index.xml +++ b/pr-preview/pr-4/index.xml @@ -13,7 +13,7 @@ Devices and Endpoints All Devices, including smartphones and home assistants, ar Matter treats networks as shared resources: it makes no stipulation of exclusive network owner­ship or access.    Resourceshttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/alliance/resources/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/alliance/resources/Resources for Members If you are already a member of the Alliance, here are some helpful links found in Causeway (you&rsquo;ll need to log in with your member credentials). New Member Orientation Slides Group Links Matter Working Group How to Join the Matter Working Group and Subgroups (pg. 32-35) Meeting Calendar for Matter Working Groups and Subroups Not seeing a calendar for a specific group? Make sure you’re a member of that group for visibility Subgroups Matter CSG Matter MPSG Matter TSG Tools Collaboration Tools (pg.Interaction Modelhttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/interactionmodel/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/interactionmodel/Concepts The Data Model (DM) of a Node isn&rsquo;t relevant if we can&rsquo;t perform operations on them. The Interaction Model (IM), defines a Node&rsquo;s DM relationship with the DM of other Nodes: a common language for communication between DMs. Nodes interact with each other by: -Reading and Subscribing to Attributes and Events Writing to Attributes Invoking Commands Whenever a Node establishes an encrypted communication sequence with another Node, they constitute an Interaction relationship.Discoveryhttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/discovery/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/discovery/Commissionable discovery Commissionable discovery happens before Commissioning and refers to the process of discovering and identifying a commissionable Node. There are three methods through which a commissionable Node may advertise itself: +Reading and Subscribing to Attributes and Events Writing to Attributes Invoking Commands Whenever a Node establishes an encrypted communication sequence with another Node, they constitute an Interaction relationship.Discoveryhttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/discovery/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/discovery/Commissionable discovery Commissionable discovery happens before Commissioning and refers to the process of discovering and identifying a commissionable Node. There are two methods through which a commissionable Node may advertise itself: Bluetooth low energy (BLE) DNS-SD on an any IP network the Node is connected to In either method, the commissionable node advertises information as shown in the table below. Field Length Required Discriminator 12 bit Yes Vendor ID 16 bit No Product ID 16 bit No Extended data variable No As per the Matter specification, Vendor ID and Product ID are not required but can be included.The Fabrichttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/fabric/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/fabric/The Matter spec uses sophisticated methods for encrypting and decrypting information, as well as safe mechanisms for assuring a Node&rsquo;s identity and sharing cryptographic credentials. Whenever a set of Devices in a network shares the same security domain, and thus allows secure communication between Nodes, this set is called a Fabric. Devices within a fabric share the same Certificate Authority (CA) top-level certificate (Root of Trust) and a 64-bit identifier named Fabric ID, unique within the context of that CA.Commissioninghttps://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/commisioning/Mon, 01 Jan 0001 00:00:00 +0000https://project-chip.github.io/matter-handbook/pr-preview/pr-4/howitworks/commisioning/Commissioning in Matter refers to the process of assigning Fabric credentials to a new device or app. The Commissioner is the device or app that does the Commissioning process. The Commissionee is the new device or app that needs to be provisioned into the Fabric. diff --git a/pr-preview/pr-4/sdk/index.html b/pr-preview/pr-4/sdk/index.html index 620cf8e..86b5d56 100644 --- a/pr-preview/pr-4/sdk/index.html +++ b/pr-preview/pr-4/sdk/index.html @@ -1,20 +1,20 @@ -SDK - Matter

    The Matter SDK

    The Matter Software Development Kit is a collection of tools to facilitate building Matter devices and control applications. The SDK comprises of several different components to guide the development process.

    ZAP

    The ZAP tool is a GUI tool that is used to generate a .zap file which describes the endpoint composition of your device, and the clusters that are on it along with their attributes, commands, features, etc. This .zap file is used by the ZAP compiler along with the cluster definitions from the SDK to generate an Ember layer. This happens automatically as part of the build process, and the Ember layer is compiled into the firmware.

    The tool produces .matter files which are a human-readable version of the .zap that can be used for review.

    Ember

    The Ember layer is a generated layer that implements the composition of ONE SPECIFIC device. It looks at each message and determines if the device has implemented the selected attribute or command on the cluster on the selected endpoint, and then blocks or routes accordingly, based on the implementation and the access control. Valid requests are forwarded on to the cluster implementations to handle and invalid requests get sent back with an error. Ember layer is the piece that makes your device your device. Most are generated statically using zap.

    Chef

    Chef is a tool to help generate sample device type zap configuration files which can be further customised with the ZAP tool.

    Core

    The Core src folder contains the underlying Matter interoperability layers that provide essential functionality. These are used by the build process.

    CHIP Tool

    CHIP Tool is our example controller app, used for development and testing of your Matter device.

    GN/Ninja

    GN is part of the build system which was originally developed for the Chromium browser project, it is used to configure the build of a Matter device. -Ninja is the component which builds the device image.

    Platform Layer

    The platform layer contains device specific delegate implementations for most of the common architectures on which Matter is deployed.

    Abstraction Layers

    The SDK contains absctraction layters for Python, Java and Kotlin controllers.

    The SDK is publically avalible on GitHub

    - - - - - - - - +Ninja is the component which builds the device image.

    Platform Layer

    The platform layer contains device specific delegate implementations for most of the common architectures on which Matter is deployed.

    Abstraction Layers

    The SDK contains absctraction layters for Python, Java and Kotlin controllers.

    The SDK is publically avalible on GitHub

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/specification/index.html b/pr-preview/pr-4/specification/index.html index b2dcc4a..5cb69b2 100644 --- a/pr-preview/pr-4/specification/index.html +++ b/pr-preview/pr-4/specification/index.html @@ -1,17 +1,17 @@ -Specification - Matter

    The Matter Specifications

    The Matter Specification is updated twice a year in Spring and Fall.

    • Version 1.0 was published in November 2022
    • Version 1.1 was published in April 2023
    • Version 1.2 was published in October 2023

    The specification is made up of a number of documents:

    • The Core Specification defines the components and how they interact along with a number of common procdedures.
    • The Application Cluster Specification details the data models used by each cluster that makes up an endpoint.
    • The Device Library Specification sets out the types of End User device in Matter and which Application Clusters make up that device.
    • The Namespace Specification (introduced in 1.2) details common data formats and structures used across multiple clusters.

    All these documents can be downloaded from The Alliance website.

    - - - - - - - - +Specification

    The Matter Specifications

    The Matter Specification is updated twice a year in Spring and Fall.

    • Version 1.0 was published in November 2022
    • Version 1.1 was published in April 2023
    • Version 1.2 was published in October 2023

    The specification is made up of a number of documents:

    • The Core Specification defines the components and how they interact along with a number of common procdedures.
    • The Application Cluster Specification details the data models used by each cluster that makes up an endpoint.
    • The Device Library Specification sets out the types of End User device in Matter and which Application Clusters make up that device.
    • The Namespace Specification (introduced in 1.2) details common data formats and structures used across multiple clusters.

    All these documents can be downloaded from The Alliance website.

    + + + + + + + + \ No newline at end of file diff --git a/pr-preview/pr-4/tags/index.html b/pr-preview/pr-4/tags/index.html index f9f7152..2650f10 100644 --- a/pr-preview/pr-4/tags/index.html +++ b/pr-preview/pr-4/tags/index.html @@ -1,18 +1,18 @@ -Tags - Matter

    tag :: -Tags

      - - - - - - - - +Tags
        + + + + + + + + \ No newline at end of file