Glucose Profile

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

For enhanced user experience a Glucose 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 Glucose Sensor may support the write property for the Device Name characteristic in order to allow a Collector to write a device name to the Glucose Sensor.

For enhanced user experience a Glucose 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 Glucose Sensor does not support multiple bonds, the Glucose Sensor shall not use a Target Address AD Type. As defined in the Glucose Service, the value of the Multiple Bond Supported bit of the Glucose Feature characteristic is to be set according to the Glucose Sensor’s functionality so a Collector can determine if the Glucose Sensor does not support a Target Address AD Type (i.e. if the Multiple Bond Supported bit is 0) or potentially supports a Target Address AD Type (i.e. if the Multiple Bond Supported bit is 1). In the following sections the words “a Target Address AD Type” are intended to refer to either of the defined Target Address AD Types.

Sensor implementers should carefully consider the possible impact on the privacy of the user when the Sensor uses one of the Target Address AD Types. Although the use of a random address does make identification more difficult, if the address is used for long periods of time it could be associated with the user.

The Collector shall discover the Glucose Service.

The Collector may discover the Device Information 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.

Within the context of the Glucose Service, a record (also referred to as a patient record) consists of a Glucose Measurement characteristic and may or may not be followed by a corresponding Glucose Measurement Context characteristic. The Collector shall determine if a Glucose Measurement record includes a corresponding Glucose Measurement Context value based on the Context Information Flag in the Flags field. If the Context Information Flag for a Glucose Measurement record is set to 1, then a corresponding Glucose Measurement Context notification will follow the Glucose Measurement notification. See Section 4.7.4.1 for recommendations on detecting and addressing single record errors.

The table below shows the requirements for the RACP procedures (Op Codes, Operators and Operands) in the context of this profile:

Notes:

The Collector shall write to the RACP characteristic using one of the supported Op Codes in Table 4.4 to request a Glucose 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 the following sections.

The Collector shall be tolerant of the fact that the user 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, it 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 due to the fact that 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, may not be able to ensure 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, a Collector shall be tolerant of the fact that other Collectors may alter the contents of the Sensor’s measurement database. E.g. Collector #2 may delete records from the Sensor’s database that Collector #1 will then never be able to retrieve. The handling of multiple bonds is vendor-specific. E.g. a Sensor may only allow certain Collectors (such as a doctor’s computer) to use the Delete Store Records procedure.

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

If the Collector writes an Op Code to the RACP characteristic that is unsupported by the Glucose Sensor, it will receive a Response Code RACP indication with the Response Code Value set to Op Code not supported.

If the Collector writes an Operator to the RACP characteristic that is invalid, it will receive a Response Code RACP indication with the Response Code Value set to Invalid Operator.

If the Collector writes an Operator to the RACP characteristic that is not supported by the Glucose Sensor, it will receive a Response Code RACP indication with the Response Code Value set to Operator not supported.

If the Collector writes an Operand to the RACP characteristic that is invalid, it will receive a Response Code RACP indication with the Response Code Value set to Invalid Operand.

If the Collector receives a Response Code RACP indication with the Response Code Value set to Procedure not completed, this indicates that the Sensor is unable to complete the procedure for some unknown reason, and the procedure shall be considered to have failed.

If the Collector writes a Filter Type within an Operand to the RACP characteristic that is not supported by the Glucose Sensor, it will receive a Response Code RACP indication with the Response Code Value set to Operand Not Supported.

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.

A RACP procedure may consist of multiple notifications of the Glucose Measurement characteristic and optionally the Glucose Measurement Context characteristic. A RACP procedure may consist of multiple notifications of the Glucose Measurement characteristic and optionally the Glucose Measurement Context 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 as 30 seconds in Volume 2 Part F section 3.3.3 of [2], from the start of the procedure or from the last notification that was received as a result of this procedure.

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

Thus 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 Glucose Measurement notification or Glucose Measurement Context notification is received. The timer shall be stopped when a 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.

