Overview¶

mbed’s BLE roadmap covers two main issues: extending vendor support for BLE, and improving our implementation.

Vendor Support¶

We’re adding support of our BLE solution to more vendors, so that you can have a wider selection of platforms for your projects.

Implementation Improvement¶

We’re working on switching Bluetooth versions, and improving our implementations and methods.

Switching Bluetooth Versions¶

Top of our list of priorities for the coming releases is extending our BLE APIs to support Bluetooth 4.1 and 4.2. This is expected to bring several improvements:

• Support for multiple concurrent connections to the peripheral, and being able to act as a peripheral and central at the same time.

• Being able to advertise in connection mode.

• Being able to scan for advertisements from nearby peripherals.

• Low-power IP connectivity (IP over BLE).

To execute this, we'll gradually move to support Nordic’s and CSR’s 4.2 compatible SoftDevices.

Firmware Over the Air¶

Firmware Over the Air (FOTA) has been supported on our Nordic platforms for a while. We'd like to enhance our FOTA functionality with the following:

• Safety: it should be possible to ensure firmware updates are not applied unless they are built for the correct MCU/platform target.

• Security: it should be possible to authenticate and validate an update before applying it.

• Standardisation around the FOTA protocol.

• A generic boot loader to allow FOTA on platforms other than Nordic.

• An mbed iOS/Android reference application to drive FOTA seamlessly, offering a conduit between an online/offline build system and mbed targets. It should also be possible to target multiple devices concurrently.

• Core FOTA functionality of the mbed app should be extracted as an SDK to allow other user-specific implementations.

• Driving FOTA from a desktop (over a BLE dongle).

• A USB to SWD adaptor that can target nRF51822 boards that don't have an mbed CMSIS-DAP interface.

Peripherals as GATT Clients¶

Some services and applications, such as ANCS, are designed to keep the Central as a GATT server and the peripherals as Clients (in the case of ANCS as notification consumers). This requires GATT client extensions to be added to BLE_API, covering at the very least service and characteristic discovery together with reads, writes and notifications or indications.

Connection Handles in all Relevant API Calls¶

Even when acting as a peripheral, version 4.1 of the specification allows connections to multiple centrals. A connection handle is therefore required in most of the API calls that deal with link-specific things: disconnecting, data transfer, etc.

GAP: Security¶

Bonding and other security features.

Unit Testing¶

Create a unit-test framework to automate testing of BLE_API. This should be able to verify protocol correctness (to some reasonable degree), and also track any regressions in energy consumption when driving the BLE stacks. This validation suite could then become the basis for integrating future Bluetooth Smart stacks and radios with BLE_API.

GATT Standard Services¶

Add implementation for the following SIG-defined GATT services, and create demos for them:

• Alert Notification

• Blood Pressure

• Body Composition

• Bond Management

• Continuous Glucose Monitoring

• Current Time Service

• Cycling Power

• Cycling Speed and Cadence

• Environmental Sensing

• Glucose

• Human Interface Device

• Immediate Alert

• Location and Navigation

• Next DST Change

• Phone Alert Status

• Reference Time Update

• Running Speed and Cadence

• Scan Parameters

• Tx Power

• User Data

• Weight Scale

PTS Qualification¶

We'll invest in getting our services approved by the Profile Tuning Suite to assist our users in getting their devices certified by Bluetooth-SIG.

Interoperation with an RTOS¶

We'd like to create a few demos where our BLE framework lives alongside an RTOS.