diff --git a/content/HowItWorks/Attestation.md b/content/HowItWorks/Attestation.md index b033287..a5b5b5a 100644 --- a/content/HowItWorks/Attestation.md +++ b/content/HowItWorks/Attestation.md @@ -39,7 +39,7 @@ The DAC's signature is validated against the Product Attestation Intermediate Ce At the root of the chain of trust stands the PAA CA's public key, which 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](../../static/primer-attestation-pki.png) +![Matter Attestation Public Key Infrastructure](../../primer-attestation-pki.png) The PAI is also a X.509 v3 certificate that includes: @@ -64,7 +64,7 @@ Lastly, the PAA is the root certificate in the chain and it is self-signed. It i 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](../../static/primer-attestation-document-hierarchy.png) +![Attestation Document Hierarchy](../../primer-attestation-document-hierarchy.png) ### Certification Declaration (CD) diff --git a/content/HowItWorks/Commisioning.md b/content/HowItWorks/Commisioning.md index 9f7247d..43b2a55 100644 --- a/content/HowItWorks/Commisioning.md +++ b/content/HowItWorks/Commisioning.md @@ -8,11 +8,11 @@ Commissioning in Matter refers to the process of assigning Fabric credentials to At a high-level, the commissioning flow can be broken down into multiple stages: -![Commissioning Flow - High Level](../../static/primer-commissioning.png) +![Commissioning Flow - High Level](../../primer-commissioning.png) ## 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](../HowItWorks/Discovery.md#commissionable-discovery) methods. The Commissionee must also provide the onboarding payload. +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](/howitworks/discovery/#commissionable-discovery) methods. The Commissionee must also provide the onboarding payload. ## 2 Connect to device using PASE @@ -44,7 +44,7 @@ The Commissioner configures the operational network on the Commissionee. This st ## 9 Operational discovery -Once the newly commissioned node is connected to the network, the Commissioner uses [Operational Discovery](../HowItWorks/Discovery.md#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. +Once the newly commissioned node is connected to the network, the Commissioner uses [Operational Discovery](/howitworks/discovery/#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. diff --git a/content/HowItWorks/DataModel.md b/content/HowItWorks/DataModel.md index 594ab98..36809af 100644 --- a/content/HowItWorks/DataModel.md +++ b/content/HowItWorks/DataModel.md @@ -13,7 +13,7 @@ All Devices, including smartphones and home assistants, are composed of Nodes. A 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](../../static/primer-device-node.png) +![Devices Nodes and Endpoints](../../primer-device-node.png) ## Node Roles @@ -35,7 +35,7 @@ A Node may also have several Endpoints, each creating an instance of the same fu 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](../../static/primer-node-endpoint-attribute.png) +![Nodes, Endpoints, Attributes and Commands](../../primer-node-endpoint-attribute.png) ### Commands @@ -45,7 +45,7 @@ Besides Attributes, Clusters also have Commands, which are actions that may be p 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](../../static/primer-device-type.png) +![A sample of the hierarchy of Matter Devices interaction model](../../primer-device-type.png) 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. @@ -73,7 +73,7 @@ For instance, we may have two table lamps: Node A and Node B. Both nodes impleme 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](../../static/primer-client-server.png) +![Client and Server Clusters](../..//primer-client-server.png) 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. diff --git a/content/HowItWorks/Fabric.md b/content/HowItWorks/Fabric.md index 0857125..0c1a9f7 100644 --- a/content/HowItWorks/Fabric.md +++ b/content/HowItWorks/Fabric.md @@ -22,7 +22,7 @@ Node Operational Certificate (NOC) is the set of credentials that Nodes use to c 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](../../static/primer-csr.png) +![NOC Generation Dependencies](../../primer-csr.png) 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: diff --git a/content/HowItWorks/InteractionModel.md b/content/HowItWorks/InteractionModel.md index 197c3ab..8474030 100644 --- a/content/HowItWorks/InteractionModel.md +++ b/content/HowItWorks/InteractionModel.md @@ -16,7 +16,7 @@ Nodes interact with each other by: 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](../../static/primer-im-hierarchy.png) +![Hierarchy of Interaction Model](../../primer-im-hierarchy.png) 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. @@ -88,7 +88,7 @@ In this Action the Initiator queries a Target providing: - 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](../../static/primer-im-reading.png) +![Read Transaction](../../primer-im-reading.png) After the Read Request Action is received by the Target it will assemble a Report Data Action with the requested information. @@ -129,7 +129,7 @@ In addition to a singular Read Request Action, an Initiator may also subscribe t 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](../../static/primer-im-subscribing.png) +![Subscription Transaction](../../primer-im-subscribing.png) A Subscribe Request Action contains: @@ -178,7 +178,7 @@ Similar to the Read Request Action, in this Action the Initiator provides the Ta - 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](../../static/primer-im-untimed-writing.png) +![Untimed Write Transaction](../../primer-im-untimed-writing.png) #### Write Response Action @@ -239,7 +239,7 @@ Similar to the Read Request Action and Write Request Action, in this Action the - 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](../../static/primer-im-untimed-invoking.png) +![Untimed Invoke Transaction](../../primer-im-untimed-invoking.png) #### Invoke Response Action @@ -270,7 +270,7 @@ A Initiator starts the Transaction sending this Action that contains: 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](../../static/primer-im-timed-invoking.png) +![Timed Invoke Transaction](../../primer-im-timed-invoking.png) #### Invoke Request Action diff --git a/content/HowItWorks/WhatIsMatter.md b/content/HowItWorks/WhatIsMatter.md index fe3dd7c..e3563de 100644 --- a/content/HowItWorks/WhatIsMatter.md +++ b/content/HowItWorks/WhatIsMatter.md @@ -9,7 +9,7 @@ Matter has the goal of being an interoperable standard that fosters technology a 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](../../static/primer-matter-architecture.png) +![The Matter Network Stack](../../primer-matter-architecture.png) 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.