Bluetooth Mesh Fernbereitstellung

Technischer Überblick

Inhaltsverzeichnis anzeigen

Freigabe :	1.0.0
Dokument Version :	1.0
Zuletzt aktualisiert :	19. September 2023
Die Autoren :	Martin Woolley, Bluetooth SIG Omkar Kulkarni, Nordischer Halbleiter Piotr Winiarczyk, Silvair

Geschichte der Revision

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Omkar Kulkarni, Nordic Semiconductor Piotr Winiarczyk, Silvair	Initial version

 

Hinweis Die Bluetooth Mesh Profilspezifikation wurde umbenannt und heißt jetzt Bluetooth Mesh Protokoll Spezifikation. Referenzen in diesem und verwandten Papieren werden diesen Namen verwenden, wenn sie sich auf die Spezifikation der Version 1.1 beziehen, aber weiterhin die Spezifikation der Version 1.0 als Bluetooth Mesh Profil Spezifikation.

 

1. Hintergrund

Die Funktion der Fernbereitstellung wurde in Version 1.1 der Protokollspezifikation Bluetooth^® Mesh eingeführt. Um die Fähigkeiten und Vorteile dieser Funktion vollständig zu verstehen, müssen bestimmte Aspekte der Version 1.0 von Bluetooth Mesh verstanden werden. Dieser Abschnitt liefert den Kontext und den Hintergrund für die nachfolgende Betrachtung des Remote Provisioning.

1.1 Bereitstellung

Ein Gerät wird durch den Vorgang der Bereitstellung Mitglied eines Bluetooth Mesh Netzes. Die Bereitstellung ist ein Verfahren, das von einem Beauftragten mit einem Gerät oder einer Anwendung namens Provisioner durchgeführt wird. Die Bereitstellung eines Geräts führt dazu, dass es über bestimmte kritische Daten verfügt, einschließlich des primären Netzwerkschlüssels (NetKey) und eines eindeutigen Bereichs zusammenhängender Unicast-Adressen, die den Elementen des Geräts zugewiesen sind. Das Gerät, das der Bereitstellung unterzogen wird, wird als " Provisionee" bezeichnet.

Ursprünglich, wie in Version 1.0 der Bluetooth Mesh Profilspezifikation definiert, musste sich der Provisioner in direkter Funkreichweite des Provisionees befinden.

1.1.1 Das Bereitstellungsprotokoll

Ein Protokoll, das ausschließlich zum Zweck der Bereitstellung verwendet wird, wird als Bereitstellungsprotokoll bezeichnet. In der Version 1.0 der Bluetooth^® Mesh Profilspezifikation umfasste das Protokoll 10 verschiedene Arten von PDUs.

1.1.2 Bereitstellung von Trägern

In Bluetooth^® Mesh Version 1.0 konnte das Bereitstellungsprotokoll entweder mit Bluetooth LE-Werbepaketen oder GATT-Verfahren über eine Verbindung arbeiten. Die Verwendung von Advertising-Paketen als Container für Provisioning-Protokoll-PDUs wird als PB-ADV-Träger bezeichnet. Die Verwendung von GATT für die Bereitstellung ist als PB-GATT-Träger bekannt.

1.1.3 Die Etappen der Bereitstellung

Die Bereitstellung erfolgt in den folgenden fünf Phasen:

1. Beaconing
2. Einladung
3. Austausch öffentlicher Schlüssel
4. Authentifizierung
5. Verteilung von Bereitstellungsdaten

1.1.3.1 Befeuerung

Ein neues Gerät, das bereit ist, bereitgestellt zu werden, signalisiert seine Verfügbarkeit, indem es Bluetooth LE-Werbepakete eines oder zweier möglicher Typen sendet, je nachdem, welche(r) Träger das Gerät unterstützt. Wenn der PB-ADV-Träger unterstützt wird, werden unprovisionierte Gerätebaken als nicht verbindbare und nicht abfragbare, ungerichtete Bluetooth LE-Werbepakete gesendet. Wenn PB-GATT unterstützt wird, dann werden verbindungsfähige Werbepakete, die die UUID des mesh Bereitstellungsdienstes enthalten, gesendet. Wenn beide Träger unterstützt werden, werden diese beiden Formen der Werbung verschachtelt.

In beiden Fällen enthalten die Beaconing-Daten die Geräte-UUID des unprovisionierten Geräts. Die Geräte-UUID ist eine eindeutige Kennung für das Gerät, die sich während der Lebensdauer eines physischen oder Software-Produkts nicht ändert und in der Regel werkseitig vergeben wird.

1.1.3.2 Einladung

Der Provisioner sucht nach Baken von nicht bereitgestellten Geräten und/oder verbindungsfähigen Anzeigen, die die Unterstützung des GATT mesh Bereitstellungsdienstes anzeigen, und baut eine Sitzung (als Link bezeichnet) entweder auf einer PB-ADV oder PB-GATT Trägerinstanz mit einem ausgewählten, nicht bereitgestellten Gerät auf. Es sendet dann eine Provisioning Invite PDU, um den Provisioning-Prozess zu starten. Das Gerät, das nun als Provisionee bezeichnet wird, antwortet mit einer Provisioning Capabilities PDU, die Informationen enthält, die zur Steuerung der nächsten Schritte des Provisioning-Prozesses verwendet werden. Der Provisioner konstruiert eine Provisioning Start PDU mit einem auf diesen Informationen basierenden Inhalt und sendet sie.

1.1.3.3 Austausch von öffentlichen Schlüsseln

Elliptic Curve Cryptography (ECC) wird verwendet, um den NetKey sicher vom Provisioner auf das nicht provisionierte Gerät zu übertragen. ECC ist ein Ansatz für die Kryptografie öffentlicher Schlüssel, der auf den mathematischen Eigenschaften elliptischer Kurven basiert. Sie erfordert relativ kleine Schlüsselgrößen und eignet sich gut für Geräte, deren Rechenleistung begrenzt ist.

Der Bereitsteller generiert ein ephemeres öffentliches/privates Schlüsselpaar und sendet seinen öffentlichen Schlüssel über die Verbindung Bluetooth unter Verwendung des ausgewählten Trägers an den Bereitstellungsempfänger. Der Provisionee kann seinen öffentlichen Schlüssel entweder über dieselbe Verbindung senden oder ihn zur Erhöhung der Sicherheit mit einer "Out-of-Band "-Methode (OOB) übermitteln, z. B. über einen QR-Code oder mittels Near Field Communications (NFC). Das Paar aus öffentlichem und privatem Schlüssel des Bereitstellungsempfängers kann statisch definiert oder dynamisch erzeugt werden.

Sobald man im Besitz der öffentlichen Schlüssel des anderen ist, ermöglicht ein Schlüsselvereinbarungsprotokoll die Berechnung eines gemeinsamen Geheimnisses, aus dem ein Sitzungsschlüssel berechnet wird. Der Sitzungsschlüssel wird dann zur Sicherung der NetKey-Übertragung verwendet. Das gemeinsam genutzte Geheimnis wird auch zur Berechnung des Bestätigungsschlüssels, der im Authentifizierungsschritt verwendet wird, und des Geräteschlüssels des Geräts verwendet.

1.1.3.4 Authentifizierung

Die Bereitstellung findet häufig an einem Ort statt, an dem es viele Bluetooth^® Mesh Geräte gibt. Um sicherzustellen, dass es sich bei dem bereitgestellten Gerät um das beabsichtigte Gerät handelt, und um sich gegen MITM-Angriffe (Man-in-the-Middle) zu schützen, umfasst das Bereitstellungsverfahren einen Authentifizierungsschritt.

Die Authentifizierung kann auf verschiedene Weise erfolgen und wird entsprechend den Fähigkeiten des nicht bereitgestellten Geräts ausgewählt, die dem Bereitsteller über eine PDU für die Bereitstellungsfähigkeiten mitgeteilt werden, die er in der Einladungsphase erhält.

Bei der OOB-Methode "Output" gibt das unprovisionierte Gerät einen Zahlen- oder Textwert mithilfe einer von ihm unterstützten Aktion aus. Zum Beispiel kann es eine LED blinken lassen oder eine bestimmte Anzahl von Signaltönen ausgeben. Die ausgegebene Zahl wird in den Provisioner eingegeben, und ein Bestätigungsverfahren überprüft, ob der erwartete Wert eingegeben wurde.

Bei der Input OOB-Methode generiert der Provisioner eine Zufallszahl, die durch eine geeignete Aktion (z. B. mehrmaliges Drücken einer Taste) in das unprovisionierte Gerät eingegeben und durch das Bestätigungsverfahren verifiziert wird.

Beim statischen OOB-Ansatz wird ein fester Wert, der möglicherweise auf dem Gerät oder seiner Verpackung aufgedruckt ist, in den Provisioner eingegeben und im Bestätigungsverfahren verwendet.

Unabhängig davon, welche Methode verwendet wird, ist das Ergebnis entweder die erfolgreiche oder die fehlgeschlagene Authentifizierung des bereitzustellenden Geräts und die Information des Benutzers über das Ergebnis.

1.1.3.5 Verteilung von Bereitstellungsdaten

Nach erfolgreicher Authentifizierung wird ein Sitzungsschlüssel generiert und zur Verschlüsselung und Authentifizierung der über die Verbindung gesendeten Provisioning Data PDU verwendet. Der Provisioner sendet Daten, die den primären NetKey und eine eindeutige Unicast-Adresse für das primäre Element des Geräts enthalten. Das Gerät kann nun als provisioniert bezeichnet werden.

