Overview¶

This section describes the high level design and functionality of the Micro BLE Stack. The Micro BLE Stack enables applications on the CC13xx or CC26xx to advertise, scan, or behave as a connection monitor. The Micro BLE stack utilizes the MultiMode RF driver as well. The MultiMode RF Driver enables dual-mode applications where another communication protocol stack is integrated and utilized alongside the Micro BLE Stack.

Constraints and Requirements¶

The Micro BLE Stack has the following internal constraints and requirements:

This design optionally depends on partial integration of ICall to save system resources if there already is an application using ICall in the dual-mode use case. In the case of using the ICall module, ICall’s system heap management and TI-RTOS service abstraction will be used.
There is no HCI because there is no separation between the controller and the host.
The privacy feature is not supported, but random address generation is supported
To minimize the memory overhead and remove redundant context switching, the Micro BLE Stack doesn’t have a separate TI-RTOS task. It is instead integrated in the application task.
The micro stack requires the use of the MultiMode RF driver
Device using only micro stack can not be Bluetooth qualified.

System Architecture¶

The Micro BLE Stack consists of the Micro Link Layer (Micro LL or uLL), Micro Generic Access Profile (Micro GAP or uGAP), and a Micro Radio Interface (Micro RFI or uRFI).

The uLL is mainly responsible for maintaining the device state and scheduling radio commands to perform advertising, scanning or connection monitoring operations. The pre- and post-processing for each radio command execution are also done by the uLL. The uLL directly invokes the RF Driver and will utilize the MicroRFI to initialize the radio for the Micro BLE Stack features being exercised.

Micro LL performs:

Radio management
Device state management between standby, advertising/scanning, and monitoring

The uGAP sits between the uLL and the application and is mainly responsible for controlling the uLL to set up and run a profile role. The application can indirectly configure the uLL through uGAP and be notified of events from uLL through uGAP callbacks. uGAP needs TI-RTOS because the clock/timer service is used.

Micro GAP performs:

Broadcaster role
Connection Monitor feature
Initialization and configuration of the uLL
State Management within the role/feature
Interfacing with the application

The uRFI is primarily used to initialize the Radio and allow Radio commands to be sent. Depending on the features enabled the uRFI will define the proper parameter structures which the uLL will externally reference to utilize the RF driver.

Micro BLE Stack is not designed to run as a separate TI-RTOS task, in order to save memory that would otherwise be required to maintain an additional task. Instead, it is integrated in the application, from TI-RTOS context’s point of view, so that all the application callbacks that are originated from RF and Clock SWIs in the Micro BLE Stack and might have lengthy operations such as command completion post processing and error handling are called in the application task context. How the Micro BLE Stack is integrated context-wise in the application is illustrated in Figure 149. Note that only the subcomponents directly relevant to the Micro BLE Stack in the application and the RF driver are depicted.

Figure 149. System Context Diagram¶

Micro RF interface¶

The micro RF interface or urfi is responsible for instantiating and configuring various RF commands used by the micro stack.

The following RF commands are used by the micro stack

rfc_CMD_BLE_ADV_COMMON_t : Advertiser command, used by broadcaster

rfc_CMD_BLE_SCANNER_t : Scanner command, used by observer

rfc_CMD_BLE_GENERIC_RX_t : Generic RX command, used by connection monitor

Micro Link Layer¶

The uLL is mainly responsible for the following:

Maintaining the device state

Scheduling radio activities

Pre- and post-processing

Note

The Filter Accept List without privacy is supported.

Radio Initialization¶

The uLL has a direct interface to the RF Driver. It opens a connection to the RF Driver as an independent client using RF_open() with setup parameters for BLE PHY. The setup parameters referenced to interface with the RF Driver are defined in the Micro RF interface. These parameters are dependent on the features enabled in Micro BLE Stack.

Application Parameters¶

The uLL maintains parameters used for advertising, scanning and connection monitoring. Most of the parameters can be accessed by uGAP through uble_setParameter() and uble_getParameter() functions. See local and global variables defined uble.c in the stack folder for Application parameters.

Micro Link Layer States¶

There are 4 states in the uLL: Standby, Advertising, Scanning, and Monitoring. The uLL changes the state from one to another at the uGAP’s request. Interfacing to the BLE Micro Stack should be done through uGAP APIs.

Standby State¶

This is the default state in the uLL. The uLL doesn’t do any radio activities in this state. The uLL may leave this state to enter any other state.

Advertising State¶

In this state, the uLL sends advertising PDUs in advertising events.

Each advertising event is composed of 3 advertising PDUs sent on the advertising channels as the commands are chained together.

Listing 180. urfi.c: Chainning advertising command¶

 urfiAdvCmd[0].pNextOp                  = (rfc_radioOp_t*) &urfiAdvCmd[1];
 urfiAdvCmd[1].pNextOp                  = (rfc_radioOp_t*) &urfiAdvCmd[2];
 urfiAdvCmd[2].pNextOp                  = NULL;

