Visão Técnica do Bluetooth Smart

Bluetooth-Smart-destaque
Este post faz parte da série Bluetooth Smart. Leia também os outros posts da série:

O BLE (Bluetooth Low Energy), também conhecido por Bluetooth Smart, foi desenvolvido para uso em dispositivos que necessitam consumir o mínimo de energia, como equipamentos industriais, sensores médicos, comunicadores portáteis e também em dispositivos movidos à bateria do tipo coin cell (baterias de relógio, ex: CR2032). Hoje é a base de sistemas para casas inteligentes, de soluções de georreferenciamento no varejo e eventos, comunicação remota e pagamentos móveis.

 

O Bluetooth Smart trata-se de um protocolo de rede de tecnologia sem fio. Embora carregue o mesmo nome do Bluetooth “Clássico”, ele tem uma especificação completamente nova, projetada para habilitar o funcionamento de dispositivos de baixo consumo de energia por vários meses com baterias pequenas. Apesar do nome se parecer com o Bluetooth clássico, seu funcionamento é diferente da versão tradicional. Sendo assim, um dispositivo que suporte somente o BLE é chamado de “single-mode” ou “smart” e só efetua conexão com um semelhante. Entretanto, existe outra arquitetura chamada de “dual-mode” ou “smart ready” que pode ser implementada em um mesmo dispositivo. Dessa forma este protocolo pode suportar comunicação usando os dois padrões, no entanto, essa implementação diminui a eficiência energética do sistema. Provavelmente seu aparelho celular atual já tem um controlador “Bluetooth Smart Ready”.

 

Por sua característica principal ser a economia de energia, um dispositivo BLE permanece em modo IDLE (sleep) durante a maior parte do tempo. Esta tecnologia foi desenvolvida para aplicações que necessitam enviar apenas poucas informações, esporadicamente saindo do modo “sleep” apenas para realizar conexões que duram apenas milissegundos. Dessa forma, tem-se um consumo energético com picos de até 15 mA, mas com uma média de 1 μA apenas, fazendo com que simples baterias e pilhas comuns durem diversos meses ou anos, dependendo da aplicação utilizada.

 

Essas diferenças e limitações fazem com que as aplicações finais que serão criadas utilizando Bluetooth Smart, ou BLE, sejam completamente diferentes das tradicionais.

 

Para uma introdução não técnica do BLE / Bluetooth Smart, veja o artigo Introdução ao BLE.

 

 

Transferência de Dados

 

Bluetooth Low Energy (BLE) foi projetado para aplicações de baixa taxa de dados como sinais de controle, leituras de sensores, parametrizações, etc. A taxa de modulação de rádio do BLE é definida por especificação em 1 Mbit/s constantes. Isso define o limite superior teórico para a taxa de transferência da camada física que o Bluetooth Smart oferece. Mas em termos reais , este limite é normalmente reduzido por uma variedade de fatores, incluindo tráfego bidirecional, overhead, limitações da CPU e do rádio, além de restrições artificiais nos softwares.

 

Então na prática podemos dizer que, no melhor cenário, a taxa de comunicação de dados será por volta 10 Kbyte/s, dependendo da limitação de ambos dispositivos. Com isso é possível ter uma ideia do que pode e o que não pode ser feito com BLE em termos de transferência de dados para um smartphone ou tablet, por exemplo, além de explicar o porquê de outras tecnologias como Wi-Fi e Bluetooth Clássico ainda serem utilizadas.

 

Em um mundo onde as coisas geralmente acontecem rápido, 10 Kbyte/s parece devagar e improdutivo, porém o foco do BLE e o primeiro objetivo para o qual foi designado é o baixo consumo de energia, além disso em algumas aplicações no universo IoT (Internet of Things) esta taxa é considerada alta para as demandas atuais.

 

 

Arquitetura

 

A arquitetura do BLE é dividida em camadas conforme a figura abaixo. Pode ser separada entre controlador e host, podendo ser produzidos por diferentes fabricantes, se comunicando através de uma camada HCI (Host Controller Interface), o que permite a interoperabilidade entre diferentes fabricantes. Também pode ser implementado um SoC (Sytem on a Chip) que é um único CI (Circuito Integrado) com controlador e host, o que torna o custo e a complexidade da placa de circuito impresso mais baixos. O controlador é quem permite que o host durma por longos períodos, somente despertando quando for necessário realizar alguma ação.

 

Esta arquitetura está representada na figura 1, a seguir:

 

Pilhas de Protocolos BLE (Bluetooth Smart)
Figura 1 - Pilhas de Protocolos BLE

 

 

Camada Física - Physical Layer (PHY)

 

Nesse nível, o BLE é um pouco semelhante à sua forma mais antiga, porém com algumas alterações abordadas a seguir.

 

O FCC e o ETSI classificam o Bluetooth BR/EDR como um sistema FHSS, entretanto o Bluetooth Smart não possui todos os requerimentos para ser definido como um sistema FHSS. Portanto, é classificado pela FCC como um Sistema de Modulação Digital (DTS). Já o ETSI classifica o BLE como um sistema DSSS (Direct-sequence Spread Spectrum). Em sua forma antiga tínhamos 79 canais de 1 MHz, já o BLE conta com apenas 40 canais, cada um com 2 MHz de espaçamento. Estes canais são divididos em dois tipos: advertising channels e os data channels.

 

Os advertising channels ocupam 3 dos 40 canais citados anteriormente e são utilizados para descobrir outros dispositivos, estabelecer uma conexão e transmissão broadcast. Quando um dispositivo quer transmitir dados, envia pacotes de anúncio através dos advertising channels e é denominado anunciante. Essa transferência é realizada em intervalos chamados de eventos e é feita sequencialmente através de todos os advertising channels.

 

O segundo tipo, data channel ou “canal de dados”, é usado para a comunicação bi-direcional entre os dispositivos conectados e faz uso de uma técnica chamada Adaptive Frequency Hopping (AFH).

 

A figura 2  mostra os espaçamentos de 2 MHz entre canais. Sendo os canais 37, 38 e 39 advertising channels.

 

Espaçamento entre canais no BLE (Bluetooth Smart)
Figura 2 - Espaçamento entre canais no BLE.

 

Os dispositivos que apenas recebem dados por esses mesmos canais recebem o nome de scanners. A Modulação continua sendo a Gaussian Frequency-Shift Keying (GFSK), como nos outros bluetooths.

 

No entanto, por um usar o espectro gratuito de 2.4 GHz (2.4 GHz até 2.4835 GHz), o BLE corre o risco de colidir com um sinal de Wi-Fi/802.11 que esteja operante na região. Para solucionar este problema, sobre os canais data channels é usado o mecanismo Adaptive Frequency Hopping (AFH). Esse processo faz com que o mapa de frequências disponíveis seja readaptado, de modo que os canais já ocupados sejam excluídos da lista de disponibilidade. Além disso, o AFH faz com que mestre e escravo utilizem o mesmo canal, a fim de impedir que um use um bom canal e o outro um canal ruim, o que poderia provocar uma série de erros e retransmissões.

 

A largura de faixa deve ser, no mínimo, 500 kHz. A tabela com mais informações pode ser acessada em Introdução ao Bluetooth Smart.

 

 

Camada de Enlace - Link Layer (LL)

 

A camada de enlace é a parte que interage diretamente com a camada física e geralmente é implementada como uma combinação de hardware e software personalizados. O software implementado nesta camada gerencia o estado do enlace do rádio, que é a forma como o dispositivo se conecta a outros dispositivos. Um dispositivo BLE pode ser um mestre, um escravo, ou ambos, dependendo do caso e dos requisitos de utilização. Dispositivos que iniciam conexões serão mestres (initiator) e dispositivos que anunciam a sua disponibilidade e aceitam ligações serão escravos (advertiser).

 

Para a conexão entre dois dispositivos ser concretizada, estes podem assumir cinco estados dentro da camada de enlace:

  • Standby: o dispositivo não recebe nem envia nenhum pacote; o estado pode ser acessado a partir de qualquer outro;
  • Advertising: o dispositivo nesse estado, chamado de advertiser (anunciador), envia pacotes por cada advertising channel (canal de anúncio) e pode responder a requisições de outros dispositivos;
  • Scanning: o dispositivo nesse estado, chamado de scanner, escuta transmissões de pacotes de anúncios e pode solicitar infomações adicionais a outros dispositivos;
  • Initiating: o dispositivo nesse estado, chamado de initiator, diferentemente do scanner, tem a intenção de se conectar a um anunciador. Ao localizar um, ele responde requisitando o início de uma conexão;
  • Connection: quando a conexão é formada entre o initiator e o advertiser, ambos entram nesse estado e se comunicam através dos data channels (canais de dados).

 

A conexão entre o mestre e escravo é realizada na seguinte sequência:

  • Um dispositivo iniciador fica à escuta de anunciadores nos advertising channels. Quando ele acha um dispositivo e decide conectar, é enviada uma mensagem de requisição de conexão ao anunciador, que, se aceita, gera uma conexão P2P (point-to-point) entre os dois dispositivos. O iniciador vira mestre e pode interromper a conexão com o escravo (antes anunciante) a qualquer momento.

 

O modelo funciona de modo com que o mestre possa gerenciar múltiplas conexões com escravos, que por sua vez, só podem estar conectados a um mestre (o tamanho destinado ao endereçamento passou de 3 bits, do Bluetooth clássico, para 48 bits no Bluetooth Smart, possibilitando bilhões de conexões).

 

O escravo, por padrão, a fim de poupar energia, fica em modo sleep. O mestre, através do esquema de Time Division Multiple Access (TDMA), onde pacotes são enviados em tempos e intervalos pré-determinados, é responsável também por acordar o escravo, a fim de concretizar as transmissões. Além disso, entra no seu poder de gerência o envio de informações para o rodar o algoritmo de Frequency Hopping, a supervisão de conexão e updates de mapa de canais disponíveis.

 

 

Modos de Operação

 

O BLE tem apenas dois tipos de pacotes (publicidade e pacotes de dados), o que simplifica imensamente a aplicação na pilha de protocolos. Os Pacotes de Publicidade tem duas principais funções:

  • Transmissão de dados para aplicações que não precisam da sobrecarga de um estabelecimento completo de conexão;
  • Descoberta de escravos e realização da conexão com eles.

 

Cada pacote de publicidade pode transportar até 31 bytes de carga de dados de publicidade, juntamente com as informações básicas do cabeçalho (incluindo o endereço do dispositivo Bluetooth). Tais pacotes são simplesmente transmitidos cegamente pelo ar pelo anunciante, sem o conhecimento prévio da presença de qualquer dispositivo digital para receber o sinal. Eles são enviados a uma taxa fixa definida pelo intervalo de publicidade, que varia de 20 ms a 10,24 s. Quanto mais curto o intervalo, maior é a frequência em que os pacotes de publicidade são transmitidos, o que resume a uma maior probabilidade de que os pacotes estão sendo recebidos por um scanner, contudo quantidades mais elevadas de pacotes transmitidos resultam em maior consumo de energia.

 

Os pacotes de dados são o carro-chefe do protocolo e são usados para transportar os dados do usuário de forma bi-direcional entre o mestre e escravo. Estes pacotes têm uma carga de dados útil de 27 bytes, porém protocolos adicionais das camadas acima geralmente limitam a quantidade real de dados do usuário para 20 bytes por pacote. Contudo esta váriavel depende do protocolo que está sendo usado. Também é importante notar que a camada de enlace atua de forma confiável, todos os pacotes recebidos são checados por um CRC e retransmissões são solicitadas caso seja detectada uma falha na transmissão.

 

 

Propriedades dos Pacotes e Scanners

 

Os pacotes de anúncios podem ser classificados de acordo com três diferentes propriedades. A primeira é conectividade:

  • Conectável: Um scanner pode iniciar a conexão após a recepção de um pacote de anúncio;
  • Não conectável: Um scanner não pode iniciar a conexão (esse pacote é utilizado para broadcast somente).

 

A segunda propriedade é escaneabilidade:

  • Escaneável: Um scanner pode emitir uma solicitação de verificação após a recepção de um pacote de anúncio;
  • Não Escaneável: Um scanner não pode emitir uma solicitação de verificação após a recepção de um pacote de anúncio.

 

E a terceira propriedade é  diretividade:

  • Direcionado: Um pacote deste tipo contém apenas o endereço bluetooth do anunciante e do scanner alvo no seu payload. Dados do usuário não são permitidos. Todos os pacotes de anúncios direcionados são também considerados conectáveis;
  • Não Direcionado: Um pacote deste tipo não tem como alvo um scanner em particular, e pode conter dados do usuário em seu payload.

 

Quanto aos Scanners, as especificações definem dois tipos básicos de escaneamento:

  • Escaneamento Passivo: O scanner escuta o meio para receber pacotes de anúncios, e o anunciante não tem conhecimento do fato de que um ou mais pacotes foram efetivamente recebidos por um scanner;
  • Escaneamento Ativo: O scanner emite um pacote de solicitação de verificação (Scan Request) depois de receber um pacote de anúncio. O anunciante recebe e responde com um pacote de resposta (Scan Response Packet). Este pacote adicional dobra a carga efetiva que o anunciante é capaz de enviar para o scanner, mas é importante notar que isto normalmente não é utilizado como um meio para o scanner enviar quaisquer dados do usuário para o anunciante.

 

A figura 3 ilustra como funciona os dois modos de escaneamento.

 

Tipos de Escaneamento no Bluetooth Smart
Figura 3 - Tipos de Escaneamento.

 

 

Host-Controller Interface (HCI)

 

Camada que tem um protocolo padrão, que faz a comunicação entre o host e o controlador. Segundo as especificações do Bluetooth, o HCI é definido como um grupo de comandos e eventos que fazem com que o host e o controlador interajam entre si, juntamente com o formato de pacotes de dados e um conjunto de regras para o controle de fluxo e outros procedimentos. Existem várias camadas de transporte padrão no HCI, cada uma usa uma interface de hardware diferente para transferir o mesmo comando, evento e pacote de dados. Os mais comuns são USB/UART para PCs, SPI para microcontroladores e smartphones, também há outros como: SDIO, BCSP, etc.

 

 

Logical Link Control and Adaptation Protocol (L2CAP)

 

Protocolo simplificado e otimizado, baseado no L2CAP do Bluetooth. Tem duas principais funções, sendo a primeira delas ser responsável pelo encapsulamento, para o formato de pacotes padrão do BLE, de mensagens das camadas superiores e vice-versa.

 

O L2CAP também realiza a fragmentação e recombinação de pacotes grandes, vindos das camadas superiores e os fragmenta em pedaços de 27 bytes, tamanho máximo do payload. Já na recepção ele pega os pacotes que tinham sido fragmentados e os recombinam em um único pacote maior para ser enviado às camadas superiores.

 

Encapsulamento L2CAP
Figura 4 - Encapsulamento L2CAP

 

 

Attribute Protocol (ATT)

 

Este protocolo define dois papéis para os dispositivos: servidor e cliente. O servidor tem a capacidade de expôr uma série de atributos (estruturas de dados que guardam informações a serem utilizadas pelo GATT) ao cliente. A definição dos papéis é feita também pelo GATT e independe do papel de mestre/escravo.

 

