Introducción a Introducción 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
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®
RN41 / 41N Type
Class 1 Bluetooth 2.1
RN42 / RN42N Class 2 Bluetooth 2.1
BM70/71 RN4870/71
BM78 RN4678
Bluetooth LE 4.1
Bluetooth LE 4.2
Bluetooth 4.2 Dual Mode (Classic & LE)
RN4020
Interfaces
UART / USB
UART
UART
UART
Profiles/ Protocols
SPP / HID / iAP / HCI
GATT / Health, Fitness / Proximity, Etc. / Custom data
GAP / SDP / SPP / GATT
GAP / SDP / SPP / GATT/iAP2
1.8-3.6V
1.9-3.6V
3.3-4.2V
PCB
Ceramic chip Antenna Or RF pad for external
Ceramic chip Antenna Or RF pad for external
11.5 x 19.5 x 2.5
BM70: Shield/Unshield 22 x12x2.4/ 15x12x1.6 BM71:Shield/Unshield 11.5x9x2.1/ 6x8x1.5
Shielded: 22 x 12 x 2.4 Unshielded: 15x12x1.8
FCC / IC/ CE / AUS / JP / Korea / Taiwan
FCC,IC,CE,NCC,KCC, MIC(Japan)
FCC,IC,CE,NCC,KCC, MIC(Japan)
Power
Antenna
3.0-3.6V Ceramic chip Antenna Or no Antenna
3.0-3.6V PCB Antenna or no Antenna
Size (mm)
13.4 x 25.8 x 2.0
RN42: 13.4x25.8x2.4 RN42N: 13.4x20.5x2.4
Certification
FCC / IC/ CE / AUS / JP
FCC / IC/ CE / AUS / JP / Korea / Taiwan
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 Services
Supported
Supported
Operation
UART Data Frame Binary Commands
ASCII 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 •
–
Módulos Certificados •
–
SPI o UART 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 Bluetooth
User Data
UART
Hello!
Bluetooth Interface
Bluetooth Module
$$$
Command Mode
$$$ Remote console
Host
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 UART
Scripting Engine BT Stack
Remote Console •
La consola remota es una característica 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 periféricos remotos Ejemplos de uso: •
RN4870 sin Host MCU UART
or UART
Easy configuration by remote console
Popular Beacon •
Definir parámetros parámetros clave con un solo comando •
•
Se configura fácilmente a otros formatos beacon •
•
advertisement & scan response payload 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 Discover App: iOS & Android* BLE Sensor App: iOS
Potentiometer
Switch
LED
DIPSwitch
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# 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Details BM70BLES1FC2 module Power On Push button SPI interface header pins GPIO interface header pins connecting to the GPIO pins of the MCP2200 USB-UART Header pin connections LED and LED Power connection header Header pins for selecting power source Reset pin Push button for testing and evaluation Header pins for Vbat voltage Header pins for connecting push buttons in section #9 I2C connection header DIP switch for switching between App mode and Firmware/Parameter Update mode LEDs with corresponding header pins for testing and evaluation Header pins connected to Ground testing/evaluation 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) SW5
3.3V
3.3V
VDD
(RN4770-PICtail™ Plus) 3.3V
RST_N SW7
VBAT
P2_0/SYSTEM_CONFIG
Module Control 3.3V
Module Status
Command & Data I/F GND
P0_2/LED0
UART_RX
UART_TX
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) –
•
Generic Attribute Profile (GATT) –
•
Lab1/2 – Averiguar y Establecer la Conexión 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 •
–
Connection-less MAC asincrónico •
•
–
latencia baja transacciones rápidas (3 ms de principio a fin)
Nueva Generic Attribute Profile •
–
mejora la facilidad de descubrimiento y conexión
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 •
•
•
Asimetría –
•
Paquetes de tamaño pequeño Minimizar el ciclo de trabajo y la latencia
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” 31.5o C
12:06 am 44.5 km/hr
PLAY
Gate 25 BOARDING
BT LE Stack Application Layer (App)
Generic Access Profile (GAP)
Security Manager (SMP)
Application
Generic Attribute Protocol (GATT) 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) –
•
Generic Attribute Profile (GATT) –
•
Lab1/2 – Averiguar y Establecer la Conexión 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
2400
2410
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
2420
2430
2440
Frecuencia (MHz)
2450
2470
2460 Data
A dver tis ing
2480
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
2400
2410
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
2420
2430
2440
Frecuencia (MHz)
2450
2470
2460 Data
2480
802.11 Superposición (WiFi) Capa Controlador: Capa Física 2.4 GHz BLE PHY Canales vs. IEEE 802.11 WiFi (EEUU)
2412 Channel 1
Ch: 37 0
1 2 3 4 5
2400
2410
6 7
2437 Channel 6
2462 Channel 11
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
2420
2430
2440
2450
2470
2460 Data
Frecuencia (MHz)
A dver tis ing
2480
Controller Layer
LINK LAYER
Roles •
Conexión Unicast (peer-peer) –
Antes/Durante la Conexión •
•
–
Después de la Conexión •
•
•
Advertiser Scanner, Initiator Slave Master
Conexión Broadcast –
–
Broadcaster Observer
Roles (Unicast) Host A
Host B
Scanner
Unassigned/ Standby
Advertiser ADV_IND: Ch37 ADV_IND: Ch38
Discovery ADV_IND: Ch39
Initiator
. . .
Advertiser
ADV_IND: Ch38
Connecting
CONNECT_REQ: Ch38
GAP “Central” Role GATT “Client” Role
Master
. . .
Slave
DATA_TX: Ch11 DATA_RX: Ch11
time
. . .
GAP “Peripheral” Role GATT “Server” Role Connected
Roles (Broadcast) Host xxx
Host A
Observer
Observer
Unassigned/ Standby
Host B
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 Initiating Scanning Connected
Scanning
Advertising
Standby
Initiating
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 •
–
Scanning PDUs •
–
ADV_IND**, ADV_DIRECT_IND, ADV_NONCONN_IND**, ADV_SCAN_IND** SCAN_REQ, SCAN_RSP
Initiating PDUs •
CONNECT_REQ
** Available
for 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 38
Scanning: Ch 37
Scanning: Ch 39
Scanner
0 ms
25 ms
50 ms
40 ms
60 ms
75 ms
100 ms
125 ms
Advertiser
0 ms
20 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 Address
AD Length
AD 0 Structure
AD Type
…
AD N Structure
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
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
•
ADV_DIRECT_IND (connectable, directed) –
–
•
Peer MAC Address
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 24bit 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 datos entre uno o más Slaves BM70 apoya 1 conexión
Slave
Slave solo puede pertenecer a 1 Piconet
Master
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) –
•
Generic Attribute Profile (GATT) –
•
Lab1/2 – Averiguar y Establecer la Conexión 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 –
•
–
Modos de Funcionamiento •
–
Broadcaster, Non discoverable, limited discovery, general discovery, non connectable, any connectable.
Procedimientos Operacionales •
–
Broadcaster, Observer, Central, Peripheral
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 Central
GAP Periférico
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 •
Modos GAP (Periféricos) –
–
–
–
–
–
–
–
–
Broadcast Non-discoverable Limited-discoverable General-discoverable Non-connectable Directed-connectable Undirected-connectable Non-bondable Bondable
•
Procedimientos GAP (Centrales) –
–
–
Dis covery Options
–
–
–
–
–
Connection O ptions
–
Observation Limited-discovery General-discovery Auto-connection General-connection Direct-connection Connection parameter update Terminate connection 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 nondiscoverable" 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 Applicable Role
Applicable Peer Procedure
Non-connectable
Peripheral
N/A
Undirected-connectable
Peripheral
General Connection Establishment First-connection (2-Step)
Directed-connectable
Peripheral
Direct Connection Establishment (1Step) reconnect
“Connection
Establishment ” Modes
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) –
•
Generic Attribute Profile (GATT) –
•
Lab1/2 – Averiguar y Establecer la Conexión Lab 3 – Intercambio de Datos
Resumen
Host Layer
GENERIC ATTRIBUTE PROFILE (GATT)
Generic Gener ic Attribute Profile (GATT) (GATT) •
Establece como se organizaran e intercambiaran los datos en una conexión –
Algunos perfiles de casos específicos son estandarizados estandarizados por el BT SIG •
•
•
Perfil del Ritmo Cardiaco, Cardiaco, Perfil de Proximidad Proximidad Muchos otros definido por el SIG
Generic Gener ic Attribute Profile (GATT) (GATT) •
•
Usa el Attribute Protocol (ATT) como un mecanismo de transporte Es una forma de organizar los datos en bits o ‘atributos’ ‘atributos’ fáciles de d e transmitir Aspectos importantes de los atributos: –
•
•
•
•
Handle, Type (UUID) Permission Valor
GATT Ejemplo Periférico / Server BM70 [GAP Peripheral, GATT Server]
Central / Cliente
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 –
–
•
Los valores de los handles incrementan en una secuencia ordenada en el servidor –
•
Hace que el atributo pueda ser acesible No cambia
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 jerarquía para organizar los atributos Atributos en un perfil de servidor GATT se agrupan de la siguiente forma: –
GATT Server Profile Service Characteristic Declaration Value Descriptor … Characteristic Declaration Value
Servicios •
Descriptor … …
Características –
–
–
Atributo de Declaración Atributo de Valor Atributo de Descripción
Service Characteristic 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
Declaration
0x8000
SERVICE (0x2800)
0x180D
READ
Declaration
0x8001
CHAR (0x2803)
NOT|0x8002|HRM
READ
Value
0x8002
HRM (0x2A37)
bpm
NONE
0x8003
CCCD (0x2902)
0x0001
READ/WRITE
Declaration
0x8004
CHAR (0x2803)
RD|0x8005|BSL
READ
Value
0x8005
BSL (0x2A38)
0x02 (Wrist)
READ
Declaration
0x8006
CHAR (0x2803)
WR|0x8007|HRC
READ
Value
0x8007
HRC (0x2A39)
0xXX
WRITE
Service
Characteristic “Heart Rate Measurement”
Descriptor
Characteristic “Body Sensor Location”
Characteristic “Heart Rate Control Point”
LAB 2
INTERCAMBIO DE DATOS
Objetivos del Lab 2 •
Desplegar un Servicio GATT –
•
Usar los comandos del Servidor GATT –
•
Ritmo Cardiaco en el RN4870 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) –
•
Generic Attribute Profile (GATT) –
•
Lab1/2 – Averiguar y Establecer la Conexión 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!