Introducción a

Bluetooth Low Energy

Ing. Ingrid Tay
Ing. Stu Chandler
 Objetivos

• Introducir el rango de soluciones que

proporcionamos
• Introducir los fundamentos del protocolo
Bluetooth® Low Energy (BLE)
• Introducir herramientas de desarrollo y
proporcionar ejemplos de como utilizarlas
MÓDULOS BLE DE MICROCHIP
 Portafolio Bluetooth®

BM70/71 BM78
RN41 / 41N RN42 / RN42N RN4020
RN4870/71 RN4678
Bluetooth 4.2
Type Class 1 Bluetooth 2.1 Class 2 Bluetooth 2.1 Bluetooth LE 4.1 Bluetooth LE 4.2 Dual Mode
(Classic & LE)

Interfaces UART / USB UART UART UART

GATT / Health, Fitness

Profiles/ GAP / SDP / SPP / GAP / SDP / SPP /
SPP / HID / iAP / HCI / Proximity, Etc. /
Protocols GATT GATT/iAP2
Custom data

Power 3.0-3.6V 3.0-3.6V 1.8-3.6V 1.9-3.6V 3.3-4.2V

Ceramic chip Antenna PCB Antenna or Ceramic chip Antenna Ceramic chip Antenna
Antenna PCB
Or no Antenna no Antenna Or RF pad for external Or RF pad for external

BM70: Shield/Unshield Shielded:

RN42: 13.4x25.8x2.4 22 x12x2.4/ 15x12x1.6 22 x 12 x 2.4
Size (mm) 13.4 x 25.8 x 2.0 11.5 x 19.5 x 2.5
RN42N: 13.4x20.5x2.4 BM71:Shield/Unshield Unshielded:
11.5x9x2.1/ 6x8x1.5 15x12x1.8

FCC / IC/ CE / AUS / FCC / IC/ CE / AUS / FCC,IC,CE,NCC,KCC, FCC,IC,CE,NCC,KCC,

Certification FCC / IC/ CE / AUS / JP
JP / Korea / Taiwan JP / Korea / Taiwan MIC(Japan) MIC(Japan)
 Modelos de Uso de los Módulos BLE
• BM (Módulo Básico)
– Hosted
– Interfaz de paquetes binarios
• Utilidades de programación y de configuración personalizadas
• RN
– Hosted
– Standalone (Host-less)
– Interfaz de comandos ASCII
• Configuración y programación usando programas de emulación de
terminal
 Comparación BM70 vs RN4870
Function BM70 RN4870
Usage Model Basic RN
Configuring parameters UI Tool ASCII Commands
Custom Service Definition UI Tool ASCII Commands
Firmware Update Flash Tool Flash Tool
Default Public and Private Supported Supported
Services
Operation UART Data Frame ASCII Commands
Binary Commands
MLDP Compatibility No Supported
Remote Console No Supported
Script Engine No Supported
 Portafolio Bluetooth®
Atmel
• ATBTLC1000-MR110CA
– BLE 4.1
– Consumo de energía BLE más bajo de la
industria
– Rango de tensión amplio: 1.8 – 4.3V
– Interfaz de Host
• SPI o UART
– Módulos Certificados
• FCC, ETSI/CE, TELEC
– Modelos de Uso
• Hosted
• Standalone
Introduciendo el Módulo BLE
RN4870
 RN4870 / 71
• Bluetooth® v4.2
– Single Mode BLE
– Más rápido y eficiente en energía que v4.1
• BT Stack onboard
• Interfaz de comandos ASCII
• Beacon
• Certificado por Bluetooth SIG
• Bajo consumo de energía
– Receive: 13mA (max), Transmit: 13mA (max) , Idle: 1.9mA , Power saving mode: 1uA
• Opciones de Shielded / Unshielded con Antena
• Herramienta de desarrollo con tarjeta de sensor
• Aplicaciones para smartphones disponibles
 Modos de Operación
• Data Streaming Mode
– UART Transparent Streaming (BLE Spec does not support SPP)
– Protocolo subyacente de Bluetooth no visto por el usuario
– Datos escritos al UART y enviados a través de Bluetooth. Datos recibidos a
través de Bluetooth y leídos del UART
• Command Mode
– $$$ hace que el modulo entre en Command Mode
– Se usa para configurar parámetros como: baud rate, device name, pin code, etc
– La configuración es persistente y se guarda en flash
User Data Bluetooth

UART Bluetooth Interface Host

Hello!

Bluetooth Module
$$$ $$$
Remote console
Command
Mode

Prototipos rápidos + fácil de diseñar = tiempo reducido al mercado

 Embedded Scripting

• Elimina el MCU anfitrión y ahorra dinero en

