BLE Bluetooth Low Energy

O Bluetooth ´e uma tecnologia/protocolo de comunica¸c˜ao sem fios criado em 1998 por um conjunto de 5 empresas com uma importante presen¸ca no mercado, dando-se assim origem ao Bluetooth SIG (Special Interest Group). Este tinha o objetivo de unificar as comunica¸c˜oes sem fios entre dispositivos de fabricantes diferentes, isto ´e, criar-se um protocolo de comunica¸c˜ao sem fios “universal”[11]. O Bluetooth, tamb´em conhecido pelo standard IEEE 802.15.1, faz parte da topologia de rede Wireless Personal Area Network (WPAN) [12].

Ao grupo inicial de empresas do Bluetooth SIG foram-se juntando muitas mais. A tecno- logia foi ganhando importˆancia no mercado e na comunidade cient´ıfica e acad´emica, contando atualmente com 30 000 empresas. Aliado a este crescimento, ao longo dos anos foram lan¸cadas novas vers˜oes desta tecnologia. A mais recente vers˜ao anunciada em 2016, Bluetooth 5.0, ter´a um alcance quatro vezes superior e uma velocidade de transmiss˜ao de dados duplicada em rela¸c˜ao `a vers˜ao 4.2 e mantendo os n´ıveis de consumo energ´etico [13].

O BLE surge em 2010 com o lan¸camento da vers˜ao Bluetooth 4.0. Este torna-se par- ticularmente apelativo pelos baixos consumos energ´eticos. ´E, atualmente, uma das op¸c˜oes tecnol´ogicas mais utilizadas em projetos de Internet of Things (IoT). O crescimento desta tecnologia tomou propor¸c˜oes enormes: est´a presente numa pan´oplia de dispostivos como cha- ves, auriculares, ratos, teclados, todo o tipo de gadgets, sendo que a presen¸ca desta nos

smartphones foi a mais potencializadora. Atualmente ´e compat´ıvel com dispositivos Android a partir da vers˜ao 4.3 e com todos os dispositivos Apple lan¸cados posteriormente ao iPhone 4S, inclusiv´e [14].

Como ´e dito por Joseph DeCuir em “Introducing Bluetooth Smart: Part 1: A look at both classic and new technologies.”[15], com o lan¸camento do BLE previa-se que este se tornasse para o mundo dos smartphones no papel que o Universal Serial Bus (USB) toma para o mundo dos computadores, isto ´e, ser uma interface para perif´ericos de conectividade universal. De facto, cada vez mais se vive num mundo em que tudo est´a conectado e uma das tecnologias que o possibilita ´e o Bluetooth.

Na perspetiva do consumidor existem dois tipos de dispositivos Bluetooth Low Energy: dispositivos Bluetooth Smart e Bluetooth Smart Ready. Estas denomina¸c˜oes tornam-se es- senciais uma vez que, por defini¸c˜ao, um dispositivo Bluetooth Smart n˜ao se consegue conectar a um dispositivo Bluetooth Classic. Um dispositivo Bluetooth Classic apenas se conecta a dispositivos Bluetooth Smart Ready e estes, por sua vez, a dispositivos Bluetooth Smart. ´E poss´ıvel identificarem-se alguns exemplos dos diferentes tipos de dispositivos Bluetooth na figura 2.5. [16].

Figura 2.5: Rela¸c˜ao entre os trˆes tipos de Bluetooth (Fonte: Bluetooth SIG)

Do ponto de vista t´ecnico, os ´ultimos trˆes termos apresentados, adquirem, respetivamente, os seguintes: Bluetooth Classic, Bluetooth dual-mode (suporta Bluetooth Classic e BLE) e Bluetooth single-mode (compat´ıvel apenas com comunica¸c˜oes BLE). Os dispositivos dual- mode, apesar de serem os que conseguem conectar-se a uma maior gama de dispositivos, acabam por n˜ao tirar partido da melhor vantagem que o BLE trouxe: o reduzido consumo energ´etico. Os dispositivos single-mode s˜ao, por norma, dispositivos alimentados a pilhas ou baterias [16].

2.2.1.1 Pilha protocolar do BLE

Em rela¸c˜ao `a pilha procolar do BLE, e em semelhan¸ca ao Bluetooth Classic, esta ´e dividida em duas principais partes: a primeira referente ao Host e a segunda referente ao Controller. A rela¸c˜ao entre as duas ´e definida no Host Controller Interface (HCI). O Host e o Controller s˜ao divididos por diversas camadas que est˜ao representadas na figura 2.6 e ser˜ao explicadas seguidamente.

Figura 2.6: Pilha Protocolar do BLE (Fonte: “Introducing Bluetooth Smart, Part 1: A look at both classic and new technologies.”[17] )