This procedure is applicable when the Glucose Sensor connects to a Collector to which it is not yet bonded (i.e. initial connection). This is typically initiated through user interaction when a user intends to bond the Glucose Sensor with a Collector.

The Glucose Sensor should use the GAP Limited Discoverable Mode with connectable undirected advertising events when establishing an initial connection. The T_GAP(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 Glucose 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 Glucose 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 Glucose Sensor, the Glucose Sensor may exit the GAP discoverable mode.

The Glucose Sensor shall 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 Glucose 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 Glucose Sensor should perform the GAP Terminate Connection procedure. This allows the Collector to perform any additional required actions (e.g. read Glucose Feature characteristic).

This procedure is applicable after the Glucose 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 new record has been taken.

A Glucose Sensor shall enter the GAP Undirected Connectable Mode either when commanded by the user to initiate a connection to a Collector or when a Glucose Sensor has one or more stored records to send to a previously connected Collector.

The Glucose 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 Glucose 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 Glucose 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 Glucose Sensor, the Glucose Sensor may exit the GAP connectable mode.

If the Client Characteristic Configuration descriptor has been configured to enable notifications and the Collector does not perform a RACP procedure, then after waiting for an idle connection timeout (see Section 5.1.4), the Glucose Sensor should perform the GAP Terminate Connection procedure. This allows the Collector to perform any additional required actions (e.g. read Glucose Feature characteristic).

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

When a connection is terminated due to link loss, a Glucose 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 Glucose Sensor should perform the GAP Terminate Connection procedure if the connection is idle for more than 5 seconds. For devices that support Man in the Middle (MITM) protection, this duration may need to be longer to allow completion of the pairing sequence.

This section is applicable when a Glucose Sensor supports multiple bonds.

A Glucose 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 Glucose Sensor advertisement intended for another bonded Collector. The applicable Public Target Address AD Type 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 Glucose 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 Glucose Sensor uses a Target Address AD Type and was given a random address by that Collector, the Glucose Sensor shall use that address in the Random Target Address AD Type. A Glucose 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 Glucose Sensor should also use a Filter Accept List to avoid connection with an unwanted Collector.

Sensor implementations may, via the User Interface, enable the user to identify primary Collector(s) (i.e. personal Collector or Collectors used daily) and secondary Collector(s) (i.e. caregiver Collector or Collectors used monthly). For reduced power consumption, implementations should avoid advertising to secondary Collectors (i.e. infrequently available Collectors) unless triggered through user interaction.

This procedure is applicable for connection establishment when the Collector connects to a Glucose Sensor to which it is not yet bonded (i.e. initial connection). This is typically initiated through user interaction when a user intends to bond the Collector with the Glucose Sensor.

A Collector should use the GAP Limited Discovery procedure to discover a Glucose 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 below to reduce power consumption.

Once the Glucose 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 the table above 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 shall bond with the Glucose Sensor during this procedure to optimize connecting to the Glucose Sensor again using the procedure in Section 5.2.2. Once a bond is created, the Collector should write the address of the Glucose Sensor in the Collector controller’s Filter Accept List.

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

The Glucose Sensor typically terminates the connection if the Collector does not perform a RACP procedure after waiting for an idle connection timeout.

This procedure is applicable after the Collector has bonded with the Glucose 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 Glucose 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 Glucose Sensor while performing the General or Selective Connection Establishment Procedure, and the Glucose Sensor supports multiple bonds (i.e. the Multiple Bond Supported bit of the Glucose 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 Glucose Sensor did not have the <<Service Changed>> characteristic), and set the Glucose Sensor Client Characteristic Configuration descriptors again before using any of the services referenced by this profile in case the configuration was altered or lost.

The Glucose 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 Glucose 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 interval limits 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 Glucose Sensor using the GAP Connection Parameter Update procedure.

If the Collector receives an undirected connectable advertisement from a bonded Glucose Sensor while performing the General or Selective Connection Establishment Procedure and the Glucose Sensor supports multiple bonds (i.e. the Multiple Bond Supported bit of the Glucose 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 Glucose 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.