aplicaciones simples
• Habilita la utilización completa de la interfaz
periférica integrada
• Fácil de usar y se puede comercializar
rápidamente
Scripting
UART Engine
BT Stack
 Remote Console
• La consola remota es una característica única del
módulo RN
• Capacidad para conectarse de forma remota a un módulo
RN4870
• Proporciona control total del RN4870 remoto
• Proporciona acceso completo a todos los periféricos remotos
• Ejemplos de uso:
• RN4870 sin Host MCU
Easy configuration by remote
console
UART

or

UART
 Popular Beacon
• Definir parámetros clave con un solo comando
• advertisement & scan response payload
• Se configura fácilmente a otros formatos beacon
• iBeacon™, Eddystone™, y otros
• Compatibles con BeaconThing® de Microchip
 Herramientas Disponibles
• Herramienta de
Evaluación contiene
• RN4870/71 PICtail
• RN4870 Sensor board
EVB
• RN4870 Apps
• Bluetooth Smart Potentiometer
Switch
Discover App: iOS &
LED
Android*
DIP-
• BLE Sensor App: iOS Switch Light
Sensor

Sensor Board

*Available CY2Q2016. Contact WSG

 Características de Smart Discover

• Escanear y conectar a periféricos

• Muestra los datos de advertising del periférico
• Descubre servicios y características habilitadas
• Características Read/Write/Notify/Indicate
• Escanea y muestra los tipos de datos adv de
broadcasters
• Versiones iOS y Android
 Herramientas
RN4870-PICTAIL
Component# Details
1 BM70BLES1FC2 module
2 Power On Push button
3 SPI interface header pins
4 GPIO interface header pins connecting to the GPIO pins of the
MCP2200
5 USB-UART Header pin connections
6 LED and LED Power connection header
7 Header pins for selecting power source
8 Reset pin
9 Push button for testing and evaluation
10 Header pins for Vbat voltage
11 Header pins for connecting push buttons in section #9
12 I2C connection header
13 DIP switch for switching between App mode and
Firmware/Parameter Update mode
14 LEDs with corresponding header pins for testing and evaluation
15 Header pins connected to Ground testing/evaluation
16 28-pin PICtail™ Interface Header for connection to other Microchip
boards.
Interfaz MCU
R70

Conexión mínima
 UART Data Frame Communications
• MCU manda paquetes
especialmente
formateados de
“Command”
• Modulo responde con
paquetes
especialmente
formateados de “Event”
LAB 1:
INTRODUCCIÓN AL MODULO
RN4870
 Objetivos del Lab 1
• Aprender a programar firmware usando la
herramienta “ISupdate.exe”
• Usar CoolTerm para comunicarnos con el modulo en
Command Mode
– Cambiar algunos ajustes básicos
• Entender en donde se encuentra toda la
documentación
 Programación
Definición

• El modulo puede ser programado con

nuevo firmware de BLE
• Nuevo firmware puede añadir
funcionalidad especifica para:
– Nuevas revisiones de la especificación
Bluetooth
– Corregir errores
 Programación
Firmware Update Tool
 Diagrama de Conexión Lab 1

Host (PC Running ISupdate Tool) (RN4770-PICtail™ Plus)

3.3V
SW5
3.3V 3.3V
VDD RST_N VBAT
SW7
P2_0/SYSTEM_CONFIG
Module
Control

3.3V

Module P0_2/LED0
Status

Command
& Data I/F
UART_RX UART_TX
GND UART_TX UART_RX GND
 Resumen del Lab 1

• Programar el RN4870 requiere acceso a los

siguientes: P2_0 and RST_N, HCI_TXD, HCI_RXD &
GND
• RN4870 se comunica con el Host MCU a través de
paquetes UART de comando / respuesta con
FUNDAMENTOS DE BLUETOOTH®
LOW ENERGY (BLE)
 Agenda
• Fundamentos
• Arquitectura
– Capa Controller
– Capa Host
• Generic Access Profile (GAP)
– Lab1/2 – Averiguar y Establecer la Conexión
• Generic Attribute Profile (GATT)
– Lab 3 – Intercambio de Datos
• Resumen
 Bluetooth® Low Energy (BLE)
• Extensión a la especificación Bluetooth 4.x
– Nueva PHY
– Nuevo mecanismo de advertising
• mejora la facilidad de descubrimiento y conexión
– Connection-less MAC asincrónico
• latencia baja
• transacciones rápidas (3 ms de principio a fin)
– Nueva Generic Attribute Profile
• simplifica los dispositivos y el software que los usa.
– Arquitectura asincrónica de Cliente/Servidor

Un estándar de radio que habilita el Internet of Things

 Bluetooth® v4.2
Mejoras Significantes
• Sincronización de Datos Más Rápida
– Hasta un rendimiento 2.5 veces más alto
– Aumento en la capacidad de los paquetes – casi 10 veces más que las
versiones previas

• Alta Seguridad
 Principios Básicos
• Funcionan con pilas de botón
– Baja Energía en total
• Paquetes de tamaño pequeño
• Minimizar el ciclo de trabajo y la latencia
• Asimetría
– El dispositivo con la fuente de energía mas baja, se le da
menos que hacer
• IoT-Ready
– Modelo de Datos Client-Server
• Things o Cosas tienen los datos
• Servicios Web quieren esos datos
 Diseñado para transferencias simples

• Transferencias discretas de una pequeña

cantidad de datos
• Los datos pueden ser activados por eventos
locales
• Los datos se pueden leer a cualquier hora por
un “cliente”
Gate 25
31.5o C 12:06 am
BOARDING
44.5 km/hr PLAY
 BT LE Stack

Application Layer (App) Application

Generic Attribute Protocol

Generic Access Profile (GAP)
(GATT)

Security Manager (SMP) Attribute Protocol (ATT) Host

Logical Link Control & Adaptation Protocol

(L2CAP)

Link Layer (LL)

Controller
Physical Layer (PHY)
 Agenda
• Fundamentos
• Arquitectura
– Capa Controller
– Capa Host
• Generic Access Profile (GAP)
– Lab1/2 – Averiguar y Establecer la Conexión
• Generic Attribute Profile (GATT)
– Lab 3 – Intercambio de Datos
• Resumen
Controller Layer

PHYSICAL LAYER
 Canales
Capa Controlador: Capa Física
• Banda ISM 2.4 GHz
• 1Mbps GFSK
– Optimizada para mandar pequeños fragmentos de datos
rápidamente
• 40 Canales con espacios de 2MHz
– Empiezan: 2402 MHz
Ch: 37 0 1 2 3 4 5 6 7 8 9 10 38 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 39

2400 2410 2420 2430 2440 2450 2460 2470 2480

Frecuencia (MHz) Data
Advertising
 Canales
Capa Controlador: Capa Física
• 3 Canales de “Advertising”
– Device Discovery
– Connection Establishment
– Broadcast Transmission
• 37 Canales de Datos
– Comunicación bidireccional entre los dispositivos conectados
– Usa adaptive frequency hopping para los eventos de conexión
subsecuentes
Ch: 37 0 1 2 3 4 5 6 7 8 9 10 38 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 39

2400 2410 2420 2430 2440 2450 2460 2470 2480

Frecuencia (MHz) Data
Advertising
 802.11 Superposición (WiFi)
Capa Controlador: Capa Física
2.4 GHz BLE PHY Canales
vs.
IEEE 802.11 WiFi (EEUU)

2412 2437 2462

Channel 1 Channel 6 Channel 11

Ch: 37 0 1 2 3 4 5 6 7 8 9 10 38 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 39

2400 2410 2420 2430 2440 2450 2460 2470 2480

Data
Frecuencia (MHz) Advertising
Controller Layer

LINK LAYER
 Roles
• Conexión Unicast (peer-peer)
– Antes/Durante la Conexión
• Advertiser
• Scanner, Initiator
– Después de la Conexión
• Slave
• Master
• Conexión Broadcast
– Broadcaster
– Observer
 Roles (Unicast)
Unassigned/
Host A Host B Standby

Scanner Advertiser
ADV_IND: Ch37

ADV_IND: Ch38
Discovery
ADV_IND: Ch39

.
.
Initiator . Advertiser

ADV_IND: Ch38

CONNECT_REQ: Ch38 Connecting

.
.
GAP “Central” Role Master
.
Slave GAP “Peripheral” Role
GATT “Client” Role GATT “Server” Role
DATA_TX: Ch11

DATA_RX: Ch11 Connected

.
.
time
.
 Roles (Broadcast)
Unassigned/
Host xxx Host A Host B
Standby

Observer Observer Broadcaster

ADV_IND**: Ch37

Within radio range ....

ADV_IND**: Ch38

**
One of 3 Advertising
channel packet types
available for Broadcasting
data

ADV_IND**: Ch39

time .
.
.
 BLE LL States
• Link Layer States
– Standby
– Advertising Scanning
– Initiating
– Scanning
Advertising Standby Initiating
– Connected

Connected
Slave Master
 Dirección del Dispositivo

• Identificador fundamental, similar a una

dirección de Ethernet MAC
– 48-bit (6-byte)
• Hay dos tipos disponibles
– Dirección del dispositivo Publica
• Equivalente a la dirección MAC que nunca cambia
– Dirección del dispositivo Random
• Generada dinámicamente en tiempo de ejecución
 Tipos/Formatos de Paquetes
Capa Controlador: Capa Link
• Uno formato de paquetes
• Dos tipos de paquetes
• Advertising
• Data
Formato:
Preamble Access Address Protocol Data Unit (PDU) CRC
1 Byte 4 Bytes 2-257 Bytes 3 Bytes

Tipos:
Advertising Channel PDU Data Channel PDU
Header Payload Header Payload MIC
2 Bytes 0-37 Bytes 2 Bytes up to 255 Bytes (incl. MIC) 4 Bytes
Message Integrity Check:
opcionál para seguridad
 Advertising Channel PDUs

• Advertising channel PDUs sirven para 2

propósitos
– Para transmitir datos para aplicaciones que no
requieren una conexión completa
– Descubrir esclavos y conectarse a ellos
Advertising Channel PDU

Header Payload
2 Bytes 0-37 Bytes

Advertising
Packet Types
 Tipos de Advertising Channel PDU Types
Advertising Channel PDU

Header Payload
2 Bytes 0-37 Bytes

Advertising
Packet Types

• Hay 7 tipos de advertising channel PDUs, cada uno tiene

una función y formato de payload diferente
– Advertising PDUs
• ADV_IND**, ADV_DIRECT_IND, ADV_NONCONN_IND**,
ADV_SCAN_IND**
– Scanning PDUs
• SCAN_REQ, SCAN_RSP
– Initiating PDUs
**
Available for
• CONNECT_REQ Broadcasting data
 Descubrimiento
Capa Controlador: Capa Link
• Advertising & Scanning ocurren en intervalos regulares
– No están sincronizados
– Deben superponerse para que el descubrimiento comience

Scanner Scan Interval = 50 ms

Scanner Scan Window = 25 ms
Scanning: Ch 37 Scanning: Ch 38 Scanning: Ch 39

Scanner

0 ms 25 ms 50 ms 75 ms 100 ms 125 ms

Advertiser

0 ms 20 ms 40 ms 60 ms 80 ms 100 ms 120 ms 140 ms

Advertising & Scanning
Advertising PDU: Ch 37

Intervalo = 20 ms + 0-10 ms aleatorio de espera Advertising PDU: Ch 38

Advertising PDU: Ch 39
Advertising Channel PDU Payload (primera
conexión)
Advertising Channel PDU

Header Payload
2 Bytes 6-37 Bytes

Advertising Packet Payload

ADV AD 0 … AD N
Address Structure Structure

AD Length AD Type AD Data

Length

• ADV_IND (connectable, undirected)

– Advertiser’s MAC/private address (6-bytes)
– A number of Advertisement Data Structure(s)
• AD Length (1-byte)
• AD Type (1-byte)
– Ver Bluetooth SIG GAP Data Types para los tipos de datos definidos
• AD Data (up to 29 bytes)
– Ver Bluetooth Core Specification Supplement para los formatos de
datos
 Tipos de Datos AD
• Típicamente
– Nombre Local Completo (0x09)
– Lista Completa de los Service UUIDs de 128-bits (0x07)
– Flags (0x01)
– Custom Data (0xFF)

NOTE:
A single 128bit Service UUID takes up 16/31 bytes available in the
ADV_IND Payload!

If you need to provide more information to your app, consider

enabling SCAN_RSP packets
 Advertising Channel PDU Payload
(reconnect)
Advertising Channel PDU

Header Payload
2 Bytes 12 Bytes

Advertising Packet Payload

Advertiser MAC Address Peer MAC Address

• ADV_DIRECT_IND (connectable, directed)

– Advertiser’s MAC/private address (6-bytes)
– Central’s MAC/private address (6-bytes)
• Se usa cuando un periférico quiere conectarse rápidamente
con un central ya conocido
– Solo los dispositivos centrales con la dirección MAC correspondiente
recibirán/pasaran el mensaje/evento a sus aplicaciones
– El intervalo es fijo (1.25mS) y dura poco (~1-2s)
 Scanning
Capa Controller: Capa Link
• Scanning Pasivo
– El scanner escucha para los paquetes de
advertising
– El advertiser nunca sabe si los paquetes fueron
recibidos
• Scanning Activo
– Scanner emite un paquete SCAN_REQ
– Advertiser responde con mas información en un
paquete SCAN_RSP
 Scanning
- Passive vs. Active -
 Iniciar una Conexión
Capa Controlador: Capa Link
• Scanner selecciona un Advertiser
de interés
• Scanner se convierte en el
Initiator
– Manda un paquete CONNECT_REQ,
que define:
• La secuencia de frequency hopping
• El intervalo de conexión
• Slave latency
• Connection link supervision timeout
• Al connectarse, se convierte en
Master
• Advertiser se convierte en Slave
 Eventos de Conexión
• Ya conectados un Master y Esclavo intercambian paquetes de
datos en cada “evento de conexion”
– “Intervalo de Conexion” dura entre 7.5ms a 4s (unit: 1.25ms)
– Payloads de 0-bytes se intercambian si no hay otros datos
• Cada evento de conexion se conduce en un canal de diferente
frecuencia
– Basado en un mapa de los canales y la secuencia de hopping
 Data Channel PDUs

• Ya conectados, los dispositivos se pueden

mandar datos el uno a otro
• Esto se logra mediante el intercambio de data
channel PDUs durante “eventos de conexión”
programados regularmente
Data Channel PDU

Header Payload MIC

2 Bytes up to 255 Bytes 4 Bytes
 Entrega Confiable
Capa Controlador: Capa Link
• Una vez conectado, la Link Layer actúa como
un portador de datos fiable
– Todos los paquetes recibidos se checan con un 24-
bit CRC
– Se piden re-transmisiones, sin limites
• Link Layer volverá a enviar el paquete hasta que reciba
el acknowledge
 Topología de la red

• Piconet
– Un solo Master Piconet #1 Piconet #2

• Coordina la transferencia de Slave

datos entre uno o más Slaves
• BM70 apoya 1 conexión
• Slave solo puede pertenecer Master
a 1 Piconet
Piconet #4

Piconet #3
 Seguridad

• La Link Layer proporciona la capacidad de

encriptación y autenticación
– AES-128 block cipher
– Cipher Block Chaining-Message Authentication Code
(CCM) Mode
• “Pairing” procedimiento utilizado para generar
y distribuir las claves
• “Bonding” procedimiento utilizado para
generar, distribuir y almacenar las claves
 Agenda
• Fundamentos
• Arquitectura
– Capa Controller
– Capa Host
• Generic Access Profile (GAP)
– Lab1/2 – Averiguar y Establecer la Conexión
• Generic Attribute Profile (GATT)
– Lab 3 – Intercambio de Datos
• Resumen
Host Layer

GENERIC ACCESS PROFILE (GAP)

 Generic Access Profile (GAP)
Capa Host: GAP
• Define como todos los dispositivos BLE interactuaran el
uno con el otro
• La capa GAP define:
– Roles
• Broadcaster, Observer, Central, Peripheral
– Modos de Funcionamiento
• Broadcaster, Non discoverable, limited discovery, general
discovery, non connectable, any connectable.
– Procedimientos Operacionales
• Discovery, establecimiento y finalización de conexión
– Modos y Procedimientos de Seguridad
 GAP Roles
Capa Host: Roles GAP
• Dispositivos BLE pueden asumir uno o más
roles a la misma vez
• Dos pares de roles se definen, permitiendo a
los dispositivos comunicarse el uno con el otro
– Unidireccional – Sin Conexión
– Bidireccional – Orientado a la Conexión
 Broadcaster/Observer
Capa Host: Modos GAP
• Unidireccional, sin conexión
– Broadcaster
• Manda paquetes de advertising con datos
periódicamente, usa el rol de advertiser de la capa link
– Observer
• Escucha los datos del advertiser, usa el rol de scanner
de la capa link
 Central/Peripheral
Capa Host: Modos GAP
• Bidireccional, orientado a la conexión
– Central
• El Master de la Link layer, capaz de establecer y
mantener una conexión, se puede conectar a varios
dispositivos simultáneamente
– Periférico
• El Esclavo de la Link Layer, usa advertising para poder
ser descubierto por el dispositivo Central
• Optimizado para tener el más bajo poder de
procesamiento y memoria para así permitir que los
dispositivos periféricos BLE sean de bajo costo
 Ejemplo
Capa Host: GAP
• Fitness tracker con un Smartphone
– Tracker es el Periférico GAP
– Smartphone es el Central GAP
– Los roles GAP no cambian
GAP Periférico
GAP Central
 GAP Operational Modes & Procedures

• Mode: Un "estado" al cual un dispositivo

puede cambiar para
– Alcanzar una meta, o,
– Permitir que un compañero realice un
"procedimiento“
• Procedure: Una secuencia de acciones para
alcanzar una meta, como
– Discovery, Connection Establishment
 Modes & Procedures
Capa Host: GAP
• Procedimientos GAP
• Modos GAP (Periféricos) (Centrales)
– Broadcast – Observation
– Non-discoverable – Limited-discovery
– Limited-discoverable – General-discovery
Discovery Options
– General-discoverable – Auto-connection
– Non-connectable – General-connection
– Directed-connectable – Direct-connection
– Undirected-connectable – Connection parameter
– Non-bondable update
– Bondable – Terminate connection
Connection Options
– Bonding
 Modos de “Discovery” & Procedimientos
Adecuados
• Manera en la cual el periférico anuncia su
presencia
– Y lo que el dispositivo Central puede/debe de
hacer con esa información

“Discovery” Modes Applicable Role Applicable Peer Procedure

Non-discoverable Peripheral N/A
Limited-discoverable Peripheral Limited and General-discovery
General-discoverable Peripheral General-discovery

Primera conexión
 “General-discoverable” Mode
- A Peripheral Mode -
• Este estado indica que el periférico quiere
ser descubierto por sus compañeros para
establecer una conexión
– El periférico manda paquetes ADV_IND
• Estado inicial predeterminado “de fábrica”
para un periférico
– Vuelve al modo "no detectable o non-
discoverable" después de un procedimiento de
unión (bonding) con un dispositivo central
 Modo Detectable General
Configuración Requerida del Periférico
• Tipo e intervalo de Advertising (ADV_IND
packet)
• Advertising payload
– Nombre Local
– UUID del Servicio
• (Opcional) Scan Response payload
– Poder TX
– Nivel de Batería
– Datos Personalizados
 Descubrimiento General
El Procedimiento del dispositivo Central
• Central empieza el escaneo sin filtro de lista
blanca
• Analiza las flags de tipo de paquete de
advertising recibidas
– Si son flags de Limited Discoverable o General
Discoverable, el dispositivo se reporta a la
aplicación para un analizis mas profundo
 Modos de “Conexión” & Procedimientos
Adecuados

• Manera en la que un dispositivo central

selecciona con qué periférico interactúa
– Proceso de 1 o 2 pasos
– Central-driven filtering
“Connection Applicable Role Applicable Peer Procedure
Establishment” Modes
Non-connectable Peripheral N/A
Undirected-connectable Peripheral General Connection Establishment
(2-Step) First-connection

Directed-connectable Peripheral Direct Connection Establishment (1-

Step) reconnect
 Establecimiento de una Conexión General

• Un procedimiento de 2 pasos
– Aceptar todos los paquetes ADV_IND
– Analizar los datos en el paquete ADV:
• Nombre, UUID, Datos, etc
– Conectarse usando el Procedimiento de Direct
Connection Establishment
 Direct Connection Establishment
Procedure
• Un solo paso
• Usando la dirección MAC obtenida de un
paquete ADV_IND o ADV_DIRECT_IND,
• Se inicia una conexión a un solo
dispositivo usando su dirección MAC
– Link Layer no sabe si el dispositivo está
disponible o si se puede conectar a el
 Parámetros de Conexión
• Establecidos por el Master durante el
establecimiento de la conexión
– Intervalo de Conexión
• Tiempo entre eventos de conexión
– Slave latency
• Número de eventos de conexión que el Slave puede
optar por omitir
– Supervision timeout
• Tiempo máximo entre dos paquetes validos recibidos
antes de que se le considere perdida a una conexión
 Agenda
• Fundamentales
• Arquitectura
– Capa Controller
– Capa Host
• Generic Access Profile (GAP)
– Lab1/2 – Averiguar y Establecer la Conexión
• Generic Attribute Profile (GATT)
– Lab 3 – Intercambio de Datos
• Resumen
Host Layer

GENERIC ATTRIBUTE PROFILE

(GATT)
 Generic Attribute Profile (GATT)

• Establece como se organizaran e

intercambiaran los datos en una conexión
– Algunos perfiles de casos específicos son
estandarizados por el BT SIG
• Perfil del Ritmo Cardiaco,
• Perfil de Proximidad
• Muchos otros definido por el SIG
 Generic Attribute Profile (GATT)

• Usa el Attribute Protocol (ATT) como un

mecanismo de transporte
• Es una forma de organizar los datos en bits o
‘atributos’ fáciles de transmitir
– Aspectos importantes de los atributos:
• Handle,
• Type (UUID)
• Permission
• Valor
 GATT Ejemplo
Periférico / Server Central / Cliente
BM70
[GAP Peripheral, GATT Server]
 Universally Unique Identifier
(UUID)
• Número de 128-bit (16-byte) único
globalmente
– Usado para identificar Perfiles, Servicios y
Tipos de Datos
– Hay una versión corta 16-bit (2-byte)
• Usada para los objetos definidos por el SIG
 GATT Roles

• Servidor
– Contiene los recursos (datos) que son
monitoreados
• Organizados como una Base de Datos de Atributos
– Recibe solicitudes del cliente y envia las
respuestas
– Típicamente asociado con el papel de periférico
GAP
 GATT Roles