Come¸cando pela camada f´ısica, muitas vezes referida nos artigos t´ecnicos/cient´ıficos como PHY, proveniente do inglˆes “Physical Layer”, trata-se da camada mais inferior da pilha protocolar do BLE. Esta controla a rece¸c˜ao e a transmiss˜ao de dados a partir dos canais de comunica¸c˜ao na banda de frequˆencia n˜ao licenciada Industrial, Scientific and Medical (ISM), a 2.4GHz. A modula¸c˜ao utilizada para transmiss˜ao do sinal ´e Gaussian Frequency-Shift Keying (GFSK) e a velocidade m´axima de transmiss˜ao ´e de 1 Mbps. A potˆencia do sinal transmitido pode variar entre 0.01mW (-20 dBm) e 10 mW (+10 dBm). Em compara¸c˜ao com o Bluetooth Classic, o BLE utiliza um n´umero de canais de comunica¸c˜ao mais reduzido (quarenta) mas com maior largura de banda entre os mesmos (2MHz). Dos quarenta canais, 3 s˜ao dedicados ao advertising (utilizados na descoberta de dispositivos, estabelecimento de

conex˜oes e transmiss˜ao de dados em modo broadcaster, explicado posteriormente) e os outros 37 s˜ao canais de dados comuns utilizados para troca de dados bidirecional entre dispositivos conectados [18] [19].

A camada de liga¸c˜ao define a camada f´ısica, ou seja cria uma liga¸c˜ao para as propriedades f´ısicas definidas na camada descrita anteriormente. Define a estrutura dos pacotes a serem enviados e os seus canais de comunica¸c˜ao, o processo de descoberta e conex˜ao a novos dispo- sitivos e envio/rece¸c˜ao de informa¸c˜ao. Nestas etapas tamb´em est´a compreendida a defini¸c˜ao das fun¸c˜oes de cada um dos dispositivos presentes na liga¸c˜ao BLE quanto `a posi¸c˜ao de master e slave [15] [20].

Logical Link Control and Adaptation Protocol (L2CAP) ´e a camada de abstra¸c˜ao das camadas anteriores, baseada nos canais de transmiss˜ao especificamente tratados nessas, uti- lizada por aplica¸c˜oes e servi¸cos. Esta consiste num protocolo que permite a fragmenta¸c˜ao e desfragmenta¸c˜ao dos dados recebidos das camadas superiores e a multiplexagem ou desmulti- plexagem dos m´ultiplos canais a serem utilizados e que s˜ao definidos nas camadas inferiores. A abstra¸c˜ao criada traz simplicidade `a intera¸c˜ao das camadas superiores com os canais f´ısicos [21].

Acima da L2CAP encontram-se mais duas camadas: a Attribute Protocol (ATT) e a camada de gest˜ao de seguran¸ca (em inglˆes, Security Manager).

´

E na ATT que os atributos, blocos que contˆem dados, s˜ao definidos, guardados e pos- teriormente tratados na camada superior Generic Attribute Profile (GATT). Esta camada organiza toda a informa¸c˜ao em blocos com a mesma estrutura, os atributos, facilitando as fun¸c˜oes desempenhadas pelas camadas superiores. ´E importante reter que cada atributo ´e constitu´ıdo por trˆes partes: o handle, o Universally Unique Identifier (UUID) e um valor propriamente dito. O handle poder´a ser visto como uma identifica¸c˜ao ´unica de um certo atributo, como um ID, j´a o UUID ´e um valor que define o tipo de atributo que se est´a a usar e o valor guardado diz respeito `a informa¸c˜ao que se pretende guardar no respetivo atributo tendo em conta o tipo do mesmo. Nenhum destes valores ´e interpretado nesta camada, isto ´e, poder-se-ia guardar um valor que n˜ao correspondesse ao tipo de atributo em quest˜ao nesta camada sem ocorrer nenhum problema. Esta interpreta¸c˜ao ´e feita na camada superior: a GATT [22] [21].

A GATT ´e a camada que d´a sentido `a ATT. ´E na GATT que os atributos s˜ao categori- zados segundo o seu UUID. Estes podem pertencer a uma das seguintes categorias: servi¸co, caracter´ıstica ou descritor. Um servi¸co ´e constitu´ıdo por uma ou v´arias caracter´ısticas e es-

