4. Controle de Acesso ao Meio
4.1. Protocolo de Gerência de Enlace (LMP)
O Gerente de Enlace (LM - Link Manager) é um software que roda no microprocessador do Bluetooth para gerenciar a comunicação entre os dispositivos. No instante em que dois dispositivos Bluetooth ficam próximos, o Gerente de Enlace de cada dispositivo descobre o outro. A partir daí, uma comunicação ponto-a-ponto se estabelece entre os Gerentes de Enlace, com as mensagens sendo trocadas através do Protocolo de Gerência de Enlace. Essas mensagens tem a função de configurar e controlar enlaces e transportes lógicos bem como controlar enlaces físicos. A configuração inclui mecanismos de segurança como autenticação e criptografia.
4.1.1. Mensagens
Mensagens LMP são trocadas através do transporte ACL. O LMP assume que os mecanismos de detecção e correção de erros da Banda Básica são suficientes e por isso suas mensagens não contêm informações adicionais para detecção de erros.
4.1.2. Formato do Pacote
Cada PDU tem associado a ele um opcode (Código de Operação) de 7 ou 15 bits cujo objetivo é unicamente identificar o tipo de PDU. Os primeiros 7 bits do opcode e um ID de transação se encontram no primeiro byte da carga útil. Se esses primeiros 7 bits são um dos valores especiais de escape (124-127), um byte de opcode extra se encontra no segundo byte da carga útil e essa combinação identifica um tipo único de PDU. Um PDU pode ser do tipo M (Mandatory - Obrigatório) ou do tipo O (Optional - Opcional).
Figura 4.1 - Carga útil de um PDU LMP. Adaptado de http://www.bluetooth.com/
4.1.3. Transações
O LMP opera em transações. Um transação é um conjunto de trocas de mensagens para atingir um objetivo determinado. Todas as PDUs numa mesma transação devem ter o mesmo ID de transação. Esse ID de transação é o bit menos significativo do primeiro byte do opcode. Se vale 0, significa que a transação foi iniciada pelo mestre. Se vale 1, a transação foi iniciada pelo escravo.
4.1.4. Tratamento de Erros
Como dito anteriormente, não há na mensagem LMP informações adicionais para detecção de erros. Mesmo assim, o Gerente de Enlace pode receber uma PDU em que o opcode não é reconhecido ou que possua parâmetros inválidos. Quando ocorre o primeiro caso, o Gerente de Enlace responde com um LMP_not_accepted ou um LMP_not_accepted_ext com o código de erro unknown LMP PDU (PDU LMP desconhecida). No segundo caso, a PDU é a mesma, mas o código de erro é invalid LMP parameters (parâmetros LMP inválidos). Podem acontecer casos em que a PDU recebida não é permitida. O tratamento é o mesmo, com o código de erro PDU not allowed (PDU não permitida).
4.1.5. Regras de Procedimento
Um procedimento pode ser melhor descrito num diagrama:
Figura 4.2 - Diagrama que representa uma transação - Copiado de http://www.bluetooth.com/
PDU1 é um PDU enviado de A para B, enquanto PDU2 é um PDU enviado de B para A. O mesmo vale para PDU3 e PDU4, de acordo com a direção das setas, mas a linha tracejada indica que são PDUs opcionais. A linha vertical indica que mais PDUs podem ser enviados opcionalmente. Finalmente, PDU5 é um PDU enviado tanto por A quanto por B.
4.1.6. Mensagens Gerais de Resposta
Em diversos procedimentos, existem PDUs que servem de mensagens de resposta. São eles:
4.1.7. Procedimentos
O LMP possui 71 diferentes PDUs. Mesmo descartando-se os 4 usados para Escape e os 4 para resposta, são muitos os procedimentos e as funcionalidades oferecidas pelo protocolo. Aqui serão vistas como exemplo duas transações para entender melhor o funcionamento do protocolo e suas capacidades.
4.1.7.1. Estabelecimento da Conexão
A transação que faz o estabelecimento da conexão ocorre depois dos procedimentos na Banda Básica. A partir daí uma série de procedimentos de configuração é realizada pelo Gerente de Enlace através do LMP. O diagrama abaixo mostra como essa configuração é feita.
Figura 4.3 - Diagrama do Estabelecimento de Conexão - Adaptado de http://www.bluetooth.com/
Os Primeiros procedimentos são informativos. Em seguida, caso o dispositivo A queira criar uma conexão que envolva camadas acima do Gerente de Enlace, ele envia um LMP_host_connection_req, que pode ou não ser aceito, o que indica se haverá ou não o envolvimento dessas camadas. Após isto, são realizados os procedimentos de segurança. Finalmente, os dispositivos enviam a confirmação de configuração concluída um para o outro.
4.1.7.2. Autenticação
O outro exemplo a ser visto é a autenticação. Nela, o verificador envia um LMP_au_rand, que contém um número aleatório. O requerente calcula uma resposta em função de sua BD_ADDR, do número aleatório e de uma chave secreta chamada de chave de enlace. A resposta é enviada na mensagem LMP_sres. O verificador então confere se a resposta está correta. Se ela não estiver, o verificador pode terminar a comunicação.
A chave de enlace pode ou não ser conhecida pelo requerente. Se for, basta enviar o LMP_sres. Se não for, o requerente envia um LMP_not_accepted com o código de erro key missing (ausência de chave). Os dois casos podem ser vistos respectivamente nos diagramas abaixo.
Figuras 4.4a e 4.4b - Autenticação - Adaptadas de http://www.bluetooth.com/
A chave de enlace pode ser adquirida por outro procedimento, o de Pairing (União de Dispositivos).
4.1.7.3. Outros procedimentos
Vários outros procedimentos podem ser realizados pelo Protocolo de Gerência de Enlace, mas que serão apenas listados aqui. São eles: