-
Revision: v1.0
-
Revision Date: 2020-12-15
-
Group Prepared By: Sports and Fitness Working Group
Revision History
|
Revision Number |
Date |
Comments |
|---|---|---|
|
v1.0 |
2020-12-15 |
Adopted by the Bluetooth SIG Board of Directors. |
Contributors
|
Name |
Company |
|---|---|
|
Javier Espina |
Koninklijke Philips N.V. |
|
Laurence Richardson |
Qualcomm Technologies International, Ltd. |
|
Leif-Alexandre Aschehoug |
Nordic Semiconductor ASA |
|
Erik Moll |
Koninklijke Philips N.V. |
Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.
Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. Each option identified in the specification is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”
Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.
Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.
Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.
Copyright © 2017–2020. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.
1. Introduction
The Physical Activity Monitor Profile (PAMP) is used to enable a data collection device to obtain data from a Physical Activity Monitor that exposes the Physical Activity Monitor Service (PAMS) [1]. The PAMP may also be used to control a Physical Activity Monitor (for example, to create and delete sessions).
1.1. Profile dependencies
This profile requires the Generic Attribute Profile (GATT) (Volume 3, Part G in the Bluetooth Core Specification [2]).
This profile depends on the Device Time Profile [6].
1.2. Conformance
If conformance to this specification is claimed, all capabilities indicated as mandatory for this specification shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated.
1.3. Bluetooth specification release compatibility
This specification is compatible with Bluetooth Core Specification v4.2 [2] or later.
1.4. Language
1.4.1. Language conventions
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:
|
shall |
is required to – used to define requirements. |
|
must |
is used to express: a natural consequence of a previously stated mandatory requirement. OR an indisputable statement of fact (one that is always true regardless of the circumstances). |
|
will |
it is true that – only used in statements of fact. |
|
should |
is recommended that – used to indicate that among several possibilities one is recommended as particularly suitable, but not required. |
|
may |
is permitted to – used to allow options. |
|
can |
is able to – used to relate statements in a causal manner. |
|
is |
is defined as – used to further explain elements that are previously required or allowed. |
|
note |
Used to indicate text that is included for informational purposes only and is not required in order to implement the specification. Each note is clearly designated as a “Note” and set off in a separate paragraph. |
For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.
1.4.2. Reserved for Future Use
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.
1.4.3. Prohibited
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.
2. Configuration
2.1. Roles
The profile defines two roles: Physical Activity Monitor and Collector.
The Physical Activity Monitor is the device that reports physical-activity-related data to a Collector. The Collector is the device (for example, a mobile phone) that receives the physical-activity-related data from a Physical Activity Monitor. If supported by the Physical Activity Monitor, the Collector may also control the Physical Activity Monitor (for example, to start, stop, and delete sessions).
-
The Physical Activity Monitor shall be a GATT Server.
-
The Collector shall be a GATT Client.
2.2. Role/service relationships
Figure 2.1 shows the relationship between services and profile roles. Profile roles are represented by blue boxes and the services are represented by gray boxes. Items shown in dashed boxes are optional.
 |
