Blood Pressure Profile

The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, is, and note in the development of specifications:

For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.

Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.

Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.

When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.

The acronym RFU is equivalent to Reserved for Future Use.

When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.

Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.

“Prohibited” is never abbreviated.

Certain terms used in this specification have been updated and are no longer used by Bluetooth SIG. For a list of terms that have been updated and their replacement terms, see the Appropriate Language Mapping Table [12].

While in a GAP Discoverable Mode for initial connection to a Collector, the Blood Pressure Sensor should include the Blood Pressure Service UUID defined in [11] in the Service UUIDs AD type field of the Advertising Data. This enhances the user experience as a Blood Pressure Sensor may be identified by the Collector before initiating a connection.

For enhanced user experience a Blood Pressure Sensor should include the Local Name (containing either the complete or shortened value of the Device Name characteristic as defined in [2]) in its Advertising Data or Scan Response Data.

The Blood Pressure Sensor may support the write property for the Device Name characteristic in order to allow a Collector to write a device name to the Blood Pressure Sensor.

For enhanced user experience a Blood Pressure Sensor that supports multiple bonds may include either the Public Target Address AD Type or Random Target Address AD Type (see Section 5.1.5) in its Advertising Data or Scan Response Data. If a Blood Pressure Sensor does not support multiple bonds, the Blood Pressure Sensor shall not use a Target Address AD Type. As defined in the Blood Pressure Service, the value of the Multiple Bond Support bit of the Blood Pressure Feature characteristic is to be set according to the Blood Pressure Sensor’s functionality. By doing so, a Collector can determine if the Blood Pressure Sensor does not support a Target Address AD Type (i.e., if the Multiple Bond Support bit is 0) or potentially supports a Target Address AD Type (i.e., if the Multiple Bond Support bit is 1). In the following sections the words “a Target Address AD Type” is intended to refer to either of the defined Target Address AD Types.

For reduced power consumption, a Blood Pressure Sensor that supports multiple users (with or without User Data Service (UDS)) should support the Service Data AD Type as follows:

When the Sensor is using Undirected Advertising, the Sensor should include the Service Data AD Type in its Advertising Data (AD) to reduce unwanted connection requests by unintended Collectors. Conversely, if the Sensor is using any form of Directed Advertising (for example, Low Duty Cycle Directed Advertising), this feature is not needed.

The definition of the Service Data payload is shown in Table 3.2 and consists of the Service Universally Unique Identifier (UUID) and a User ID List that contains a list of one or more User IDs for which the Sensor has new measurements.

The Collector can read the User ID List value to determine whether the Sensor has any new measurements since the last time they connected to avoid unnecessary connection requests. In other words, this can be used by the Collector to determine whether it should attempt to reconnect to the Sensor to receive new measurements.

The Collector shall discover the Blood Pressure Service.

The Collector may discover the Device Information Service.

The Collector may discover the User Data Service.

An Enhanced Blood Pressure Collector shall discover the User Data Service.

The Collector shall perform either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure in order to discover the characteristics of the service.

The Collector shall perform the GATT Discover All Characteristic Descriptors sub-procedure in order to discover the characteristic descriptors described in the following sections.

The Collector may discover the characteristics of the Device Information Service.

In order for the Collector to discover the characteristics of the Device Information Service, it shall use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure to discover all characteristics of the service.

If the Sensor exposes the User Data Service, then the Collector may discover the characteristics of the User Data Service. If exposed, an Enhanced Blood Pressure Collector shall discover this service.

In order for the Collector to discover the characteristics of the User Data Service, it shall use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure to discover all characteristics of this service.

The requirements for the Collector on User Data Service characteristic discovery are shown in Table 4.5.

Table 4.5 includes some common optional User Data Service characteristics in the context of this Profile, but other User Data Service characteristics not listed here may also be used.

Within the context of the Blood Pressure Service, a record is a Blood Pressure Record. Support for the RACP is mandatory for a Collector but optional for a Sensor.

The Collector shall support the Op Codes, Operator, and Filter Type combinations defined as mandatory in Table 3.3 in [1].

The Collector shall write to the RACP characteristic using one of the supported Op Codes in [1] to request a Sensor to perform a procedure. This shall include an Operator and Operand that is valid within the context of that Op Code as defined in [1].

The procedures including the use of Filter Types are described in Sections 4.11.3.1–4.11.3.5.