Abbildung 1 - Stufe 1 der Bereitstellung - Beaconing

Abbildung 2 - Phasen 2-5 des Bereitstellungsprozesses

1.2 Geräteschlüssel und der Inbetriebnahmeprozess

Das Sicherheitssystem Bluetooth^® Mesh besteht aus einer Reihe von Sicherheitsschlüsseln, von denen jeder eine bestimmte Rolle spielt.

Netzwerkschlüssel werden bei der Verschlüsselung und Authentifizierung von Feldern in PDUs verwendet, die sich auf die Netzwerkschicht beziehen. Der Besitz eines bestimmten Netzwerkschlüssels, der durch seine Verwendung auf diese Weise nachgewiesen wird, bedeutet die Zugehörigkeit eines Knotens zu dem Teilnetz, zu dem der Netzwerkschlüssel gehört.

Anwendungsschlüssel werden bei der Verschlüsselung und Authentifizierung von Feldern in PDUs verwendet, die sich auf höhere Schichten des Protokollstapels Bluetooth Mesh beziehen, und werden im Allgemeinen an Geräte ausgegeben, die Teil eines bestimmten Gebäudesystems sind, z. B. Beleuchtung oder Klimatisierung.

Ein Knoten kann über mehrere Netzschlüssel und mehrere Anwendungsschlüssel verfügen.

Alle Knoten haben einen einzigen Geräteschlüssel (DevKey). Dieser Schlüssel wird zur Sicherung von Nachrichten verwendet, die zu bestimmten Modellen gehören und in der Regel die Gerätekonfiguration betreffen. Ein Knoten berechnet seinen DevKey, wenn er bereitgestellt wird. Der DevKey wird niemals über das Netz übertragen.

Bei der erstmaligen Einrichtung eines Bluetooth^® Mesh Netzwerks, insbesondere in der Welt der intelligenten Gebäude, werden die Geräte in der Regel von einem Team von Auftragnehmern installiert, bereitgestellt und konfiguriert, die das fertige Netzwerk schließlich an den Gebäudeeigentümer übergeben. Für eine optimale Sicherheit ist es wünschenswert, dass der Gebäudeeigentümer die Möglichkeit hat, die Sicherheitsschlüssel in jedem Knoten des Netzwerks zu ändern.

Bluetooth Mesh 1.0 definiert das Verfahren zur Schlüsselaktualisierung, mit dem Netzwerkschlüssel und Anwendungsschlüssel im gesamten Netzwerk geändert werden können. Ein Verfahren zur Änderung von Geräteschlüsseln ist in Bluetooth Mesh 1.0 nicht definiert.

1.3 Knotenadressen

Bluetooth^® Mesh enthält ein Adressierungsschema.

Alle Elemente haben eine eindeutige 16-Bit-Unicast-Adresse, die als Quelladresse für alle Nachrichten und gelegentlich auch als Zieladresse verwendet wird.

Gruppenadressen und virtuelle Adressen sind zwei Arten von Adressen, die es ermöglichen, Sammlungen von Knoten in einer einzigen Nachricht zu adressieren. Knoten, die an eine bestimmte Gruppen- oder virtuelle Adresse gesendete Nachrichten empfangen und beantworten möchten, müssen diese Adresse abonnieren.

Ursprünglich, in der Version 1.0 von Bluetooth Mesh , konnte die Unicast-Adresse eines Elements nicht geändert werden, ohne dass der Provisioner es zunächst aus dem Netz entfernte und dann erneut bereitstellte, was in der Regel auch eine vollständige Neukonfiguration des Elements erforderte.

1.4 Zusammensetzung des Knotens

Knoten haben eine logische Struktur. Ein Knoten besteht aus einem oder mehreren Elementen. Ein Element ist ein einzeln adressierbarer Teil eines Geräts und hat seine eigene Unicast-Adresse. Die Elementadressen innerhalb eines Knotens müssen in einem zusammenhängenden Bereich zugewiesen werden, wobei das primäre Element die niedrigste Adresse hat.

Elemente enthalten ein oder mehrere Modelle. Modelle sind standardisierte Softwarekomponenten, die ein Element mit einer bestimmten Funktionalität ausstatten, z. B. mit der Fähigkeit, das Gerät ein- und auszuschalten oder seine Helligkeit zu verändern. Modelle haben zugehörige Zustände und Nachrichten. In den meisten Fällen ist die Beziehung zwischen Knoten, Element und Modell hierarchisch, wobei 1 Knoten 1:n Elemente und jedes Element 1:m Modelle enthält. Einige Arten von Modellen können jedoch mehr als einem Element gehören, so dass es sich nicht um eine streng hierarchische Struktur handelt.

