Administración de energía Bluetooth para plataformas modernas en espera

Un dispositivo de radio Bluetooth permite la comunicación rf de corto alcance entre un equipo y un dispositivo de entrada, un dispositivo de audio u otro periférico de usuario conectado a Bluetooth. En un pc en espera moderno, el controlador para una radio Bluetooth debe administrar los estados de energía de este dispositivo según las directrices presentadas en este artículo.

Radio Bluetooth

En un sistema Windows, la forma en que se administra el estado de alimentación del dispositivo de radio Bluetooth depende del bus al que está conectada la radio. En plataformas de hardware que admiten el modelo de energía en espera moderno, Windows admite radios Bluetooth que están conectados a UART o a bus serie universal (USB). (En teoría, el modelo de controlador de bus de transporte Bluetooth que se introdujo en Windows 8 debe admitir cualquier bus de comunicación subyacente. Actualmente, Microsoft comprueba la compatibilidad moderna en espera solo para las radios Bluetooth que están conectadas a UART o USB, o se integran en un sistema en un chip (SoC)).

Al igual que en las pilas típicas de controladores de Windows, la directiva de energía de radio Bluetooth se administra mediante un único propietario de la directiva de energía (PPO), específicamente BthPort (bthport.sys). BthPort funciona junto con un controlador específico del transporte (UART o USB) correspondiente para dirigir adecuadamente la radio al estado de alimentación deseado. En el caso de USB, esto se hace a través de la suspensión selectiva USB a través del controlador de host USB. En el caso de UART, un controlador de bus de transporte proporcionado por el proveedor adicional coordina las solicitudes de BthPort al dispositivo de radio Bluetooth a través de la conexión de bus específica del sistema. Para controlar el hardware, el controlador usa una combinación de comunicación de bus en banda, coordinación con el plug-in del motor de alimentación (PEP) o señalización fuera de banda a través de patillas GPIO.

Los dispositivos de radio Bluetooth suelen admitir varios modos de bajo consumo, algunos de los cuales pueden ser propietarios del propio dispositivo. La pila de controladores Bluetooth de Windows requiere que una radio Bluetooth admita los siguientes tres estados de alimentación del dispositivo:

• Activo (D0)
• Suspensión (D2)
• Desactivado (D3)

Se espera que la administración de energía del dispositivo para una radio Bluetooth funcione de forma coherente en todos los estados de energía del sistema. La radio Bluetooth no entra en modo de administración de energía especial cuando el sistema entra en espera moderno. En su lugar, la radio Bluetooth se pasa dentro y fuera del estado de suspensión (D2) en función de los tiempos de espera de inactividad administrados por BthPort. Para admitir la reactivación desde el modo de espera moderno en dispositivos de entrada HID conectados a Bluetooth, la radio permanece en estado suspensión (D2) y está armado para reactivación. Solo el dispositivo Bluetooth HID emparejado puede reactivar el sistema durante el modo de espera moderno. Se espera que la radio Bluetooth tenga un consumo de energía muy bajo (menos de un milliwatt) en el estado Suspensión (D2) si no hay dispositivos conectados a través de enlaces RF. Se puede esperar que el consumo de energía varíe en función del número de dispositivos asociados, los tipos de esos dispositivos y sus patrones de actividad.

La radio Bluetooth también debe admitir la capacidad de apagar la radio a través de la interfaz de usuario de administración de radio. Este control de interfaz de usuario está integrado en Windows. Después de apagar la radio Bluetooth a través de esta interfaz de usuario, la radio se pasa al estado de alimentación Desactivado (D3), en el que se espera que consuma casi cero vatios.

Las versiones anteriores de Windows, incluidas Windows 8 y Windows 8 RT, requieren que el proveedor del dispositivo Bluetooth proporcione un archivo DLL de control de radio. Sin embargo, a partir de Windows 8.1 y Windows RT 8.1, todas las radios Bluetooth en plataformas modernas en espera deben admitir la especificación Bluetooth Core Versión 4.0. Por lo tanto, los proveedores ya no tienen que suministrar un archivo DLL de software para implementar la función de control de radio on/off. Windows ahora controla esta función y omitirá cualquier archivo DLL de este tipo, incluso si está presente.

Modos de administración de energía