The Collector shall be tolerant of the fact that the Sensor may add or delete measurements while RACP procedures are taking place and also between two different RACP procedures. For example, the Collector may perform the Request Number of Stored Records procedure with the Procedure Operator set to All Stored Records to get the total number of records currently stored by the Sensor. However, if the Collector then performs a Report Stored Records procedure with the Procedure Operator set to All Stored Records, then the Collector shall be tolerant of receiving a different number of records from this procedure than the Sensor reported having stored in the response to the Report Number of Stored Records. This is because the Sensor may have taken new measurements and/or deleted stored measurements through user interaction in the time between the Request Number of Stored Records procedure and the Report Stored Records procedure. This is used as an example, but the Collector shall be tolerant of this happening with any RACP procedure.

The Collector shall also be tolerant of the possibility that the Sensor, although required to maintain a Sequence Number continuum while collecting measurements, may not be able to provide a continuum in the case of any catastrophic hardware or software error that results in the Sequence Number being reset.

If the Sensor supports multiple bonds, then a Collector shall be tolerant of the fact that other Collectors may alter the contents of the Sensor’s measurement database. For example, Collector #2 may delete records from the Sensor’s database that Collector #1 will then never be able to retrieve. This will also affect the Sequence Number continuum.

The handling of multiple bonds is vendor-specific. For example, a Sensor may only allow certain bonded Collectors (such as a doctor’s computer) to use the Delete Store Records procedure, while disallowing this to other bonded Collectors (such as those of patients). The Blood Pressure Profile does not define the authorization mechanism for this scenario.

When a Sensor supports both the RACP and the User Data Service, the Collector shall use the Consent Procedure to retrieve the Blood Pressure Records for a specific user. This is defined further in Section 4.124.12.

Other than error handling procedures that are specific to certain Op Codes, the following apply:

See Section 4.14 for requirements on the Collector for handling Control Point errors.

In the context of the RACP characteristic, a procedure is started when the Sensor sends the response to the Collector’s Write request for the RACP characteristic. The procedure is considered to be complete when the RACP characteristic is indicated with the Op Code set to Response Code.

An RACP procedure may consist of multiple notifications of the Blood Pressure Record characteristic. The procedure is completed when the RACP characteristic is indicated. A procedure is considered to have timed out if a notification or an indication is not received within the ATT transaction timeout, defined in Volume 2, Part F, Section 3.3.3 of [2] as 30 seconds from the start of the procedure or the last notification that was received as a result of this procedure.

If the link is lost while an RACP procedure is in progress, then the procedure shall be considered to have timed out. See Section 4.11.5.1 for handling this condition.

Therefore, a Collector shall start a timer, with the value set to the ATT transaction timeout, after the write response is received from the Sensor. The timer shall be restarted after every Blood Pressure Record notification is received. The timer shall be stopped when an RACP indication is received and the Op Code is set to Response Code. If the timer expires, then the procedure shall be considered to have failed.

The Collector may read and write the value of UDS characteristics.

For UDS characteristics that exceed the negotiated ATT_MTU size (for example, UTF8-based characteristics), the Collector should use the GATT Read Long Characteristic Value sub-procedure and GATT Write Long Characteristic Value sub-procedure, respectively.

Although most Collectors are expected to support the caching of User Data Service characteristic values, this is not required. Collectors that are used in a public environment (for example, a gym with a fitness machine) will typically not cache values, but personal Collectors (for example, a smartphone, tablet, sports watch, or personal computer) typically will cache values for later use for improved efficiency.

The Collector shall use the Consent procedure defined in Section 4.12.5.2.2 to access the UDS characteristics exposed by the Sensor.

If a Sensor supports the User Data Service (bit 7 of the Blood Pressure Feature field is set to 1), then the Collector may read the User Index characteristic to confirm for which user the UDS characteristics are exposed before the Collector attempts to read or write any UDS characteristics.

The Database Change Increment characteristic is used to keep track of updates to UDS characteristics supported by both a Sensor and a Collector (in other words, updates made either through the user interface (UI) of the Sensor or through the UI of a Collector).

If the Sensor supports the Database Change Increment characteristic, it is optional for the Collector to configure the Database Change Increment characteristic for notifications except for Collectors that support the User Data Synchronization feature for which notifications become mandatory, as specified in Section 4.12.7.

A notification of the Database Change Increment characteristic alerts the Collector that a change to at least one of the values has occurred and the Collector shall read all UDS characteristic values that the two devices have in common.

If the Collector supports the User Data Synchronization feature, then the requirements in Section 4.12.7 apply.

If the Collector does not support the User Data Synchronization feature, then after the Collector has completed writing a new value to one or more UDS characteristics, the Collector shall read the Database Change Increment value from the Sensor and write the value incremented by one to the Database Change Increment characteristic of the Sensor.