Die spezifische Anzahl der Elemente eines Knotens und die einzelnen Modelle, die jedes Element enthält, sind Teil der Knotenzusammensetzung. Die Zusammensetzung eines Knotens wird durch Informationen im Zustand " Composition Data" dargestellt. Dieser Zustand unterteilt seinen Inhalt in eine Reihe von Seiten, die indiziert werden. Seite 0 ist wichtig und enthält die derzeit aktiven Kompositionsdaten für den Knoten.

Unter Bluetooth^® Mesh Version 1.0 konnte die Zusammensetzung eines Knotens nicht geändert werden, ohne einen Knoten-Reset auszuführen und ihn neu zu provisionieren.

1.5 Komplexe Geräte

Einige Geräte sind komplex und bestehen aus vielen Einzelkomponenten, von denen jede dem Gerät als Ganzes spezielle Funktionen hinzufügt. DALI (Digital Addressable Lighting Interface)-Geräte beispielsweise sind um einen Kommunikationsbus herum aufgebaut, in den einzelne Komponenten, wie z. B. Sensoren, ein- und ausgesteckt werden können. Diese Geräte sind nicht nur hochentwickelt und haben eine komplexe logische Struktur, sondern diese Struktur ist auch dynamisch, da die Komponenten leicht hinzugefügt oder entfernt werden können.

2. Über Remote Provisioning

Remote Provisioning (RPR) wurde in Version 1.1 der Bluetooth^® Mesh Protokollspezifikation eingeführt, um das Provisioning und Re-Provisioning von Knoten über ein mesh Netzwerk zu ermöglichen, die sich nicht in direkter Funkreichweite des Provisioners befinden.

2.1 Fähigkeiten und Vorteile

RPR bietet Funktionen und Vorteile, die in drei Themenbereiche fallen:

2.1.1 Multi-Hop-Gerätebereitstellung

Bei der Fernbereitstellung können sich der Bereitsteller und das nicht bereitgestellte Gerät an einem beliebigen Ort befinden, sofern ein Kommunikationspfad über das Netz zwischen den beiden Geräten hergestellt werden kann. Dies macht das Verfahren in vielen realen Situationen praktischer.

2.1.2 Wechsel des Eigentümers

RPR definiert Verfahren, die nützlich sind, wenn die Geräte in einem Netzwerk den Besitzer wechseln und es ermöglichen, einen neuen Wert des Geräteschlüssels festzulegen.

2.1.3 Dynamische Gerätezusammensetzung

Komplexe Geräte, die in der Lage sind, Änderungen an ihrer eigenen physischen Zusammensetzung zu erkennen, können nun die erforderliche Änderung der Zusammensetzungsdaten mesh anzeigen. Der Provisioner kann dies erkennen und ein RPR-Verfahren einleiten, das den aktiven Zustand der Zusammensetzungsdaten aktualisiert, um die neue Zusammensetzung widerzuspiegeln. Es ist nicht mehr notwendig, das Gerät zurückzusetzen, neu zu provisionieren und neu zu konfigurieren, wie es früher erforderlich war.

Im Zusammenhang mit der neuen Plug-and-Play-Fähigkeit führt die Protokollspezifikation mesh 1.1 eine neue formale Bezeichnung für den Lebenszyklus eines Geräts und dessen Struktur und Konfiguration ein. Das Konzept eines Terms wird in der Spezifikation wie folgt beschrieben:

A Begriff ist ein Zeitraum während der Lebensdauer eines Knotens, in dem sich die Struktur des Knotens (d. h. die Merkmale, die Elemente und Modelle) und die Unicast-Adressen der Elemente des Knotens nicht ändern. Das Starten eines neuen Begriffs kann erforderlich sein, um eine Änderung der Hardwarekonfiguration eines physischen Geräts zu unterstützen, wie z. B. das Anbringen eines zusätzlichen Sensors, oder um eine Änderung der Teilsystemkonfiguration des Knotens zu unterstützen, wie z. B. das Anbringen eines neuen Vorschaltgeräts an ein leuchteninternes Netzwerk. Die Änderungen werden vom Knoten durch Ausfüllen der Composition Data Page 128 (siehe Abschnitt 4.2.2.3) angezeigt und treten in Kraft, wenn ein neuer Laufzeit beginnt. Die ursprüngliche Laufzeit eines Knotens in einem Netz beginnt, wenn der Knoten im Netz bereitgestellt wird. A Amtszeit endet und eine neue Begriff beginnt, wenn ein Verfahren zur Aktualisierung der Knotenadresse oder der Knotenzusammensetzung ausgeführt wird (siehe Abschnitt 3.11.8). Der letzte Begriff eines Knotens in einem Netz endet, wenn der Knoten aus dem Netz entfernt wird.

 

2.2 Technische Highlights

2.2.1 Architektur

