Kernarchitekturblöcke
Inhalt
Definition des KernsystemsDas Bluetooth-Kernsystem deckt die in der Bluetooth-Spezifikation definierten vier niedrigsten Schichten und zugehörigen Protokolle sowie ein gemeinsames Protokoll der Serviceschicht ab; das Dienstsucheprotokoll (SDP) und die allgemeinen Profilanforderungen sind im allgemeinen Zugriffsprotokoll (GAP) angegeben. Eine vollständige Bluetooth-Anwendung erfordert zahlreiche zusätzliche Dienste und Protokolle höherer Schichten, die in der Bluetooth-Spezifikation definiert sind.
Bluetooth-ControllerDie untersten drei Schichten werden mitunter in ein Untersystem namens Bluetooth-Controller gruppiert. Dies ist eine gemeinsame Implementierung mithilfe einer standardmäßigen physischen Kommunikationsschnittstelle zwischen dem Bluetooth-Controller und dem übrigen Bluetooth-System mit L2CAP, Dienstschichten und höheren Schichten (bekannt als Bluetooth-Host). Diese Schnittstelle ist zwar optional, doch die Architektur ist auf ihre Existenz und Eigenschaften zugeschnitten. Die Bluetooth-Spezifikation ermöglicht Interoperabilität zwischen unabhängigen, Bluetooth-fähigen Systemen durch Definition der zwischen gleichwertigen Schichten ausgetauschten Protokollmitteilungen sowie Interoperabilität zwischen unabhängigen Bluetooth-Untersystemen durch Definition einer gemeinsamen Schnittstelle zwischen Bluetooth-Controllern und Bluetooth-Hosts.
Es werden zahlreiche Funktionsblöcke und die dazwischen befindlichen Dienst- und Datenpfade dargestellt. Die im Diagramm dargestellten Funktionsblöcke sind informativer Natur; im Allgemeinen definiert die Bluetooth-Spezifikation keine Einzelheiten der Implementierungen, sofern dies nicht zur Interoperabilität erforderlich ist.
Kernsystemprotokolle und SignaleFür alle zwischen den Geräten erfolgenden Abläufe werden Standardinteraktionen definiert, bei denen Bluetooth-Geräte die Protokollsignale laut Bluetooth-Spezifikation austauschen. Bei den Bluetooth-Kernsystemprotokollen handelt es sich um das Hochfrequenzprotokoll (RF), das Verbindungssteuerungsprotokoll (LC), das Verbindungsmanagerprotokoll (LM) und das logische Verbindungssteuerungs- und Adaptationsprotokoll (L2CAP), die jeweils in den nachfolgenden Teilen der Bluetooth-Spezifikation vollständig definiert sind. Darüber hinaus stellt das Dienstsucheprotokoll (SDP) ein von allen Bluetooth-Anwendungen benötigtes Protokoll der Dienstschicht dar.
Das Bluetooth-Kernsystem stellt die Dienste durch zahlreiche im Diagramm als Ellipsen dargestellte Dienstzugriffspunkte bereit. Diese Dienste umfassen die grundlegenden Elemente, die das Bluetooth-Kernsystem steuern. Die Dienste können in drei Arten unterteilt werden. Es gibt Gerätesteuerungsdienste, die das Verhalten und die Modi eines Bluetooth-Geräts ändern, Übertragungssteuerungsdienste, die Verkehrsträger (Kanäle und Verbindungen) herstellen, ändern und freigeben, sowie Datendienste, die die Daten zur Übertragung über Verkehrsträger vorlegen. Üblicherweise werden die ersten beiden Dienste der C-Ebene und der letzte der U-Ebene zugeordnet.
Host-Controller-Schnittstelle (HCI): Teilt den Bluetooth-Stack in Controller und Host Eine Dienstschnittstelle zum Untersystem des Bluetooth-Controllers ist so definiert, dass der Bluetooth-Controller als Standardteil betrachtet werden kann. In dieser Konfiguration steuert der Bluetooth-Controller die unteren drei Schichten, und die L2CAP-Schicht befindet sich mit der übrigen Bluetooth-Anwendung in einem Hostsystem. Die Standardschnittstelle heißt Host-Controller-Schnittstelle (HCI). Die Implementierung dieser Standarddienstschnittstelle ist optional.
Da die Bluetooth-Architektur mit der Möglichkeit einer getrennten Host-Controller-Kommunikation über eine HCI definiert ist, gelten zahlreiche allgemeine Annahmen. Es wird angenommen, dass der Bluetooth-Controller im Vergleich zum Host über begrenzte Fähigkeiten zur Datenpufferung verfügt. Aus diesem Grund soll die L2CAP-Schicht einfaches Ressourcenmanagement durchführen, wenn L2CAP-PDUs (Protokoll-Dateneinheiten) zur Übertragung an ein gleichberechtigtes Gerät an den Controller gesendet werden. Dies umfasst die Segmentierung von L2CAP-SDUs in kompakte PDUs und die anschließende Fragmentierung von PDUs in Anfangs- und Folgepakete geeigneter Größe für die Controller-Puffer, außerdem die Auslastungsverwaltung der Controller-Puffer, um die Verfügbarkeit für Kanäle mit Dienstgüte sicherzustellen.
Fehlerermittlung in der L2CAP-SchichtDie Basisbandschicht stellt in der Bluetooth-Technologie das grundlegende ARQ-Protokoll bereit. Die L2CAP-Schicht kann optional weitere Fehlerermittlung und erneute Übertragung an die L2CAP-PDUs bereitstellen. Diese Funktion wird für Anwendungen empfohlen, bei denen eine niedrige Wahrscheinlichkeit unentdeckter Fehler in den Benutzerdaten erforderlich ist. Eine weitere optionale Funktion von L2CAP ist eine fensterbasierte Flusssteuerung, mit der die Speicherzuordnung im Empfangsgerät verwaltet werden kann. Durch diese beiden optionalen Funktionen kann die Dienstgüte in bestimmten Szenarien verbessert werden.
Diese Annahmen sind zwar bei eingebetteten Implementierungen der Bluetooth-Technologie, die alle Schichten in einem Einzelsystem zusammenfassen, nicht erforderlich, doch die allgemeinen Architektur- und Dienstgütemodelle sind unter Berücksichtigung dieser Annahmen als kleinster gemeinsamer Nenner definiert.
Prüfungsschnittstelle: RF und Teststeuerungsschnittstelle (TCI)Es sind automatisierte Konformitätstests von Implementierungen des Bluetooth-Kernsystems erforderlich. Dies wird erreicht, indem der Prüfer die Implementierung über die allen Bluetooth-Systemen gemeinsame HF-Schnittstelle und über die nur zur Konformitätsprüfung erforderliche Teststeuerungsschnittstelle (TCI) steuert.
Der Prüfer führt über die HF-Schnittstelle einen Austausch mit der zu prüfenden Implementierung (IUT) durch, um sicherzustellen, dass auf Anfragen entfernter Geräte die korrekte Antwort gegeben wird. Der Prüfer steuert die IUT über die TCI, damit die IUT einen Austausch über die HF-Schnittstelle veranlasst, der dann wiederum als konform bestätigt werden kann.
Die TCI verwendet eine unterschiedliche Befehlsgruppe (Dienstschnittstelle) zur Prüfung der einzelnen Architekturschichten und Protokolle. Eine Untergruppe der als TCI-Dienstschnittstelle für sämtliche Schichten und Protokolle innerhalb des Untersystems des Bluetooth-Controllers ausgegebenen HCI-Befehlsgruppe. Zum Testen von L2CAP-Schicht und -Protokoll wird eine eigene Dienstschnittstelle verwendet. Da in der Bluetooth-Kernspezifikation keine L2CAP-Dienstschnittstelle festgelegt ist, wird sie getrennt in der TCI-Spezifikation definiert. Eine Implementierung der L2CAP-Dienstschnittstelle ist nur zur Konformitätsprüfung erforderlich.
Seitenanfang
Kernarchitekturblöcke
KanalmanagerDer Kanalmanager ist verantwortlich für das Herstellen, Verwalten und Löschen der L2CAP-Kanäle zur Übertragung der Dienstprotokolle und Anwendungsdatenströme. Der Kanalmanager verwendet das L2CAP-Protokoll zur Interaktion mit dem Kanalmanager eines entfernten (gleichberechtigten) Geräts, um diese L2CAP-Kanäle zu erstellen und ihre Endpunkte mit den entsprechenden Einheiten zu verbinden. Der Kanalmanager interagiert mit dem lokalen Verbindungsmanager, um ggf. neue logische Verbindungen herzustellen und diese Verbindungen zu konfigurieren, damit die erforderliche Dienstgüte für die übertragende Datenart bereitgestellt wird.
L2CAP-RessourcenmanagerDer L2CAP-Ressourcenmanagerblock verwaltet die Reihenfolge, in der die PDU-Fragmente an das Basisband gesendet werden, sowie die relative Planung zwischen den Kanälen, um sicherzustellen, dass L2CAP-Kanälen mit Dienstgüte nicht wegen einer Auslastung der Bluetooth-Controllerressourcen der Zugang zum physischen Kanal verweigert wird. Dies ist erforderlich, da das Architekturmodell nicht davon ausgeht, dass der Bluetooth-Controller über eine unbegrenzte Puffermöglichkeit oder die HCI über unbegrenzte Bandbreite verfügt.
Außerdem können L2CAP-Ressourcenmanager Richtlinien für die Verkehrskonformität erstellen, um sicherzustellen, dass die Anwendungen L2CAP-SDUs innerhalb der Grenzen ihrer vereinbarten Einstellungen für die Dienstgüte senden. Das allgemeine Bluetooth-Datenübertragungsmodell geht von Anwendungen aus, die die Verhaltensregeln einhalten, und definiert nicht, wie eine Implementierung mit diesem Problem umgehen soll.
GerätemanagerBeim Gerätemanager handelt es sich um denjenigen Funktionsblock im Basisband, der das allgemeine Verhalten des Bluetooth-fähigen Geräts steuert. Er ist verantwortlich für den gesamten Betrieb des Bluetooth-Systems, der nicht direkt mit der Datenübertragung in Verbindung steht, und ermittelt zum Beispiel, ob andere Bluetooth-fähige Geräte sich in der Nähe befinden, er stellt Verbindungen zu anderen Bluetooth-fähigen Geräten her oder macht das lokale Bluetooth-fähige Gerät für andere Geräte sichtbar und kommunikationsbereit.
Der Gerätemanager beantragt beim Basisband-Ressourcencontroller den Zugriff auf das Übertragungsmedium, um seine Aufgaben durchführen zu können.
Außerdem steuert der Gerätemanager über HCI-Befehle das Verhalten lokaler Geräte, etwa durch die Verwaltung des lokalen Gerätenamens, gespeicherter Verbindungsschlüssel und sonstige Funktionen.
Seitenanfang
VerbindungsmanagerDer Verbindungsmanager ist verantwortlich für das Herstellen, Ändern und Freigeben logischer Verbindungen (und ggf. ihrer zugehörigen logischen Übertragungen) sowie für die Aktualisierung der Parameter für die physischen Verbindungen zwischen Geräten. Der Verbindungsmanager erreicht dies durch die Kommunikation mit dem Verbindungsmanager in entfernten Bluetooth-Geräten mithilfe des Verbindungsmanagementprotokolls (LMP).
Das LMP ermöglicht die Herstellung neuer logischer Verbindungen und ggf. logischer Übertragungen zwischen Geräten sowie die allgemeine Steuerung von Verbindungs- und Übertragungsattributen, wie die Aktivierung der Verschlüsselung während der logischen Übertragung, die Übernahme der Übertragungsleistung bei der physischen Verbindung oder die Anpassung der Dienstgüteseinstellungen bei einer logischen Verbindung.
Basisband-RessourcenmanagerDer Basisband-Ressourcenmanager ist für den gesamten Zugriff auf das Funkmedium verantwortlich. Er erfüllt zwei grundlegende Funktionen. Im Zentrum befindet sich ein Scheduler oder Zeitgeber, der allen Einheiten, die Zugriff vereinbart haben, ein Zeitfenster auf den physischen Kanälen gewährt. Die andere wesentliche Funktion sind Zugriffsvereinbarungen mit diesen Einheiten. Eine Zugriffsvereinbarung ist letztlich eine Zusage, eine bestimmte Dienstgüte bereitzustellen, die erforderlich ist, damit einer Benutzeranwendung die erwartete Leistung zur Verfügung gestellt wird.
Die Funktion zur Zugriffsvereinbarung und -planung muss deshalb jedes Verhalten berücksichtigen, das die Verwendung des Bluetooth-Funks voraussetzt. Dies umfasst zum Beispiel den normalen Datenaustausch zwischen verbundenen Geräten über logische Verbindungen und logische Übertragungen sowie die Verwendung des Funkmediums, um Abfragen durchzuführen, Verbindungen herzustellen, sichtbar oder kommunikationsbereit zu sein oder um im AFH-Modus Ablesungen nicht verwendeter Träger zu übernehmen.
Mitunter führt die Zeitplanung einer logischen Verbindung dazu, dass auf einen anderen physischen Kanal als den zuvor verwendeten gewechselt werden muss, zum Beispiel aufgrund eines Scatternet, einer regelmäßigen Abfragefunktion oder eines Page-Scans. Wenn die physischen Kanäle nicht nach Zeitschlitzen ausgerichtet sind, berücksichtigt der Ressourcenmanager auch die Zeit zur Neuausrichtung zwischen Zeitschlitzen des ursprünglichen physischen Kanals und Zeitschlitzen des neuen physischen Kanals. Mitunter werden die Zeitschlitze von vornherein ausgerichtet, da dieselbe Geräteuhr für beide physischen Kanäle als Referenz verwendet wird.
VerbindungscontrollerDer Verbindungscontroller ist verantwortlich für das Verschlüsseln und Entschlüsseln von Bluetooth-Paketen aus den Nutzdaten (Payload) und Parametern des physischen Kanals, der logischen Übertragung und der logischen Verbindung.
Der Verbindungscontroller übernimmt die Signale des Verbindungssteuerungsprotokolls (in enger Abstimmung mit der Planungsfunktion des Ressourcenmanagers), das die Signale zur Flusssteuerung sowie zur Bestätigung und für Anfragen zur erneuten Übertragung überträgt. Die Interpretation dieser Signale ist eine Eigenschaft des zum Basisbandpaket gehörenden logischen Transports. Die Interpretation und Steuerung der Signale zur Verbindungssteuerung übernimmt normalerweise der Scheduler des Ressourcenmanagers.
RFDer RF-Block ist verantwortlich für die Übertragung und den Empfang von Informationspaketen auf dem physischen Kanal. Durch einen Steuerungspfad zwischen Basisband und RF-Block kann der Basisbandblock die zeitliche Abstimmung und den Frequenzträger des RF-Blocks steuern. Der RF-Block wandelt einen Datenstrom vom und zum physischen Kanal und dem Basisband in die erforderlichen Formate um.
Seitenanfang
|