Bluetooth: inquiring, 3.0 e 4.0
Bluetooth: inquiring, 3.0 e 4.0
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 descreve muito genericamente 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, não é preciso chegar a 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 vêm todos com BT 2.1 no mínimo.
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, e adiciona uma adaptação a Wi-Fi.
É isso mesmo; Bluetooth usando WiFi como transporte. Além do óbvio ganho de velocidade, muitos fabricantes de chips já oferecem WiFi e Bluetooth no mesmo circuito, então sai "de graça" oferecer WiFi como transporte alternativo.
O Bluetooth possui alguns perfis (como o de impressão) cujo uso é na prática inviável por conta da baixa velocidade. O Bluetooth 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, praticamente qualquer modelo tem Wi-Fi e comunica-se com os computadores via TCP/IP. Protocolos de auto-descoberta como o Bonjour da Apple já cobrem os casos de uso do Bluetooth. Vamos ver o que acontece.
O Bluetooth gasta pouca energia em termos absolutos. Mas para determinadas aplicações ainda é 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 tendo como única fonte de energia uma pilha-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. (Fazendo um paralelo com TCP/IP, PSM seria equivalente ao número de porta do protocolo UDP do lado servidor. CID não tem um equivalente, mas poderia ser a porta UDP do lado cliente, que normalmente é um número aleatório a cada conexão.)
As modificações, quase todas visando simplicidade, querem no final das contas diminuir custo e consumo de energia.