Die Fernbereitstellung umfasst zwei neue Modelle: das Modell des Remote Provisioning Client und das Modell des Remote Provisioning Server. Das Remote-Provisioning-Client-Modell ermöglicht es dem Provisioner-Gerät, mit einem entfernten, nicht provisionierten Gerät zu kommunizieren und den Provisionierungsprozess zu steuern. Dieses Gerät wird als PB-Remote Client bezeichnet. Das Client-Modell sendet und empfängt Provisioning-Protokoll-PDUs unter Verwendung von Modellnachrichten. Die Nachrichten werden auf die übliche Art und Weise über das Netzwerk weitergeleitet, wobei verwaltetes Flooding, gerichtete Weiterleitung oder eine Kombination der beiden Methoden verwendet wird. Das Remote Provisioning Server Modell ermöglicht es einem PB-Remote Client, unprovisionierte Geräte in seiner direkten Funkreichweite zu scannen und zu provisionieren. Ein Gerät, das dieses Modell implementiert, wird PB-Remote Server genannt. Das Server-Modell unterstützt auch die Ausführung von Prozeduren, die für die Änderung des Geräteschlüssels oder der Plug-and-Play-Gerätekonfiguration benötigt werden.

Die Fernbereitstellung definiert auch PB-Remote-Bereitstellungsträger. Der PB-Remote-Bearer verwendet PB-ADV oder PB-GATT, um mit einem unprovisionierten Gerät zu kommunizieren, wenn er auf einem PB-Remote-Server-Gerät implementiert ist. Wenn er auf einem PB-Remote-Server-Gerät implementiert ist, ermöglicht dieser Bearer dem Provisioner die Kommunikation mit einem entfernten Gerät, das am Provisioning-Prozess teilnimmt.

Es wird eine Schnittstelle, das so genannte Node Provisioning Protocol Interface, definiert, die eine Reihe wichtiger neuer Verfahren ermöglicht, darunter die Änderung des Geräteschlüssels und die Plug-and-Play-Gerätekonfiguration.

Die Fernbereitstellungsmodelle definieren Nachrichten, die:

1. Ermöglicht die Erkennung von Geräten überall im Netzwerk, die für die Bereitstellung verfügbar sind und sich in direkter Funkreichweite eines PB-Remote Servers befinden.
2. Erlaubt den Aufbau einer Verbindung zwischen einem PB-Remote Server und einem ausgewählten, nicht provisionierten Knoten.
3. Verkapselung der PDUs des Bereitstellungsprotokolls, so dass sie zwischen Client und Server in beide Richtungen transportiert werden können.
4. sind mit dem Geräteschlüssel (DevKey) des Knotens gesichert, der als Server fungiert.
5. Beziehen sich auf die Verfahren der Knotenbereitstellungsprotokollschnittstelle.

Im Groben funktioniert die Fernbereitstellung so, dass der PB-Remote Server auf Anfrage des PB-Remote Clients eine Verbindung zu einem ausgewählten, nicht bereitgestellten Gerät herstellt. Er empfängt dann Provisioning-Protokoll-PDUs, die in Remote-Provisioning-Nachrichten gekapselt sind, extrahiert diese PDUs und sendet sie über die Verbindung. Als Antwort erhält er Provisioning-Protokoll-PDUs, die er in andere Remote-Provisioning-Nachrichten kapselt, um sie an den PB-Remote Client zurückzusenden. Siehe Abbildung 3.

Auf diese Weise führt der PB-Remote Client den üblichen Provisionierungsprozess mit einem entfernten, unprovisionierten Gerät durch. Der PB-Remote Server agiert als Vermittler innerhalb des Prozesses, indem er zwischen den Trägern übersetzt und Provisioning-PDUs aus PB-Remote-Nachrichten, die vom Client an das unprovisionierte Gerät gesendet werden, weiterleitet.

Abbildung 3 - Die Architektur der Remote-Bereitstellung

2.2.2 Die Etappen der Fernbereitstellung

Die Fernbereitstellung durchläuft die folgenden vier Phasen:

1. Remote-Scanning durchführen
2. Öffnen Sie einen Link zu dem nicht bereitgestellten Gerät
3. Bereitstellung des Geräts
4. Schließen Sie den Link

2.2.2.1 Fernabfrage

Abbildung 4 - Die Verfahren für den Remote Provisioning Scan

Zwei Formen des Remote-Scannens können von einem PB-Remote Client angefordert werden, nämlich Remote Provisioning Scan Start oder Remote Provisioning Extended Scan Start. Siehe Abbildung 4.

2.2.2.1.1 Der Scanvorgang für die Fernbereitstellung

Eine Remote Provisioning Scan Start Nachricht wird an die Unicast-Zieladresse eines PB-Remote Servers gesendet, um ihn anzuweisen, mit dem Scannen nach Geräten zu beginnen, die für die Bereitstellung verfügbar sind. Die Nachricht kann eine Geräte-UUID enthalten, die, falls vorhanden, anzeigt, dass nur nach einem bestimmten Gerät gescannt werden soll. Alternativ können auch alle nicht provisionierten Geräte in Reichweite des PB-Remote Servers gescannt werden. Diese beiden Optionen werden als Einzelgeräte-Scan bzw. Mehrfachgeräte-Scan bezeichnet.