• Cliente
– Averigua la presencia y naturaleza de los atributos
en el servidor
• Descubre los Servicios
– Envía peticiones a un servidor y recibe respuestas
– Típicamente asociado con el papel de Central GAP
 Atributo

• Una pieza de datos etiquetados y accesibles, o

metadata
– Contenida dentro de un Servidor
– Accedido por el Cliente
• Estructura de un Atributo:
 Handle del Atributo
• Identificador Único de 16-bits
– Hace que el atributo pueda ser acesible
– No cambia
• Los valores de los handles incrementan en una
secuencia ordenada en el servidor
– Se permiten huecos o brechas
• Los valores de estos handles son descubiertos por
el cliente cuando descubre los servicios
 Tipo de Atributo (UUID)

• Determina el tipo de datos presentes en el

"valor" del atributo
• Usa un universally unique identifier (UUID)
de 2/16-byte
– Formato de 2-byte (16-bit) usado para los
tipos, perfiles y servicios definidos por el SIG
– Formato de 16-byte (128-bit) requerido para
tipos, perfiles y servicios personalizados
 Valor del Atributo

• Guarda el contenido de los "datos"

– Accedido por un cliente
• También puede guardar “metadata” acerca
del atributo
– Depende del tipo
 Permisos
• Metadata del atributo que especifica:
– Las operaciones ATT permitidas en el Valor del
Atributo
• Access
– None, Readable, Writable, R+W
– Requisitos de Seguridad
• Cifrado (Encryption)
– Level required
• Autorización
– Yes/No
 Jerarquía de Atributos & Data
• GATT establece una GATT Server Profile

Service
jerarquía para organizar Characteristic

los atributos Declaration

Value

• Atributos en un perfil de Descriptor

…
servidor GATT se agrupan Characteristic

de la siguiente forma: Declaration

Value
– Servicios Descriptor
…
• Características …
– Atributo de Declaración
– Atributo de Valor Service
Characteristic
– Atributo de Descripción Declaration

Value
Descriptor
…
…
…
 Servicio
• Recopilación de datos y comportamientos para lograr
una función particular.
– Definidos por una Definición de Servicios
• (i.e. a collection of characteristic attributes)
• Los servicios primarios se descubren usando el
procedimiento de “GATT Primary Service Discovery”
• Servicios
– “Públicos”
• Definidos por BT SIG (16-bit UUID)
– “Privados”
• Definidos por el vendedor (128-bit UUID)
 Características

• Contenedores para los datos del usuario

– Contienen un mínimo de 2 atributos
• Declaración de la característica
• Valor de la característica
– Opcionalmente pueden contener un atributo
descriptor
• Metadata que expande la declaración
 Descriptores de (Características)
• Descriptores comunes definidos por GATT
– Extended Properties
– Characteristic User Description
– Client Characteristic Configuration Descriptor
(CCCD)
• Modificado por el cliente
• Actua como un switch para habilitar los updates
iniciados por el usuario
– Notificaciones
– Indicaciones
 SIG-Approved GATT UUIDs

• https://www.bluetooth.com/specifications/as
signed-numbers
– Std GATT Services, Attribute Types, Characteristic
Descriptors, Characteristic Types
– SIG-Defined GATT Services
– SIG-Defined GATT Characteristics
– SIG-DefinedGATT Descriptors
 Ejemplo de un Perfil GATT
Servicio de Ritmo Cardiaco
GATT Heart Rate Service

Handle Type (UUID) Value Permissions

Service
Declaration 0x8000 SERVICE (0x2800) 0x180D READ

Characteristic
Declaration 0x8001 CHAR (0x2803) NOT|0x8002|HRM READ
“Heart Rate
Measurement” Value 0x8002 HRM (0x2A37) bpm NONE

Descriptor
0x8003 CCCD (0x2902) 0x0001 READ/WRITE

Characteristic
Declaration 0x8004 CHAR (0x2803) RD|0x8005|BSL READ
“Body Sensor
Location”
Value 0x8005 BSL (0x2A38) 0x02 (Wrist) READ

Characteristic
Declaration 0x8006 CHAR (0x2803) WR|0x8007|HRC READ
“Heart Rate
Control Point”
Value 0x8007 HRC (0x2A39) 0xXX WRITE
LAB 2
INTERCAMBIO DE DATOS
 Objetivos del Lab 2

• Desplegar un Servicio GATT

– Ritmo Cardiaco en el RN4870
• Usar los comandos del Servidor GATT
– Actualizar las características en el tiempo de
ejecución (Servidor)
• Interactuar con una app (Cliente)
 Lab 2 Resumen

• Varios Servicios Publicos GATT están

disponibles para añadirlos a la GATT Table del
RN4870
• Perfiles se cargan al RN4870 usando los
comandos ASCII
 Agenda
