IoT has been around for a while, but the current detonation in interest is due to the massive price drops of sensors combined with near ubiquitous connectivity. As per the recent report by IDC, Worldwide technology spending on the Internet of Things to reach $1.2T in 2022, attaining a CAGR of 13.6% over the 2017-2022 forecast period. Bluetooth technology is widely used in IoT in various smart applications for connecting over short distances (up to 100m) using short-wavelength radio transmissions in the unlicensed industrial, scientific, and medical (ISM) band from 2400.0 to 2483.5 MHz.
Bluetooth device communicate from one device to another in multiple modes:
- Unicast: Source sends and receives messages to multiple destinations establishing one-to-one device communication
- Broadcast: Source send messages to multiple destinations establishing one-to-many device communication
- Multicast (Mesh): Multiple Source and destinations establishing many-to-many device communication
BLE is marketed by Bluetooth Special Interest Group (SIG). Bluetooth SIG manages the certification process which needs to be followed by any Product using Bluetooth Wireless Technology. All these products must be Bluetooth SIG qualified and satisfy the requirements of the Bluetooth license agreements and specifications. SIG owns the logo as shown below and word “Bluetooth”:
Further process for qualifying Bluetooth enabled product can be followed at below link on Bluetooth website:
Bluetooth Protocol and Tests
Integration level tests for BLE involves the verification of advertisement data, handshake process (initiate communication and negotiate transfer parameters), connection process, bonding process, packet data format. This can be achieved by two ways:
- Connecting with any BLE device acting as Master to verify services and data exchange
- “Spy” between communications using Sniffer application
Every Bluetooth device has a unique MAC Address and clock. Master controls the clock and hopping frequency.
Source and Destination at various layer plays different roles which needs to be thoroughly verified for UUT (Unit Under Test – One Bluetooth Device acting as Scanner and another as Advertiser) which are discussed in this Blog. Below are the terms synonymously used for Source and Destination at each layer:
| Source | Destination | |
| Link Layer | Master | Slave |
| GAP | Central | Peripheral |
| GATT | Client | Server |
Link Layer
Link Layer is the layer in between Physical Layer and L2CAP Layer. It mainly plays the role of advertising, establishing connection and discovering services. The below state diagram depicts the workflow at Link layer:
Standby: Default state
Advertising: The device sends advertising events in the 3 advertising channels at regular intervals (rest 37 are data channels) as shown in below image.
Scanning
There are two different scanning modes:
- Passive scanning – Controller only supports data reception and doesn’t support transmission.
- Active scanning – Scan requests are transmitted. Scanner issues SCAN_REQ packet and advertiser responds with SCAN_RSP packet.
Initiating
The Scanner selects a suitable advertiser on basis of advertising data. The scanner can send a connection request to an advertiser if the advertiser signals a connection opportunity. Once CONNECT_REQ packet is sent, scanner becomes the Initiator.
Connection
Once the connection is successfully established, both devices are in “connection” state. Initiator becomes master and advertiser becomes slave. They exchange data packets at regular intervals termed as connection events (this connection is handshaking and data exchange happens only after handshaking is successful). BLE connections maintain a Piconet Network structure where single master co-ordinates for connection events with slaves called pico. Data transfer rates vary from 200 to 2,100 kbps at the application.
BLE Packet forms the fundamental building block of the Link Layer. BLE Packet Data Format can be broadly divided as below:
BLE has two types of packet:
- Advertising Packets – Find and connect to nearby devices
- Data Packets – Data transfer between two connected devices
Below are the different Advertising Packet types as per the Protocol Data Unit (PDU):
| Advertising | PDU |
| General Advertising – Scan request and Connect request | ADV_IND |
| Direct Advertising – Connect request only | ADV_DIRECT_IND |
| Discoverable Advertising – Scan request only | ADV_SCAN_IND |
| Non-connectable – Broadcast | ADV_NONCONN_IND |
Follow the steps from below link to setup Nordic BLE Sniffer and Wireshark setup for packet capture: nRF_Sniffer_UserGuide_v2.2
Below are the test cases which can be verified using the Wireshark Packet Analyzer:
- Verify that Peripheral Device advertises <Required data> in clear text
- Verify the advertisement algorithm of the Peripheral Device when it is advertising and not connected. (Advertisement algorithm includes the number of advertising events and duration in between them)
- Verify the advertisement algorithm of the Peripheral Device during handshake
- Verify the advertisement events after UUT is paired and bonded
Generic Access Profile (GAP)
GAP defines the device roles, advertising modes and bonding procedures. Security Manager, a part of GAP can be designed as per the security needs for the system. “Pairing” and “Bonding” processes are controlled through GAP:
- Pairing: Central and peripheral devices exchange the encrypted keys which is authenticated and accepted to establish the connection.
- Bonding: Information from the pairing process is stored on the devices such that the pairing process is not repeated, and reconnection is established whenever device is nearby.
Three primarily pairing methods are:
- Just Works – Encryption key is shared between Central and Peripheral
- Passkey Display – Random Key is generated on one device and other needs to enter the same
- Out of Band – This supports another BLE radio for sharing the key
Using the same setup as above, below are the test cases which can be verified using the Wireshark packet capture:
- Verify the Key Exchange pairing process at packet level
- Verify the Advertising Hop Sequences
Generic Attribute Profile (GATT)
Bluetooth device acts as GATT Server or Client. GATT identifies hierarchy to organize attributes such as services, characteristics. Attribute is grouped data and UUID (Universally Unique Identifier) is a 16-byte assigned to each attribute. GATT Attribute’ hierarchy can be understood from below Image:
Services consist collection of data required to accompolish a particular function. Characteristics contain User Data. Below flow shows communication of data packets between client and server:
Follow the below link to install nRF Connect Emulator App: nrFconnect App
Below are the test cases which can be verified using the nRF Connect App:
- Verify the Services available for discovery after connection is established
- Verify the services available like Device Information Service(UUID 0x180a) to get the Manufacturer details, Hardware, Firmware and Software strings data, Generic Access Profile (UUID 0x01800), Generic Attribute Profile(UUID 0x1801)
- Verify the Custom Services (Unknown Services as shown in below screenshot) available
- Verify the Characteristics for Service and properties enabled for those characteristics like Read, Write etc
- Verify the defined data sent and received using the Data Read and Write feature
Conclusion:
With the advent of Bluetooth Low Energy (BLE) supported from version 4.0, now it is being widely used in consumer market because of Low Energy and low power demand in consumer market (the BLE was invented and formalized by Bluetooth SIG). To help ensure the successful implementation of Bluetooth low energy in these new, low-power designs, test solutions must be able to conduct the necessary tests based upon the Bluetooth standards, quickly and cost efficiently.
Know more about our Quality Engineering Services.
See how we have helped our esteemed clients to ensure quality of their product – Read Case Studies.
About the Author: Monika Chaurasia
Monika is associated with VOLANSYS Technologies as a Principal Engineer with around 6 years’ experience in Quality Assurance for various domains like Embedded, IoT and Medical Devices.