A Physical Activity Monitor instantiates the PAMS [1] and the Device Information Service [3].
A Physical Activity Monitor may instantiate the User Data Service (UDS) [4].
A Physical Activity Monitor may support the Device Time Server role (as defined in [6]) and instantiate the Device Time Service (as defined in [5]).
A Collector shall support the Device Time Client role as defined in [6].
2.3. Concurrency limitations/restrictions
There are no concurrency limitations or restrictions for the Collector and Physical Activity Monitor imposed by this profile.
2.4. Topology limitations/restrictions
2.4.1. Topology limitations/restrictions for Low Energy
This section describes topology limitations and restrictions when the profile is used over Bluetooth Low Energy (LE) transport.
The Physical Activity Monitor shall use the Generic Access Profile (GAP) Peripheral role defined in Volume 3, Part C, Section 2.2.2 of the Core Specification [2].
The Collector shall use the GAP Central role.
2.4.2. Topology limitations/restrictions for BR/EDR
There are no topology limitations or restrictions when the profile is used over the Basic Rate/Enhanced Data Rate (BR/EDR) transport.
2.5. Transport dependencies
There are no transport restrictions imposed by this profile specification.
Where the term BR/EDR is used in this document, it also includes the optional use of Alternate MAC/PHYs (AMP).
3. Physical Activity Monitor role requirements
The Physical Activity Monitor shall instantiate one and only one PAMS [1] (see specific recommendations in Section 3.1).
The PAMS shall be instantiated as a «Primary Service».
The Physical Activity Monitor shall instantiate one and only one Device Information Service [3] (see additional requirements in Section 3.3).
The Physical Activity Monitor may instantiate one and only one User Data Service [4].
The User Data Service [4], if supported, shall be instantiated as a «Primary Service» (see additional requirements in Section 3.2).
The Physical Activity Monitor should instantiate the Device Time Service [5] (see additional requirements in Section 3.4).
|
Service |
Physical Activity Monitor |
|---|---|
|
Physical Activity Monitor Service [1] |
M |
|
Device Information Service [3] |
M |
|
User Data Service [4] |
C.1 |
|
Device Time Service [5] |
O |
- M:
-
Mandatory
- O:
-
Optional
- C.1:
-
Mandatory if the Physical Activity Monitor supports multiple users, otherwise Optional.
Other than the Physical Activity Monitor requirements in this section, refer to Sections 5.1 and 6.1 for additional Physical Activity Monitor requirements for the LE transport, and Sections 5.3 and 6.3 for the BR/EDR transport.
3.1. Additional Physical Activity Monitor service requirements
This section describes additional requirements beyond those defined in the PAMS.
The Physical Activity Monitor shall send indications or notifications of the data characteristics to the Collector, if the Client Characteristic Configuration descriptor associated with these data characteristics is properly configured. However, if the Physical Activity Monitor supports the User Data Service, see additional requirements related to the sending of indications or notifications in Section 3.2. Refer to Section 4.8 for Collector requirements to access the measurement data.
3.1.1. Additional requirements for Low Energy transport
This section describes additional Physical Activity Monitor requirements beyond those defined in the PAMS when using this profile over the LE transport.
3.1.1.1. Service UUIDs AD type
While in GAP Discoverable mode for initial connection to a Collector, the Physical Activity Monitor should include the PAMS Universally Unique Identifier (UUID) defined in [7] in the Service UUID’s Advertising Data (AD) type field. This enhances the user experience, because a Physical Activity Monitor may be identified by the Collector before initiating a connection.
3.1.1.2. Local Name AD type
For an enhanced user experience, a Physical Activity Monitor may 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.
3.1.1.3. Writable GAP Device service characteristic
The Physical Activity Monitor may support the write property for the Device Name characteristic in order to allow a Collector to write a device name to the Physical Activity Monitor.
3.1.1.4. Appearance AD type
For an enhanced user experience, a Physical Activity Monitor should include the value of the Appearance characteristic defined in [2] in its Advertising Data or Scan Response Data.
3.2. Additional User Data Service requirements
This section describes additional requirements beyond those defined in the User Data Service (UDS) [4].
The Physical Activity Monitor shall maintain the value of the Database Change Increment characteristic separately for each supported User Index.
For Physical Activity Monitors that support multiple users, PAMS data characteristic indications and notifications shall not be sent unless the user has given consent via UDS for the specified user (i.e., only for the user corresponding to the User Index value). If user data is deleted (i.e., using the Delete User Data procedure), then only data corresponding to the User Index value shall be deleted.
A Physical Activity Monitor should expose the UDS Characteristics defined in Table 3.2.
|
UDS Characteristic |
Requirement |
|---|---|
|
First Name |
O |
|
Middle Name |
O |
|
Last Name |
O |
|
Age |
O |
|
Date of Birth |
O |
|
Gender |
O |
|
Weight |
O |
|
Height |
O |
|
High Resolution Height |
O |
|
Stride Length |
O |
|
Handedness |
O |
|
Device Wearing Position |
O |
|
Heart Rate Max |
O |
|
Resting Heart Rate |
O |
|
Maximum Recommended Heart Rate |
O |
|
Two Zone Heart Rate Limits |
O |
|
Three Zone Heart Rate Limits |
O |
|
Four Zone Heart Rate Limits |
O |
|
Five Zone Heart Rate Limits |
O |
|
VO2 Max |
O |
|
High Intensity Exercise Threshold |
O |
|
Activity Goal |
O |
|
Sedentary Interval Notification |
O |
|
Caloric Intake |
O |
|
Language |
O |
|
Preferred Units |
O |
- O:
-
Optional
If the Date of Birth characteristic exists in the User Data Service, then a value of 0 for Year shall not be used, but a value of 0 for Month and Day may be used.
3.3. Additional Device Information Service requirements
This section describes additional requirements beyond those defined in the Device Information Service [3].
The requirements for support of Device Information Service characteristics are defined in Table 3.3. This allows the Collector to log the type of equipment used in a session.
|
Device Information Service Characteristic |
Requirement |
|---|---|
|
Manufacturer Name String |
M |
|
Model Number String |
M |
|
System ID |
O |
- M:
-
Mandatory
- O:
-
Optional
System ID is required for implementations requiring compliance with IEEE 11073-20601 [9].
3.4. Device Time Server role
The Physical Activity Monitor might implement the Device Time Server role in accordance with the Device Time Profile [6].The Physical Activity Monitor should use the Device Time Server role as the mechanism to expose a time source to Collectors.
The date and time of the Physical Activity Monitor may be updated by various means such as via a simple user interface (UI) on the Physical Activity Monitor or via the Device Time Service [5]. The Physical Activity Monitor should use the date and time updated via the Device Time Service [5] to populate the base time and time offset information fields of a session.
3.5. Transcoding to the ISO/IEEE 11073 ecosystem
Characteristic values in the services listed in this profile may be transcoded by the Collector for use in the ISO/IEEE 11073 ecosystem. See Section 2 of the Personal Health Devices Transcoding White Paper [8] for more information.
4. Collector role requirements
The Collector shall use the Physical Activity Monitor Service [1], the User Data Service [4], and the Device Time Service [5].
The Collector should use the Device Information Service [3].
|
Service |
Collector |
|---|---|
|
Physical Activity Monitor Service |
M |
|
Device Information Service |
O |
|
User Data Service |
M |
|
Device Time Service |
M |
- M:
-
Mandatory
- O:
-
Optional
Table 4.2 describes the profile requirements for a Collector.
|
Profile Requirement |
Section |
Support in Collector |
|---|---|---|
|
Service Discovery |
– |
– |
|
- Physical Activity Monitor Service [1] Discovery |
M |
|
|
- Device Information Service [3] Discovery |
C.1 |
|
|
- User Data Service [4] Discovery |
M |
|
|
- Device Time Service [5] Discovery |
M |
|
|
Characteristic Discovery |
– |
– |
|
- Physical Activity Monitor Service [1] Characteristic Discovery |
M |
|
|
- Device Information Service [3] Characteristic Discovery |
C.1 |
|
|
- User Data Service [4] Characteristic Discovery |
M |
|
|
- Device Time Service [5] Characteristic Discovery |
M |
|
|
Physical Activity Monitor Service [1] Characteristic Support |
– |
– |
|
- Physical Activity Monitor Features |
M |
|
|
- General Activity Instantaneous Data |
M |
|
|
- General Activity Summary Data |
M |
|
|
- CardioRespiratory Activity Instantaneous Data |
O |
|
|
- CardioRespiratory Activity Summary Data |
O |
|
|
- Step Counter Activity Summary Data |
O |
|
|
- Sleep Activity Instantaneous Data |
O |
|
|
- Sleep Activity Summary Data |
O |
|
|
- Physical Activity Monitor Control Point |
M |
|
|
- Physical Activity Current Session |
M |
|
|
- Physical Activity Session Descriptor |
M |
|
|
Device Information Service [3] Characteristics Support |
C.1 |
|
|
User Data Service [4] Characteristic Support |
– |
– |
|
- Database Change Increment |
C.2 |
|
|
- User Control Point |
M |
|
|
- User Index |
– |
M |
|
- User Data Service characteristics for remote updating of user data |
O |
|
|
Device Time Client Role Support |
M |
- M:
-
Mandatory
- O:
-
Optional
- C.1:
-
Mandatory if the Device Information Service is used, otherwise not specified.
- C.2:
-
Mandatory if writing to UDS Characteristics is supported, otherwise Optional.
4.1. GATT sub-procedure requirements
Requirements in this section represent a minimum set of requirements for a Collector. Other GATT sub-procedures may be used if supported by both client and server.
Table 4.3 summarizes additional GATT sub-procedure requirements beyond those required by all GATT Clients.
|
GATT Sub-Procedure |
Collector Requirements |
|---|---|
|
Discover All Primary Services |
C.1 |
|
Discover Primary Services by Service UUID |
C.1 |
|
Discover All Characteristics of a Service |
C.2 |
|
Discover Characteristics by UUID |
C.2 |
|
Discover All Characteristic Descriptors |
M |
|
Read Characteristic Value |
M |
|
Read Long Characteristic Values |
M |
|
Write Characteristic Value |
M |
|
Write Long Characteristic Values |
O |
|
Read Characteristic Descriptors |
M |
|
Write Characteristic Descriptors |
M |
- M:
-
Mandatory
- O:
-
Optional
- C.1:
-
Mandatory to support at least one of these Service Discovery sub-procedures when using the LE transport. Excluded when using the BR/EDR transport (see Section 4.2).
- C.2:
-
Mandatory to support at least one of these Characteristic Discovery sub-procedures.
4.2. Service discovery
When using the LE transport, the Collector shall perform primary service discovery by using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure.
The Collector shall discover the Physical Activity Monitor Service, the Device Time Service, and the User Data Service.
The Collector may discover the Device Information Service.
When using the BR/EDR transport, the Collector shall perform service discovery by retrieving the Service Discovery Protocol (SDP) record of the PAMS as defined in [1].
4.3. Characteristic discovery
Where a characteristic is discovered that can be indicated or notified, the Collector shall also discover the associated Client Characteristic Configuration descriptor.
4.3.1. Physical Activity Monitor Service characteristic discovery
The Collector shall use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure to discover the characteristics of the service.
The Collector shall use the GATT Discover All Characteristic Descriptors sub-procedure to discover the characteristic descriptors.
The discovery requirements for the Collector are shown in Table 4.4.
Note
Note: The GATT specification [2] requires the Collector to ignore any additional characteristics in the service declaration.
|
Characteristics |
Discovery Requirements for Collector |
|---|---|
|
Physical Activity Monitor Features |
M |
|
General Activity Instantaneous Data |
M |
|
General Activity Summary Data |
M |
|
CardioRespiratory Activity Instantaneous Data |
O |
|
CardioRespiratory Activity Summary Data |
O |
|
Step Counter Activity Summary Data |
O |
|
Sleep Activity Instantaneous Data |
O |
|
Sleep Activity Summary Data |
O |
|
Physical Activity Monitor Control Point |
M |
|
Physical Activity Current Session |
M |
|
Physical Activity Session Descriptor |
M |
- M:
-
Mandatory
- O:
-
Optional
4.3.2. Device Information Service characteristic discovery
The Collector may discover the characteristics of the Device Information Service.
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.
4.3.3. User Data Service characteristic discovery
If the Physical Activity Monitor exposes the User Data Service, then the Collector shall discover the characteristics of the User Data Service.
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.
If the Physical Activity Monitor exposes the User Data Service, the requirements for the Collector apply. They are shown in Table 4.5.
|
Characteristics |
Discovery Requirements for Collector |
|---|---|
|
User Control Point |
M |
|
Database Change Increment |
C.1 |
|
User Index |
M |
|
First Name |
O |
|
Middle Name |
O |
|
Last Name |
O |
|
Age |
O |
|
Date of Birth |
O |
|
Gender |
O |
|
Weight |
O |
|
Height |
O |
|
High Resolution Height |
O |
|
Stride Length |
O |
|
Handedness |
O |
|
Device Wearing Position |
O |
|
Heart Rate Max |
O |
|
Resting Heart Rate |
O |
|
Maximum Recommended Heart Rate |
O |
|
Two Zone Heart Rate Limits |
O |
|
Three Zone Heart Rate Limits |
O |
|
Four Zone Heart Rate Limits |
O |
|
Five Zone Heart Rate Limits |
O |
|
VO2 Max |
O |
|
High Intensity Exercise Threshold |
O |
|
Activity Goal |
O |
|
Sedentary Interval Notification |
O |
|
Caloric Intake |
O |
|
Language |
O |
|
Preferred Units |
O |
|
Other UDS Characteristics |
O |
- M:
-
Mandatory
- O:
-
Optional
- C.1:
-
Mandatory for Collectors that write UDS Characteristics, otherwise Optional.
4.3.4. Device Time Service characteristic discovery
The Collector may discover the characteristics of the Device Time Service.
For the Collector to discover the characteristics of the Device Time Service, it shall use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure.
4.4. Physical Activity Monitor Service characteristics
As defined in the PAMS [1], a Data Record consists of multiple session/sub-session-related data that is sent to the Collector via notifications or indications of a data characteristic (i.e., any of the instantaneous data characteristics or summary data characteristics defined in Section 3 of the PAMS [1]).
If the Collector enables notifications or indications of a data characteristic, then the Collector shall follow the procedure below to re-assemble the data:
-
The Collector shall inspect the values of the First Segment and Last Segment bits of the Header field and shall interpret the bits as shown in Table 4.6.
First Segment
Last Segment
Interpretation
1 (True)
1 (True)
This is the first and last segment; there is only one segment.
1 (True)
0 (False)
This is the first segment of a set and more segments will follow.
0 (False)
0 (False)
This is a continuation segment and more segments will follow.
0 (False)
1 (True)
This is a continuation segment and is the last of the set.
Table 4.6. Interpretation of First Segment and Last Segment bits of the Header field
-
If the value of the Last Segment bit of the Header field is 0 (False), then the Collector shall wait for another notification or indication of the data characteristic containing additional data. This step shall be repeated until the Collector receives a notification or indication of the data characteristic in which the value of the Last Segment bit of the Header field is 1 (True). The Collector should wait for the anticipated notification for at least one second; however, if the waiting time exceeds an implementation-specific timeout, then the Collector may abandon the procedure.
-
The Collector shall inspect the Rolling Segment Counters associated with the notifications or indications to verify that they are consecutive. If there is a discontinuity in the Rolling Segment Counters, then the Collector should discard the data and wait for a new notification or indication to be received in which the value of the First Segment bit is 1 (True), indicating the start of a new Data Record.
-
The Collector shall re-assemble the data by concatenating the values of the data in the received segments, preserving the same order as indicated by the Rolling Segment Counters, with the octet received for which the First Segment bit is 1 (True) as the least significant octet, and the octet received for which the Last Segment bit is 1 (True) as the most significant octet.
The Collector shall then parse the reassembled data in accordance with the definition of the data characteristic format, which is specified in the PAMS [1].
4.4.1. Physical Activity Monitor Features
The Collector shall read the Physical Activity Monitor Features characteristic to determine the supported features of the Physical Activity Monitor in order to understand its capabilities.
4.4.2. General Activity Instantaneous Data
The Collector may enable notifications of the General Activity Instantaneous Data characteristic.
If the Physical Activity Monitor Features characteristic does not denote support for the Device Worn feature, then the Collector shall ignore the Device Worn bit of the Flags field of the General Activity Instantaneous Data characteristic.
4.4.3. General Activity Summary Data
The Collector may enable indications of the General Activity Summary Data characteristic.
4.4.4. CardioRespiratory Activity Instantaneous Data
The Collector may enable notifications of the CardioRespiratory Activity Instantaneous Data characteristic.
If the Physical Activity Monitor Features characteristic does not denote support for the Device Worn feature, then the Collector shall ignore the Device Worn bit of the Flags field of the CardioRespiratory Activity Instantaneous Data characteristic.
4.4.5. CardioRespiratory Activity Summary Data
The Collector may enable indications of the CardioRespiratory Activity Summary Data characteristic.
4.4.6. Step Counter Activity Summary Data
The Collector may enable indications of the Step Counter Activity Summary Data characteristic.
4.4.7. Sleep Activity Instantaneous Data
The Collector may enable notifications of the Sleep Activity Instantaneous Data characteristic.
If the Physical Activity Monitor Features characteristic does not denote support for the Device Worn feature, then the Collector shall ignore the Device Worn bit of the Flags field of the Sleep Activity Instantaneous Data characteristic.
4.4.8. Sleep Activity Summary Data
The Collector may enable indications of the Sleep Activity Summary Data characteristic.
4.4.9. Physical Activity Monitor Control Point
Before requesting a Physical Activity Monitor Control Point procedure, the Collector shall configure the Physical Activity Monitor Control Point characteristic for indications.
The Collector may write to the Physical Activity Monitor Control Point characteristic to request a desired procedure.
A procedure begins when the Collector writes an opcode to the Physical Activity Monitor Control Point characteristic to perform some desired action.
A successful Start Session/Sub-session, Stop Session, Delete Ended Session, or Set Average Activity Type procedure ends when the Physical Activity Monitor sends an Attribute Protocol (ATT) Write Response PDU.
An unsuccessful Start Session/Sub-session, Stop Session, Delete Ended Session, or Set Average Activity Type procedure ends when the Physical Activity Monitor sends an ATT Error Response PDU.
A successful Enquire Sessions, Enquire Sub-sessions, or Get Ended Session Data procedure ends when the Collector sends the Handle Value Confirmation to acknowledge the Physical Activity Monitor Control Point indication sent by the Physical Activity Monitor at the end of a successful procedure (i.e., Get Ended Session Data Success Response).
An unsuccessful Enquire Sessions, Enquire Sub-sessions, or Get Ended Session Data procedure ends when the Physical Activity Monitor sends an ATT Error Response PDU, or, alternatively, when the Collector sends the Handle Value Confirmation to acknowledge the Physical Activity Monitor Control Point indication sent by the Physical Activity Monitor at the end of a failed procedure (i.e., with the Get Ended Session Data Error Response error code).
4.4.9.1. Physical Activity Monitor Control Point procedure requirements
Table 4.7 shows the Collector requirements for the Physical Activity Monitor Control Point procedures (opcodes) in the context of this profile.
|
Procedure (Opcode) |
Requirement |
|---|---|
|
Enquire Sessions |
M |
|
Enquire Sub-sessions |
M |
|
Get Ended Session Data |
M |
|
Start Session/Sub-session |
M |
|
Stop Session |
M |
|
Delete Ended Session |
M |
|
Set Average Activity Type |
M |
- M:
-
Mandatory
4.4.10. Physical Activity Current Session
The Collector shall enable indications of the Physical Activity Current Session characteristic to receive updated information on the current session of the Physical Activity Monitor. The Collector may also read this characteristic for the same purpose.
4.4.11. Physical Activity Session Descriptor
The Collector shall enable indications of the Physical Activity Session Descriptor characteristic.
4.5. Device Information Service characteristics
The Collector may read the value of Device Information Service characteristics.
4.6. User Data Service characteristics
The Collector may read and write the value of User Data Service characteristics.
For UDS characteristics that may exceed the negotiated ATT_MTU size (e.g., UTF8-based characteristics), the Collector should use the GATT Read Long Characteristic Value and GATT Write Long Characteristic Value sub-procedures, respectively.
When the Collector initiates a connection to a Physical Activity Monitor that exposes UDS, the Collector should use the Consent procedure defined in Section 4.6.2.2.2, along with the Consent Code defined during the registration procedure, in order to read or write the User Data characteristics.
For more information about the user data access methods, see Section 4.8.
4.6.1. Database Change Increment characteristic
The Database Change Increment characteristic is used to perform synchronization functions (e.g., if the Physical Activity Monitor allows the user to update his or her data through its UI, the Collector will be informed of this update).
If the Physical Activity Monitor supports the Database Change Increment characteristic, then it is optional for the Collector to configure notifications of the Database Change Increment characteristic (i.e., via the Client Characteristic Configuration descriptor), except for Collectors that support the User Data Synchronization procedure, for which notifications become mandatory, as defined in Section 4.6.4.
If the Collector receives a notification of the Database Change Increment characteristic, which alerts the Collector that a change to at least one of the values has occurred, then the Collector should read the UDS characteristic values that the Collector supports.
If the Collector does not support the User Data Synchronization procedure, after the Collector has completed writing to UDS characteristics, then the Collector shall write an incremented value to the Database Change Increment characteristic of the Physical Activity Monitor (i.e., the Collector shall increment the current value by 1).
If the Collector supports the User Data Synchronization procedure, then the requirements in Section 4.6.4 apply.
The Collector may read the Database Change Increment characteristic to determine whether the value cached in the Collector is equal to, greater than, or less than the value in the Physical Activity Monitor. The result of this value comparison is used in the User Data Synchronization procedure as defined in Section 4.6.4.
A rollover of the value of the Database Change Increment characteristic is extremely unlikely over the life of the device, but if a rollover occurs, this may be handled in an implementation-specific way (e.g., the implementation may ask the user to confirm the values via the UI).
For more information about the user data access methods, see Section 4.8.
4.6.2. User Control Point characteristic
Before performing a User Control Point procedure, the Collector shall configure the User Control Point characteristic for indications (i.e., 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 an opcode to the User Control Point to perform some desired action, and it ends when the Collector sends the Handle Value Confirmation to acknowledge the User Control Point indication sent by the Physical Activity Monitor at the end of the procedure. This indication includes the Response Code, the Requested Op Code, and the Response Value, and may also include a Response Parameter as defined in [4].
For more information about the user data access methods, see Section 4.8.
4.6.2.1. User Control Point procedure requirements
Table 4.8 shows the Collector requirements for the User Control Point procedures (opcodes) in the context of this profile.
|
Procedure (Opcode) |
Requirement |
|---|---|
|
Register New User |
M |
|
Consent |
M |
|
Delete User Data |
M |
- M:
-
Mandatory
4.6.2.2. User Control Point behavioral description
The Collector shall write to the User Control Point characteristic by using one of the supported opcodes in Table 4.8 to request a Physical Activity Monitor to perform a procedure. This may include a parameter that is valid within the context of that opcode as defined in [4].
4.6.2.2.1. Register New User procedure
To register a new user in the Physical Activity Monitor, the Collector shall use the Register New User opcode followed by a parameter value that represents the Consent Code defined by the user (or automatically generated by the Collector) as defined in [4].
The Collector shall wait for the Response Code indication of the User Control Point with the Response Value set to Success, indicating successful operation, with a Response Parameter value that represents the User Index assigned by the Physical Activity Monitor to the new user, or wait for the procedure to time out according to the procedure timeout operation described in Section 4.6.2.3. When the procedure is successful, the Physical Activity Monitor will return a Response Code containing the User Index.
See Section 4.7 for general error-handling procedures.
4.6.2.2.2. Consent procedure
To request the consent of a Physical Activity Monitor user in order to access the user’s UDS characteristics, the Collector shall use the Consent opcode followed by an array of 3 UINT8 parameter values that represents the User Index (1 octet), followed by the Consent Code (2 octets) defined by the user as defined in [4].
The Collector shall wait for the Response Code indication of the User Control Point with the Response Value set to Success, indicating a successful operation, or for the procedure to time out according to the procedure timeout operation described in Section 4.6.2.3.
See Section 4.7 for general error-handling procedures.
4.6.2.2.3. Delete User Data procedure
To request the deletion of the UDS characteristics of the Physical Activity Monitor, the Collector shall use the Delete User Data procedure.
The Collector shall wait for the Response Code indication of the User Control Point with the Response Value set to Success, indicating successful operation, or for the procedure to time out according to the procedure timeout operation described in Section 4.6.2.3.
See Section 4.7 for general error-handling procedures.
4.6.2.3. Procedure timeout
In the context of the User Control Point characteristic, a procedure is started when the Collector writes a particular opcode to the User Control Point characteristic to perform some desired action, and it ends when the Collector sends the Handle Value Confirmation to acknowledge the User Control Point characteristic indication sent by the Physical Activity Monitor at the end of the procedure with the opcode set to Response Code.
In the context of the User Control Point characteristic, a procedure is not considered started and is not queued in the Physical Activity Monitor when a write to the User Control Point results in an ATT Error Response PDU.
A procedure is considered to have timed out if a User Control Point indication is not received within 30 seconds from the start of the procedure.
If the link is lost while a User Control Point procedure is in progress, then the procedure shall be considered to have timed out.
Therefore, a Collector shall start a timer with the value set to 30 seconds after the write response is received from the Physical Activity Monitor. The timer shall be stopped when a User Control Point indication is received and the opcode is set to Response Code. If the timer expires, then the procedure shall be considered to have failed.
If a User Control Point procedure times out, then no new User Control Point procedure shall be started by the Collector until a new link is established with the Physical Activity Monitor.
4.6.3. User Data Service characteristics for remote updating of user data
If the Collector supports remote updating of user data to the Physical Activity Monitor (e.g., First Name, Height, 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 [4].
4.6.4. User Data Synchronization procedure
If the User Data Synchronization procedure is supported, then the requirements in this section apply.
When a connection is established to a Physical Activity Monitor with a previously registered user, and the Consent procedure has succeeded, 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.9. After the synchronization procedure is completed, the Collector and the Physical Activity Monitor will have the same UDS characteristic and Database Change Increment values.
|
Condition |
Action Requirement |
|---|---|
|
Database Change Increment values are equal in both the Collector and the Physical Activity Monitor. |
The databases are synchronized and do not require any action by the Collector. |
|
The Database Change Increment value in the Physical Activity Monitor is greater than the value in the Collector (i.e., the user data at the Physical Activity Monitor is more recent). |
The Collector shall read and cache all the UDS characteristics supported by the Collector. The Collector shall also cache the Database Change Increment value for future use. |
|
The Database Change Increment value in the Physical Activity Monitor is less than the value in the Collector (i.e., the user data at the Collector is more recent). |
The Collector shall write updated UDS characteristics to the Physical Activity Monitor. After the user data is updated, the Collector shall also write its local Database Change Increment value to the Physical Activity Monitor to complete the synchronization procedure. |
If notifications of the Database Change Increment characteristic are supported by the Physical Activity Monitor, then the Collector shall configure the Database Change Increment characteristic for notifications.
When the Collector updates the cached UDS characteristics while not in a connection (e.g., through its UI), it shall increment the value of the cached Database Change Increment characteristic by 1. This is to synchronize the UDS characteristics values with the Physical Activity Monitor at the next connection.
When a Collector that supports the update of UDS characteristics (e.g., through its UI) is connected to a Physical Activity Monitor, and when the Collector updates one or more UDS Characteristics values exposed by the Physical Activity Monitor, the Collector shall increment its local Database Change Increment value by 1 and write the incremented value of the Database Change Increment characteristic to the Physical Activity Monitor.
4.7. General error handling
This section describes error handling by the Collector when using procedures of the Physical Activity Monitor Control Point defined in [1] or the User Control Point defined in [4].
The Collector shall be tolerant and behave appropriately (i.e., the Collector shall be able to continue to process commands and/or receive data normally) when receiving the following Control Point error codes defined in [4]:
-
Op Code Not Supported
-
Invalid Parameter
-
Operation Failed
-
User Not Authorized
The Collector shall also be tolerant and behave appropriately (i.e., the Collector shall be able to continue to process commands and/or receive data normally) when receiving the following Application ATT error code defined in [4]:
-
User Data Access Not Permitted
The Collector shall also be tolerant and behave appropriately (i.e., the Collector shall be able to continue to process commands and/or receive data normally) when receiving the following Physical Activity Monitor Control Point error codes defined in [1]:
-
Get Ended Session Data Error Response
-
Enquire Sub-sessions Error Response
-
Enquire Sessions Error Response
The Collector shall also be tolerant and behave appropriately (i.e., the Collector shall be able to continue to process commands and/or receive data normally) when receiving the following Application ATT error codes defined in [1]:
-
Op Code Not Supported
-
Invalid Session ID
-
Invalid Sub-session ID
-
Session Still Running
-
No Data Available
-
No Sessions Available
-
Invalid Type
-
No Session Running
-
Nothing To Stop
-
Activity Type Out Of Range
-
Operation Failed
The Collector shall also be tolerant and behave appropriately (i.e., the Collector shall be able to continue to process commands and/or receive data normally) when receiving the following ATT error codes as defined in [2]:
-
Procedure Already In Progress
-
Client Characteristic Configuration Descriptor Improperly Configured
If a Service Changed indication is received from the Physical Activity Monitor, this indicates not only that the Collector must perform service and characteristic discovery (as defined in GATT in Vol. 3, Part G, Section 7 in [2]) again within the handle range specified, but also that the cached values for characteristics and descriptors might no longer be valid, and the Collector is required to refresh these cached values.
4.8. Data access methods
The Collector shall be able to use the User Control Point characteristic to receive the measurement data (i.e., indications or notifications from PAMS data characteristics) and to access the UDS characteristics.
When UDS is not used, the Physical Activity Monitor shall send all measurement data to any connected Collector that uses the proper security mode and level.
Where UDS is used by the Physical Activity Monitor, the Consent procedure shall be used to get access to the data for users registered on the Physical Activity Monitor via the Register New User procedure.
Table 4.10 provides an overview of the data access requirements.
|
Physical Activity Monitor Configuration |
Consent Requirement for Measurement Data |
Consent Requirement for UDS Characteristic Data |
|---|---|---|
|
No UDS support |
No consent possible |
N/A |
|
UDS supported and used for a user |
Consent needed |
Consent needed |
A Physical Activity Monitor is a multi-user Physical Activity Monitor if it can record measurements for multiple users, using a User ID to distinguish them. Support for UDS improves the support for multiple users, but even a single-user Physical Activity Monitor may use UDS. See Section 4.4.1 for reading the Physical Activity Monitor Feature characteristic for multiple user support and UDS support.
When consent is needed according to Table 4.10, the Collector shall use one of the procedures defined in Table 4.11 to access data of the Physical Activity Monitor.
|
Condition |
Action Requirement |
|---|---|
|
The user has not been registered. |
The Collector shall use the Register New User procedure defined in Section 4.6.2.2.1, followed by the Consent procedure defined in Section 4.6.2.2.2, in order to demonstrate consent to access the data of the Physical Activity Monitor. |
|
The user is registered. |
The Collector shall use the Consent procedure defined in Section 4.6.2.2.2 to demonstrate consent to access the data of the Physical Activity Monitor. If the Consent procedure succeeds, then the Collector should initiate the User Data Synchronization procedure defined in Section 4.6.4. If the Consent procedure fails, then the Collector shall assume that the user data no longer exists on the Physical Activity Monitor (for example, the data has been deleted via the UI of the Physical Activity Monitor) and should reinitiate the Register New User procedure defined in Section 4.6.2.2.1. |
After the Consent procedure has succeeded, the Collector should write the user data to the Physical Activity Monitor.
A multi-user Physical Activity Monitor that supports UDS shall transmit measurement data for measurements not bound to a user registered via UDS to any connected Collector. The presence and value of the User ID in these measurements is implementation dependent.
If the connection is terminated because of a link loss, then the Collector should attempt to reinitiate the connection. If the connection is reestablished, then the Collector shall still use the Consent procedure defined in Section 4.6.2.2.2 to access the data of the Physical Activity Monitor.
4.9. Device Time Client role
The Collector shall support the Device Time Client role as defined in the Device Time Profile [6]. This requirement complements the recommendation for the Physical Activity Monitor to support the Device Time Server role.
5. Connection establishment procedures
This section describes the connection establishment and connection termination procedures used by a Physical Activity Monitor and Collector in typical scenarios.
5.1. Physical Activity Monitor connection establishment for Low Energy transport
This section describes connection procedures that a Physical Activity Monitor should follow to initiate a connection with a Collector that uses an LE transport.
-
Section 5.1.1 describes the connection procedure when the Physical Activity Monitor does not support bonding or when the Physical Activity Monitor supports bonding but is not bonded with any Collectors.
-
Section 5.1.2 describes the connection procedure when the Physical Activity Monitor is bonded with one or more Collectors.
-
Section 5.1.3 describes the reconnection procedure used when the established connection is broken after a link loss and a reconnection is required.
-
Section 5.1.4 is applicable when the connection is idle.
5.1.1. Connection procedure for unbonded devices
This procedure is used for connection establishment when the Physical Activity Monitor is not bonded with any Collectors and is ready for connection (for example, when the Physical Activity Monitor is initially powered on).
If a connection is not established within a certain period, which is defined by the manufacturer, then the Physical Activity Monitor may either continue sending background advertising (to reduce power consumption) for as long as it chooses, or stop advertising. The advertising interval and the time to perform advertising are implementation specific and should be configured with consideration for user expectations of connection establishment time by using the GAP timers defined in Volume 3, Part C, Section 9.3.11 in [2].
If a connection is not established within a time limit defined by the Physical Activity Monitor, then the Physical Activity Monitor may exit the GAP Connectable mode.
Table 5.1 summarizes the recommended connection procedure if the Physical Activity Monitor is not bonded to any Collectors.
|
Recommended GAP Modes |
Recommended Filter Policy |
Remarks |
|---|---|---|
|
General Discoverable mode Undirected Connectable mode Bondable mode |
Attempt to connect to any Collectors. |
None |
When a bond is created, refer to the recommendations in Section 5.1.2.
When the Physical Activity Monitor no longer requires a connection, it should perform the GAP Terminate Connection procedure.
5.1.2. Connection procedure for bonded devices
Table 5.2 summarizes the recommended connection procedure if the Physical Activity Monitor is bonded with one or more Collectors.
|
Recommended Time |
Recommended GAP Modes |
Recommended Filter Policy |
Remarks |
|---|---|---|---|
|
First 10 seconds |
Non-Discoverable mode Undirected Connectable mode |
Attempt to connect to only bonded Collectors in the Filter Accept List [10]. |
The Filter Accept List should be used in order to accept connection requests only from the relevant bonded Collector. |
|
After 10 seconds |
General Discoverable mode Undirected Connectable mode Bondable mode |
Attempt to connect to any Collectors. |
This allows bonding with a new Collector. The connection procedure for unbonded devices is described in Section 5.1.1. |
If a connection is not established within TGAP(adv_fast_period), then the Physical Activity Monitor may either continue sending background advertising (to reduce power consumption) for as long as it chooses or stop advertising.
The advertising interval and the time to perform advertising are implementation specific and should be configured with consideration for user expectations of connection establishment time by using the GAP timers defined in Volume 3, Part C, Section 9.3.11 in [2].
If a connection is not established within a time limit defined by the Physical Activity Monitor, then the Physical Activity Monitor may exit the GAP Connectable mode.
When the Physical Activity Monitor is disconnected, and the Physical Activity Monitor is ready for reconnection (e.g., when commanded by the user), the Physical Activity Monitor should reinitiate the connection procedure (e.g., start advertising).
5.1.3. Link loss reconnection procedure
When a connection is terminated due to link loss, the Physical Activity Monitor should attempt to reconnect to the Collector by entering a GAP Connectable mode.
5.1.4. Idle connection
If the Physical Activity Monitor has no (further) data to transfer and the connection is idle, then the Physical Activity Monitor should wait at least longer than the maximum connection interval (e.g., 5 seconds) before performing the GAP Terminate Connection procedure. This allows the Collector to perform any additional required actions (e.g., read and write to UDS characteristics or delete the user data). For devices that support man-in-the-middle (MITM) protection, a longer duration might be needed to allow the pairing sequence to complete.
5.2. Collector connection establishment for Low Energy transport
This section describes connection procedures a Collector should follow to initiate a connection with a Physical Activity Monitor that uses an LE transport.
The Collector should use the GAP General Discovery procedure to discover a Physical Activity Monitor.
A Collector may use one of the GAP connection procedures based on its connectivity requirements as described in Table 5.3.
|
GAP Connection Procedure |
Unbonded Collector |
Bonded Collector |
|---|---|---|
|
General Connection Establishment |
Allowed |
Allowed |
|
Direct Connection Establishment |
Allowed |
Allowed |
|
Auto Connection Establishment |
Not Allowed |
Allowed |
|
Selective Connection Establishment |
Not Allowed |
Allowed |
If a connection is not established within TGAP(scan_fast_period), then the Collector may either continue background scanning to reduce power consumption, or stop scanning.
The connection interval, scan interval, scan window, and time to perform scanning are implementation specific and should be configured with consideration for user expectations of connection establishment time by using the GAP timers defined in Volume 3, Part C, Section 9.3.11 in [2].
If a connection is not established within a time limit defined by the Collector, then the Collector may exit the connection establishment procedure.
When the connection is established, the Collector may bond with the Physical Activity Monitor, if requested by the Physical Activity Monitor.
Upon initial connection, the Collector may initiate the Register New User procedure defined in Section 4.6.2.2.1, and may configure the new user data by writing to UDS characteristics.
The Collector should terminate the connection when the measurement session is terminated at the Collector by the user.
When the Collector is disconnected, the Collector may continue scanning for advertisements from the Physical Activity Monitor and may initiate a new connection.
5.2.1. Link loss reconnection procedure
When a connection is terminated because of link loss, the Collector should attempt to reconnect to the Physical Activity Monitor by using any of the GAP connection procedures that use the connection establishment timing parameters defined in Volume 3, Part C (GAP), Section 9.3.11 in [2] and the connection interval timing parameters defined in Volume 3, Part C (GAP), Section 9.3.12 in [2].
5.3. Connection establishment for BR/EDR
This section describes the procedures for establishing and terminating connections used by a Physical Activity Monitor and Collector that use a BR/EDR transport. Unlike the LE connection procedures, which describe specific connection parameters, BR/EDR connection establishment does not state requirements beyond those described in GAP based on potential interactions with other BR/EDR profiles operating concurrently on the Physical Activity Monitor and/or Collector.
When using BR/EDR, devices can use sniff mode and sniff subrating to reduce power consumption; however, no particular parameters are recommended, and the requirements of other profiles might need to be considered.
5.3.1. Connection procedure
The procedures for establishing a connection between a Physical Activity Monitor and a Collector that do not have an existing bond and for re-establishing a connection between bonded devices use the inquiry, discovery, paging, pairing, and security procedures described in GAP, defined in Volume 3, Part C of the Core Specification [2], and any additional GAP requirements enumerated in Sections 6 and 7.
5.3.1.1. Connection procedure for unbonded devices
The Physical Activity Monitor shall use the GAP General or Limited Discoverable mode when it is not bonded with any Collectors and is ready for a connection (e.g., when commanded by the user).
The Collector should use the GAP General Discovery procedure to discover a Physical Activity Monitor and establish a connection to a Physical Activity Monitor to which it is not bonded.
Either the Physical Activity Monitor or the Collector can establish a BR/EDR link to a remote peer device. After a link is established, the Collector discovers the Physical Activity Monitor Service by using SDP procedures before the Collector establishes a GATT connection. The Collector may also discover other services instantiated by the Physical Activity Monitor, following the requirements set forth in Sections 3 and 4.
After the Physical Activity Monitor Service and any other instantiated services are discovered and a GATT connection is established, the Collector discovers the exposed characteristics by using GATT Discovery procedures.
Once connected, the Collector shall configure any supported Physical Activity Monitor characteristics that require indications or notifications. This includes characteristics exposed by the Physical Activity Monitor Service and by any other discovered services.
The Collector should terminate the connection when the measurement session is terminated at the Collector by the user.
When the Physical Activity Monitor no longer has data to send, it may disconnect the link, depending on the use cases of the devices and other profiles connected on either device.
5.3.1.2. Connection procedure for bonded devices
The Physical Activity Monitor shall use the GAP Link Establishment procedure to connect to any bonded Collectors when the Physical Activity Monitor is ready for a connection (e.g., when commanded by the user).
The Collector shall be in Connectable mode to accept a connection from a Physical Activity Monitor to which it is bonded.
Either the Physical Activity Monitor or the Collector can establish a BR/EDR link to a remote peer device.
Upon initial connection, the Collector may initiate the Register New User procedure defined in Section 4.6.2.2.1, and may configure the new user data by writing to UDS characteristics.
If a higher layer determines that the bond no longer exists on the remote device, then the local device reconfigures the remote device after the following conditions are met:
-
User interaction confirms that the user wants to pair with the remote device again,
-
Re-bonding has been performed, and
-
Service discovery has been performed. (If the local device had previously determined that the remote device did not have the «Service Changed» characteristic, then service discovery may be skipped, because the service is not allowed to change per the Core Specification [2].)
When the Physical Activity Monitor no longer has data to send, it may disconnect the link, depending on the use cases of the devices and other profiles connected on either device.
The Collector should terminate the connection when the measurement session is terminated at the Collector by the user.
When the Physical Activity Monitor is disconnected, and it is ready for reconnection (e.g., when commanded by the user), the Physical Activity Monitor should initiate a connection with the Collector.
If the Physical Activity Monitor has no (further) data to transfer and the connection is idle, then the Physical Activity Monitor should wait 5 seconds (the idle connection timeout interval) before performing the GAP Terminate Connection procedure. This allows the Collector to perform any additional required actions (e.g., read and write to UDS characteristics). For devices that support MITM protection, a longer duration might be needed to allow completion of the pairing sequence.
5.3.2. Link loss reconnection procedure
When a connection is terminated due to link loss, a Physical Activity Monitor should reconnect to the Collector by attempting, for an implementation-specific time, to reestablish an asynchronous connection-oriented (ACL) link between the two devices. The Collector should remain in Connectable mode for an implementation-specific time so that a Physical Activity Monitor can reestablish an ACL link.
6. Security considerations
This section describes the security considerations for a Physical Activity Monitor and Collector.
6.1. Physical Activity Monitor security considerations for Low Energy
This section describes the security requirements for the Physical Activity Monitor for an LE transport.
-
All supported characteristics specified by the Physical Activity Monitor Service shall be set to LE Security Mode 1 and Security Level 2 or 3. Security Level 3 is recommended if authentication is possible.
-
If used, all characteristics exposed by the UDS for use by this profile should be set to the same security mode and level as the Physical Activity Monitor characteristics.
-
The Physical Activity Monitor should support LE Secure Connections.
-
If present and writable, the Device Name characteristic should require authentication for writing.
-
The Physical Activity Monitor should request bonding.
-
The Physical Activity Monitor should use the Security Manager (SM) Peripheral [10] Security Request procedure to inform the Collector of its security requirements. If the Physical Activity Monitor uses bonding, then it shall use the SM Peripheral Security Request procedure when the Collector accesses a Physical Activity Monitor characteristic.
-
If the Physical Activity Monitor has a UI or any other mechanisms enabling a higher security level (e.g., Out of Band using Near Field Communication (NFC)), then the Physical Activity Monitor should request MITM protection (LE Security Mode 1, Level 3).
6.2. Collector security considerations for Low Energy
This section describes the security requirements for the Collector for an LE transport.
-
The Collector shall support bonding.
-
The Collector should bond with the Physical Activity Monitor.
-
The Collector shall support LE Security Mode 1 and Security Level 2 and 3.
-
The Collector shall accept any request by the Physical Activity Monitor for a specific Security Mode and Security Level as defined by this profile for the Physical Activity Monitor.
-
The Collector should support LE Secure Connections.
6.3. Security considerations for BR/EDR
As required by the GAP, Security Mode 4 (service-level enforced security) shall be used for connections by the Physical Activity Monitor and the Collector.
-
The Physical Activity Monitor may initiate Dedicated Bonding with the Collector. However, if the Physical Activity Monitor supports multiple users, then it shall initiate Dedicated Bonding and shall support as many bonds as the number of supported users.
-
The Collector shall support bonding in case it is requested by the Physical Activity Monitor.
-
If the Physical Activity Monitor has a UI or any other mechanisms enabling a higher security level, then the Physical Activity Monitor should request MITM protection.
7. Generic Access Profile for BR/EDR
This section defines the support requirements for the capabilities as defined in the GAP when BR/EDR is used.
7.1. Modes
The Mode procedures, as defined in the GAP, describe requirements for both Physical Activity Monitors and Collectors. This profile further refines the requirements.
-
Discoverable mode shall be supported by Physical Activity Monitors supporting BR/EDR.
-
Bondable mode should be supported by Physical Activity Monitors.
-
Bondable mode shall be supported by Collectors.
Table 7.1 shows the support status for GAP Modes in this profile.
|
Mode |
Support in Physical Activity Monitor |
Support in Collector |
|---|---|---|
|
Discoverable mode |
M |
N/A |
|
Bondable mode |
O |
M |
- M:
-
Mandatory
- O:
-
Optional
7.2. Idle Mode procedures
The Idle Mode procedures, as defined in the GAP, describe requirements for both Physical Activity Monitors and Collectors. This profile further refines the requirements.
-
General Inquiry shall be supported by all Collectors.
-
General Bonding should be supported by Physical Activity Monitors.
-
General Bonding shall be supported by all Collectors.
Table 7.2 shows the support status for Idle Mode procedures within this profile.
|
Procedure |
Support in Physical Activity Monitor |
Support in Collector |
|---|---|---|
|
General Inquiry |
N/A |
M |
|
General Bonding |
O |
M |
- M:
-
Mandatory
- O:
-
Optional
8. Acronyms and abbreviations
|
Abbreviation |
Meaning |
|---|---|
|
ACL |
Asynchronous connection-oriented |
|
AD |
Advertising Data |
|
AMP |
Alternate MAC/PHYs |
|
ATT |
Attribute Protocol |
|
BR/EDR |
Basic Rate/Enhanced Date Rate |
|
GAP |
Generic Access Profile |
|
GATT |
Generic Attribute Profile |
|
LE |
Low Energy |
|
MITM |
Man-in-the-middle |
|
NFC |
Near Field Communication |
|
PAMP |
Physical Activity Monitor Profile |
|
PAMS |
Physical Activity Monitor Service |
|
PDU |
Protocol Data Unit |
|
RFU |
Reserved for Future Use |
|
SDP |
Service Discovery Protocol |
|
SM |
Security Manager |
|
UDS |
User Data Service |
|
UI |
User Interface |
|
UUID |
Universally Unique Identifier |
9. References
Bibliography
[1] Bluetooth Physical Activity Monitor Service, Version 1.0 or later
[2] Bluetooth Core Specification, Version 4.2 or later
[3] Bluetooth Device Information Service, Version 1.1 or later
[4] Bluetooth User Data Service, Version 1.0 or later
[5] Bluetooth Device Time Service, Version 1.0 or later
[6] Bluetooth Device Time Profile, Version 1.0 or later
[7] Bluetooth SIG Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers
[8] Bluetooth Personal Health Devices Transcoding White Paper, Version 1.6 or later, https://www.bluetooth.com/wp-content/uploads/2019/03/PHD_Transcoding_WP_v16.pdf
[9] International Organization for Standardization (ISO), “ISO/IEEE11073-20601:2016 Health informatics – Personal health device communication – Part 20601: Application profile – Optimized exchange protocol”, June 2016, https://www.iso.org/standard/66717.html
[10] Appropriate Language Mapping Table, https://www.bluetooth.com/language-mapping/Appropriate-Language-Mapping-Table