 Hands-on, bonding. Bonding means storing identity and security-related information persistently between connections. For bonding to take place, it must be supported on both sides of the BLE link. Up until now, bonding was disabled, which meant that we had to pair on every connection. When bonding is enabled and the security information stored in the flash, the link may be encrypted based on a key which is derived from it. In KubeMX, we will do a single change to enable the bonding in the BLE pairing tab. So let's go to the vpal middleware. And in the BLE pairing tab, let's enable the bonding. And this is it. We can generate the project and make another test. So now the code is compiled and loaded to the target and the device is advertising. Again, I will go to STBLE Toolbox application and connect to my device. When I try to read the characteristic, you see a pairing request. We are still using the numeric comparison from the previous example. And now we see that the link is encrypted, the pairing succeeded and the characteristic value was read. Now if I disconnect and reconnect again, you can see in the application traces that the link is re-encrypted automatically. And this is due to the bonding information which is stored on both sides, on WB55 and also on the Android phone. If you would like to delete this bonding information on the Android, you would have to go to the menu, here find the device and click forget. To delete a bonding information on WB side, you would call ACI GAP Clear Security Database. More information about this API can be found in the application node AN5272. And this is the end of the hands-on.