Bluetooth-Energieverwaltung für moderne Standby-Plattformen

Ein Bluetooth-Funkgerät ermöglicht die kurzstreckende RF-Kommunikation zwischen einem PC und einem Eingabegerät, einem Audiogerät oder einem anderen Bluetooth-angeschlossenen Benutzerperipheriegerät. In einem modernen Standby-PC sollte der Treiber für ein Bluetooth-Funkgerät die Leistungszustände dieses Geräts gemäß den in diesem Artikel beschriebenen Richtlinien verwalten.

Bluetooth-Adapter

In einem Windows-System hängt die Verwaltung des Energiezustands des Bluetooth-Funkgeräts vom Bus ab, mit dem das Funkgerät verbunden ist. Auf Hardwareplattformen, die das moderne Standby-Leistungsmodell unterstützen, unterstützt Windows Bluetooth-Funkgeräte, die mit UARTs verbunden sind, oder mit universal Serial Bus (USB). (Theoretisch sollte das in Windows 8 eingeführte Bluetooth-Transportbustreibermodell jeden zugrunde liegenden Kommunikationsbus unterstützen. Derzeit überprüft Microsoft die moderne Standby-Kompatibilität nur für Bluetooth-Funkgeräte, die mit UARTs oder USB verbunden sind oder in ein System auf einem Chip (SoC) integriert sind.

Genau wie in typischen Windows-Treiberstapeln wird die Stromversorgungsrichtlinie für Bluetooth-Funkgeräte von einem einzigen Power Policy Owner (PPO) verwaltet, nämlich BthPort (bthport.sys). BthPort arbeitet in Verbindung mit einem entsprechenden transportspezifischen Treiber (UART oder USB), um das Radio entsprechend in den gewünschten Leistungszustand zu fahren. Im Falle von USB geschieht dies durch USB Selective Suspend über den USB-Host-Controller. Im Falle von UART koordiniert ein zusätzlicher, vom Hersteller bereitgestellter Transportbustreiber die Anfragen von BthPort an das Bluetooth-Funkgerät über die systemspezifische Busverbindung. Um die Hardware zu steuern, verwendet der Treiber eine Kombination aus In-Band-Buskommunikation, Koordination mit dem Power-Engine-Plug-In (PEP) und/oder out-of-Band-Signalisierung über GPIO-Pins.

Bluetooth-Funkgeräte unterstützen in der Regel mehrere Low-Power-Modi, von denen einige möglicherweise proprietär für das Gerät selbst sind. Der Windows Bluetooth-Treiberstapel setzt voraus, dass ein Bluetooth-Funkgerät die folgenden drei Gerätestromzustände unterstützt:

• Aktiv (D0)
• Schlaf (D2)
• Aus (D3)

Die Gerätestromverwaltung für ein Bluetooth-Funkgerät wird voraussichtlich in allen Systemstromzuständen einheitlich funktionieren. Das Bluetooth-Radio wechselt nicht in einen speziellen Energieverwaltungsmodus, wenn das System in den modernen Standbymodus wechselt. Stattdessen wird das Bluetooth-Funkgerät auf der Grundlage von Leerlaufzeitüberschreitungen, die von BthPort verwaltet werden, in den und aus dem Ruhezustand (D2) versetzt. Zur Unterstützung des Aufweckens aus dem modernen Standbymodus bei mit Bluetooth verbundenen HID-Eingabegeräten bleibt das Funkgerät im Ruhezustand (D2) und wird für das Aufwecken aktiviert. Nur gekoppelte Bluetooth-HID-Geräte können das System im modernen Standbymodus aufwecken. Das Bluetooth-Radio soll einen sehr geringen Stromverbrauch von weniger als einem Milliwatt im Schlafmodus (D2) haben, wenn keine Geräte über RF-Verbindungen angeschlossen sind. Der Stromverbrauch kann je nach Anzahl der zugehörigen Geräte, den Typen dieser Geräte und deren Aktivitätsmustern variieren.

Das Bluetooth-Funkgerät muss auch die Funktion zum Deaktivieren des Radios über die Funkverwaltungs-Benutzeroberfläche unterstützen. Dieses Benutzeroberflächensteuerelement ist in Windows integriert. Nachdem das Bluetooth-Funkgerät über diese Benutzeroberfläche ausgeschaltet wurde, wird das Funkgerät in den Energiezustand "Aus" (D3) umgestellt, in dem erwartet wird, dass es fast null Watt verbraucht.

In früheren Versionen von Windows, einschließlich Windows 8 und Windows 8 RT, muss der Bluetooth-Geräteanbieter eine Funksteuerungs-DLL bereitstellen. Ab Windows 8.1 und Windows RT 8.1 sollten jedoch alle Bluetooth-Funkgeräte auf modernen Standbyplattformen die Bluetooth Core Specification Version 4.0 unterstützen. Daher müssen Anbieter keine Software-DLL mehr bereitstellen, um die Funk-On/Off-Steuerungsfunktion zu implementieren. Windows behandelt diese Funktion jetzt und ignoriert jede solche DLL, auch wenn vorhanden.

Energieverwaltungsmodi

Aus Softwaresicht unterstützt das Bluetooth-Radio drei Energieverwaltungsmodi, unabhängig vom Bus, an den das Radio angeschlossen ist. Der Windows Bluetooth-Treiber besitzt die Definition der drei Modi und verwaltet die Übergänge in und aus diesen Modi. In der folgenden Tabelle werden die drei Bluetooth-Funkleistungsmodi beschrieben.

Modus	BESCHREIBUNG	Gerätestromzustand (Dx)	Durchschnittlicher Stromverbrauch	Beenden der Latenz für aktiv	Übergangsmechanismus
Aktiv	Das Bluetooth-Funkgerät kommuniziert aktiv mit einem zugeordneten Gerät im Namen einer Anwendung auf dem Betriebssystem.	D0	Variiert, spezifisch für das Szenario und die zugehörigen Geräte.	Nicht verfügbar	Nicht verfügbar
Ruhezustand (meist Leerlauf mit niedrigem Tastverhältnis)	Das Bluetooth-Funkgerät befindet sich in einem Energiesparmodus. Das System wurde mit einem Remote-Bluetooth-Gerät gekoppelt, aber es gibt keine Verbindung zwischen den beiden. Das heißt, das Gerät ist nicht mehr verbunden. Der Bluetooth-Controller muss in der Lage sein, ein Wecksignal zu erzeugen (an den SoC, wenn das Funkgerät nicht integriert ist), wenn neue Daten von dem gekoppelten Gerät eintreffen. Oder das Bluetooth-Funkgerät hat keine Zuordnungen. Oder das Bluetooth-Radio verfügt über eine aktive Verbindung, die im Leerlauf ist (keine gesendeten/empfangenen Daten), und der Link befindet sich im Sniff-Modus.	D2	< 4 Milliwatt	< 100 Millisekunden	Der Windows-Bluetooth-Treiber initiiert einen Übergang zu D2 mithilfe eines D2-Leistungs-IRP. Der Windows-Bluetooth-Treiber initiiert ein ausstehendes Wait-Wake-IRP im zugrunde liegenden Transportbustreiber. Wenn das Bluetooth-Gerät über USB angeschlossen ist, entspricht dieser Zustand dem selektiven Anhalten. (Das selektive Aussetzen von Bluetooth erfordert, dass das Gerät im USB-Gerätedeskriptor als fernweckfähig und eigenbetrieben gekennzeichnet wird.)
Deaktiviert	Das Bluetooth-Funkgerät ist vollständig ausgeschaltet (null Watt) oder in einem Energiesparzustand, in dem kein Funkzustand erhalten bleibt. Das Bluetooth-Funkgerät ist nicht in der Lage, ein Wake-Signal in diesem Zustand an den SoC zu generieren. Das Bluetooth-Funkgerät kann auch keine Funksignale senden oder empfangen – alle RF-Komponenten werden ausgeschaltet.	D3	0 Watt	< 2 Sekunden	Der Windows Bluetooth-Treiber initiiert einen D3-Übergang mithilfe eines D3-Leistungs-IRP. Der Transportbustreiber oder die ACPI-Firmware des Systems kann die Stromversorgung entfernen oder GPIO-Leitungen umschalten, um die Bluetooth-Funkhardware in den Zustand "Aus" (D3) zu versetzen.

Das Bluetooth-Radio unterstützt auch einen zugehörigen Modus, in dem der Funksender als Reaktion auf eine Anforderung des Benutzers durch Software heruntergefahren werden kann. Wenn das Funkgerät für das Bluetooth-Gerät aktiviert ist, befindet sich dieses Gerät im Status Active (D0) oder Sleep (D2). Wenn das Funkmodul für das Bluetooth-Gerät vom Benutzer deaktiviert wird, stoppt Windows die Bluetooth-Aktivität, indem es die Protokolltreiber und deren untergeordnete Elemente plötzlich entfernt und anschließend den Funkmodulstapel in den Zustand "Aus" (D3) versetzt.

Mechanismen zur Verwaltung von Software-Energie

Die Energieverwaltung eines Bluetooth-Funkgeräts wird durch Dx-Zustandsübergänge des Geräts gesteuert, die von BthPort als Besitzer der Energierichtlinie (Power Policy Owner, PPO) initiiert werden. Das PPO entscheidet, wann das Gerät zwischen den Status Active (D0), Sleep (D2) und Off (D3) wechselt.

Wenn das Radio über keine zugehörigen Geräte verfügt, übergibt Windows das Gerät zu D2 und speichert es in diesem Zustand, bis der Benutzer den Kopplungsprozess beginnt. Wenn das Funkgerät einem oder mehreren Geräten zugeordnet ist, verwendet der Windows Bluetooth-Treiber ein Leerlauftimeout, um zu entscheiden, wann das Bluetooth-Funkgerät von D0 auf D2 umgestellt werden soll. Dieser Algorithmus verwendet das Muster der Bluetooth-Verwendung durch das Betriebssystem und Anwendungen, um zu bestimmen, wann das Radio in den D2-Zustand übergehen soll. So schaltet das Funkgerät beispielsweise einige Sekunden nach dem letzten Tastendruck auf einer Bluetooth-Tastatur auf D2 um, wenn keine andere Aktivität auf dem Bluetooth-Funkgerät stattfindet.

Der Windows Bluetooth-Treiber übergibt das Gerät in den Zustand D0 als Reaktion auf eines der folgenden Ereignisse:

• Der Benutzer beginnt einen Kopplungsprozess.
• Eine Anwendung fordert die Verwendung von Bluetooth-Funktionen an.
• Das Bluetooth-Radio hat eine Wake-Anforderung basierend auf der Eingabe eines zugeordneten Geräts generiert.

Im Gegensatz zu anderen Geräten folgt das Bluetooth-Radio dem gleichen Energieverwaltungsmuster während des modernen Standbymodus (Systemanzeige aus), das beim normalen Betrieb des Systems und der Anzeige ausgeführt wird. Das liegt daran, dass das Bluetooth-Radio voraussichtlich verfügbar ist, um den SoC zu aktivieren, wenn die Eingabe von einem zugeordneten Gerät jederzeit während des modernen Standbymodus empfangen wird. Wenn ein Benutzer beispielsweise eine Bluetooth-Tastatur einem Windows-Computer zugeordnet hat, sollte durch Drücken einer beliebigen Taste auf der Tastatur der Computer aus dem modernen Standbymodus aufgeweckt und die Anzeige eingeschaltet werden.

Wenn keine Geräte mit dem Funk verbunden sind, wird erwartet, dass das Funkgerät weniger als ein Milliwatt verbraucht, wenn es sich im Standbymodus (D2) befindet.

Wenn sich das Bluetooth-Radio im Zustand "Aus" (D3) befindet, wird erwartet, dass es fast null Watt verbraucht.

Hinweise zur Treiberimplementierung

Wenn das Bluetooth-Funkmodul über eine UART verbunden oder in das SoC selbst integriert ist, muss der Bluetooth-Geräteanbieter einen Transportbustreiber implementieren und bereitstellen. Der Verkehrsbusfahrer ist für Folgendes verantwortlich:

• Übersetzen von Bluetooth HCI-Paketanforderungen vom Windows Bluetooth-Treiber (Bthmini.sys) in Befehle, die über den Transportbus an das Bluetooth-Radio gesendet werden.
• Übergang des Bluetooth-Funkgeräts in verschiedene Energieverwaltungsmodi, die den Geräteenergiezuständen Aktiv (D0), Ruhezustand (D2) und Aus (D3) entsprechen. Der Treiber implementiert auch Routinen, die Energieverwaltungsereignisse behandeln.
• Konfigurieren des Bluetooth-Radios, um den SoC zu reaktivieren, wenn ein Gerät Eingaben generiert, und den Zustand beliebiger optionaler GPIO-Leitungen vom SoC zum Bluetooth-Radio ändern, das für die Energieverwaltung verwendet wird.
• Aufzählen und Energieverwaltung anderer Geräte (z. B. ein FM-Sender oder GPS-Gerät), die denselben Bus wie das Bluetooth-Radio gemeinsam nutzen. Wenn andere Geräte physisch mit dem gemeinsam genutzten Bus verbunden sind, aber nicht dem Betriebssystem ausgesetzt sind, muss der Transportbustreiber diese Geräte vollständig ausschalten.

Einzelheiten zur Implementierung eines Transportbustreibers finden Sie unter „Richtlinien zur Handhabung des Transportbustreibers für die Bluetooth-Leistungssteuerung“. Transportbustreiber müssen mit dem Windows Driver Framework (WDF) geschrieben werden. Ein Beispieltreiber ist unter Bluetooth Serial HCI Bus Driver verfügbar.

Um die Bluetooth-Funkstromverwaltung zu aktivieren, muss der Transportbustreiber die folgenden Aktionen ausführen:

• Aktivieren Sie die Unterstützung für die Leerlauf-Energieverwaltung während der Laufzeit und stellen Sie die Unterstützung für die Geräte-Energiezustände Aktiv (D0), Ruhezustand (D2) und Aus (D3) bereit.
• Zeigt dem Windows-Bluetooth-Treiber an, dass das Bluetooth-Funkgerät in der Lage ist, Weck-Ereignisse aus dem D2-Zustand zu signalisieren.
• Unterstützt das Aktivieren des Bluetooth-Funkgeräts zum Aufwecken des SoC und das Deaktivieren des Wecksignals des Bluetooth-Geräts für den SoC. Diese Unterstützung kann die Verarbeitung eines oder mehrerer GPIO-Interrupts und die Ausführung von Wake-Methoden innerhalb von WDF erfordern.
• Ändern Sie den Zustand beliebiger optionaler GPIO-Leitungen vom SoC zum Bluetooth-Funkgerät, wenn das Gerät zwischen dem Status "Active (D0),Sleep (D2) und Off (D3)" wechselt.

Wenn das Bluetooth-Funkgerät in das SoC selbst integriert ist, kann sich der Transportbustreiber beim Windows-Energieverwaltungsrahmen registrieren, um den Energiestatus des Bluetooth-Funkgeräts an ein SoC-spezifisches Power-Engine-Plug-in (PEP) zu übermitteln. Dazu legen Sie das IdleTimeoutType-Element der WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS Struktur auf den Wert "SystemManagedIdleTimeout" fest.

Wenn das Bluetooth-Funkgerät über USB verbunden ist, muss der integrierte Windows-USB-Bluetooth-Treiberstapel verwendet werden. Der Stack übernimmt alle Energiemanagementvorgänge.

Funkverwaltung

Der Zustand des Bluetooth-Funksenders ist direkt an den Energiezustand des Geräts gebunden. Der Funksender wird voraussichtlich eingeschaltet sein, wenn sich das Radio im Energiezustand "Aktiv (D0) oder Sleep (D2)" befindet. Der Funksender muss ausgeschaltet werden, wenn das Funkgerät in den Zustand "Aus" (D3) wechselt.

Wenn der Benutzer das Bluetooth-Radio deaktiviert, beendet Windows die Bluetooth-Aktivität, indem ausstehende E/A-Vorgänge abgebrochen und die Protokolltreiber und ihre untergeordneten Elemente entladen werden. Der Windows Bluetooth-Treiberstapel gibt dann den HCI_Reset Befehl an den Controller aus, um das Radio auf den Standardzustand zurückzusetzen. Im Standardzustand darf der Controller keine Funksignale übertragen oder empfangen. Schließlich wechselt der Controller in den Zustand "Aus" (D3).

Als Reaktion auf den Übergang zu "Aus" (D3) muss der Transportbustreiber das Bluetooth-Gerät mit gerätespezifischen Methoden auf den niedrigsten Leistungszustand ausschalten. Eine typische Implementierung besteht darin, den Zustand einer GPIO-Leitung von der SoC zum Bluetooth-Radio zu ändern, um die Stromversorgung für das Bluetooth-Modul zu deaktivieren. Eine alternative Implementierung besteht darin, dass die ACPI-Firmware die Stromversorgung vom Bluetooth-Modul mittels der Steuerungsmethoden _PS0 und _PS3 entfernt.

Wenn der Benutzer das Bluetooth-Funkgerät einschaltet, übergibt Windows das Radio in den Status "Active (D0)", initialisiert das Radio neu und listet dann untergeordnete Protokolltreiber erneut auf. Wenn das Funkgerät in den aktiven Zustand (D0) übergeht, müssen alle erforderlichen GPIO-Leitungen als Teil der normalen D0-Sequenz für das Bluetooth-Funkgerät umgeschaltet werden. Wenn die ACPI-Firmware verwendet wurde, um das Funkgerät herunterzuschalten, muss sie die Stromversorgung mithilfe der _PS0-Steuerungsmethode wiederherstellen.

Als Teil dieser normalen Sequenz muss der Transportbustreiber das Gerät als intern verbundenes Gerät markieren, indem die ContainerId des Bluetooth-Radios auf einen bestimmten GUID-Wert festgelegt wird, {0000000-0000-000-ffffffffffff}. Auf diese Weise können die Windows-Funkbenutzeroberflächenelemente erkennen, dass das Bluetooth-Funkgerät, das vom Transportbustreiber verfügbar gemacht wird, intern im Computer ist und kein extern angeschlossenes Funkgerät, für das keine Funksteuerung vorgesehen ist.

Unterstützte Hardwareleistungskonfigurationen

Die Hardwarekonfiguration der Energieverwaltung für ein Bluetooth-Funkgerät hängt vom Kommunikationsbus ab. Im Allgemeinen wird erwartet, dass alle Bluetooth-Radios die folgenden Hardware-Energieverwaltungsfeatures gemeinsam haben:

• Unterstützung für den Zustand "Aus" (D3) als Mittel zum Deaktivieren des Radios als Reaktion auf eine Benutzeranforderung. Durch das Deaktivieren des Radios wird das Bluetooth-Radio in einen Energiesparzustand versetzt, der fast null Watt beträgt.
• Ein Mechanismus zum Eingeben eines Energiesparmoduszustands (Low-Power Sleep, D2), in dem Verbindungen mit zugehörigen Geräten beibehalten werden, aber es gibt keine aktiven Übertragungen.
• Ein Mechanismus zum Generieren eines Wake-Interrupts, wenn ein zugeordnetes Gerät Daten für den SoC enthält und sich der SoC in einem Energiesparzustand befindet, in dem der Bus, an den das Bluetooth-Funkgerät angeschlossen ist, derzeit nicht aktiv ist.

Jeder der unterstützten Busse (USB, UART und Integration in das SoC) für das Bluetooth-Funkgerät unterstützt alle drei grundlegenden Hardwareleistungsverwaltungsfeatures in der vorherigen Liste. Darüber hinaus kann jedes Bluetooth-Funkgerät herstellerspezifische oder gerätespezifische Energieverwaltungsfeatures aufweisen, dies ist jedoch außerhalb des Umfangs dieses Themas.

Bluetooth-Funkanbieter werden ermutigt, Leistungsverwaltungsfeatures mit Mehrwert auf eine Weise zu implementieren, die in der Hardware autonom ist und keine zusätzliche vom Hersteller bereitgestellte Treibersoftware auf dem Windows-System erfordert. Bluetooth-Funkanbieter werden auch ermutigt, ihre Treiber und ihre Energieverwaltungssoftware so zu implementieren, dass plattformspezifische Unterschiede in die ACPI-Firmware des Systems abstrahiert werden, anstatt in den Gerätetreibercode oder die Inf-Datei des Treibers. Mit diesem Ansatz kann ein Treiberpaket für das Bluetooth-Gerät auf zusätzlichen Plattformen wiederverwendet werden, ohne dass eine Aktualisierung der Treiberquelle, der Binärdatei oder des signierten Installationspakets erforderlich ist.

Bluetooth-Funk, der über einen UART außerhalb des SoC angeschlossen ist

Wenn das Bluetooth-Funkgerät über eine UART verbunden ist und sich physisch außerhalb des SoC befindet, muss der Bluetooth-Funkanbieter einen Transportbustreiber bereitstellen, der das Bluetooth-Radio und alle anderen Gerätefunktionen (z. B. ein FM-Radio) verfügbar macht, die denselben Kommunikationspfad über die UART gemeinsam nutzen. Der Bustreiber ist auch für die Verwaltung der GPIO-Ressourcen verantwortlich, die den Stromverbrauch und die Aufwachfunktion des Bluetooth-Funkgeräts steuern.

Im Gegensatz zu anderen Geräteklassen werden die GPIO-Leitungen, die Bluetooth-Energie und -Wake steuern, direkt vom Transportbustreiber verwaltet, anstatt von ACPI-Steuerungsmethoden abstrahiert zu werden. Dieses Steuerungsschema ist ein Ergebnis des Multifunktionsbustreiberdesigns, das das Bluetooth-Radio und andere Funktionen aufzählt, die denselben UART-Port gemeinsam nutzen. In diesem Design wird der Windows ACPI-Treiber, Acpi.sys, nicht in den Treiberstapeln für Bluetooth und das FM-Radio geladen, sodass die Ausführung der ACPI-Steuerungsmethode nicht als Möglichkeit zum Reagieren auf einen Geräte-DX-Zustandsübergang verwendet werden kann.

Wenn das Bluetooth-Funkgerät an den UART-Port auf dem SoC angeschlossen ist, muss der Systemintegrator einen Pin auf dem GPIO-Controller auf dem SoC verwenden, um die Energie an das Funkgerät zu steuern. In der ACPI-Firmware muss dieser Pin dem Geräteobjekt, das das Stammgerät des Transportbustreibers darstellt, als GPIO-E/A-Ressource zugewiesen werden. Der GPIO-Pin kann direkt mit dem Bluetooth-Funkgerät verbunden werden, wenn das Funkgerät das Ausschalten des Geräts mit internem Power-Gating unterstützt.

Wenn das Bluetooth-Funkgerät Power-Gating unterstützt, kann die Stromquelle für das Bluetooth-Funkgerät an eine beliebige Systemstromschiene angeschlossen werden.

Wenn das Funkgerät keine interne Stromversorgung unterstützt, die durch einen GPIO-Pin gesteuert wird, muss der Systemintegrator das Bluetooth-Funkgerät auf einer Netzschiene platzieren, die umschaltbar ist. Der GPIO-Pin des SoC wird dann mit der Hardware für die Stromschaltung verbunden. Bei diesem Entwurf können ACPI-Steuerungsmethoden nicht zum Nachverfolgen der Referenzanzahl oder zum Aggregieren des Leistungszustands mehrerer Geräte verwendet werden, die denselben Netzschienen gemeinsam nutzen, sodass das Bluetooth-Funkgerät auf seiner eigenen schaltbaren Stromschiene isoliert werden muss.

Der Systemintegrator muss einen zusätzlichen Pin am GPIO-Controller auf dem SoC verwenden, um Wake-Interrupts vom Bluetooth-Funkgerät zu empfangen. Unterbrechungen auf diesem Pin müssen in der Lage sein, den SoC aus seinem energiesparendsten Zustand zu wecken. In einigen SoC-Designs wird ein solcher Pin als always-on GPIO-Pin bezeichnet, da der GPIO-Controller Unterbrechungen auf diesem Pin jederzeit erkennen kann, unabhängig vom Energiezustand des SoC. Die Always-On-Funktion kann in der Hardware auf eine bestimmte Gruppe von GPIO-Pins auf dem SoC beschränkt sein oder in der Firmware konfigurierbar sein. Es ist wichtig, dass der Systemintegrator dieses Design mit dem SoC-Anbieter überprüft, um sicherzustellen, dass der Wake-Interrupt des Bluetooth-Radios dazu führt, dass der SoC seinen tiefsten Leerlauf-Energiezustand verlässt. (Zu jeder Zeit während des modernen Standbymodus befindet sich das System in S0. Moderne Standby-Systeme unterstützen S3 nicht.)

Wenn alle vom Transportbustreiber aufgezählten Funktionen abgeschaltet wurden und das vom ACPI aufgezählte Transportbusgerät in den Zustand D3 übergeht, kann der immer eingeschaltete GPIO-Pin abgeschaltet werden. Dies tritt auf, wenn die Funkgeräte für alle Gerätefunktionen, die vom Transportbustreiber aufgelistet werden, vom Benutzer deaktiviert wurden.

Bluetooth-Funk über USB

Wenn das Bluetooth-Funkgerät an das SoC- oder Core-Silizium über den USB-Bus angeschlossen ist, muss das Funkgerät von einer anderen Quelle als dem USB-Bus betrieben werden. In der USB-Spezifikation wird ein solches Funkgerät als selbstbetrieben beschrieben, und diese Funktion muss in den USB-Deskriptoren des Bluetooth-Geräts gemeldet werden.

In ähnlicher Weise muss die Hardware des USB-Geräts die Unterstützung für das ferngesteuerte Aufwecken ankündigen, d. h. die Fähigkeit des Bluetooth-Funkgeräts, In-Band-USB-Resume-Signale zu erzeugen, um den USB-Host-Controller aufzuwecken. Die Remote-Wake-Funktion muss auch in den USB-Deskriptoren des Bluetooth-Geräts beworben werden.

Das Bluetooth-Funkgerät muss sowohl die Selbstversorgungs- als auch die Fernweckfunktion unterstützen, damit es in den Ruhezustand (D2) übergehen und die selektive Aussetzung aktivieren kann.

Wenn sich das Bluetooth-Funkmodul im Schlafzustand (D2) befindet und Daten von einem zugeordneten Gerät für den Host verfügbar sind, muss das Bluetooth-Funkmodul das Signal zur Fernaufweckung erzeugen, um den Host zu reaktivieren. Ein bandexternes Fortsetzungssignal über eine GPIO-Leitung zum Kernsilizium wird nicht unterstützt. Das Bluetooth-Funkgerät, einschließlich seiner USB-Verbindungsschaltung, wird voraussichtlich weniger als ein Milliwatt Energie im Standbymodus (D2) verbrauchen.

Aktivierungsbedenken

Das Bluetooth-Radio soll in der Lage sein, einen Wake-Interrupt zu generieren, wenn sich das Gerät im Standby-Modus (D2) befindet. Der Wake-Interrupt muss dazu führen, dass der SoC eingeschaltet wird, auch wenn sich der SoC in seinem niedrigsten Leistungszustand befindet. In der folgenden Tabelle sind die beiden Bluetooth-Wake-Signaling-Mechanismen zusammengefasst.

Verbindungsbus	Hardwaresignalpfad	Kommentare und Notizen
UART (mit vom Anbieter bereitgestellter Transportbustreiber)	GPIO vom Bluetooth-Radio zum SoC.	Das Funkgerät muss mit einem GPIO-Pin verbunden sein, der den SoC aus dem niedrigsten Leistungszustand reaktivieren kann.
USB	Bandinterne USB-Wiederaufnahme-Signalisierung nach selektiver Unterbrechung.	Bandexternes GPIO-Wecken wird nicht unterstützt.

Tests und Prüfung

Bluetooth-Gerätehersteller werden ermutigt, den Energieverwaltungsvorgang des Bluetooth-Funkgeräts zu testen und zu überprüfen.

Die Übergänge zwischen den Zuständen Active (D0), Sleep (D2) und Off (D3) können mithilfe des Xperf-Tools leicht beobachtet werden, wie in anderen Abschnitten beschrieben.

Bluetooth-Treiberaktivitäten können mithilfe der in Windows integrierten ETW-Instrumentierung überwacht werden. Der Treiberentwickler wird ermutigt, die Ereignisablaufverfolgung für Windows (ETW)-Instrumentierung zu verwenden, um erhebliche Änderungen des Energieverwaltungszustands im Treiber verfügbar zu machen und diese mithilfe des Xperf-Tools oder der integrierten Windows-Ereignisanzeige zu beobachten.

Wenn das Bluetooth-Funkgerät über USB angeschlossen ist, kann das integrierte Dienstprogramm Powercfg.exe zusammen mit der Befehlszeilenoption /energy verwendet werden, um zu überprüfen, ob das Funkgerät in den Ruhezustand (D2) übergeht und angehalten wird. So verwenden Sie das hilfsprogramm Powercfg.exe:

• Öffnen Sie ein Eingabeaufforderungsfenster als Administrator.
• Ändern Sie das Stammverzeichnis des Laufwerks (cd \).
• Geben Sie den Befehl powercfg.exe /energy ein.
• Warten Sie die standardmäßigen 60 Sekunden ab.
• Das Hilfsprogramm Powercfg.exe gibt die Anzahl der Fehler und Warnungsbedingungen auf dem System aus, wie im folgenden Screenshot gezeigt.
• Nachdem das Tool die Zusammenfassungsinformationen in das Eingabeaufforderungsfenster geschrieben hat, wird eine HTML-Datei mit dem Namen Energy-report.htmlgeneriert. Öffnen Sie die Datei, und suchen Sie nach Fehler- oder Warnbedingungen vom USB-Bluetooth-Gerät. Die folgende Beispielzusammenfassung meldet, dass ein USB-Bluetooth-Gerät nicht in den Ruhezustand (D2) übergegangen ist, wenn es sich im Leerlauf befindet.

Bluetooth-Gerätehersteller, die zusätzliche Bluetooth-Profiltreiber und -Anwendungen von Drittanbietern bereitstellen, müssen überprüfen, ob ihre Software die Entfernung von Überraschungen unterstützt und der Funkverwaltungsinfrastruktur das ordnungsgemäße Deaktivieren des Bluetooth-Funkgeräts zeitnah ermöglicht. Diese Szenarien sollten überprüft werden, während das Profil oder die Anwendung verwendet wird. Bei Audiotreibern sollte beispielsweise Bluetooth-Audiostreaming vorhanden sein, während das Radio ausgeschaltet ist. Anschließend sollte das Radio wieder aktiviert und der Audiodatenstrom neu gestartet werden, um sicherzustellen, dass es weiterhin funktioniert.

Prüfliste zur Bluetooth-Energieverwaltung

Systemintegratoren, Bluetooth-Funkanbieter und SoC-Anbieter sollten die folgende Checkliste verwenden, um sicherzustellen, dass ihr System-Energieverwaltungsdesign mit Windows 8 und Windows 8.1 kompatibel ist:

• Bestimmen Sie den Kommunikationsbus für den Bluetooth-Funkgerät im Systementwurf. Das Bluetooth-Funkgerät ist entweder über UART angeschlossen oder über USB angeschlossen.

• Stellen Sie sicher, dass das Bluetooth-Radio einen niedrigen Energiesparmodus unterstützt, der weniger als ein Milliwatt verbraucht, wenn keine Geräte verbunden sind.

  Der Stromverbrauch des Bluetooth-Radios im Energiesparmodus kann je nach Anzahl der aktuell vorhandenen Geräte variieren, sollte jedoch in der Regel nicht zu jeder Zeit fünf Milliwatt überschreiten.

• Stellen Sie sicher, dass das Bluetooth-Radio die folgenden grundlegenden erforderlichen Energieverwaltungsfunktionen unterstützt:

  • Unterstützung für den Zustand "Aus" (D3) als Möglichkeit, dem Benutzer das Deaktivieren des Radios zu ermöglichen.
  • Ein Mechanismus für den Energiesparmodus (Low-Power Sleep, D2), in dem Verbindungen mit zugehörigen Geräten beibehalten werden, aber es gibt keine aktiven Übertragungen.
  • Ein Mechanismus zum Aktivieren des SoC, wenn ein zugeordnetes Gerät Daten generiert und sich der SoC in einem Energiesparmodus befindet.

• Wenn das Bluetooth-Funkgerät über einen Nicht-USB-Bus (UART oder integriert in den SoC) angeschlossen ist, muss der Bluetooth-Funkanbieter einen Transportbustreiber entwickeln. Der Verkehrsbusfahrer muss folgendes tun:

  • Die Funktionen und Anforderungen, die in den Richtlinien zur Handhabung des Transportbustreibers für die Bluetooth-Leistungssteuerung beschrieben sind, unterstützen.
  • Übersetzen Sie Bluetooth-Anforderungen vom Windows Bluetooth-Treiber (Bthmini.sys) in Befehle in das Bluetooth-Radio über den UART-Bus oder einen proprietären internen SoC-Bus.
  • Übertragen Sie das Bluetooth-Funkgerät in verschiedene Energieverwaltungsmodi, die den Status Active (D0), Sleep (D2) und Off (D3) zugeordnet sind. Der Treiber muss auch Routinen implementieren, die irPs für die Gerätestromverwaltung (Dx) verarbeiten.
  • Konfigurieren Sie das Bluetooth-Radio so, dass das SoC aktiviert wird, wenn ein Gerät Eingaben generiert, und ändern Sie den Zustand aller optionalen GPIO-Leitungen, die den SoC für energieverwaltungszwecke mit dem Bluetooth-Funk verbinden.
  • Geben Sie andere Geräte (z. B. einen FM-Transmitter) an, die gemeinsam mit dem Bluetooth-Funkgerät genutzt werden können.
  • Verwenden Sie das Windows Driver Framework (WDF) für die Treiberentwicklung.
  • Auf der Grundlage des Bluetooth Serial HCI Bus Driver implementiert werden.

• Wenn das Bluetooth-Funkgerät über USB angeschlossen ist, muss der Bluetooth-Funkanbieter:

  • Aktivieren Sie die Unterstützung für das selektive Anhalten im Radio.
  • Stellen Sie sicher, dass das Funkgerät über die Fernaktivierungs- und selbstversorgenden Funktionen verfügt, die im USB-Gerätedeskriptor festgelegt sind.
  • Stellen Sie sicher, dass das Radio (einschließlich USB-Komponenten) weniger als ein Milliwatt verbraucht.

• Unabhängig vom Verbindungsbus muss das Bluetooth-Funkgerät für ein intern verbundenes Funkgerät Folgendes ausführen:

  • Stellen Sie sicher, dass alle RF-Komponenten ausgeschaltet sind, nachdem ein HCI_Reset-Befehl an das Radio gesendet wurde, um das Radio auszuschalten. Das Funkgerät sollte nicht in der Lage sein, Funksignale zu übertragen oder zu empfangen.
  • Geben Sie den niedrigsten Energiemodus ein, wenn er auf den Zustand "Aus" (D3) festgelegt ist.

• Wenn das Bluetooth-Funkgerät über UART angeschlossen ist, muss der Systemintegrator das Wakesignal vom Bluetooth-Funk an einen GPIO-Pin auf dem SoC anschließen, der den SoC vom niedrigsten Energiezustand aus reaktivieren kann.

  • Der SoC kann die Weiterleitung von Wakesignalen an einen begrenzten Satz von GPIO-Pins erfordern, die vorkonfiguriert sind, um immer aktiviert zu sein.
  • Oder der SoC kann die Konfiguration eines GPIO-Pins in einen immer-aktiv-Pin in der Systemfirmware während des Bootprozesses unterstützen.

• Der Systemintegrator muss testen und überprüfen, ob das Bluetooth-Funkgerät in den Standbymodus (D2) wechselt, wenn keine zugehörigen Geräte vorhanden sind.

• Der Systemintegrator muss testen und überprüfen, ob das Bluetooth-Funkgerät in den Standbymodus (D2) wechselt, wenn alle zugehörigen Geräte keine aktiven Übertragungen haben.

• Der Systemintegrator muss testen und überprüfen, ob das Bluetooth-Radio den SoC aus dem niedrigsten Leistungszustand wecken kann, wenn sich das Radio im Standbymodus (D2) befindet.

• Der Systemintegrator muss testen und überprüfen, ob das Bluetooth-Radio während des Standbyzustands (D2) keine spurhaften Wake-Signale generiert.

• Der Systemintegrator muss testen und überprüfen, ob Add-On-Drittanbietersoftware, z. B. Profiltreiber und Anwendungen, ordnungsgemäß mit der Bluetooth-Funkverwaltung funktionieren. Das Radio sollte deaktiviert und eingeschaltet werden, während die Software von Drittanbietern aktiv verwendet wird (z. B. Audio wiedergeben oder eine Datei übertragen).