Roadmap¶

In addition to adding support for BLE solutions from more vendors, we've got the following on our roadmap.

Switching to Bluetooth 4.1 and eventually to 4.2¶

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

• Low-power IP connectivity [IP over BLE].
• Support for multiple concurrent connections at the peripheral; and being able to act as a peripheral and central at the same time.
• Being able to advertise while still being in a connection.
• Being able to scan for advertisements from nearby peripherals.

To execute this, we'll move to support the S130 softdevice or whatever else Nordic's going to release to become compatible with BLE-4.2; and the same for CSR.

Firmware Over The Air¶

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

• Adding safety to FOTA; this means it should be possible to ensure firmware updates are not applied unless they are built for the correct MCU/platform target.
• Adding security to FOTA; which means that it should be possible to authenticate and validate the update before applying it.
• We want to develop standardization around the FOTA protocol.
• We would also like to create a generic bootloader 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.
• Being able to drive FOTA from a desktop (over a BLE dongle).
• We're working on releasing a USB->SWD adaptor which can target nRF51822 boards which don't have an mbed CMSIS-DAP interface.

Peripherals as GATT clients¶

Some services/applications, such as ANCS, are designed keeping the Central as a GATT server, and expecting the peripherals to act 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/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 to be enabled.

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 be the basis for

GATT Standard Services¶

Add implementation for the following SIG-defined GATT services; and create demos for them.

• Alert Notification Service
• 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 Service
• Phone Alert Status Service
• Reference Time Update Service
• 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.