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 equipo 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 energía 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 moderna, Windows admite radios Bluetooth que están conectadas a UART o a USB (Bus Universal en Serie). (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 verifica la compatibilidad del modo de espera moderno solo para las radios Bluetooth que están conectadas a UART o USB, o están integradas 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 realiza 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 adicional proporcionado por el proveedor 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 utiliza una combinación de comunicación de bus en banda, coordinación con el complemento de motor de potencia (PEP) y/o señalización fuera de banda a través de pines 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 tres estados de alimentación del dispositivo siguientes:

• 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 se permite que el dispositivo Bluetooth HID emparejado active 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 miliwatt) 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 según el 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 desactivar la radio a través de la interfaz de usuario de administración de radios. 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 Apagado (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, todos los dispositivos Bluetooth en plataformas modernas en modo de espera deben ser compatibles con la versión 4.0 de la Especificación principal Bluetooth. Por lo tanto, los proveedores ya no tienen que suministrar un archivo DLL de software para implementar la función de control de radio activado/desactivado. 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 de software, la radio Bluetooth admite tres modos de administración de energía, independientemente del bus al que está conectado 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 energía de radio Bluetooth.

Modo	Descripción	Estado de energía 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.	No disponible	No disponible
Suspensión (principalmente inactiva con un ciclo de servicio de baja velocidad)	La radio Bluetooth está en estado de baja potencia. 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 detección.	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 de bus de transporte subyacente. 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 autoprotección en el descriptor del dispositivo USB).
Desactivado	La radio Bluetooth está completamente desactivada (cero vatios) o en un estado de baja potencia 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 ni 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 se puede apagar mediante 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 para el dispositivo Bluetooth, Windows detiene la actividad Bluetooth quitando inesperadamente los controladores de protocolo y sus elementos secundarios y, a continuación, realizando la transición de la pila de dispositivos de radio al estado off (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 política 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 la espera moderna (pantalla del sistema desactivada) 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 activar 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, presionar cualquier tecla en el teclado 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 miliwatt cuando se encuentra en estado suspensión (D2).

Cuando la radio Bluetooth está en estado Off (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 (Bthmini.sys) de Windows a los 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 energía activo (D0), suspensión (D2) y apagado (D3). El controlador también implementa rutinas que controlan los eventos de administración de energía.
• Configurar la radio Bluetooth para reactivar el SoC cuando un dispositivo genera la entrada y cambiar el estado de las líneas GPIO opcionales de la radio 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 bus de transporte, consulta las Guías de manejo de control de potencia de Bluetooth para controladores de bus de transporte. Los controladores de autobús de transporte deben escribirse mediante Windows Driver Framework (WDF). Hay un controlador de ejemplo disponible 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 energía 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ñalar eventos de reactivación desde el estado D2.
• Admite activar el dispositivo de radio Bluetooth para activar el SoC y desactivar la señal de activación del dispositivo Bluetooth al SoC. Este soporte puede requerir manejar una o varias interrupciones de GPIO y ejecutar métodos de reactivación en WDF.
• Cambie el estado de las líneas GPIO opcionales del soC al dispositivo de radio Bluetooth cuando el dispositivo pase 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 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 de alimentación Activo (D0) o Suspensión (D2). El transmisor de radio debe desactivarse cuando la radio pasa al estado Desactivado (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 ninguna señal 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 energía 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 de ACPI desconecte la energía del módulo Bluetooth mediante los métodos de control _PS0 y _PS3.

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-ffffffff}. 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 coloca la radio Bluetooth en un estado de baja potencia que es casi cero vatios.
• Un mecanismo para entrar en un estado de reposo de baja potencia (D2) donde las conexiones se mantienen con los dispositivos asociados, pero no se realizan 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 buses 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 forma que abstraa las diferencias específicas de la plataforma en el firmware ACPI del sistema en lugar del código del controlador del dispositivo o 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 paquete de instalación firmado, binario o fuente del controlador.

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 cualquier recurso GPIO que controle el consumo de energía y la capacidad de reactivación de la radio Bluetooth.

A diferencia de otras clases de dispositivos, las líneas GPIO que controlan la alimentación y la reactivación de Bluetooth se administran directamente mediante el controlador del bus de transporte en lugar de ser abstraídas por métodos de control ACPI. Este esquema de control es el resultado del diseño del controlador multifunción de bus 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 al módulo Bluetooth si este admite apagar el dispositivo mediante el control interno de energía.

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 el control de alimentación interno controlado por un patilla 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 del 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 potencia 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 de SoC, este tipo de pin se conoce como un pin GPIO siempre activo porque el controlador GPIO puede detectar interrupciones en este pin en todo momento, independientemente del estado de energía del SoC. La funcionalidad siempre activada puede estar limitada en hardware a un conjunto específico de patillas GPIO en el SoC o puede configurarse en el firmware. Es fundamental que el integrador de sistemas 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 bus de transporte se han apagado y el dispositivo de bus de transporte enumerado por ACPI entra en D3, la patilla GPIO siempre activada se puede apagar. Esto ocurre cuando el usuario ha desactivado las radios para todas las funciones de dispositivo enumeradas por el controlador de bus 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 ser alimentada desde una fuente distinta del bus USB. En la especificación USB, este tipo de radio se describe como autopropulsado, 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ñales 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 activació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 está 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 desde la radio Bluetooth hasta el SoC.	La radio debe estar conectada a un pin GPIO que pueda reactivar 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.

Pruebas y validación

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

Las transiciones entre los estados Activo (D0), Suspensión (D2) y Desactivado (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 la 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 el Visor de eventos integrado 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 de comandos 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 Bluetooth USB. 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 de perfil Bluetooth adicionales de terceros deben comprobar que su software admite la eliminación sorpresa y permite que la infraestructura de administración de radios apague 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 sea 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 dispositivos asociados.

  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 Desactivado (D3) como una manera de permitir que el usuario desactive la radio.
  • Mecanismo para introducir un estado de suspensión de baja potencia (D2) en el que 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 distinto de USB (UART o integrado en el SoC), el proveedor de radio Bluetooth debe desarrollar un controlador de bus de transporte. El conductor del autobús de transporte debe hacer lo siguiente:

  • Admite las características y los requisitos detallados en las Pautas de manejo del control de potencia del controlador de bus de transporte para Bluetooth.
  • Traducir solicitudes de Bluetooth desde el controlador de Bluetooth de Windows (Bthmini.sys) a comandos para la radio Bluetooth a través del bus UART o un bus interno propietario de SoC.
  • 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 cambie el estado de las líneas GPIO opcionales que conectan el SoC a la radio Bluetooth con fines de administración de energía.
  • Enumere otros dispositivos (por ejemplo, un transmisor FM) que podrían compartirse en la radio Bluetooth.
  • Usa Windows Driver Framework (WDF) para el desarrollo de controladores.
  • Se implementará en función del controlador de bus serie de Bluetooth HCI.

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

  • Active la función de suspensión selectiva en la radio.
  • Asegúrese de que la radio tiene las funcionalidades de reactivación remota y autoprotección 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 de HCI_Reset que se envía a la radio como preparación para apagar la radio. La radio no debe ser capaz de transmitir ni recibir señales de radio.
  • Entra en la modalidad de menor consumo cuando se configure 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 pines GPIO preconfigurados para estar siempre encendidos.
  • O bien, el SoC puede admitir la configuración de un pin GPIO a un pin siempre encendido en el firmware del sistema durante el arranque.

• El integrador del sistema debe probar y comprobar que la radio Bluetooth entra en estado suspensión (D2) cuando no hay ningún dispositivo asociado.

• 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 transferencias activas.

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

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

• El integrador de sistemas debe probar y verificar que el software complementario de terceros, como los controladores de perfil y las aplicaciones, funcionen correctamente con la gestión de radio Bluetooth. La radio debe desactivarse y encenderse mientras el software de terceros está en uso activamente (por ejemplo, reproducir audio o transferir un archivo).