O Attribute Protocol é um protocolo cliente/servidor sem estado, baseado nos atributos apresentados pelo dispositivo. No BLE, cada dispositivo é um cliente, um servidor ou ambos,  independentemente de se tratar de um mestre ou escravo. Um cliente solicita dados de um servidor, e um servidor envia dados para clientes. O protocolo é rigoroso quanto à sua sequenciação: se uma solicitação ainda está pendente (nenhuma resposta para ela ainda foi recebida), outras solicitações não podem ser enviadas até que a resposta seja recebida e processada. Isso se aplica a ambos os sentidos, mesmo no caso onde dois pares atuam cliente e servidor.

 

Cada Servidor contém dados organizados sob a forma de atributos, cada um dos quais é alocado um atributo de 16 bits para manuseio, um Identificador Único Universal (UUID), um conjunto de permissões e um valor. O UUID específica o tipo e a natureza dos dados contidos no valor. Um UUID completo possui 128 bits (16 bytes), porém buscando eficiência e baixo consumo dos preciosos 27 bytes de payload  da Camada de Enlace, as especificações do BLE introduzem dois UUIDs adicionais, de 16 e 32 bits. Estes formatos menores podem ser utilizados somente com UUIDs que são definidos pelas especificações do Bluetooth, ou seja, só é compatível com tecnologia Bluetooth.

 

 

Security Manager Protocol (SMP)

 

O SMP é um protocolo que utiliza uma série de algoritmos de segurança que fornecem à pilha de protocolo Bluetooth a capacidade de gerar e trocar chaves de segurança. Define os métodos de enlace de dispositivos de uma rede, oferecendo funções às outras camadas para que a troca de informação seja feita de forma segura sobre um link criptografado, a fim de confirmar a identidade do dispositivo remoto e esconder o endereço público do Bluetooth, se necessário, para evitar pares maliciosos de rastreamento em dispositivos particulares.

 

O SM (Security Manager) define dois papéis para os dispositivos:

  • Iniciador: sempre corresponde ao Link Layer mestre e por consequência ao GAP central;
  • Respondedor: sempre corresponde ao Link Layer escravo e portanto ao GAP periférico.

 

O Iniciador é sempre que aciona o começo do procedimento, porém o Respondedor também pode solicitar o início de alguns procedimentos, entretanto não há garantias que o Iniciador irá atender esse requerimento

 

Os procedimentos de segurança que são suportados pelo SM são Pairing (Pareamento), Bonding (Ligação) e Encryption Re-establishment (Restabelecimento de Encriptação) e serão explicados a seguir:

  • Pareamento: com este procedimento, é gerada uma chave de criptografia comum temporária para permitir a troca de um link seguro para um criptografado. Esta chave temporária não é armazenada e também não é reutilizada nas conexões subsequentes;
  • Ligação: procedimento que vem em seguida ao Pareamento, nela há a geração e troca das chaves de segurança permanentes, a chave é armazenada em uma memória não-volátil e assim cria-se um vínculo permanente entre dois dispositivos, permitindo que eles rapidamente criem um link seguro em ligações subsequentes, e não precisem executar este procedimento outra vez;
  • Restabelecimento de Encriptação: depois de terminar o procedimento anterior, as chaves podem ter sido armazenadas nos dois lados da conexão. Se sim, este procedimento definirá como usar essas chaves em conexões futuras de forma segura e criptografada, afim de não ser necessária a execução dos procedimentos anteriores (Pareamento e/ou Ligação) novamente.

 

 

Generic Attribute Profile (GATT)

 

