Mistake on this page? Email us

System context

The BLE Host software system consists of two main components:

The software system is dependent on WSF and PAL. WSF is an OS porting layer. It provides general-purpose software services such as queues, timers, and buffer management. PAL is the hardware platform abstraction layer. It provides the platform specific implementation to the hardware's BSP libraries.

System Configuration

The Cordio Stack and Profiles are designed to support single-chip SoC systems and dual-chip systems.

When operating in a single-chip system the Cordio Stack and Profiles run on the processor inside the SoC. A "thin" HCI layer adapts to the software interface of the target’s BLE Link Layer.

When operating in a dual-chip system the Cordio Stack and Profiles run on a microcontroller and communicate with a BLE Controller chip over a wired interface such as UART or SPI. A standard transport-based HCI layer manages the communication between the two devices.

Figure 2-1. Cordio Stack and Profiles in a single-chip SoC system and dual-chip system

Cordio Profiles

Arm's Cordio Profiles consists of Sample Application, interoperable Bluetooth Profiles and Services components and an Application Framework for simplified application development and porting.

Figure 2-2. Cordio Profiles software system

For more information see Cordio Profile Developer's Guide.

Sample Applications

Arm’s Bluetooth Low Energy sample applications provides example source code for products such as a proximity keyfob, health sensor, and watch. The sample applications are designed with a product-oriented focus, with each application supporting one or more BLE profile. The sample applications interface to the Profiles and Services and the Application Framework.

Profiles and Services

The profiles and services are interoperable components designed to Bluetooth profile and service specification requirements. The profiles and services are used in applications to implement particular profile and service features.

The profiles are implemented in separate files for each profile role. The services, however, may be grouped together in files based on their logical function and the profile they are used by.

Application Framework

The Application Framework performs many operations common to BLE embedded applications, such as:

  • Application-level device, connection, and security management.
  • Simple user interface abstractions for button press handling, sounds, display, and other user feedback.
  • An abstracted device database for storing bonding data and other device parameters.

Figure 2-3. Application Framework software subsystem

The Application Framework consists of several modules, each with their own API interface file:

  • Main: Device, connection, and security management.
  • UI: User interface abstraction.
  • DB: Device database.
  • HW: Hardware sensor interface abstraction.

Cordio Stack

The Cordio Stack is complete host protocol stack solution for single-mode BLE devices. It consists of five protocol layers:

  • ATT: Attribute protocol.
  • SMP: Security manager protocol.
  • L2C: L2CAP protocol.
  • HCI: Host controller interface protocol.
  • DM: Device manager.

Figure 2-4. Cordio Stack software system


The ATT subsystem implements the attribute protocol and generic attribute profile (GATT). It contains two independent subsystems: The attribute protocol client (ATTC) and attribute protocol server (ATTS).

ATTC implements all attribute protocol client features and is designed to meet the client requirements of the generic attribute profile. ATTC can support multiple simultaneous connections to different servers.

ATTS implements all attribute protocol server features and has support for multiple simultaneous client connections. ATTS also implements the server features defined by the generic attribute profile.

For more information see ATT API.


The SMP subsystem implements the security manager protocol. It contains two independent subsystems:

  • The initiator (SMPI). SMPI implements the initiator features of the security manager protocol and has support for multiple simultaneous connections.
  • The responder (SMPR). SMPR implements the responder features of the security manager protocol and has support for only one connection (by Bluetooth specification design).

SMP also implements the cryptographic toolbox, which uses AES. The interface to AES is asynchronous and abstracted through WSF. SMP also implements functions to support data signing.

For more information see SMP API.


The L2C subsystem implements the BLE L2CAP protocol. It is a substantially scaled-down version of regular Bluetooth L2CAP.

In the TX data path, the main function of L2C is building L2CAP packets and sending them to HCI. In the RX data path, its main function is receiving packets from HCI and routing them to either SMP or ATT.

L2C also implements the connection parameter update procedure.

For more information see L2CAP API.


The HCI subsystem implements the host-controller interface specification. This specification defines commands, events, and data packets sent between a BLE protocol stack on a host and a link layer on a controller.

The HCI API is optimized to be a thin interface layer for a single chip system. It is configurable for either a single chip system or traditional system with wired HCI.

This configurability is accomplished through a layered implementation. A core layer can be configured for either a single chip system or wired HCI. A transport and driver layer below the core layer can be configured for different wired transports such as UART.

For more information see HCI API.


The DM subsystem implements device management procedures required by the stack. These procedures are partitioned by procedure category and device role (master or slave). The following procedures are implemented in DM:

  • Advertising and device visibility: Enable/disable advertising, set advertising parameters and data, set connectability and discoverability.
  • Scanning and device discovery: Start/stop scanning, set scan parameters, advertising reports, name discovery.
  • Connection management: Create/accept/remove connections, set/update connection parameters, read RSSI.
  • Security management: Bonding, storage of security parameters, authentication, encryption, authorization, random address management.
  • Local device management: Initialization and reset, set local parameters, vendor-specific commands.

DM procedures support the Generic Access Profile (GAP) when applicable.

For more information see DM API.


The Wireless Software Foundation (WSF) is a simple OS wrapper, porting layer, and general-purpose software service used by the software system. The goal of WSF is to stay small and lean, supporting only the basic services required by the stack. It consists of the following:

  • Event handler service with event and message passing.
  • Timer service.
  • Queue and buffer management service.
  • Portable data types.
  • Critical sections and task locking.
  • Trace and assert diagnostic services.
  • Security interfaces for encryption and random number generation.

For more information see Cordio WSF Developer's Guide.

Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.