tas, por sua vez, podem ter um ou mais descritores. O Bluetooth SIG convencionou que o UUID de um servi¸co ´e 0x2800. Assim, quando um dispositivo est´a a descobrir os servi¸cos de que o outro disp˜oe, n˜ao necessita de procurar um servi¸co espec´ıfico, pois consegue ter acesso a todos, uma vez que todos s˜ao identificados pelo mesmo UUID. O dispositivo que lˆe os atributos dispon´ıveis, a partir dos valores correspondentes, consegue delimitar os atributos pertencentes a cada um dos servi¸cos. A partir da identifica¸c˜ao dos UUID correspondentes a servi¸cos, e dos respetivos valores de handle, ´e poss´ıvel demarcar-se os atributos em grupos. Todos os atributos que tiverem valores de handle correspondentes entre o intervalo de valores de handle do primeiro e segundo servi¸cos encontrados, pertencer˜ao ao primeiro servi¸co. No intervalo de valores de handle mencionado anteriormente aparecem as caracter´ısticas princi- pais com o UUID fixo de 0x2803. Este UUID fixo representativo de caracter´ısticas tamb´em facilita a procura das mesmas por parte do dispositivo cliente. Os atributos pertencentes a uma certa caracter´ıstica est˜ao compreendidos entre o handle dessa mesma caracter´ıstica e da pr´oxima a ser encontrada. Os descritores, compreendidos entre caracter´ısticas, n˜ao tˆem um UUID ´unico que os identifique. Existem v´arios definidos. S˜ao identificados pelo handle. Caso este valor esteja compreendido no intervalo de handles entre servi¸cos, por exemplo entre o primeiro e o segundo servi¸cos encontrados, ent˜ao este descritor pertence ao primeiro servi¸co e `a caracter´ıstica com o handle mais pr´oximo e anterior ao deste [23] [24].

Dentro dos v´arios descritores definidos, referidos anteriormente, existe um com particular importˆancia denominado de Client Characteristic Configuration (CCC). Este decritor com UUID de 0x2902, tamb´em ´e definido no lado do servidor mas pode ser alterado pelo cliente. Serve para habilitar uma certa caracter´ıstica de indicar ou notificar o cliente quando o seu valor sofrer altera¸c˜oes. Entende-se por notifica¸c˜ao a capacidade de o servidor informar o cliente que o valor da caracter´ıstica correspondente foi alterado e n˜ao esperar confirma¸c˜ao de rece¸c˜ao dos dados por parte do cliente. J´a por indica¸c˜ao, entende-se que o servidor informa o cliente quando ocorre essa altera¸c˜ao e espera uma confirma¸c˜ao da rece¸c˜ao da mesma por parte dele. Quando este descritor apresenta o valor de 1 significa que o cliente ser´a notificado quando a caracter´ıstica alterar o seu valor. Se estiver a 0, o cliente ser´a indicado que a caracter´ıstica sofreu altera¸c˜oes [24].

´

E tamb´em na GATT que s˜ao definidos os pap´eis de cliente e servidor numa liga¸c˜ao BLE. O servidor guarda a informa¸c˜ao passada pela ATT e aceita pedidos, comandos e confirma¸c˜oes de recebimento de respostas por parte do cliente. Em suma, ´e no servidor que os atributos e correspondentes valores est˜ao guardados. O cliente apenas tem permiss˜ao para ler esses

valores ou escrever quando solicitado e concedida autoriza¸c˜ao para tal. O servidor envia respostas aos pedidos do cliente, notifica¸c˜oes ou indica¸c˜oes quando algum evento espec´ıfico ocorre na GATT do servidor, de forma ass´ıncrona [24].

A camada mais superior da pilha protocolar ´e a Generic Access Profile (GAP). Esta, tem como principal fun¸c˜ao gerir os pap´eis desempenhados por cada dispositivo numa liga¸c˜ao BLE. Estes pap´eis poder˜ao ser de: broadcaster, observador, perif´erico e central. Um dispositivo que densempenhe a fun¸c˜ao de broadcaster apenas difunde dados pelos canais de advertising e n˜ao suporta conex˜oes com outros dispositivos. Por outro lado, um observador apenas consegue receber as informa¸c˜oes transmitidas por um broadcaster via advertising, tamb´em n˜ao conseguindo assim conectar-se a outros dispositivos. Um dispositivo com fun¸c˜ao de central inicia e gera m´ultiplas conex˜oes (exercendo, consequentemente, o papel de master) enquanto que um dispositivo perif´erico apenas suporta a conex˜ao com um ´unico dispositivo central (e, por sua vez, ´e sempre um slave). ´E importante ter em aten¸c˜ao que um dispositivo pode desempenhar v´arias destas quatro fun¸c˜oes, no entanto s´o poder´a exercer uma de cada vez [22].

Acima da GAP s˜ao definidos perfis de aplica¸c˜ao adicionais, caso sejam proveitosos para o sistema a desenvolver. Um novo perfil pode ser inclu´ıdo nesta camada desde que cumpra todos os requisitos necess´arios. Existem perfis de n´ıvel superior que especificam como os aplicativos podem interoperar. Estes, que tamb´em s˜ao definidos na norma Bluetooth SIG, poder˜ao favorecer a interoperabilidade entre dispositivos de diferentes fabricantes [25].