Desde un punto de vista del software, la radio Bluetooth admite tres modos de administración de energía, independientemente del bus al que está conectada la radio. El controlador Bluetooth de Windows posee la definición de los tres modos y administra las transiciones dentro y fuera de estos modos. En la tabla siguiente se describen los tres modos de alimentación de radio Bluetooth.

Mode	Descripción	Estado de alimentación del dispositivo (Dx)	Consumo medio de energía	Latencia de salida a activa	Mecanismo de transición
Activo	La radio Bluetooth se comunica activamente con un dispositivo asociado en nombre de una aplicación en el sistema operativo.	D0	Varía, específico del escenario y de los dispositivos asociados.	N/D	N/D
Suspensión (principalmente inactiva con un ciclo de trabajo de bajo tipo)	La radio Bluetooth está en estado de bajo consumo. El sistema se ha emparejado con un dispositivo Bluetooth remoto, pero no hay conexión entre los dos. Es decir, el dispositivo se ha desconectado. El controlador Bluetooth debe ser capaz de generar una señal de reactivación (al SoC si la radio no está integrada) cuando llegan nuevos datos desde el dispositivo emparejado. O bien, la radio Bluetooth no tiene asociaciones. O bien, la radio Bluetooth tiene una conexión activa que está inactiva (no se envían o reciben datos) y el vínculo está en modo de examen.	D2	< 4 miliwatts	< 100 milisegundos	El controlador Bluetooth de Windows inicia una transición D2 mediante un IRP de alimentación D2. El controlador Bluetooth de Windows inicia un IRP de reactivación de espera pendiente en el controlador subyacente del bus de transporte. Si el dispositivo Bluetooth está conectado a través de USB, este estado es equivalente a la suspensión selectiva. (La suspensión selectiva de Bluetooth requiere que el dispositivo se marque como compatible con reactivación remota y autoalimentado en el descriptor del dispositivo USB).
Desactivado	La radio Bluetooth está completamente desactivada (cero vatios) o en un estado de bajo consumo en el que no se conserva ningún estado de radio. La radio Bluetooth no es capaz de generar una señal de reactivación al SoC en este estado. La radio Bluetooth tampoco es capaz de emitir o recibir señales de radio, todos los componentes rf están apagados.	D3	0 Vatios	< 2 segundos	El controlador Bluetooth de Windows inicia una transición D3 mediante un IRP de alimentación D3. El controlador del bus de transporte o el firmware ACPI del sistema pueden quitar la alimentación o alternar las líneas GPIO para pasar el hardware de radio Bluetooth al estado Desactivado (D3).

La radio Bluetooth también admite un modo asociado en el que el transmisor de radio puede ser apagado por software en respuesta a una solicitud del usuario. Cuando la radio está habilitada para el dispositivo Bluetooth, este dispositivo está en estado Activo (D0) o Suspensión (D2). Cuando el usuario deshabilita la radio del dispositivo Bluetooth, Windows detiene la actividad Bluetooth quitando sorpresa los controladores de protocolo y sus elementos secundarios y, a continuación, realizando la transición de la pila del dispositivo de radio al estado Desactivado (D3).

Mecanismos de administración de energía de software

La administración de energía de un dispositivo de radio Bluetooth está controlada por transiciones de estado Dx del dispositivo iniciadas por BthPort como propietario de la directiva de energía (PPO). El PPO decide cuándo cambia el dispositivo entre los estados Activo (D0), Suspensión (D2) y Desactivado (D3).

Cuando la radio no tiene ningún dispositivo asociado, Windows pasa el dispositivo a D2 y lo conserva en ese estado hasta que el usuario inicia el proceso de emparejamiento. Cuando la radio está asociada a uno o varios dispositivos, el controlador Bluetooth de Windows usa un tiempo de espera de inactividad para decidir cuándo realizar la transición de la radio Bluetooth de D0 a D2. Este algoritmo usa el patrón de uso de Bluetooth por parte del sistema operativo y las aplicaciones para determinar cuándo realizar la transición de la radio al estado D2. Por ejemplo, la radio pasa a D2 varios segundos después de la última pulsación de tecla en un teclado Bluetooth si no hay ninguna otra actividad en la radio Bluetooth.

El controlador Bluetooth de Windows realiza la transición del dispositivo a D0 en respuesta a cualquiera de las siguientes opciones:

• El usuario inicia un proceso de emparejamiento.
• Una aplicación solicita el uso de la funcionalidad bluetooth.
• La radio Bluetooth ha generado una solicitud de reactivación basada en la entrada de un dispositivo asociado.

A diferencia de otros dispositivos, la radio Bluetooth sigue el mismo patrón de administración de energía durante el modo de espera moderno (pantalla del sistema) que hace cuando el sistema está normalmente operativo y la pantalla está activada. Esto se debe a que se espera que la radio Bluetooth esté disponible para reactivar el SoC cuando se recibe la entrada de un dispositivo asociado en cualquier momento durante el modo de espera moderno. Por ejemplo, si un usuario ha asociado un teclado Bluetooth con un equipo Windows, al presionar cualquier tecla del teclado se debe reactivar el equipo desde el modo de espera moderno y activar la pantalla.

Si no hay ningún dispositivo asociado a la radio, se espera que la radio se configure para consumir menos de un milliwatt cuando se encuentra en estado suspensión (D2).

Cuando la radio Bluetooth está en estado Desactivado (D3), se espera que consuma casi cero vatios.

Notas de implementación del controlador

Si la radio Bluetooth está conectada a través de un UART o se integra en el propio SoC, el proveedor del dispositivo Bluetooth es necesario para implementar y proporcionar un controlador de autobús de transporte. El conductor del autobús de transporte es responsable de lo siguiente:

• Traducción de solicitudes de paquetes Bluetooth HCI desde el controlador Bluetooth de Windows (Bthmini.sys) a comandos que se envían a través del bus de transporte a la radio Bluetooth.
• Transición del dispositivo de radio Bluetooth a varios modos de administración de energía que se asignan a los estados de alimentación activo (D0), Suspensión (D2) y Apagado (D3). El controlador también implementa rutinas que controlan los eventos de administración de energía.
• Configurando la radio Bluetooth para reactivar el SoC cuando un dispositivo genera la entrada y cambiar el estado de las líneas GPIO opcionales del SoC a la radio Bluetooth que se usan para la administración de energía.
• Enumeración y administración de energía de otros dispositivos (como un transmisor FM o un dispositivo GPS) que comparten el mismo bus que la radio Bluetooth. Si otros dispositivos están conectados físicamente al bus compartido, pero no se exponen al sistema operativo, el controlador del bus de transporte debe apagar completamente estos dispositivos.

Para obtener más información sobre cómo implementar un controlador de autobús de transporte, consulta Transport Bus Driver for Bluetooth Power Control Handling Guidelines. Los controladores de autobús de transporte deben escribirse mediante Windows Driver Framework (WDF). Hay disponible un controlador de ejemplo en Bluetooth Serial HCI Bus Driver.

Para habilitar la administración de energía de radio Bluetooth, el controlador del bus de transporte debe realizar las siguientes acciones:

• Habilite la compatibilidad con la administración de energía inactiva en tiempo de ejecución y exponga la compatibilidad con los estados de alimentación del dispositivo Activo (D0), Suspensión (D2) y Apagado (D3).
• Indique al controlador Bluetooth de Windows que el dispositivo de radio Bluetooth es capaz de señalizar eventos de reactivación desde el estado D2.
• Soporte para arming the Bluetooth radio device to wake the SoC and disarming the Bluetooth device's wake signal to the SoC. Esta compatibilidad puede requerir controlar una o varias interrupciones gpIO y ejecutar métodos de reactivación dentro de WDF.
• Cambie el estado de las líneas GPIO opcionales del soC al dispositivo de radio Bluetooth cuando el dispositivo cambie entre los estados Activo (D0), Suspensión (D2) y Desactivado (D3).

Si la radio Bluetooth está integrada en el propio SoC, el controlador del bus de transporte puede registrarse con el marco de administración de energía de Windows para comunicar el estado de energía de la radio Bluetooth a un complemento de motor de alimentación específico de SoC (PEP). Esto se logra estableciendo el miembro IdleTimeoutType de la estructura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS en el valor SystemManagedIdleTimeout.

Si la radio Bluetooth está conectada a través de USB, se debe usar la pila integrada del controlador Bluetooth USB de Windows. La pila controla todas las operaciones de administración de energía.

Administración de radio

El estado del transmisor de radio Bluetooth está vinculado directamente al estado de alimentación del dispositivo. Se espera que el transmisor de radio esté encendido cuando la radio esté en estado activo (D0) o suspensión (D2). El transmisor de radio debe estar desactivado cuando la radio pasa al estado Off (D3).

Cuando el usuario desactiva la radio Bluetooth, Windows finaliza la actividad Bluetooth cancelando las operaciones de E/S pendientes y descargando los controladores de protocolo y sus elementos secundarios. A continuación, la pila del controlador Bluetooth de Windows emite el comando HCI_Reset al controlador para restablecer la radio a su estado predeterminado. En el estado predeterminado, el controlador no debe ser capaz de transmitir ni recibir señales de radio. Por último, el controlador pasa al estado Desactivado (D3).

En respuesta a la transición a Desactivado (D3), el controlador del bus de transporte debe apagar el dispositivo Bluetooth a su estado de alimentación más bajo mediante métodos específicos del dispositivo. Una implementación típica es cambiar el estado de una línea GPIO de soC a la radio Bluetooth para deshabilitar la alimentación en el módulo Bluetooth. Una implementación alternativa consiste en requerir que el firmware ACPI quite la energía del módulo Bluetooth mediante _PS0 y _PS3 métodos de control.

Cuando el usuario activa la radio Bluetooth, Windows realiza la transición de la radio al estado Activo (D0), vuelve a inicializar la radio y, a continuación, vuelve a enumerar los controladores de protocolo secundarios. Cuando la radio pasa a Activo (D0), las líneas GPIO necesarias deben alternarse como parte de la secuencia D0 normal para la radio Bluetooth. Si el firmware ACPI se usó para apagar la radio, debe restaurar la potencia mediante el método de control _PS0.

Como parte de esta secuencia normal, el controlador del bus de transporte debe marcar el dispositivo como un dispositivo conectado internamente estableciendo el ContainerId de la radio Bluetooth en un valor GUID específico, {00000000-0000-000-ffff-ffffffffff}. Esto permite que los elementos de la interfaz de usuario de radio de Windows detecten que la radio Bluetooth expuesta por el controlador del bus de transporte es interna en el equipo y no una radio conectada externamente para la que el control de radio no es adecuado.

Configuraciones de energía de hardware admitidas

La configuración del hardware de administración de energía para una radio Bluetooth depende del bus de comunicación. Por lo general, se espera que todas las radios Bluetooth tengan las siguientes características de administración de energía de hardware en común:

• Compatibilidad con el estado Desactivado (D3) como medio para desactivar la radio en respuesta a una solicitud de usuario. Apagar la radio pone la radio Bluetooth en un estado de bajo consumo que es casi cero vatios.
• Mecanismo para entrar en un estado de suspensión de bajo consumo (D2) en el que las conexiones se conservan en los dispositivos asociados, pero no hay transferencias activas.
• Un mecanismo para generar una interrupción de reactivación cuando un dispositivo asociado tiene datos para el SoC y el SoC está en un estado de baja potencia en el que el bus al que está conectado el dispositivo de radio Bluetooth no está activo actualmente.

Cada uno de los autobuses admitidos (USB, UART e integración en el SoC) para el dispositivo de radio Bluetooth admite las tres características básicas de administración de energía de hardware de la lista anterior. Además, cada radio Bluetooth puede tener características de administración de energía específicas del proveedor o específicas del dispositivo, pero están fuera del ámbito de este tema.

Se recomienda a los proveedores de radio Bluetooth implementar características de administración de energía de valor añadido de forma autónoma en hardware y no requiere software de controlador suministrado por el proveedor adicional en el sistema Windows. También se recomienda a los proveedores de radio Bluetooth implementar sus controladores y su software de administración de energía de manera que abstraa las diferencias específicas de la plataforma en el firmware ACPI del sistema en lugar de en el código del controlador del dispositivo o en el archivo .inf del controlador. Este enfoque permite volver a usar un paquete de controladores para el dispositivo Bluetooth en plataformas adicionales sin necesidad de actualizar el origen del controlador, binario o paquete de instalación firmado.

Radio Bluetooth que está conectada a través de un UART fuera del SoC