The time between two consecutive advertising events is specified in UBLE_PARAM_ADVINTERVAL. The actual interval will be UBLE_PARAM_ADVINTERVAL + AdvDelay, where AdvDelay is a pseudo-random value ranging from 0 ms to 10 ms generated by the uLL for each advertising event.

An advertising event is limited to the following type in this version of design:

A non-connectable undirected event: ADV_NONCONN_IND PDU is used. No response PDU is expected.

Per each advertising event, the following notifications will be delivered to the uGAP before and after the event. Note that these notifications are conveyed based on the application task’s priority since they are following the paths illustrated in Figure 149.

UGB_EVT_ADV_PREPARE: This notification event is generated UBLE_PARAM_DFLT_TIMETOADV ms prior to every advertising event. The purpose of this event is to let the application take time to update the advertising data with up-to-date information if necessary. If UBLE_PARAM_DFLT_TIMETOADV is 0, this notification event won’t happen.

Note

You can change advertising data by using uble_setParameter()
UGB_EVT_ADV_POSTPROCESS: This notification event is generated at the completion of every advertising event.
UGB_EVT_STATE_CHANGE: This notification event is generated when state has changed

Monitoring State¶

In this state, the uLL will scan a particular channel with specified scan parameters. An access address filter is applied based on the accessAddr parameter. The uGAP will supply all the necessary parameters and initialize the scan. Each scan has an associated monitorHandle which maintains the session. The scan will be performed over the specified channels by monitorChan.

The monitor session currently scanning is determined by the startTime which accounts for when the next connection event of the monitored connection should start. Furthermore the crcInit of the connection to follow must be input.

If a packet is detected before the end of scan duration, monitorDuration, the uLL will call the callback registered for indications. The application is then notified with a UGAP_MONITOR_EVT_MONITOR_INDICATION event.

Once the scan duration is elapsed, the application is notified with UGAP_MONITOR_EVT_MONITOR_COMPLETE event.

If there are pending scans, the uGAP will automatically start the next one.

If there is a state change, the application is notified with UGAP_MONITOR_EVT_STATE_CHANGE event.

RF Callbacks¶

Each RF event is processed differently depending on the role the micro stack is operating in (broadcaster, observer, connection monitor). These RF events are consumed through callbacks that are plugged to the RF driver via the uLL. See the table below for a summary of how the RF events are processed by the uLL.

Table 36. RF Driver Event processing by the Micro BLE-Stack¶
Mode	RF callback	Events Processed	Events generated
Broadcaster	ull_advDoneCb	RF_EventLastCmdDone	ULL_EVT_ADV_TX_SUCCESS
Broadcaster	ull_advDoneCb	RF_EventCmdAborted, RF_EventCmdStopped, RF_EventCmdPreempted, RF_EventCmdCancelled	ULL_EVT_ADV_TX_FAILED
Observer	ull_scanDoneCb	RF_EventRxEntryDone	ULL_EVT_SCAN_RX_SUCCESS
Observer	ull_scanDoneCb	RF_EventLastCmdDone, RF_EventInternalError	ULL_EVT_SCAN_RX_FAILED or ULL_EVT_SCAN_RX_BUF_FULL (depending on status from RF driver)
Connection Monitor	ull_monitorDoneCb	RF_EventRxEntryDone	ULL_EVT_MONITOR_RX_SUCCESS
		RF_EventLastCmdDone	ULL_EVT_MONITOR_RX_WINDOW_COMPLETE ULL_EVT_MONITOR_RX_BUF_FULL ULL_EVT_MONITOR_RX_FAILED (depending on status from RF driver)
		RF_EventInternalError	ULL_EVT_MONITOR_RX_FAILED

For more information regarding the RF driver see the RF Driver API Driver API Reference.

Micro GAP¶

The uGAP sits between the uLL and the application, and it is responsible for controlling the uLL to set up and run profile roles. The application can indirectly configure the uLL through the uGAP and be notified of events from the uLL through uGAP callbacks.

Parameters Management¶

The uGAP maintains the following parameters that control its behavior

ugbNumAdvEvent¶

The number of advertising events to be done before the Broadcaster stops its job. This is given when the application starts the Broadcaster by calling ug_bcastStart(). If this parameter is set to 0, the Broadcaster will not go to UGAP_BCAST_STATE_INITIALIZED state once started unless it is requested to stop.

ugbDutyOnTime¶

Time period during which the Broadcaster stays in UGAP_BCAST_STATE_ADVERTISING state. The uLL stays in Advertising State as well. When this time period ends, the Broadcaster state will transition to UGAP_BCAST_STATE_WAITING and the uLL will exit Advertising State. This parameter is effective only if Broadcaster Duty Control is enabled. If Broadcaster Duty Control is disabled, transition to other state from UGAP_BCAST_STATE_ADVERTISING is not affected by this parameter. A 100-ms time unit is used.

ugbDutyOffTime¶

