Extended advertising

Starting with Bluetooth 5, the advertising channels are separated in primary advertising channels and secondary advertising channels:

  1. Primary advertising channels

    • Use 3 legacy advertising channels 37, 38, and 39.

    • Can use either legacy 1M PHY or new LE Coded PHY.

    • PHY payload can vary from 6 to 37 bytes.

    • Packets on these channels are part of the advertising events.

  2. Secondary advertising channels

    • Use 37 channels, with the same channel index as the data channels.

    • Can use any LE PHY, but the same PHY during an Extended Advertising Event.

    • PHY payload can vary from 0 to 255 bytes.

    • Auxiliary packets on these channels are part of the Extended Advertising Event that begins at the same time with the advertising event on primary channel and ends with the last packet on the secondary channel.

An advertising data set is represented by advertising PDUs belonging together in an advertising event. Each set has different advertising parameters: PDU type, advertising interval, and PHY mode. The advertising data sets are identified by the Advertising SID (Set ID) field from the ADI – Advertising Data Info. Advertising data or Scan response data can be changed for each adverting data set and the random value of DID (Data ID) field is updated to differentiate between them.

Refer to Figure 1 and Figure 2.

Peripheral setup

This section describes the extended advertising GAP API. The application should not use both the extended and legacy API (described in section 4.2.1). If this requirement cannot be met, the application should at least wait for the generated events in the Advertising Callback prior to using the other API. That is, it is advisable to call legacy functions only after the event pertaining to an extended API is received, and vice versa. This GAP constraint can be considered an extension of the HCI constraint from the Bluetooth 5 specification: “A Host should not issue legacy commands to a Controller that supports the LE Feature (Extended Advertising)”.

The application configures extended advertising by going through the following states:

  1. Set the extended advertising parameters by calling:

    bleResult_t **Gap\_SetExtAdvertisingParameters**
(
gapExtAdvertisingParameters_t* pAdvertisingParameters
);

    It may use the default set of parameters gGapDefaultExtAdvertisingParameters_d. The application should wait for a gExtAdvertisingParametersSetupComplete_c event in the Generic Callback. Only one advertising set can be configured at a time. Comparing with the legacy Gap_SetAdvertisingParameters command, the new set of parameters is as follows.

    Parameter

    Description

    SID

    Value of the Advertising SID subfield in the ADI field of the PDU.

    handle

    Used to identify an advertising set. Possible values are 0x00 or 0x01 since the current implementation supports two advertising sets.

    extAdvProperties

    BIT0 - Connectable advertising

BIT1 - Scannable advertising

BIT2 - Directed advertising

BIT3 - High Duty Cycle Directed Connectable advertising (≤3.75 ms Advertising Interval)

BIT4 - Use legacy advertising PDUs

BIT5 - Omit advertiser’s address from all PDUs

(“anonymous advertising”)

BIT6 - Include TxPower in the extended header of the advertising PDU.

If legacy advertising PDU types are being used (BIT4 = 1),

permitted properties values are presented in the next table. If the advertising set already contains data, the type shall be one that supports advertising data and the amount of data shall not exceed 31 octets.

If extended advertising PDU types are being used (BIT4 =0), then the advertisement shall not be both connectable and scannable. While high duty cycle directed connectable advertising (≤ 3.75 ms advertising interval) shall not be used (BIT3 = 0).

| |txPower|Maximum power level at which the advertising packets are to be transmitted, the Controller can choose any power level <= txPower. Value 127 to be used if Host has no preference.| |primaryPHY|PHY for ADV_EXT_IND: LE 1 M or LE Coded| |secondaryPHY|PHY for AUX_ADV_IND and periodic advertising: LE 1 M, LE 2 M or LE Coded. Ignored for legacy advertising| |secondaryAdvMaxSkip|Maximum advertising events that the Controller can skip before sending the AUX_ADV_IND packets on the secondary advertising channel. Higher values may result in lower power consumption. Ignored for legacy advertising| |enableScanReqNotification|Whether to enable notifications when scanning PDUs (SCAN_REQ, AUX_SCAN_REQ) are received. If enabled, the application is notified upon scan requests by gExtScanNotification_c events in the Advertising Callback|

When using LE Coded PHY for advertising, the default coding scheme chosen by link layer is S=8 \(125 kb/s data rate\). To change the default coding scheme, the user has two options:

-   At compile time by defining *mLongRangeAdvCodingScheme\_c*, or
-   At run time by calling the API *Controller\_ConfigureAdvCodingScheme\(\)*.
In both cases, the value of the define or the parameter of the API has to be an appropriate value for primary and secondary PHYs as defined by the enumeration *advCodingScheme\_tag* found in *controller\_interface.h*.

