Bluetooth® Low Energy Mesh - NXP Community

PUBLIC USE

Tudor Stănescu

Software Development Manager

FTF-HMB-N1963

16 May 2016

Simple and Easy to Use Low Power Wireless

Networking Protocol

Bluetooth® Low Energy Mesh

PUBLIC USE1 #NXPFTF PUBLIC USE1 #NXPFTF

AGENDA

• Introduction and Objectives

• Bluetooth LE Mesh Concepts and Use Cases

• The Mesh and the BLE Stack

• The Kinetis KW41Z Mesh

• Demo on KW41Z

• The Future of the BLE Mesh

PUBLIC USE2 #NXPFTF

Session Introduction

This session aims to familiarize attendees with the concept of Mesh over Bluetooth Low Energy, its applications, its implementation on Kinetis devices and what the future holds

• This presentation is relevant to all who want to develop Bluetooth LE-based connectivity and Internet of Things (IoT)-enabling applications or add connectivity capabilities to existing designs:

− This presentation is important because it shows how BLE Mesh technology can better serve IoTand connectivity use cases.

− The attendees will be become familiar with the Kinetis Bluetooth LE and Mesh technology, gaining a great starting point in their application and product development.

• Presenter: Tudor Stănescu – manager of the Kinetis Bluetooth and IEEE® 802.15.4 software team ([email protected]).

• Time allocated to this presentation is 1 hour. Questions will also be during the session itself.

mailto:[email protected]

PUBLIC USE3 #NXPFTF

Session Objectives

• After completing this session you will be able to:

− Gain an understanding of the BLE mesh concepts and their applicability in commercial

solutions

− Gain knowledge of how an existing BLE implementation can be complemented with Mesh

capabilities

− Appreciate the advantages and ease of use of the KW41Z BLE Mesh solution

− Understand what the future for the BLE mesh technology looks like and the impact on the

market

PUBLIC USE4 #NXPFTF

BLE MESH

CONCEPTS AND USE

CASES

PUBLIC USE5 #NXPFTF

A Bit of History

2010

Bluetooth v4.0 core specification was ratified, containing the first LE volume

2013

Bluetooth v4.1 brought in L2CAP credit-based channels

2014

Cambridge Silicon Radio announced the “CSR Mesh”, the first implementation of a flood

mesh over BLE advertising channels

2015

The Bluetooth Special Interest Group (SIG) announces the formation of the “Bluetooth

Smart Mesh” working group aimed at standardizing mesh networking over BLE

2015

Bluetooth v4.2 brought in enhanced security and privacy plus data packet length extension

PUBLIC USE6 #NXPFTF

Where Bluetooth LE Stops and the Mesh Starts

• Two states of a device: advertising and connected

• Topology: point-to-point or at best star

• Range: line of sight: protocol allows a datagram to be exchanged by two neighbor devices

• A single state of a device: advertising

• Topology: flooded mesh

• Range: configurable: protocol allows datagram to be relayed as many times as desired

Bluetooth LE Bluetooth LE Mesh

PUBLIC USE7 #NXPFTF

The Need and the Motivation for Mesh Development (1)

“Range Limitation? What Range Limitation?”-Martin Woolley, Technical PM, Bluetooth SIG

PUBLIC USE8 #NXPFTF

The Need and the Motivation for Mesh Development (2)

• Bluetooth LE has become ubiquitous, however:

− it’s point-to-point

− it’s short range

• The low power, interoperability and the low cost implementation brought in by BLE need to be leveraged in use cases with a multitude of nodes that need to communicate amongst themselves over large areas

• The obvious way to do that is a Mesh and the simplest way to implement it is flooding

• The existing hardware implementations needn’t change. Mesh is purely software.

PUBLIC USE9 #NXPFTF

• The reference use case for the Bluetooth Mesh standard is Home

Automation

• Typical profiles: Lighting, Security, HVAC (Heating, Ventilation

and Air Conditioning)

• Future Bluetooth versions will allow for increased payloads such

that IPv6 packets can be encapsulated over Bluetooth Mesh

Bluetooth Mesh – Use Cases

PUBLIC USE10 #NXPFTF

THE MESH AND THE

BLE STACK


BLE System Architecture

Generic Access Profiles (GAP) – what we can do…

Generic Attribute Profile (GATT) – how things are organized

Attribute Protocol (ATT) – protocol for accessing data

Security Manager (SM) – secures data

Logical Link Control and Adaptation Protocol (L2CAP) – multiplex logical to physical links

Host Controller Interface (HCI) – interface between Host and Controller

Link Layer (LL) – packets and control

Physical Layer (PHY) – transmits/receives bits

Physical Layer

Link Layer

HCI

L2CAP

Attribute

Protocol

Security

Manager

Generic

Attribute

Profile

Generic

Access

Profile

He

art

Ra

te

Pro

file

Blo

od

Pre

ss

ure

HID

Application

…

Host

Controller


Mesh System Architecture

• The Mesh uses only ADV packets

configured via GAP

• Special device cases (proxies) can use

connection intervals over a GATT custom

profile to interoperate with “legacy” handsets

with no native Mesh support in the stack.

• Security features involve BLE v4.2 LE

Secure Connections for commissioning

• Standard GATT peripheral profiles are not

typically used in Mesh applications

Mesh

Infra

stru

ctu

re

Physical Layer

Link Layer

HCI

L2CAP

Attribute

Protocol

Security

Manager

Generic

Attribute

Profile

Generic

Access

Profile

Host

Controller

Core Mesh

Functionality

Mesh Application


THE KINETIS KW41Z

BLE MESH


Kinetis KW41Z/31Z/21Z

Core/Memory/System• Cortex-M0+ running up to 48 MHz

• Up to 512 kB Flash

• Up to 128 kB SRAM

• Four independently programmable DMA controller channels

Radio• Support for BLE v4.2, 802.15.4-2011

• -96 dBm in BLE mode, -102 dBm in 802.15.4 mode

• -20 to +4 dBm programmable output power

• Increased coexistence performance

• 6.2 mA Rx & 6.0 Tx (0dBm) current target (DC-DC enabled)

• <2uA low power current

• Integrated balun (~9% board area savings)

Communications/HMI/Timers• 2xSPI, LP-UART, 2xI2C, CMT, GPIO with IRQ capability (KBI)

• Hardware Touch Sensing Inputs (TSI)

• 3xFlexTimer (TPM) with PWM & quadrature decode support

• Low Power (LPTMR), Programmable Interrupt (PIT) and RTC timers

Analog• 16-bit ADC with integrated temperature sensor and battery monitor

• 12-bit DAC and 6-bit High-speed Comparator

Security• AES Accelerator and True Random Number Generator

Integrated DC/DC Converter• Normal: 1.71V to 3.6V

• Buck : 2.1V to 4.2V for coin cell operation

• Boost : 0.9V to 1.795V for single alkaline battery operation

Unique Identifiers• 80-bit device ID programmed at factory

• 40-bit unique number can be used for Bluetooth Low Energy or IEEE 802.15.4 MAC Address

-40ºC to +85ºC

Memories TransceiverSystemCore

Analog

Clocks

Security

CommunicationsTimers

AES-128

True Random Number

Generator

2xSPI

2xI2C

PA / LNA

Control Registers

Internal and External Watchdogs

DMA

Phase-Locked Loop

Internal Reference Clocks

Low / High Frequency Osc.

Low Leakage Wake-Up Unit

FlexTimers

Programmable Delay Block

Independent Real Time Clock

Periodic Interrupt Timers

Low Power Timer

ARM Cortex-M0+48 MHz

Debug Interfaces

Interrupt Controller

Up to 512 kB Flash

Up to 128 kB SRAM

16-bit ADC

12-bit DAC

DC-DC Converter

LPUART

GPIO w/ IRQ Capabilities

Frequency Locked Loop

BLE 4.2 & 802.15.4 radio

Baseband IP

6-bit ACMP

TSI

CMT


Kinetis KW41Z Complete BLE Environment

Profile and Application

Bluetooth LE Host Stack

Connectivity Framework

RTOS

Kinetis SDK

KW41Z MCU

HCI

Bluetooth Link Layer Firmware

Bluetooth PHY

Bluetooth Link Layer Hardware

Highlights:• Bluetooth LE GATT profiles and demo

applications

• Implementation of the Bluetooth LE host specification v4.2

• Host Controller Interface (HCI) layer with software or UART transport options

• Connectivity Framework middleware collection

• Bluetooth LE Link Layer firmware library that interacts with the corresponding hardware.

• Kinetis SDK v2.0 driver support for KW41Z

• RTOSes available in Kinetis SDK: FreeRTOS, uCOS/II and bare-metal non-preemptive scheduler.

• Applications and library support for IAR Embedded Workbench and Kinetis Design Studio (gcc).

PUBLIC USE16

WHAT CAN THE MESH DO?


Kinetis Bluetooth LE Mesh Capabilities (1)

▪ Full-featured flood-based mesh solution

▪ An optimization of the flood and replay protection techniques has been

enclosed in a patent application, filed in 4Q2015

▪ Data transmissions can be unicast or multicast/broadcast, reliable

or unreliable, and based on the publish-subscribe paradigm

▪ Architecture relies mainly on the Advertising Bearer

▪ For legacy devices (e.g. smartphone that cannot advertise), a

second, GATT-based Bearer is provided

▪ Proxy devices are used to ensure legacy access in the network

▪ Smartphones are very well suited as Commissioning Devices

▪ Creating and adding devices to a Bluetooth Mesh network is an easy

process requiring minimal user intervention



▪ Commissioning Procedure uses Bluetooth 4.2 LE Secure Connections

security -Elliptic Curve Diffie-Hellman (ECDH) on P-256

▪ Mesh packets are protected by AES128-CCM encryption

▪ KW40Z/KW41Z platforms feature hardware acceleration for AES128

▪ Periodic Security Updates are triggered and propagated autonomously in the

network

▪ Key Refresh Procedures can be triggered by the Commissioner, allowing a

network to be fully re-provisioned without further user intervention

▪ This procedure also supports blacklisting of devices that are considered unsafe

▪ 2 patent disclosures are pending for filing; they contain optimizations of the Key

Refresh Procedure for mesh networks that may be applied to a Bluetooth Mesh

implementation



• Battery-powered devices can implement the Leaf Node role to save

energy

• Leaf Nodes can autonomously associate themselves with a neighboring

mains-powered Relay that can cache packets and security updates for

them

• Leaf Nodes may sleep most of the time and only wake up periodically to

receive updates from their associated Relays



• Software solution code sizes (current estimations, not final)

− Bluetooth Mesh memory overhead in a typical application

▪ 15-20 kB of Flash

▪ 2-3 kB of RAM

− Full application firmware (including RTOS & drivers) with Mesh support (un-optimized)

▪ 100-120 kB of Flash

▪ 15-20 kB of RAM

• Per-hop latency

− ~37 ms

• Data throughput (over advertising channels, 1 hop)

− ~26 kbps

• Maximum number of hops

− Max TTL: 63

PUBLIC USE21

HOW DOES THE MESH DO IT?


• The Bluetooth Mesh network is designed to function primarily on the Bluetooth Low Energy Advertising Channels (BLE ADV)

• Devices in range exchange information by placing it in the Advertising Data, eliminating the need for connections

− Reduces power consumption and latency

• GATT Connections are still supported by some nodes (called Proxies) to allow legacy smartphone access into the network

• A BLE device can be part of more than one Mesh Network at the same time

Kinetis Bluetooth LE Mesh Network Functionality (1)


• Mesh Packets are contained in an Advertising Data Structure with the Manufacturer Specific Advertising Data (AD) Type (0xFF) and NXP’s Company Identifier

• All BLE devices in range that are scanning can receive the Mesh Packet.

• The Mesh Packet header contains a source address, a destination address and a TTL field

• The network is based on a flooding mechanism – mains-powered devices retransmit (relay) all incoming packets (after security checks) unless the destination is their own unicast address

• Mesh routing is being explored to reduce the network traffic



• The Bluetooth Mesh Network defines two topological roles:

− Leaf Nodes

▪ Nodes that never relay packets, but only generate and/or process them

▪ Typically these are battery-powered devices that require an association with a Relay Node to be able to effectively participate in the network

▪ Examples: an energy-harvesting switch, a temperature sensor

− Relay Nodes

▪ Nodes that, in addition to generation and consumption of packets, also perform the retransmissionsrequired by the mesh network

▪ Typically there are mains-powered devices

▪ Examples: a light-bulb, a power socket


Relay

Leaf


Kinetis Bluetooth LE Mesh Network Packet Flooding

3

1

6

5

4

7

2

[1,7,4]

SRC = 1

DST = 7

TTL = 4 DST=7

X

X

[1,7,3]

X

[1,7,3]

[1,7,2]

[1,7,2]

Relay

Leaf


Kinetis Bluetooth LE Mesh Packet

AD

Length

Company

Identifier

AD

Type

AD

Header0xBA Mesh Packet

ADV_NONCONN_IND

• Encapsulated in a non-connectable advertising packet


Mesh Packet Format - Encrypted

Encrypted

Network Header

Encrypted

Data PayloadMIC

• Encrypted Network Header – 7 bytes

• Encrypted with AES128-ECB

• Uses

• HeaderEncryptionKey (HEK)

• EncryptedDataPayload as randomization input

• Payload – 2-15 bytes

• Encrypted with AES128-CCM, generating 4-byte MIC

• Uses

• PayloadEncryptionKey (PEK)

• Network Header (Plain) as Nonce


Mesh Packet Format – Decrypted Header

Network Header Data Payload

SPC TTLADD

• Network Header – 7 bytes

• ADD – Addressing Information (4 bytes)

• SPC – Source Packet Counter (2 bytes)

• TTL – Time To Live (6 bits)

• FRAG – Fragmentation Flags (2 bits)

FRAG


Mesh Packet Format – Decrypted Payload

Data Payload

• Profile ID (PID) – 1 byte

• Identified the Mesh Profile, e.g.:

• Lighting

• Security

• GATT

• Profile Data – 1-14 bytes

• Profile-specific format, e.g., opcodes, parameters etc.

Profile DataPID

Network Header

PUBLIC USE30

COMMISSIONING


• Commissioning is the process of bringing a new device into the Bluetooth Mesh Network

• A device that is capable of commissioning a new device in the network is called Commissioner Node or, simply, Commissioner

• There can be multiple Commissioners in a certain Network

• Commissioning is a process performed in two phases:

1. Commissioning Link Establishment

▪ Consists of creating a secure link between the Commissioner and the new device

2. Network Credentials Distribution

▪ Consists of the distribution of the network security credentials from the

Commissioner to the new device over the secure link

Kinetis Bluetooth LE Mesh Commissioning



a) The new device advertises a Mesh Commissioning Broadcast packet.

b) The Commissioner connects to the new device.

c) The Commissioner starts LE Secure Connections Pairing with bonding enabled.

d) Pairing must complete with MITM protection. The generated LTK is stored on the Commissioner Node as Mesh Node Key for this device.

Commissioning – Link Establishment



a) The new device advertises a Mesh Commissioning Broadcast connectable packet

Commissioning – Link Establishment

AD

Length

Company

Identifier

AD

Type

AD

Header0xBB

Device

CapabilitiesADV_IND


2. Network Credentials Distribution

− Once the link has been encrypted, the Commissioner distributes the following data to the new node:

▪ Address

▪ Network Key

▪ Security Information

− The data is distributed using the Mesh Commissioning GATT Service located on

the new device, which contains the Mesh Commissioning Characteristic

− The Commissioner acts as GATT Client and sends Write Without Response

packets containing the data to be distributed.

Commissioning - Network Credentials Distribution

PUBLIC USE35

EXTRAS


− Over-the-Wire Firmware Upgrade through the Mesh:

▪ Any node from the Mesh needs to be upgradable with a firmware

image sent over the air through the Mesh from other nodes not in

line of sight

▪ Multiple nodes need to be upgraded simultaneously

▪ Kinetis KW41Z Mesh solution will provide the application framework

on top of the Mesh to achieve OTA upgrades

Complementary Features for the Kinetis Mesh Solution


BLE MESH DEMO ON

KINETIS KW41Z


Demo Scenario – Light Profile

5-9

1-4

Relay - Light

Leaf - Switch

0 Commissioner

6

1

7 8

2

9

5

0PCUART

3 4


Light Profile Associations

• Publish-Subscribe Model• Switch publishes Light Commands to a Group Address

• A Light subscribes to a Group Address in order to process Light

Commands on that address

• All Lights are subscribed to the Broadcast Address (0x0FFF)

Switch

ID

Publish

Address

1 0x0801

2 0x0802

3 0x0803

4 0x0804

Light ID Default Subscription List

5 0x0801, 0x0802, 0x0804

6 0x0801, 0x0803, 0x0804

7 0x0801, 0x0802, 0x0803,

0x0804

8 0x0802, 0x0804

9 0x0803, 0x0804



5-9

1-4

Relay - Light

Leaf - Switch

0 Commissioner

6

1

7 8

2

9

5

0PCUART

3 4

Group 1 – Address 0x8001



December 18

5-9

1-4

Relay - Light

Leaf - Switch

0 Commissioner

6

1

7 8

2

9

5

0PCUART

3 4




5-9

1-4

Relay - Light

Leaf - Switch

0 Commissioner

6

1

7 8

2

9

5

0PCUART

3 4




5-9

1-4

Relay - Light

Leaf - Switch

0 Commissioner

6

1

7 8

2

9

5

0PCUART

3 4




5-9

1-4

Relay - Light

Leaf - Switch

0 Commissioner

6

1

7 8

2

9

5

0PCUART

3 4

Broadcast – Address 0x0FFF


Packet Relay Example

5-9

1-4

Relay - Light

Leaf - Switch

0 Commissioner

9

1

5

6

2

7

8

X

X

X

0PCUART

3X

X

!

!

!


Demo Scenario – Temperature Profile

5-6 Temperature Sensor

0 Commissioner

6

1

7 8

2

9

5

0PCUART

3 4

Temp

Sensor ID

Publish

Address

5 0x0905

6 0x0906

• The Commissioner is

subscribed to both

Temperature Sensor Reports

“Inside Temperature”

“Outside Temperature”


Demo Setup – Types of Nodes

Leaf Node - Switch

• Generates Light Toggle commands on button

press

• By default, does not relay packets

• Default TTL is 5

• Can receive Publish Set/Get commands for

read/write access to the Publish Address

• Publish Address is set as DST in the Light

Toggle packets

Relay Node - Light

• Light State indicated by LED array

• Can received Light Toggle commands

• By default, they relay packets

• Can receive Subscription List

Add/Remove/Get commands for

read/write access to the Subscription List

• Only accept Light Toggle commands with

DST equal to an address from the

Subscription List

Commissioner Device

• Connected to PC via UART

• Exposes terminal logs and accept

commands

• Sends Mesh Configuration

commands

• Receives Mesh Status responses

and updates

• Identified on terminal with ID=0

x x 0

Hardware – All Nodes

• FRDM-KW41Z

• Adafruit NeoPixel LED Shield

• Adafruit PowerBoost 500 Battery Shield


Light Profile – Switch Device

1

• Switch Device – Light Blue ID

• Push button publishes Toggle Light command