Construído sobre o Attribute Protocol (ATT), é o modo que cliente e servidor compartilham suas informações de modo estruturado, trocando características. Determinado para ser usado por uma aplicação ou um perfil, é considerado o backbone de transferência de dados do BLE porque ele define como os dados são organizados e trocados entre aplicações. O GATT define papéis de interatividade que os dispositivos podem adotar:

  • Cliente: o cliente GATT corresponde ao cliente ATT, envia um requerimento ao servidor e recebe a resposta. O cliente não sabe de antecedência sobre os atributos de servidor, por isso ele deve ser o primeiro a questionar sobre a presença e natureza dos atributos através da realização de descoberta de serviço. Depois de completada a descoberta de serviço, ele pode ler e escrever atributos achados no servidor assim como o recebimento de atualizações do servidor inicializado;
  • Servidor: o servidor GATT corresponde ao servidor ATT, recebe as requisições de um cliente e envia a resposta de volta, também envia atualizações do servidor inicializado (se programado para fazer isso). É responsável por armazenar e criar dados de usuários disponíveis para o cliente, organizado em atributos. Cada dispositivo BLE vendido deve ao menos incluir um servidor GATT básico que responde para os requisições do cliente, mesmo que até o retorno, seja resposta errada.

 

Como funciona a comunicação entre Servidor GATT e Cliente GATT
Figura 5 - Como funciona a comunicação entre Servidor GATT e Cliente GATT.

 

 

General Access Profile (GAP)

 

O GAP é o pilar que permite os dispositivos BLE interoperarem entre si e que torna o dispositivo visível ao mundo exterior. Ele fornece um framework que qualquer implementação BLE tem que seguir para permitir que dispositivos descubram outros e sejam descobertos, forneçam dados de broadcast e estabeleçam conexões seguras.

 

Topologia Broadcast com Bluetooth Smart
Figura 6 - Topologia Broadcast

 

O GAP aplica ao BLE diferentes aspectos da interação dos dispositivos, que são Roles (Papéis), Modes (Modos), Procedures (Procedimentos), Security (Segurança):

  • Roles: cada dispositivo pode operar com um ou mais Roles (papéis), cada papel impõe restrições e certas exigências comportamentais. Algumas combinações permitem a comunicação entre os dispositivos e o GAP estabelece essas interações com precisão. Os papéis são divididos em 4 especificações diferentes, em que a central e o periférico são os mais relevantes;
    • Broadcaster: que apenas faz transmissão de dados através dos advertising channels, sem poder se conectar com outros dispositivos;
    • Observador: que buscam anunciantes, sem poder iniciar uma conexão;
    • Periférico: um anunciante que pode se conectar e atua como escravo;
    • Central: que buscam anunciantes e iniciam as conexões, atuando como mestres.
  • Modes: refina ainda mais o conceito de Role. O Modo é um estado que pode variar de acordo com o tempo para alcançar um objetivo particular, ou mais especificamente, permitir um ponto realizar um processo específico;
  • Procedures: é uma sequência de ações que permite o dispositivo atingir um objetivo, um procedimento é associado com um modo de outro par, então eles muitas vezes são fortemente acoplados juntos;
  • Security: define modos de segurança e procedimentos que especificam como os pares estabelecem o nível de segurança requerido para uma troca de dados particular.

 

Existem duas maneiras de enviar a publicidade com GAP que são o Dados de Publicidade (Advertising Data) e a Resposta de Escaneamento (Scan Response). Ambos payloads são idênticos e contém 31 bytes de dados, mas somente no Advertising Data é obrigatória, porque ela será constantemente transmitida a partir do periférico para a central para saber que ele existe. A resposta é opcional que as centrais podem solicitar, o que permitem que caiba um pouco mais de informação na carga útil como nomes para dispositivo, entre outros.

 

Processo de publicidade entre Central e Periférico com Bluetooth Smart
Figura 7 - Processo de publicidade entre Central e Periférico.

 

 

Bluetooth Smart 4.1 e 4.2

 

O Bluetooth SIG (Special Interest Group) anunciou a adoção de atualizações no final de 2013.

 