Remote Provisioning Scan Start ist eine bestätigte Nachricht und ein PB-Remote Server Knoten wird darauf mit einer Remote Provisioning Scan Status Nachricht antworten.

Remote Provisioning Scan Report Nachrichten werden vom PB-Remote Server zurück an den PB-Remote Client gesendet, der das Scannen initiiert hat. Diese Nachrichten enthalten Details über jedes einzelne, entdeckte, unprovisionierte Gerät, welches der Server in der Lage ist zu provisionieren und beinhalten Informationen wie die identifizierende Geräte-UUID, Informationen bezüglich der Out-of-Band (OOB) Authentifizierungsfähigkeiten des Gerätes, die vom PB-Remote Server gemessene Signalstärke (RSSI) und den URI Hash-Wert, falls vom zu provisionierenden Gerät verfügbar. Das Scannen eines einzelnen Geräts führt nur zu einer Scan-Report-Nachricht für die angegebene Geräte-UUID (wenn das Gerät gefunden wird).

2.2.2.1.2 Das erweiterte Remote Provisioning Scan-Verfahren

Diese Variante des Remote Scannings erlaubt es dem PB-Remote Client, spezifische, zusätzliche Informationen über ein einzelnes Gerät anzufordern, die nicht in unprovisionierten Device Beacons (im Falle von PB-ADV) oder im Service Data AD-Typ von verbindbaren Werbepaketen (im Falle von PB-GATT) zu finden sind. Zusätzliche Informationen, die von Interesse sind, können in Bluetooth^® LE Scan-Response-Paketen oder in zusätzlichen Werbepaketen enthalten sein, die jeweils andere Inhalte von demselben Gerät enthalten.

Erweitertes Scannen kann Informationen entweder von einem einzelnen unprovisionierten Gerät oder von dem PB-Remote Server Knoten selbst erhalten. Im ersten dieser Szenarien, während die Remote Provisioning Extended Scan Prozedur nur für ein einzelnes Gerät durchgeführt wird, wenn die PB-Remote Server Implementierung dies unterstützt, können mehrere Instanzen der Prozedur, jede für eine andere Geräte-UUID, gleichzeitig ausgeführt werden.

Eine Remote Provisioning Extended Scan Start Nachricht, die vom PB-Remote Client gesendet wird, initiiert Remote Extended Scan durch den PB-Remote Server Knoten, der eine spezifizierte Unicast Adresse hat. Sie kann eine Liste von AD-Typen enthalten, deren Werte angefordert werden (vorbehaltlich einiger Einschränkungen, die in der Bluetooth Mesh Protokoll-Spezifikation dokumentiert sind). Wenn eine Geräte-UUID in der Nachricht enthalten ist, wird das Scannen nach dem spezifizierten unprovisionierten Gerät durchgeführt, andernfalls werden die Informationen vom PB-Remote Server Knoten selbst bezogen.

Remote Provisioning Extended Scan Start ist eine unbestätigte Nachricht.

Remote Provisioning Extended Scan Report-Nachrichten werden von Servern zurück an den PB-Remote Client gesendet, der das erweiterte Scannen initiiert hat, und enthalten die Informationen des/der angeforderten Typs/Typen, die vom PB-Remote Server erhalten wurden.

2.2.2.2 Einen Link öffnen

Abbildung 5 - Öffnen einer Fernverbindung zu einem nicht bereitgestellten Gerät

Ein PB-Remote Client kann eine Remote Provisioning Link Open Nachricht mit einem Device UUID Parameter senden, um den PB-Remote Server Knoten aufzufordern, einen Provisioning Link mit dem angegebenen Gerät aufzubauen. Dies ist eine bestätigte Nachricht und führt dazu, dass der Server eine Remote Provisioning Link Status Nachricht zurück an den Client sendet. Siehe Abbildung 5.

Beachten Sie, dass die Remote Provisioning Link Open Nachricht verwendet werden kann, um den PB-Remote Server für andere Prozeduren vorzubereiten, die über das neue Node Provisioning Protocol Interface verfügbar sind (siehe 2.2.3).

2.2.2.3 Bereitstellung des Geräts

Abbildung 6 - Fernbereitstellung

