SWCU191 February 2022 CC1311P3 , CC1311R3 , CC2651P3 , CC2651R3 , CC2651R3SIPA
Legacy advertising packets (ADV_IND, ADV_NONCONN_IND, ADV_SCAN_IND, and ADV_DIRECT_IND), are accepted if running CMD_BLE_SCANNER or if running CMD_BLE5_SCANNER on a primary advertising channel with 1-Mbps PHY. The operation is described as follows:
Filter Policy | RPA Mode | AdvA is RPA | AdvA Matches Whitelist Entry with bWlIgn = 1 | AdvA Matches Whitelist Entry with bEnable = 1 | AdvA Filter Result | Perform Auto-Ignore if bAutoWlIgnore = 1 |
---|---|---|---|---|---|---|
1 | X | X | No | No | Reject | No |
1 | X | X | No | Yes | Accept | Yes |
1 | X | X | Yes | X | Reject | No |
0 | 0 | X | No | X | Accept | No |
0 | 0 | X | Yes | X | Reject | No |
0 | 1 | No | No | X | Accept | No |
0 | 1 | No | Yes | X | Reject | No |
0 | 1 | Yes | No | No | Reject | No |
0 | 1 | Yes | No | Yes | Accept | Yes |
0 | 1 | Yes | Yes | X | Reject | No |
RPA Filter Policy | TargetA is RPA | TargetA is Equal to Device Address | TargetA Match |
---|---|---|---|
0 | X | No | No |
0 | X | Yes | Yes |
1 | No | No | No |
1 | No | Yes | Yes |
1 | Yes | X | Yes |
PDU Type | CRC Result | AdvA Filter Result | TargetA Match | Active Scan | Action No. |
---|---|---|---|---|---|
ADV_IND | OK | Reject | N/A | X | 1 |
ADV_IND | OK | Accept | N/A | No | 2 |
ADV_IND | OK | Accept | N/A | Yes | 3 |
ADV_IND | NOK | X | N/A | X | 4 |
ADV_SCAN_IND | OK | Reject | N/A | X | 1 |
ADV_SCAN_IND | OK | Accept | N/A | No | 2 |
ADV_SCAN_IND | OK | Accept | N/A | Yes | 3 |
ADV_SCAN_IND | NOK | X | N/A | X | 4 |
ADV_NONCONN_IND | OK | Reject | N/A | X | 1 |
ADV_NONCONN_IND | OK | Accept | N/A | X | 2 |
ADV_NONCONN_IND | NOK | X | N/A | X | 4 |
ADV_DIRECT_IND | OK | Reject | X | X | 1 |
ADV_DIRECT_IND | OK | Accept | No | X | 1 |
ADV_DIRECT_IND | OK | Accept | Yes | X | 2 |
ADV_DIRECT_IND | NOK | X | X | X | 4 |
ADV*_IND with invalid length | X | X | X | X | 5 |
Other (see also Section 26.8.10.2) | X | X | N/A | X | 5 |
Action No. | bCrcErr | bIgnore | Description |
---|---|---|---|
1 | 0 | 1 | Continue scanning |
2 | 0 | 0 | Continue scanning or end operation with BLE_DONE_OK status |
3 | 0 | 0 | Perform backoff procedure and send SCAN_REQ and receive SCAN_RSP if applicable. Then continue scanning or end operation |
4 | 1 | 0 | Continue scanning |
5 | — | — | Stop receiving packet, then continue scanning |
If the packet being received did not fit in the RX queue, the packet shall be received to the end, but the received bytes are not stored. If the packet would normally not have been discarded from the RX buffer, the operation shall end.
If the action from the received packet is 3, a SCAN_REQ message is to be transmitted if allowed after a backoff procedure. This procedure starts with decrementing pParams->backoffCount. If this variable becomes 0 after the decrement, a SCAN_REQ message shall be transmitted. If not, the operation shall end.
If the action from the received packet is 2 or 3, the next action may either be to continue scanning or to end the operation. This is configured with pParams->scanConfig.bEndOnRpt; if 1, the operation shall end, otherwise scanning shall continue.
When transmitting a SCAN_REQ message, the radio CPU shall construct this packet. In the header, the PDU Type bits shall be 0011b. The TxAdd bit shall be as in pParams->scanConfig.deviceAddrType (if the least significant bit of pParams->pDeviceAddress is 1, the TxAdd bit is inverted, see Section 26.8.17). The RxAdd bit shall be as in the TxAdd field of the header of the received ADV_IND or ADV_SCAN_IND message. The length shall be calculated from the size of the scan request data, meaning that it shall be pParams->scanReqLen + 12. The ChSel and RFU bits shall be 0. The payload shall start with the 6-byte device address, which shall be read from pParams->pDeviceAddress, followed by the 6-byte peer address read from the AdvA field of the received message. By the Bluetooth low energy specification, there shall be no more payload, but when using the CMD_BLE_SCANNER command, a noncompliant message may be constructed by setting pParams->scanReqLen to a nonzero value. If so, the rest of the payload shall be read from the pParams->pScanData buffer.
After a SCAN_REQ message is transmitted, the radio CPU shall configure receiver and look for a SCAN_RSP from the advertiser to which the SCAN_REQ was sent. If sync is obtained on the demodulator, the header is shall be checked once it is received, and if it is not a SCAN_RSP message, the demodulator shall be stopped immediately. If it is a SCAN_RSP message, then it shall be received into the RX queue. Depending on the received SCAN_RSP message, the values of bCrcErr and bIgnore shall be as given in Table 26-148. If pParams->scanConfig.bStrictLenFilter is 1, only length fields that are compliant with the Bluetooth low energy specification shall be considered valid. For a SCAN_RSP, it means a length field in the range 6–37. If pParams->scanConfig.bStrictLenFilter is 0, all received packets with a length field less than or equal to the maximum length of an advertiser packet shall be considered valid. If the length is not valid, the receiver shall be stopped.
PDU Type | CRC Result | AdvA Same as in Request | bCrcErr | bIgnore | Response Packet Result |
---|---|---|---|---|---|
SCAN_RSP | OK | No | 0 | 1 | Failure |
SCAN_RSP | OK | Yes | 0 | 0 | Success |
SCAN_RSP | NOK | X | 1 | 0 | Failure |
SCAN_RSP with invalid length | X | X | — | — | Failure |
Other | X | N/A | — | — | Failure |
No packet received | N/A | N/A | — | — | Failure |
After receiving or attempting to receive a SCAN_RSP, the backoff parameters shall be updated by the radio CPU as described in Section 26.8.15, based on the result as given in the Response Packet Result column of Table 26-148 and the old values of the backoff parameters.
If pParams->scanConfig.bAutoWlIgnore is 1, an auto-ignore feature is enabled. In the cases where stated in the right-most column of Table 26-154, the radio CPU shall then automatically set the bWlIgn bit of the whitelist entry corresponding to the address from which an ADV*_IND message was received. This shall be done either after action 2 is performed or after action 3 is performed and a SCAN_RSP is received with the result Success. This can be used to avoid reporting multiple advertising messages from the same device and to avoid scanning the same device repeatedly.