A versão 4.1 apresenta algumas inovações, sendo a principal delas a melhoria na cooperação entre as ondas de rádio do Bluetooth e as que são utilizadas por redes 4G LTE. Também há melhorias no intervalo entre uma conexão e uma reconexão com os mesmos aparelhos, ou seja, se você sair do alcance da conexão e voltar logo em seguida, a reconexão será automática e mais veloz, além disso o consumo de energia deve ser reduzido. Outra novidade da versão 4.1 é que os dispositivos podem ser master e slave ao mesmo tempo. Dessa forma, um relógio inteligente pode ser o escravo de um smartphone e ao mesmo tempo ser o central de um sensor de batimento cardíaco, por exemplo.

 

A versão 4.2, por sua vez, adiciona algumas melhorias de segurança, bem como suporte a IPv6/6LoWPAN, permitindo que dispositivos BLE se conectem à Internet através de um gateway, inclusive possibilitando que sejam criadas redes em malha (mesh).

 

 

Conclusão

 

Esse artigo foi o segundo de um série de três sobre o Bluetooth Smart. Tratamos de aspectos técnicos, servindo como uma introdução a stack do protocolo. Na próxima parte, abordaremos a usabilidade e aplicações do Bluetooth Smart.

 

Um agradecimento especial ao pessoal do momote.io  e a todos que contribuíram com esse artigo. Valeu galera! Até logo!

 

 

Referências

 

Introdução ao Bluetooth Smart (BLE) - Emabarcados

https://www.geekbooks.me/book/view/getting-started-with-bluetooth-low-energy

https://www.bluetooth.com/~/media/files/specification/bluetooth-quic-ref-guide.ashx?la=en

https://www.bluetooth.com/~/media/files/specification/bluetooth-faq.ashx?la=en 

https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439 

http://chapters.comsoc.org/vancouver/BTLER3.pdf

https://www.embarcados.com.br/bluetooth-low-energy/

http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2012_2/bluetooth/aplicacoes.htm

https://atmosphere.anaren.com/wiki/Data_rates_using_BLE

http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2012_2/bluetooth/bt.htm

https://en.wikipedia.org/wiki/Bluetooth_low_energy

http://convergenciadigital.uol.com.br/cgi/cgilua.exe/sys/start.htm?UserActiveTemplate=site&infoid=35710

http://www.mdpi.com/1424-8220/12/9/11734/htm

https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gap

https://msdn.microsoft.com/pt-br/library/aa910275%28v=winembedded.60%29.aspx

https://developer.bluetooth.org/TechnologyOverview/Pages/HCI.aspx

https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt

http://www.anatel.gov.br/legislacao/resolucoes/2008/104-resolucao-506

https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=237781

https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/218486

https://www.quora.com/What-are-the-main-differences-between-Bluetooth-4-0-4-1-and-4-2-in-the-Layers-Baseband-LMP-L2CAP-app-Layer

Outros artigos da série

<< Introdução ao Bluetooth Smart (BLE)Aplicações e Perfis do Bluetooth Low Energy (BLE) >>
Este post faz da série Bluetooth Smart. Leia também os outros posts da série:

Graduado em Engenharia Elétrica com ênfase em Telecomunicações pelo INATEL (Instituto Nacional de Telecomunicações) e técnico em Automação Industrial, participante do Projeto Momote.io e entusiasta na área de Internet das Coisas. Gosta de inovação, arte, pinga e viola.

Deixe um comentário

2 Comentários em "Visão Técnica do Bluetooth Smart"

Notificar
avatar
Ordenar por:   recentes | antigos | mais votados
Thiago Lima
Admin
Thiago Lima

Excelente texto Leandro!

Leandro Pessoa
Visitante
Leandro Pessoa

Muito obrigado Thiago! Espero continuar fazendo bons trabalhos com o embarcados.

wpDiscuz