|EventType|PDU Type|Advertising Event Properties|
|---------|--------|----------------------------|
|Connectable and scannable undirected|ADV\_IND|00010011b|
|Connectable directed \(low duty cycle\)

|ADV_DIRECT_IND|00010101b| |Connectable directed (high duty cycle)

|ADV_DIRECT_IND|00011101b| |Scannable undirected|ADV_SCAN_IND|00010010b| |Non-connectable and

Nonscannable undirected

|ADV_NONCONN_IND|00010000b|

  1. Set the advertising data and/or scan response data by calling:

    bleResult_t **Gap\_SetExtAdvertisingData**
(
uint8_t handle,
gapAdvertisingData_t* pAdvertisingData,
gapScanResponseData_t* pScanResponseData
);

    Either of the pAdvertisingData or pScanResponseData parameters can be NULL, but not both. For extended advertising (BIT4 = 0) only one must be different than NULL – the scannable advertising bit (BIT1) indicates whether pAdvertisingData (BIT1 = 0) orpScanResponseData (BIT1 = 1) is accepted. The total amount of Advertising Data shall not exceed 1650 bytes. Application should wait for a gExtAdvertisingDataSetupComplete_c event in the Generic Callback.

  2. Enable extended advertising by calling:

    bleResult_t **Gap\_StartExtAdvertising**
(
gapAdvertisingCallback_t advertisingCallback,
gapConnectionCallback_t connectionCallback,
uint8_t handle,
uint16_t duration,
uint8_t maxExtAdvEvents
);

    When using the common application structure, the application can use the following API defined in app_conn.h:

    bleResult_t **BluetoothLEHost\_StartExtAdvertising**
(
    appExtAdvertisingParams_t *pExtAdvParams,
    gapAdvertisingCallback_t  pfAdvertisingCallback,
    gapConnectionCallback_t   pfConnectionCallback
);

    The API goes through the steps of setting the advertising data and parameters. Events from the Host task are treated in the App_AdvertiserHandler() function, implemented in app_advertiser.c. To set the extended advertising parameters and data BluetoothLEHost_StartExtAdvertising a parameter of the following type:

    typedef struct **appExtAdvertisingParams\_tag**
{
    gapExtAdvertisingParameters_t *pGapExtAdvParams;
    gapAdvertisingData_t *pGapAdvData;
    gapScanResponseData_t *pScanResponseData;
    uint8_t                     handle;
    uint16_t                    duration;
    uint8_t                     maxExtAdvEvents;
} appExtAdvertisingParams_t;

    Advertising may be enabled for each previously configured advertising set, identified by the handle parameter. If duration is set to 0, advertising continues until the Host disables it, otherwise advertising is only enabled for this period (multiple of 10 ms). maxExtAdvEvents represent the maximum number of extended advertising events the Controller shall attempt to send prior to terminating the extended advertising, ignored if set to 0. Application should wait for a gExtAdvertisingStateChanged_c or a gAdvertisingCommandFailed_c event in the Advertising Callback.

  3. Disable advertising by calling:

    bleResult_t **Gap\_StopExtAdvertising**
(
uint8_t handle
);

    Application should wait for a gExtAdvertisingStateChanged_c or a gAdvertisingCommandFailed_c event in the Advertising Callback.

  4. Remove the advertising set by calling:

    bleResult_t** Gap\_RemoveAdvSet**
(
uint8_t handle
);

    Application should wait for a gExtAdvertisingSetRemoveComplete_c event in the Generic Callback.

Parent topic:Extended advertising

Central setup

The application configures the extended scanning by going through the following states:

  1. Start scanning by calling:

    bleResult_t Gap_StartScanning
(
const gapScanningParameters_t* pScanningParameters,
gapScanningCallback_t scanningCallback,
gapFilterDuplicates_t enableFilterDuplicates,
uint16_t duration,
uint16_t period
)

    When using the common application structure, the application can use the following API defined in app_conn.h:

    bleResult_t **BluetoothLEHost\_StartScanning**
