Extending further from the previous section, we saw that the GATT profile imposes a client–server architecture to facilitate the communication between Bluetooth Low Energy devices (the sensor and the collector) and Bluetooth Low Energy technology. Following a service-oriented architecture, the blood pressure sensor (or any other Bluetooth Low Energy device playing a GATT Server role) exposes some services.
Remember, how we compared Bluetooth Low Energy to a very intelligent database in the previous section, and that is exactly what is happening here. The primary reason for the existence of a blood pressure device sensor (or any other Bluetooth Low Energy sensor/device) is extremely simple. It measures the correct data (blood pressure levels in this case), stores it, and then makes the data available when requested by a client. A service is a wrapper on top of this data (this data is also known as characteristics and more on characteristics later). Similar kinds of data or characteristics are bundled together in a single service. This is a key factor in understanding the design of services, which exist to bundle similar kinds of data together. Perhaps an example will provide further clarity to this. The Blood Pressure Profile indicated the existence of two kinds of services:
- Blood Pressure Service: This consists of Blood Pressure Measurement data/characteristics
- Device Information Service: This consists of device data (Manufacturer Name, Model Number, Serial Number, and Hardware Revision):
Did you notice how each service consists of different kinds of data, which is similarly pertaining to itself? If you want to get blood pressure data, you should go and interrogate the blood pressure service and if you need information about the device itself, then you should go and talk to the device service. This is the primary reason for the existence of services. We had already established in the previous section that a profile can have multiple services. Like Bluetooth profiles, the Bluetooth SIG defines a number of official services.
Each official service is assigned a unique 16-bit UUID so that it can distinguish itself from others; for example, a blood pressure service has a UUID of 0x1810 and a device information service has a UUID of 0x180A. You can also write your own custom service for a specific purpose, but then it will need to have a 128-bit custom UUID.
Once again, I will strongly advise you to go over the relevant documentation of Blood Pressure Service and Device Information Service. Not only will this be very helpful in the discussion ahead, it will also clarify the information indicated in the preceding diagram.
The documents outline what characteristics each of the services contain or what information can be found on interrogating relevant services. For example, the blood pressure service contains three distinct characteristics:
- Blood Pressure Measurement
- Intermediate Cuff Pressure
- Blood Pressure Feature
The documentation also indicates what kind of data each characteristic holds; for example, the Blood Pressure Feature characteristic is used to describe the supported features of the blood pressure sensor. And by that, we have already started touching base on characteristics which deserve a topic of their own.