A rollover of the value of the Database Change Increment characteristic is extremely unlikely over the life of the Sensor, but if a rollover occurs, this can be handled in an implementation-specific way. The implementation can, for example, ask the user to confirm the values via the UI.

The Sensor uses the Registered User characteristic to communicate a Registered User Index and Registered User Name via one or more GATT indications to the Collector. The Collector can initiate this via the List All Users Procedure described in Section 4.12.5.2.4. For this procedure, the Collector shall configure the Registered User Characteristic for indications (via the Client Characteristic Configuration descriptor).

Before performing a User Control Point procedure, the Collector shall configure the User Control Point characteristic for indications (via the Client Characteristic Configuration descriptor).

The Collector may perform a write to the User Control Point to request a desired procedure. A procedure begins when the Collector writes a particular Op Code to the User Control Point to perform some desired action and ends when the Collector sends a confirmation to acknowledge the User Control Point indication sent by the Sensor at the end of the procedure. This indication includes the Response Code, Requested Op Code, and Response Value. This indication may also include a Response Parameter as defined in [10].

If the Collector supports remote updating of user data to the Sensor, such as First Name, Last Name, Gender, Age, or Date of Birth values, then the Collector shall support reading and writing to the corresponding User Data Service characteristics as defined in [5].

The User Data Synchronization feature is optional. If supported, the requirements in this section apply.

When a connection is established, the Collector shall read the Database Change Increment characteristic value and compare it to its local (cached) value. Based on the comparison between these two values, the Collector shall perform the appropriate action defined in Table 4.8. After the synchronization procedure is completed, both the Collector and the Sensor will have the same UDS characteristic and Database Change Increment values.

If the Sensor supports notifications of the Database Change Increment characteristic, then the Collector shall configure this characteristic for notifications.

When the Collector updates the cached UDS characteristics while not in a connection (for example, through its UI), the Collector shall increment the value of the cached Database Change Increment characteristic by one. This is to synchronize the UDS characteristics values with the Sensor at the next connection.

When a Collector that supports the update of UDS characteristics (for example, through its UI) is connected to a Sensor, and when the Collector updates one or more UDS characteristics values exposed by the Sensor, the Collector shall increment its local Database Change Increment value by one and write the incremented value of the Database Change Increment characteristic to the Sensor.

This procedure is applicable when the Blood Pressure Sensor connects to a Collector to which it is not bonded. This is typically initiated through user interaction when a user intends to bond the Blood Pressure Sensor with a Collector.

The Blood Pressure Sensor should use the GAP Limited Discoverable Mode with connectable undirected advertising events when establishing an initial connection. The TGAP(lim_adv_timeout) used during GAP Limited Discoverable Mode may be larger than the value specified in the Section 16, Appendix A in the GAP specification [2], but the value shall be less than or equal to 180 seconds.

It is recommended to use the advertising interval parameters in Table 5.1 during the GAP Limited Discoverable Mode. The interval values in the first row are designed to attempt fast connection during the first 30 seconds; however, if a connection is not established within that time, the interval values in the second row are designed to reduce power consumption for devices that continue to advertise.

Notwithstanding the above, the advertising interval and time to perform advertising should be configured with consideration for user expectations of connection establishment time.

The Blood Pressure Sensor shall accept any valid values for connection interval and connection latency set by the Collector until service discovery and encryption is complete. Only after this has been completed should the Blood Pressure Sensor request to change to the preferred connection parameters that best suits its use case.

If a connection is not established within a time limit defined by the Blood Pressure Sensor, the Blood Pressure Sensor may exit the GAP discoverable mode.

The Blood Pressure Sensor should be in a bondable mode during this procedure to optimize connecting to the Collector again using the procedure described in Section 5.1.2.

If the Client Characteristic Configuration descriptor has been configured to enable indications or notifications and the Blood Pressure Sensor has no data to transfer (or no further data to transfer), then after waiting for an idle connection timeout (see Section 5.1.4), the Blood Pressure Sensor should perform the GAP Terminate Connection procedure. This allows the Collector to perform any additional required actions (e.g. read Blood Pressure Feature characteristic).

This procedure is applicable after the Blood Pressure Sensor has bonded with the Collector using the connection procedure in Section 5.1.1 and either when the user initiates a connection or autonomously when a notification or indication is pending.

A Blood Pressure Sensor should enter the GAP Undirected Connectable Mode either when commanded by the user to initiate a connection to a Collector or when a Blood Pressure Sensor has one or more indications or notifications to send to a previously connected Collector.

The Blood Pressure Sensor should write the address of the target Collector in its Filter Accept List and set its controller advertising filter policy to ‘process scan and connection requests only from devices in the Filter Accept List’.