Time period during which the Broadcaster stays in UB_BCAST_STATE_WAITING state. The uLL cannot be in Advertising State during this period. When this time period ends, the Broadcaster state will transition to UGAP_BCAST_STATE_ADVERTISING and the uLL will enter Advertising State. This parameter is effective only if Broadcast Duty Control is enabled. If 0, Broadcaster Duty Control is disabled and the Broadcaster will not enter UGAP_BCAST_STATE_WAITING state. A 100-ms time unit is used.

Role Management¶

The uGAP is the main interface to operate in various roles.

There are three distinct roles the uGAP supports:

Broadcaster
Monitor
Observer

The application must configure the uGAP to operate in the mode desired. This section goes over specifics of the individual roles.

Broadcaster Role¶

If the application configures the uGAP to operate Broadcaster role, the uGAP lets the uLL send advertising events as described in Advertising State

The Broadcaster Role has 4 states:

UG_BCAST_STATE_INITIALIZED: Broadcaster is initialized but has never started. The corresponding state of the uLL can be anything but ULL_STATE_ADVERTISING.
UGAP_BCAST_STATE_ADVERTISING: Broadcaster is advertising in this state. The corresponding state of the uLL is ULL_STATE_ADVERTISING. If Broadcaster Duty Control is enabled, the duty timer starts with the duration of BcastDutyOnTime when this state is entered. Then, the state switches to UGAP_BCAST_STATE_WAITING when the duty timer expires. If 0 was passed to NumAdvEvent when ug_bcastStart() is called, ugbNumAdvEvent won’t have any effect on this state. Otherwise, the state switches to UG_BCAST_STATE_IDLE if requested through ug_bcastStop() or the total number of Advertising Events since ug_bcastStart() was called reaches ugbNumAdvEvent. If ug_bcastSuspend() is called, the state switches to UGAP_BCAST_STATE_SUSPENDED, putting the duty timer on hold if Duty Control is enabled. The duty timer will resume when the state switches back to this state.
UGAP_BCAST_STATE_WAITING: Broadcaster started but is not advertising in this state because it’s in DutyOffTime period. The corresponding state of the uLL is UL_STATE_STANDBY. If Broadcaster Duty Control is enabled, the duty timer starts with the duration of BcastDutyOffTime when this state is entered. Then, the state switches to UGAP_BCAST_STATE_ADVERTISING when the duty timer expires. The state switches to UG_BCAST_STATE_IDLE if requested through ug_bcastStop(). If ug_bcastSuspend() is called, the state switches to UGAP_BCAST_STATE_SUSPENDED, putting the duty timer on hold if Duty Control is enabled. The duty timer will resume when the state switches back to this state.
UGAP_BCAST_STATE_SUSPENDED: Broadcaster started but is not advertising in this state. The corresponding state of the uLL can be anything but ULL_STATE_ADVERTISING. The former state shall be recorded when this state is entered. If the suspension is lifted through ug_bcastResume(), the state will switch back to the former state. The state switches to UG_BCAST_STATE_IDLE if ug_bcastStop() is called.

Figure 150. Broadcaster states¶

The Bluetooth Core Specifications Version 5.2 doesn’t allow Broadcaster to have Limited Discoverable Mode. However, the uGAP provides a duty control means similar to Limited Discoverable Mode to save power consumption. The duty control can be implemented with timers based on BcastDutyOnTime and BcastDutyOffTime explained in Parameters Management. Broadcaster’s Advertising State corresponds to the uLL’s Advertising State.

The typical life cycle of the Broadcasting function encompassing the application down to the uLL is illustrated in Figure 151.

Figure 151. Life Cycle of Broadcaster Function¶

Monitor Role¶

The Monitor Role is not defined by Bluetooth Core Specifications Version 5.2. This section is to describe how the uGAP operates when using the Monitor Feature.

Warning

This role is should only be used as stand alone condition only, which means no other uBLE Stack feature should be used in conjunction.

Monitor role is designed to follow an active Bluetooth LE connection. It requires knowledge of connection information such as access address, hop increment, and connection interval. With this information the Monitor role sets up uGAP and uBLE.

The Monitor Role has 3 States:

UGAP_MONITOR_STATE_INITIALIZED: The monitor is initialized but is not monitoring.
UGAP_MONITOR_STATE_IDLE: The monitor is not monitoring in this state. This corresponds to UL_STATE_STANDBY in the uLL.
UGAP_MONITOR_STATE_MONITORING: The monitor is scanning. This corresponds to UL_STATE_MONITORING in the uLL.

When a packet is detected with the during a scan with the Connection Parameters passed in from the ‘uble.c’ source file a UGAP_MONITOR_EVT_MONITOR_INDICATION event is generated.

When a scan is complete, a UGAP_MONITOR_EVT_MONITOR_COMPLETE event is generated. If there are pending scans, the uGAP will start the next scheduled scan.

Each time the Monitor switches states, a UGAP_MONITOR_EVT_STATE_CHANGE event is generated.

For more information regarding monitor role and its application, please refer to Connection Monitor (CM) Application