Si la radio Bluetooth está conectada a través de un UART y se encuentra físicamente fuera del SoC, el proveedor de radio Bluetooth debe proporcionar un controlador de autobús de transporte que exponga la radio Bluetooth y cualquier otra función del dispositivo (por ejemplo, una radio FM) que comparta la misma ruta de comunicación a través del UART. El controlador de autobús también es responsable de administrar los recursos GPIO que controlan el consumo de energía y la capacidad de reactivación de la radio Bluetooth.

A diferencia de otras clases de dispositivo, las líneas GPIO que controlan la alimentación y reactivación bluetooth se administran directamente mediante el controlador de autobús de transporte en lugar de abstraerse por los métodos de control ACPI. Este esquema de control es el resultado del diseño del controlador de bus multifunción que enumera la radio Bluetooth y otras funciones que comparten el mismo puerto UART. En este diseño, el controlador ACPI de Windows, Acpi.sys, no se carga en las pilas de controladores para Bluetooth y la radio FM, lo que hace imposible usar la ejecución del método de control ACPI como una manera de responder a una transición de estado Dx del dispositivo.

Cuando la radio Bluetooth está conectada al puerto UART del SoC, el integrador del sistema debe usar un pin en el controlador GPIO en el SoC para controlar la alimentación de la radio. En el firmware ACPI, este pin debe asignarse como un recurso de E/S GPIO al objeto de dispositivo que representa el dispositivo raíz del controlador de bus de transporte. El pin GPIO se puede conectar directamente a la radio Bluetooth si la radio admite apagar el dispositivo con el control de alimentación interno.

Si la radio Bluetooth admite la alimentación, la fuente de alimentación de la radio Bluetooth se puede conectar a cualquier raíl de alimentación del sistema.

Si la radio no admite la alimentación interna controlada por un pin GPIO, el integrador del sistema debe colocar la radio Bluetooth en un raíl de alimentación que se pueda alternar. A continuación, el pin GPIO de SoC se conecta al hardware de conmutación de energía. En este diseño, los métodos de control ACPI no se pueden usar para realizar un seguimiento de los recuentos de referencias ni para agregar el estado de alimentación de varios dispositivos que comparten el mismo raíl de alimentación, por lo que la radio Bluetooth debe estar aislada en su propio riel de alimentación conmutable.

El integrador del sistema debe usar un pin adicional en el controlador GPIO en el SoC para recibir interrupciones de reactivación de la radio Bluetooth. Las interrupciones en este pin deben ser capaces de despertar el SoC desde su estado de potencia más bajo. En algunos diseños soC, este pin se conoce como un pin GPIO siempre activado porque el controlador GPIO puede detectar interrupciones en este pin en todo momento, independientemente del estado de alimentación del SoC. La funcionalidad siempre activada puede estar limitada en hardware a un conjunto específico de patillas GPIO en el SoC o puede ser configurable en firmware. Es fundamental que el integrador del sistema revise este diseño con el proveedor de SoC para asegurarse de que la interrupción de reactivación de la radio Bluetooth hará que el SoC salga de su estado de energía inactivo más profundo. (En todo momento durante el modo de espera moderno, el sistema está en S0. los sistemas en espera modernos no admiten S3).

Cuando todas las funciones enumeradas por el controlador de autobús de transporte se han apagado y el dispositivo de bus de transporte enumerado ACPI entra en D3, el pin GPIO siempre activado se puede apagar. Esto ocurre cuando el usuario ha desactivado las radios para todas las funciones del dispositivo enumeradas por el controlador de autobús de transporte.

Radio Bluetooth en USB

Si la radio Bluetooth está conectada al soC o al silicio central a través del bus USB, la radio debe estar encendida desde una fuente distinta del bus USB. En la especificación USB, dicha radio se describe como autopropulsada, y esta funcionalidad debe notificarse en los descriptores USB del dispositivo Bluetooth.

Del mismo modo, el hardware del dispositivo USB debe anunciar la compatibilidad con la reactivación remota, que es la capacidad de la radio Bluetooth para generar señalización de reanudación USB en banda para reactivar el controlador de host USB. La funcionalidad de reactivación remota también debe anunciarse en los descriptores USB de la radio Bluetooth.

La radio Bluetooth debe admitir las funcionalidades de reactivación automática y remota para que pueda entrar en el estado Suspensión (D2) y habilitar la suspensión selectiva.

