Essentials for Integration Testing; Bluetooth Low Energy

By Monika Chaurasia

Software Verification Engineer

Boston Scientific

August 27, 2019

Blog

Essentials for Integration Testing; Bluetooth Low Energy

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.

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 will reach $1.2T in 2022, attaining a CAGR of 13.6 percent 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 devices 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 the word “Bluetooth.”  
 
 

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 in two ways: 
1. Connecting with any BLE device acting as Master to verify services and data exchange  
2. “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 layers play different roles, which need 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:
 

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 the Link layer. 
  
 
Standby: Default state
Advertising: The device sends advertising events in the three advertising channels at regular intervals (the remaining 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 coordinates for connection events with slaves called pico. Data transfer rates vary from 200 to 2,100 kbps in 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 packets:
• 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): 
 
 
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 that can be verified using the Wireshark Packet Analyzer: 
1. Verify that Peripheral Device advertises in clear text
2. 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)
3. Verify the advertisement algorithm of the Peripheral Device during handshake
4. 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: 
1. Just Works – Encryption key is shared between Central and Peripheral.
2. Passkey Display – Random Key is generated on one device and other needs to enter the same.
3. Out of Band – This supports another BLE radio for sharing the key. 
Using the same setup as above, below are the test cases that can be verified using the Wireshark packet capture: 
1. Verify the Key Exchange pairing process at packet level.
2. 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 and characteristics. Attribute is grouped data and UUID (Universally Unique Identifier), as 16-byte is assigned to each attribute.  GATT Attribute’s hierarchy can be understood in the below image:
 
Services consist of collection of data required to accomplish a particular function. Characteristics contain user data. The flow chart below 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 that can be verified using the nRF Connect App: 
1. Verify the Services available for discovery after connection is established.
2. 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).
3. Verify the Custom Services (Unknown Services as shown in below screenshot) available.
4. Verify the Characteristics for Service and properties enabled for those characteristics like Read, Write, etc.
5. Verify the defined data sent and received using the Data Read and Write feature.
 
 
 
Conclusion:
With the advent of Bluetooth Low Energy (BLE) supported by version 4.0, now it is being widely used in the consumer market because of low energy and low power demand in the 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.  
 
For more details on Quality Engineering Services, click here
 
Monika Chaurasia is associated with Volansys Technologies as a Principal Engineer with six years’ experience in quality assurance for various domains like embedded, IoT and medical devices. 

Experienced Quality Assurance Engineer with a demonstrated history of working in the Computer Software, Embedded industry and Medical Device Industry. Skilled at QA processes, Test Artifacts and Agile Methodologies. Experienced in ISO 13485, IEC 62304 and ISO 14971 Medical Device standards. Good knowledge of Python and Embedded system. Verification Engineer of Class I and Class II Medical Devices. Hands on experience on Bluetooth, API, Website, Mobile Application testing.

More from Monika