Sobald eine Verbindung zwischen dem PB-Remote Server Knoten und dem unprovisionierten Zielgerät hergestellt wurde, kann der PB-Remote Client den Provisionierungsprozess selbst durchführen. Der Prozess ist im Wesentlichen derselbe wie die vier in 1.1.3.2 bis 1.1.3.5 beschriebenen Schritte, mit der Ausnahme, dass die erforderlichen Provisioning Protocol PDUs in einem PB-Remote Nachrichtentyp, der Remote Provisioning PDU Send Nachricht, gekapselt sind. Der Server extrahiert Provisioning Protocol PDUs aus den PB-Remote Nachrichten und leitet sie über den Link an das unprovisionierte Gerät weiter. Provisioning Protocol PDUs, die von dem unprovisionierten Gerät an den PB-Remote Server gesendet werden, werden in Remote Provisioning PDU Report Nachrichten gekapselt und zurück an den PB-Remote Client Knoten gesendet. Siehe Abbildung 6.

2.2.2.4 Schließen der Verbindung

Abbildung 7 - Schließen der Fernbereitstellungsverbindung

Wenn die Provisionierung abgeschlossen ist, weist der PB-Remote Client den PB-Remote Server an, seine Verbindung zu dem Gerät, das provisioniert wurde, zu schließen. Dies wird durch das Senden einer Remote Provisioning Link Close Nachricht erreicht, auf die der Server mit einer Remote Provisioning Link Status Nachricht antwortet.

2.2.3 Die Schnittstelle des Knotenbereitstellungsprotokolls

PB-Remote definiert eine Reihe von Prozeduren, die über eine neu definierte Schnittstelle namens Node Provisioning Protocol Interface (NPPI) verfügbar sind. Ein Knoten, der das Remote Provisioning Server Modell unterstützt, muss die NPPI Schnittstelle und die damit verbundenen Prozeduren unterstützen. Jede der NPPI-Prozeduren kann gestartet werden, indem das Remote-Provisioning-Client-Modell eine Remote-Provisioning-Link-Open-Nachricht sendet, die ein NPPI-Prozedurenfeld enthält, das die gewünschte NPPI-Prozedur angibt. Die NPPI-Prozeduren werden vom Remote Provisioning Server-Modell ausgeführt.

Die Knotenbereitstellungsprotokollschnittstelle ist geschlossen, bis das Modell "Remote Provisioning Server" eine an das Modell "Remote Provisioning Server" selbst gerichtete Nachricht "Remote Provisioning Link Open" empfängt. Wenn die Schnittstelle offen ist, werden Provisioning-Protokoll-PDUs gemäß dem normalen Fluss ausgetauscht (jedoch mit einigen Einschränkungen hinsichtlich der Werte der Provisioning-Daten-PDUs), die in Remote Provisioning-Nachrichten gekapselt sind. Diese PDUs werden dann vom Remote Provisioning Server-Modell verarbeitet, um ausgewählte Prozeduren auszuführen. Dies steht im Gegensatz zu dem in Abschnitt 2.2.2.3 beschriebenen Verhalten, bei dem Provisioning-Protokoll-PDUs über eine Verbindung an ein nicht provisioniertes Gerät weitergeleitet werden, wie in den Abbildungen 5, 6 und 7 dargestellt.

Abbildung 8 - NPPI-Architektur

Die NPPI-Verfahren, die in der Bluetooth Mesh 1.1 Protokollspezifikation definiert sind, lauten wie folgt.

2.2.3.1 Gerätetaste aktualisieren

Mit diesem Verfahren kann einem Knoten ein neuer Geräteschlüssel zugewiesen werden, ohne dass der Knoten vollständig neu bereitgestellt werden muss. Vorhandene Daten wie die Elementadressen des Knotens und seine Listen von NetKeys und AppKeys bleiben davon unberührt.

Das Verfahren läuft in zwei Stufen ab, wobei ein neuer Schlüsselkandidat, der so genannte Geräteschlüsselkandidat, mit Hilfe des Standardprotokolls und der Standardverfahren für die Bereitstellung berechnet wird. Dieser Schlüssel verlässt nie das Gerät, und das Diffie-Hellman-Schlüsselvereinbarungsprotokoll, das auf elliptischer Kurvenkryptografie basiert, wird verwendet, um den Konfigurationsmanager sicher in den Besitz einer Kopie des Schlüssels zu bringen. Auf diese Weise wird sichergestellt, dass die mit diesem Verfahren verbundene Sicherheit auf demselben Niveau liegt wie bei der Erstbereitstellung eines Geräts. In diesem Stadium ist der Geräteschlüssel des Knotens noch nicht geändert worden, aber ein neuer Schlüsselkandidat ist ihm bekannt. In Phase 2 wird der Geräteschlüsselkandidat zum neuen DevKey des Knotens, wenn eine Zugangsnachricht empfangen wird, die mit dem neuen Geräteschlüsselkandidaten verschlüsselt wurde. Dies zeigt an, dass der neue Schlüssel in Gebrauch ist. Zu diesem Zeitpunkt wird der alte Schlüssel widerrufen, und der neue Schlüsselkandidat tritt an seine Stelle.

2.2.3.2 Aktualisierung der Knotenadresse