The Blood Pressure Sensor should use the recommended advertising interval values shown in Table 5.1.

The advertising interval and time to perform advertising should be configured with consideration for user expectations of connection establishment time.

Once connected, the Blood Pressure Sensor may request to change to the preferred connection parameters that best suits its use case.

If a connection is not established within a time limit defined by the Blood Pressure Sensor, the Blood Pressure Sensor may exit the GAP connectable mode.

If the Client Characteristic Configuration descriptor has been configured to enable indications or notifications and the Blood Pressure Sensor has no data to transfer (or no further data to transfer), then after waiting for an idle connection timeout (see Section 5.1.4), the Blood Pressure Sensor should perform the GAP Terminate Connection procedure. This allows the Collector to perform any additional required actions (e.g. read Blood Pressure Feature characteristic).

See Section 5.1.5 for additional requirements related to support for multiple bonds.

When a connection is terminated due to link loss, a Blood Pressure Sensor should attempt to reconnect to the Collector by entering the GAP Undirected Connectable Mode using the recommended advertising interval values shown in Table 5.1.

The Blood Pressure Sensor should perform the GAP Terminate Connection procedure if the connection is idle for more than five (5) seconds.

This section is applicable when a Blood Pressure Sensor supports multiple bonds.

A Blood Pressure Sensor supporting multiple bonds may advertise with the address of the target Collector(s) in a Target Address AD Type to enable bonded Collectors to determine if they are the intended recipient of the data. This feature is designed to avoid a situation where a bonded Collector unnecessarily responds to the Blood Pressure Sensor advertisement intended for another bonded Collector. The applicable Public Target Address AD Type format or Random Target Address AD Type format (see Table 5.2) should be used when including the address corresponding to Collector’s address type. As stated in Section 3.1.4, if the Blood Pressure Sensor does not support multiple bonds, a Target Address AD Type is not to be included in either the Advertising Data or the Scan Response Data.

If the Blood Pressure Sensor uses a Target Address AD Type and was given a random address by that Collector, the Blood Pressure Sensor shall use that address in the Random Target Address AD Type. A Blood Pressure Sensor may include multiple target addresses in its Advertising Data or Scan Response Data although the maximum number possible is four due to data size restrictions. As described in Section 5.1.2, the Blood Pressure Sensor should also use a Filter Accept List to avoid connection with an unwanted Collector.

This section outlines an optional procedure that is applicable when a Sensor uses the Undirected Connectable Mode and the Service Data AD Type.

The Service Data AD Type described in Section 3.1.1 provides a mechanism to reduce unwanted connection requests by unintended Collectors when Undirected Connectable Mode is used and when a Sensor has new indications to send. Refer also to Section 5.2.6 for the procedure from the Collector perspective.

When a Sensor uses undirected connectable advertisements, it should include the Service Data AD Type in its Advertising Data. The value of the User ID List field of the Service Data AD Type shall be populated with the User IDs for which the Sensor has measurements. The absence of any User ID indicates the absence of measurements. This allows each Collector to determine whether the Sensor has any new data to be collected since the last time the Collector read the User ID List field.

This procedure is applicable for connection establishment when the Collector connects to a Blood Pressure Sensor to which it is not bonded. This is typically initiated through user interaction when a user intends to bond the Collector with the Blood Pressure Sensor.

A Collector should use the GAP Limited Discovery procedure to discover a Blood Pressure Sensor.

The Collector should use the recommended scan interval and scan window values shown in Table 5.3. For the first 30 seconds (or optionally continuously for mains powered devices), the Collector should use the first scan window / scan interval pair to attempt fast connection. However, if a connection is not established within that time, the Collector should switch to one of the other scan window / scan interval options as defined in Table 5.3 to reduce power consumption.

Once the Blood Pressure Sensor is discovered, the Collector should initiate connection using the Direct Connection Establishment procedure.

* A scan interval of 60ms is recommended when the Collector is supporting other operations to provide a 50% scan duty cycle versus 100% scan duty cycle.

Option 1 in Table 5.3 uses the same background-scanning interval used in BR/EDR so the power consumption for LE will be similar to the power consumption used for background scanning on BR/EDR. Option 2 uses a larger background-scanning interval (e.g. twice as long) than used in BR/EDR so the power consumption for LE will be less than the power consumption used for background scanning on BR/EDR. Connection times during background scanning will be longer with Option 2.

After the connection is established, the Collector should bond with the Blood Pressure Sensor during this procedure to optimize connecting to the Blood Pressure Sensor again using the procedure in Section 5.2.2. If a bond is created, the Collector should write the address of the Blood Pressure Sensor in the Collector controller’s Filter Accept List.