• Fundamentos
• Arquitectura
– Capa Controller
– Capa Host
• Generic Access Profile (GAP)
– Lab1/2 – Averiguar y Establecer la Conexión
• Generic Attribute Profile (GATT)
– Lab 3 – Intercambio de Datos
• Resumen
RESUMEN & RECURSOS
ADICIONALES
 Resumen
• Hoy hemos introducido:
– Conceptos e implementación de Bluetooth LE
– Fundamentos del protocolo BLE
• GAP
• GATT
– Modulo BLE RN4870 & Herramientas de
Microchip
• Características
• Métodos para utilizarlas
www.microchip.com/developerhelp
 Libros Selecionados

“Bluetooth Low Energy: The Developer’s Handbook”

Robin Heydon, 2012

“Getting Started with Bluetooth Low Energy: Tools &

Techiques for Low Power Networking”
Kevin Townsend, 2014

“Essentials of Short Range Wireless”

Nick Hunn, 2010
¡Mil Gracias!
 LEGAL NOTICE
SOFTWARE:
You may use Microchip software exclusively with Microchip products. Further, use of Microchip software is subject to the copyright notices, disclaimers, and any license terms
accompanying such software, whether set forth at the install of each program or posted in a header or text file.

Notwithstanding the above, certain components of software offered by Microchip and 3 rd parties may be covered by “open source” software licenses – which include licenses that require
that the distributor make the software available in source code format. To the extent required by such open source software licenses, the terms of such license will govern.

NOTICE & DISCLAIMER:

These materials and accompanying information (including, for example, any software, and references to 3 rd party companies and 3rd party websites) are for informational purposes only
and provided “AS IS.” Microchip assumes no responsibility for statements made by 3rd party companies, or materials or information that such 3rd parties may provide.

MICROCHIP DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING ANY IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY, AND
FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL MICROCHIP BE LIABLE FOR ANY DIRECT OR INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, OR CONSEQUENTIAL LOSS, DAMAGE,
COST, OR EXPENSE OF ANY KIND RELATED TO THESE MATERIALS OR ACCOMPANYING INFORMATION PROVIDED TO YOU BY MICROCHIP OR OTHER THIRD PARTIES, EVEN IF MICROCHIP
HAS BEEN ADVISED OF THE POSSIBLITY OF SUCH DAMAGES OR THE DAMAGES ARE FORESEEABLE. PLEASE BE AWARE THAT IMPLEMENTATION OF INTELLECTUAL PROPERTY PRESENTED
HERE MAY REQUIRE A LICENSE FROM THIRD PARTIES.

TRADEMARKS:
The Microchip name and logo, the Microchip logo, AnyRate, dsPIC, FlashFlex, flexPWR, Heldo, JukeBlox, KEELOQ, KEELOQ logo, Kleer, LANCheck, LINK MD, MediaLB, MOST, MOST logo,
MPLAB, OptoLyzer, PIC, PICSTART, PIC32 logo, RightTouch, SpyNIC, SST, SST Logo, SuperFlash and UNI/O are registered trademarks of Microchip Technology Incorporated in the U.S.A.
and other countries.
ClockWorks, The Embedded Control Solutions Company, ETHERSYNCH, Hyper Speed Control, HyperLight Load, IntelliMOS, mTouch, Precision Edge, and QUIET-WIRE are registered
trademarks of Microchip Technology Incorporated in the U.S.A.
Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, BodyCom, chipKIT, chipKIT logo, CodeGuard, dsPICDEM, dsPICDEM.net, Dynamic Average Matching, DAM, ECAN, EtherGREEN,
In-Circuit Serial Programming, ICSP, Inter-Chip Connectivity, JitterBlocker, KleerNet, KleerNet logo, MiWi, motorBench, MPASM, MPF, MPLAB Certified logo, MPLIB, MPLINK, MultiTRAK,
NetDetach, Omniscient Code Generation, PICDEM, PICDEM.net, PICkit, PICtail, PureSilicon, RightTouch logo, REAL ICE, Ripple Blocker, Serial Quad I/O, SQI, SuperSwitcher, SuperSwitcher
II, Total Endurance, TSHARC, USBCheck, VariSense, ViewSpan, WiperLock, Wireless DNA, and ZENA are trademarks of Microchip Technology Incorporated in the U.S.A. and other
countries.
SQTP is a service mark of Microchip Technology Incorporated in the U.S.A.
Silicon Storage Technology is a registered trademark of Microchip Technology Inc. in other countries.
GestIC is a registered trademarks of Microchip Technology Germany II GmbH & Co. KG, a subsidiary of Microchip Technology Inc., in other countries.
All other trademarks mentioned herein are property of their respective companies.