Light Profile – Light Device

5

• Light Device

• OFF – Red ID only

• ON – Red ID on White Background

• Relay Indicator - Green

OFF ON


• help

− List of commands

• status

− Get network status of device (ID, TTL, relay state)

• pub get/set

− Get/set Publish address for a Switch

• sub get/add/rem

− Get/edit Subscription List for a Light

• rel get/set

− Get/set Relay State

• ttl get/set

− Get/set TTL

Network configuration using terminal

0PCUART

• Terminal commands

are translated into

Mesh Configuration

Model commands that

are sent over-the-air by

the Commissioner

towards Mesh Nodes

• When Commissioner

receives status

messages over-the-air,

it sends logs to the

terminal


• light on / off / toggle

− light on ID

▪ Light ON command is sent to Light

ID

− light on

▪ Light ON command is broadcasted

to all Lights

− light off, light toggle

▪ Same as light on

Network configuration using terminal

0PCUART

• Some commands send

Light messages directly

to the lights


Example Configuration - Switch

10PCUART

Configure Publish address to 2500 (0x09C4):

• pub set 1 2500

Will respond with Publish Status

Set Publish Address

Publish Status


Example Configuration - Light

0PCUART

Add address 2500 (0x09C4) to Subscription List

• sub add 5 2500

Will respond with Subscription List

Subscribe to Address

Subscription List5


Toggle Light

0PCUART

1Push buttonToggle Light

Light Status

5

1. From Switch:


Toggle Light

0PCUART

Toggle LightToggle Light on Light 5

• light toggle 5

5Light Status

2. From Console:


THE FUTURE OF THE

BLE MESH


So What’s Missing?

Integration with Existing Networks

Internet Protocol (IP) v6 is everywhere

IP addressing in the BLE Mesh is a natural step

Multi-protocol gateways can make every BLE device addressable via the Internet

Routing protocols within a BLE Mesh network would improve efficiency compared to flooding

Throughput

ADV PDUs have small payloads which can encapsulate little information

Data rate of the physical layer (PHY) is only 1Mbps

Even more range keeping a low power consumption

The mesh transcends the concept of low range of BLE and given longer point-to-point range

can target new applications and markets, where ultra long range is needed (Smart Cities)

Standardization or rather ratification and public availability

The v1.0 specification will be ratified by the Bluetooth SIG and thus interoperability ensured.

Kinetis KW41Z will be launched with a fully compliant and interoperable BLE Mesh.

Post-v1.0 specifications will aim to address all 3 points above.


ATTRIBUTION STATEMENT

NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, CoolFlux, EMBRACE, GREENCHIP, HITAG, I2C BUS, ICODE, JCOP, LIFE VIBES, MIFARE, MIFARE Classic, MIFARE

DESFire, MIFARE Plus, MIFARE FleX, MANTIS, MIFARE ULTRALIGHT, MIFARE4MOBILE, MIGLO, NTAG, ROADLINK, SMARTLX, SMARTMX, STARPLUG, TOPFET, TrenchMOS, UCODE, Freescale,

the Freescale logo, AltiVec, C 5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C Ware, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert,

QorIQ, QorIQ Qonverge, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit, BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine,

SMARTMOS, Tower, TurboLink, and UMEMS are trademarks of NXP B.V. All other product or service names are the property of their respective owners. ARM, AMBA, ARM Powered, Artisan, Cortex,

Jazelle, Keil, SecurCore, Thumb, TrustZone, and μVision are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. ARM7, ARM9, ARM11, big.LITTLE, CoreLink,

CoreSight, DesignStart, Mali, mbed, NEON, POP, Sensinode, Socrates, ULINK and Versatile are trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. Oracle and

Java are registered trademarks of Oracle and/or its affiliates. The Power Architecture and Power.org word marks and the Power and Power.org logos and related marks are trademarks and service marks

licensed by Power.org. © 2015–2016 NXP B.V.

Documents

Bluetooth® Low Energy Mesh - NXP Community