The Collector should configure the Client Characteristic Configuration descriptor to enable indications or notifications as needed.

The Blood Pressure Sensor typically terminates the connection if it has no data to transfer.

This procedure is applicable after the Collector has bonded with the Blood Pressure Sensor using the connection procedure in Section 5.2.1 and either when the user initiates a connection or autonomously when a Collector requires measurements from a Blood Pressure Sensor.

A Collector may use one of the following GAP connection procedures based on its connectivity requirements:

If the Collector receives an undirected connectable advertisement from a bonded Blood Pressure Sensor while performing the General or Selective Connection Establishment Procedure, and the Blood Pressure Sensor supports multiple bonds (i.e. the Multiple Bond Support bit of the Blood Pressure Feature characteristic is set to 1 meaning ‘Multiple Bonds supported’) see Section 5.2.5 for multi-bond considerations and the use of target addresses. Otherwise a Target Address AD Type will not be present in either the Advertising Data or Scan Response Data.

The Collector should use the recommended scan interval and scan window values shown in Table 5.3. When initiating connection, the Collector should use the first scan window / scan interval pair to attempt fast connection. However, if a connection is not established within 30 seconds, the Collector should switch to one of the other scan window / scan interval options as defined in Table 5.3 to reduce power consumption.

If the Collector is in background scanning, it may use the scan window / scan interval Option 1 or Option 2 to reduce power consumption.

Notwithstanding the above, the Collector should use a scan window and scan interval suitable to its power and connection time requirements. Increasing the scan window increases the power consumption, but decreases the connection time.

The scan interval and scan window should be configured with consideration for user expectations of connection establishment time.

The Collector shall start encryption after each connection creation to verify the status of the bond. If encryption fails upon connection establishment (i.e. the bond no longer exists), the Collector must, after user interaction, re-bond, perform service discovery (unless the Collector had previously determined that the Blood Pressure Sensor did not have the <<Service Changed>> characteristic), and set the Blood Pressure Sensor Client Characteristic Configuration descriptor again before using any of the services referenced by this profile in case the configuration was altered or lost.

The Blood Pressure Sensor typically terminates the connection after it has no additional data to transfer.

When a connection is terminated due to link loss, a Collector should attempt to reconnect to the Blood Pressure Sensor using any of the GAP connection procedures with the parameters in Table 5.3.

To avoid very long service discovery and encryption times, the Collector should use the connection intervals defined in Table 5.4 in the connection request.

At any time a lower latency is required, for example to perform key refresh or encryption setup, this should be preceded with a connection parameter update to the minimum and maximum connection interval values defined in Table 5.4 and a connection latency of zero. This fast connection interval should be maintained as long as low latency is required. After that, it should switch to the preferred connection parameters as decided by the Blood Pressure Sensor using the GAP Connection Parameter Update procedure.

If the Collector receives an undirected connectable advertisement from a bonded Blood Pressure Sensor while performing the General or Selective Connection Establishment Procedure and the Blood Pressure Sensor supports multiple bonds (i.e. the Multiple Bond Support bit of the Blood Pressure Feature characteristic is set to 1 meaning ‘Multiple Bonds supported’) then the Collector should decode the Target Address AD Type to attempt to get the target address. If supported by the Blood Pressure Sensor, this will allow the Collector to determine the intended recipient of the advertisement.

If the Advertising Data or Scan Response Data contains a Target Address AD Type;

If the Advertising Data and Scan Response Data do not contain a Target Address AD Type, the Collector may initiate Connection to the Sensor using Direct Connection Establishment Procedure.

For the case where a Collector is associated with a Blood Pressure Sensor for multiple users, the User ID field in the Blood Pressure Measurement characteristic shall be used by the Collector to associate measurements with the correct user.

This section outlines an optional procedure that is applicable when a Collector supports the use of the Service Data AD Type for the Blood Pressure Service.

The Service Data AD Type described in Section 3.1.1 provides a mechanism to reduce unwanted connection requests by unintended Collectors when Undirected Connectable Mode is used and when a Sensor has new data to send. Refer to Section 5.1.6 for the procedure from the Sensor perspective.

When a Collector receives an undirected connectable advertisement from a Sensor that includes the Service Data AD Type in its Advertising Data, the Collector shall read the User ID List field of the Service Data AD Type to determine whether any new data is pending since the last time it read the User ID List field. If the value of one of the User IDs in the User ID List field matches the value assigned to that Collector, then the Collector should attempt to connect to the Sensor to receive or retrieve new measurements.