Si la radio Bluetooth está en estado Suspensión (D2) y los datos de un dispositivo asociado están disponibles para el host, la radio Bluetooth debe generar la señal de reanudación de reactivación remota para reactivar el host. No se admite una señal de reanudación fuera de banda mediante una línea GPIO al silicio principal. Se espera que la radio Bluetooth, incluido su circuito de conexión USB, consuma menos de un milliwatt de potencia en estado suspensión (D2).

Problemas de reactivación

Se espera que la radio Bluetooth pueda generar una interrupción de reactivación cuando se encuentra en estado de suspensión (D2). La interrupción de reactivación debe hacer que el SoC se active, incluso si el SoC está en su estado de potencia más bajo. En la tabla siguiente se resumen los dos mecanismos de señalización de reactivación bluetooth.

Bus de conexión	Ruta de señalización de hardware	Comentarios y notas
UART (con controlador de autobús de transporte suministrado por el proveedor)	GPIO de la radio Bluetooth al SoC.	La radio debe estar conectada a un pin GPIO que pueda activar el SoC desde su estado de potencia más bajo.
USB	La señalización usb en banda reanuda la señalización de la suspensión selectiva.	No se admite la reactivación GPIO fuera de banda.

Prueba y validación

Se recomienda a los proveedores de dispositivos Bluetooth probar y validar la operación de administración de energía del dispositivo de radio Bluetooth.

Las transiciones entre los estados Active (D0), Sleep (D2) y Off (D3) se pueden observar fácilmente mediante la herramienta Xperf, como se describe en otras secciones.

Las actividades del controlador Bluetooth se pueden supervisar mediante el uso de instrumentación ETW integrada en Windows. Se recomienda al desarrollador de controladores usar la instrumentación de Seguimiento de eventos para Windows (ETW) para exponer cambios significativos en el estado de administración de energía en el controlador y observarlos mediante la herramienta Xperf o la Visor de eventos integrada de Windows.

Si la radio Bluetooth está conectada a través de USB, la utilidad integrada Powercfg.exe se puede usar junto con la opción de línea de comandos /energy para validar que la radio entra en estado Sleep (D2) y se suspende. Para usar la utilidad Powercfg.exe:

• Abra una ventana del símbolo del sistema como administrador.
• Cambie al directorio raíz de la unidad (cd \).
• Escriba el comando powercfg.exe /energy.
• Espere los 60 segundos predeterminados.
• La utilidad Powercfg.exe generará el número de errores y condiciones de advertencia en el sistema, como se muestra en la captura de pantalla siguiente.
• Una vez que la herramienta escribe la información de resumen en la ventana del símbolo del sistema, genera un archivo HTML denominado Energy-report.html. Abra el archivo y busque condiciones de error o advertencia desde el dispositivo Usb Bluetooth. En el siguiente resumen de ejemplo se informa de que un dispositivo Bluetooth USB no ha entrado en el estado Suspensión (D2) cuando está inactivo.

Los proveedores de dispositivos Bluetooth que proporcionan controladores y aplicaciones adicionales de perfil Bluetooth de terceros deben comprobar que su software admite la eliminación sorpresa y permite que la infraestructura de administración de radio desactive correctamente la radio Bluetooth de forma oportuna. Estos escenarios deben validarse mientras el perfil o la aplicación están en uso. Por ejemplo, para los controladores de audio, debe haber streaming de audio Bluetooth mientras la radio está desactivada. A continuación, la radio debe volver a activarse y la secuencia de audio se reiniciará para comprobar que sigue funcionando.

Lista de comprobación de administración de energía bluetooth

Los integradores de sistemas, los proveedores de radio Bluetooth y los proveedores de SoC deben usar la siguiente lista de comprobación para asegurarse de que su diseño de administración de energía del sistema es compatible con Windows 8 y Windows 8.1:

• Determine el bus de comunicación para la radio Bluetooth en el diseño del sistema. La radio Bluetooth está conectada a través de UART o conectada a través de USB.

• Asegúrese de que la radio Bluetooth admite un modo de suspensión de bajo consumo que consume menos de un miliwatt cuando no hay ningún dispositivo asociado.

  El consumo de energía de la radio Bluetooth en modo de suspensión puede variar en función del número de dispositivos asociados que están presentes actualmente, pero generalmente no debe superar los cinco miliwatts en cualquier momento.