(
    appScanningParams_t   *pAppScanParams,
    gapScanningCallback_t pfCallback
);

    The API starts scanning using the given parameters, which must have the following structure:

    typedef struct appScanningParams_tag
{
    gapScanningParameters_t *pHostScanParams;         /*!< Pointer to host scan structure */
    gapFilterDuplicates_t enableDuplicateFiltering;        /*!< Duplicate filtering mode */
    uint16_t duration;                                                           /*!< scan duration  */
    uint16_t period;                                                               /*!< scan period  */
} appScanningParams_t;

    Application may use the default set of parameters gGapDefaultExtScanningParameters_d. If the pScanningParameters pointer is NULL, the latest set of parameters are used. The scanningPHYs parameter indicates the PHYs on which the advertising packets should be received on the primary advertising channel. As a result, permitted values for the parameter are 0x01 (scan LE 1M), 0x04 (scan LE Coded) and 0x05 (scan both LE 1M and LE Coded). There are no strict timing rules for scanning, yet if both PHYs are enabled for scanning, the scan interval value must be large enough to accommodate two scan windows (interval >= 2 * window).

    If the advertiser uses legacy advertising PDUs, the device may actively scan by sending a SCAN_REQ PDU to the advertiser on the LE 1M primary advertising channel (no secondary channel in legacy advertising). Respectively, if the advertiser uses extended advertising PDUs, the active scan operation takes place on the secondary advertising channel. After the device receives a scannable ADV_EXT_IND PDU on the primary advertising channel (PHY LE 1M or Coded), it starts listening for the AUX_ADV_IND PDU on the secondary advertising channel (PHY 1M, 2M or Coded). Once received, the device sends an AUX_SCAN_REQ to the advertiser. Next, an AUX_SCAN_RSP PDU should be received, containing the scan response data. Application should wait for a gScanStateChanged_c or a gScanCommandFailed_cin the Scanning Callback.

  2. Collect information by waiting for gDeviceScanned_c (legacy advertising PDUs) or gExtDeviceScanned_c (extended advertising PDUs) event in the Scanning Callback. The gExtDeviceScanned_c event contains additional information pertaining to the extended received PDU, such as: primary PHY, secondary PHY, advertising SID, interval of the periodic advertising if enabled in the set.

    When using the common application structure, the application can use the following API defined in app_conn.h, to search the contents from pData in an advertising element:

    bool_t **BluetoothLEHost\_MatchDataInAdvElementList**
(
    gapAdStructure_t *pElement,
    void             *pData,
    uint8_t          iDataLen
);

  3. Stop scanning by calling the function below:

    bleResult_t **Gap\_StopScanning**(void);

    Application should wait for a gScanStateChanged_c or a gScanCommandFailed_c in the Scanning Callback.

  4. Connect to a device by calling the function below:

    bleResult_t **Gap\_Connect**
(
const gapConnectionRequestParameters_t* pParameters,
gapConnectionCallback_t connCallback
);

    When using the common application structure, the following API can be used:

    bleResult_t **BluetoothLEHost\_Connect**
(
    gapConnectionRequestParameters_t*   pParameters,
    gapConnectionCallback_t             connCallback
);

    The initiatingPHYs parameter indicates the PHYs on which the advertising packets should be received on the primary advertising channel and the PHYs for which connection parameters have been specified. The parameter is a bitmask of PHYs: BIT0 = LE 1M, BIT1 = LE 2M and BIT2 = LE Coded. The Host may enable one or more initiating PHYs, but it must at least set one bit for a PHY allowed for scanning on the primary advertising channel, i.e., BIT0 for LE 1M PHY or BIT2 for LE Coded PHY.

    If the advertiser uses legacy advertising PDUs, the device may connect by sending a CONNECT_IND PDU to the advertiser on the LE 1M primary advertising channel (no secondary channel in legacy advertising). On the other hand, if the advertiser uses extended advertising PDUs, the extended connect operation takes place on the secondary advertising channel. After the device receives a connectable ADV_EXT_IND PDU on the primary advertising channel (PHY LE 1M or Coded), it starts listening for the connectable AUX_ADV_IND PDU on the secondary advertising channel (PHY 1M, 2M or Coded). Once received, the device sends an AUX_CONNECT_REQ to the advertiser. Next, if AUX_CONNECT_RSP PDU is received, the device enters the Connection State in the Central role on the secondary advertising channel PHY.

    Application should wait for a gConnEvtConnected_c event in the Connection Callback. If the channel selection algorithm #2 is used for this connection, then a gConnEvtChanSelectionAlgorithm2_c event is also generated.

    After the connection is successfully established, the application may choose to read the connection PHY by calling the Gap_LeReadPhy API. It may also opt to change the PHY of the connection by triggering a PHY Update Procedure using the Gap_LeSetPhy API. However, the Controller might not be able to perform the change if, in case the peer does not support the new requested PHY.

Parent topic:Extended advertising

Parent topic:Generic Access Profile (GAP) Layer