Usando o Bluetooth no dia-a-dia, dá pra notar que o negócio só funciona de forma confiável e confortável quando os dispositivos já estão pareados.
Em geral, as pilhas de software BT armazenam informações sobre dispositivos com os quais parearam, o que acelera bastante a reconexão num segundo momento.
Mas, num primeiro momento, os brinquedinhos têm de achar uns aos outros. É o processo de "inquiry". A tradução literal seria "inquérito", mas como é uma palavra antipática em português, vou usar inquiry mesmo.
Conceitualmente não há nada de mais no inquiry; o dispositivo interessado em achar outros emite sinais de rádio durante alguns segundos, e quem está em volta (e configurado para responder publicamente) responde.
Na prática, o inquiry do BT é complexo porque o rádio Bluetooth usa saltos periódicos de freqüência para "espalhar" o sinal numa banda larga. São 79 canais e os rádios saltam 1600 vezes por segundo. Não há um canal fixo para "broadcast", que todo dispositivo fique ouvindo o tempo todo.
Isto não é problema entre dispositivos conectados porque eles sincronizam os saltos. Mas, e um dispositivo desconhecido? Como é que você vai falar com ele se não sabe em que canal ele está ouvindo?
Bem, a "solução" para isso é a seguinte. Apenas um subconjunto de canais (22, eu acho) é utilizado para inquiry, e o processo de inquiry é feito por um tempo relativamente longo: 5 ou 10 segundos. Com isto, a probabilidade de um dispositivo desconhecido ouvir nosso inquiry é quase 100%.
Mas note que o negócio é probabilístico, não é determinístico. E isto é confirmado pela prática: todo mundo já teve problemas em "achar" um dispositivo Bluetooth na primeira, segunda ou até na terceira tentativa.
O inquiry descobre pouca coisa sobre os dispositivos: endereço, nome, device class (um mapa de 24 bits que diz um pouco sobre os tipos de serviço e o tipo de aparelho). Depois do inquiry, é necessáro conectar via SDP para descobrir realmente que perfis e serviços o aparelho oferece.
O Bluetooth 2.1 aprimorou um pouco isto, incluindo o EIR (Extended Inquiry Resposne), onde já na fase de inquiry é possível obter perfis e serviços. Se não há nada que interessa, nem é preciso fazer a consulta SDP.
O Bluetooth "baunilha" que nós usamos no dia-a-dia é chamado de "basic rate", que deve ser foneticamente semelhante a "Por que é tão lento?" em sueco ou finlandês. Dispositivos novos decentes vêm todos com BT 2.1.
O padrão Bluetooth especifica diversas adaptações entre a camada HCI e transportes como USB, cabo serial etc. O padrão 3.0 é basicamente o mesmo que 2.1, mas adiciona uma adaptação a WiFi 802.11.
É isso mesmo; Bluetooth usando WiFi como transporte. Além do óbvio ganho de velocidade (e o broadcast que deve tornar o inquiry muito mais rápido), muitos fabricantes de chips já oferecem WiFi e Bluetooth no mesmo circuito, então sai "de graça" usar WiFi como transporte.
BT possui alguns perfis (como o de impressão) cujo uso é inviável por conta da baixa velocidade. Mas o BT 3.0 muda este cenário para melhor.
Realmente não sei se este novo padrão vai pegar. No caso específico das impressoras, qualquer modelo pouquinha coisa melhor já tem módulo Ethernet ou wireless e usa protocolo IPP (sobre TCP/IP). Vamos ver o que acontece.
BT gasta pouca energia, mas para determinadas aplicações ainda gasta muito. A duração da bateria de um celular é perceptivelmente maior quando BT está desativado. Não dá pra usar BT padrão para coisas como sensores de alarme, que devem funcionar meses ou anos com uma única pilha AAA ou "botão".
O Bluetooth 4.0 adiciona um padrão Low Energy, bastante diferente do BT baunilha. O rádio é obviamente diferente, a velocidade é mais lenta, e a pilha de protocolos é simplificada.
Um protocolo genérico de troca de informações (GATT) é utilizado por todos os perfis LE, inclusive no estágio de procura de serviços; ou seja, não há SDP em LE. Também não há RFCOMM, e o L2CAP não tem PSM; os serviços devem usar CID fixos.
As modificações, em sua maioria na direção da simplicidade, visam no final das contas diminuir custo e consumo de energia. Espera-se que dispositivos mais poderosinhos, como celulares, sejam "dual mode" (basic rate + low energy), e a API para os aplicativos seja a mais transparente possível. Os aplicativos nem precisariam saber se os dispositivos com que estão se comunicando são LE ou normais.
Os novos perfis de serviços para LE devem ser "inéditos", ou seja, coisas que não existem hoje no BT normal, então os benefícios desta transparência vão demorar a dar frutos. No curto prazo, o maior beneficiário é o pobre desenvolvedor que pode trabalhar em aplicativos LE mas testando em BT convencional.