• Asegúrese de que la radio Bluetooth admite las siguientes funcionalidades básicas de administración de energía necesarias:

  • Compatibilidad con el estado Off (D3) como una manera de permitir al usuario desactivar la radio.
  • Mecanismo para entrar en un estado de suspensión de bajo consumo (D2) donde las conexiones se conservan en los dispositivos asociados, pero no hay transferencias activas.
  • Un mecanismo para reactivar el SoC cuando un dispositivo asociado genera datos y el SoC está en un estado de bajo consumo.

• Si la radio Bluetooth está conectada a través de un bus no USB (UART o integrado en el SoC), el proveedor de radio Bluetooth debe desarrollar un controlador de autobús de transporte. El conductor del autobús de transporte debe hacer lo siguiente:

  • Compatibilidad con las características y requisitos detallados en Transport Bus Driver for Bluetooth Power Control Handling Guidelines.
  • Traduce las solicitudes Bluetooth del controlador Bluetooth de Windows (Bthmini.sys) a los comandos a la radio Bluetooth a través del bus UART o un bus soC interno propietario.
  • Cambie el dispositivo de radio Bluetooth a varios modos de administración de energía que se asignan a los estados Activo (D0), Suspensión (D2) y Apagado (D3). El controlador también debe implementar rutinas que controlen los IRP de administración de energía de dispositivos (Dx).
  • Configure la radio Bluetooth para reactivar el SoC cuando un dispositivo genera la entrada y cambiar el estado de las líneas GPIO opcionales que conectan el SoC a la radio Bluetooth con fines de administración de energía.
  • Enumerar otros dispositivos (por ejemplo, un transmisor FM) que podrían compartirse en la radio Bluetooth.
  • Use Windows Driver Framework (WDF) para el desarrollo de controladores.
  • Se implementa en función del controlador de bus serie Bluetooth HCI.

• Si la radio Bluetooth está conectada a través de USB, el proveedor de radio Bluetooth debe:

  • Habilite la compatibilidad con la suspensión selectiva en la radio.
  • Asegúrese de que la radio tiene las funcionalidades de reactivación remota y autopropulsada establecidas en el descriptor del dispositivo USB.
  • Asegúrese de que la radio (incluidos los componentes USB) consume menos de un miliwatt.

• Independientemente del bus de conexión, la radio Bluetooth debe hacer lo siguiente para una radio conectada internamente:

  • Asegúrese de que todos los componentes de RF están desactivados en respuesta a un comando HCI_Reset que se envía a la radio en preparación para encender la radio. La radio no debe ser capaz de transmitir ni recibir señales de radio.
  • Escriba su modo de alimentación más bajo cuando se establezca en el estado Desactivado (D3).

• Si la radio Bluetooth está conectada a través de UART, el integrador del sistema debe conectar la señal de reactivación desde la radio Bluetooth a un pin GPIO en el SoC que pueda reactivar el SoC desde el estado de energía más bajo.

  • El SoC puede requerir que las señales de reactivación se enruten a un conjunto limitado de patillas GPIO preconfiguradas para que estén siempre activadas.
  • O bien, el SoC puede admitir la configuración de un pin GPIO en un pin siempre activado en el firmware del sistema durante el arranque.

• El integrador del sistema debe probar y comprobar que la radio Bluetooth entra en el estado Suspensión (D2) cuando no hay dispositivos asociados.

• El integrador del sistema debe probar y comprobar que la radio Bluetooth entra en el estado Suspensión (D2) cuando todos los dispositivos asociados no tienen ninguna transferencia activa.

• El integrador del sistema debe probar y comprobar que la radio Bluetooth puede activar el SoC desde su estado de energía más bajo cuando la radio está en estado suspensión (D2).

• El integrador del sistema debe probar y comprobar que la radio Bluetooth no genera señales de reactivación falsa mientras se encuentra en estado de suspensión (D2).

• El integrador del sistema debe probar y comprobar que el software de terceros del complemento, como los controladores de perfil y las aplicaciones, funcione correctamente con la administración de radio Bluetooth. La radio debe desactivarse y activarse mientras el software de terceros está en uso activamente (por ejemplo, reproducir audio o transferir un archivo).