Mit dem Verfahren "Node Address Refresh" können die Unicast-Adresse und der Geräteschlüssel eines Knotens geändert werden, ohne dass dieser zurückgesetzt und neu bereitgestellt werden muss. Vorhandene Daten wie die Liste der NetKeys und AppKeys des Knotens bleiben davon unberührt. Es kann auch verwendet werden, um die Anzahl der Elemente eines Knotens zu ändern, wobei jedem Element eine Adresse zugewiesen wird, die einen fortlaufenden Bereich bildet, beginnend mit der neuen Unicast-Adresse, die dem primären Element zugewiesen wird.

2.2.3.3 Aktualisierung der Knotenzusammensetzung

Dieses Verfahren ermöglicht es, die Zusammensetzung eines Knotens (d. h. die Anzahl der Elemente und Modelle) zu ändern, und bietet eine Art Plug-and-Play-Fähigkeit für komplexe Geräte, deren physische Zusammensetzungsstruktur dynamisch ist.

Stellen Sie sich ein DALI-Gerät im Netz vor. Das Gerät ist ein hochentwickeltes Beleuchtungsprodukt, dessen interner Bus bis zu 128 verschiedene Komponenten aufnehmen kann. Verschiedene Arten von Sensoren können z. B. in den Knoten eingesteckt oder ausgesteckt werden. Geräte dieser Art können, wenn sie mit geeigneter Firmware programmiert sind, diese Art von Veränderungen erkennen.

Diese NPPI-Prozedur verlangt von einem Knoten, der eine Änderung seiner physikalischen Zusammensetzung festgestellt hat, dass er Details auf die Seite 128 des Zusammensetzungsdaten-Zustands schreibt. Die Prozedur, die von einem PB-Remote Client initiiert wird, führt letztendlich dazu, dass die neuen Daten des Zusammensetzungszustands von Seite 128 auf Seite 0 kopiert werden, wo die aktiven Daten des Zusammensetzungszustands gespeichert sind, und somit die gewünschte Änderung herbeigeführt wird.

Wenn diese Prozedur ausgeführt wird, wird dem Knoten auch ein neuer Geräteschlüssel zugewiesen. Der Status "Composition Data" des Knotens wird durch die Prozedur aktualisiert, andere Status bleiben jedoch unverändert.

2.2.4 Fernbereitstellung und Sicherheit

Abbildung 9 zeigt die Art und Weise, wie die Fernbereitstellung gesichert wird. Die zwischen dem PB-Remote Client und dem Server ausgetauschten Nachrichten werden mit dem Geräteschlüssel des PB-Remote Serverknotens gesichert. Die dann ausgeführten Provisionierungsprozeduren verwenden die Standard-Provisionierungssicherheit und durchlaufen die Stufen 2 - 5 der üblichen Provisionierungsprozedur, wie in Abschnitt 1.1.3 erläutert.

Abbildung 9 - Sicherheit bei Remote Provisioning

Einige der Authentifizierungsmethoden, die von einem Gerät unterstützt werden können, setzen voraus, dass der Benutzer das Gerät sehen, hören oder berühren kann. Die Fernbereitstellung soll die Bereitstellung von Geräten ermöglichen, die sich in beträchtlicher Entfernung vom Bereitsteller befinden können, und daher sind diese Authentifizierungsmethoden möglicherweise nicht optimal oder in manchen Situationen unpraktisch. Glücklicherweise wurde mit Bluetooth^® Mesh Version 1.1 auch ein neuer Authentifizierungsansatz hinzugefügt, der sich ideal für die Bereitstellung von Geräten aus der Ferne eignet, nämlich die zertifikatsbasierte Bereitstellung. Diese Funktion wird im technischen Übersichtspapier zur zertifikatsbasierten Bereitstellung beschrieben.

2.2.5 Massenbereitstellung

Da man sich bei der Bereitstellung in direkter Funkreichweite der neuen Geräte befinden muss, eignet sich Bluetooth^® Mesh 1.0 nicht für die Bereitstellung großer Geräteansammlungen, vielleicht sogar aller Geräte im Netzwerk, ohne den Provisioner zu verlegen.

Die Fernbereitstellung bietet in Verbindung mit der zertifikatsbasierten Bereitstellung das Potenzial für Bereitstellungswerkzeuge, mit denen jedes einzelne Gerät im neuen Netz in einem einzigen, vom Auftraggeber initiierten Vorgang programmatisch bereitgestellt werden kann.

3. Schließen Sie

Die Remote-Provisioning-Funktion Bluetooth^® Mesh vereinfacht die Bereitstellung neuer Geräte im Netzwerk erheblich. Die neuen Knotenbereitstellungsprotokoll-Schnittstellenverfahren spiegeln reale Anwendungsfälle wider und stellen sicher, dass die üblichen Arbeitsabläufe bei der Einrichtung eines neuen Netzwerks und der Wartung komplexer Geräte gut unterstützt werden.