-
Revision: v1.0.0
-
Revision Date: 2015-Jul-14
-
Prepared By: Automation Working Group
-
Feedback Email: [email protected]
Revision History
|
Revision Number |
Date |
Comments |
|---|---|---|
|
v1.0.0 |
2015-07-14 |
Approved by Bluetooth SIG BoD |
Contributors
|
Name |
Company |
|---|---|
|
Mats Andersson |
u-blox |
|
Robin Heydon |
CSR |
|
David Edwin |
Nordic Semiconductor |
|
Ola Björsne |
u-blox |
|
Michael Wang |
Toshiba |
|
Terry Bourke |
Qualcomm |
|
Brian Redding |
Qualcomm |
|
Rob Hulvey |
Broadcom |
|
Tim Howes |
Accenture |
|
Robert Hughes |
Intel |
|
Chris Church |
CSR |
|
Alicia Courtney |
Broadcom |
|
Victor Zhodzishsky |
Broadcom |
DISCLAIMER AND COPYRIGHT NOTICE
This disclaimer applies to all draft specifications and final specifications adopted by the Bluetooth SIG Board of Directors (both of which are hereinafter referred to herein as a Bluetooth “Specification”). Your use of this Specification in any way is subject to your compliance with all conditions of such use, and your acceptance of all disclaimers and limitations as to such use, contained in this Specification. Any user of this Specification is advised to seek appropriate legal, engineering or other professional advice regarding the use, interpretation or effect of this Specification on any matters discussed in this Specification.
Use of Bluetooth Specifications and any related intellectual property is governed by the Promoters Membership Agreement among the Promoter Members and Bluetooth SIG (the “Promoters Agreement”), certain membership agreements between Bluetooth SIG and its Adopter and Associate Members, including, but not limited to, the Membership Application, the Bluetooth Patent/Copyright License Agreement and the Bluetooth Trademark License Agreement (collectively, the “Membership Agreements”) and the Bluetooth Specification Early Adopters Agreements (1.2 Early Adopters Agreements) among Early Adopter members of the unincorporated Bluetooth SIG and the Promoter Members (the “Early Adopters Agreement”). Certain rights and obligations of the Promoter Members under the Early Adopters Agreements have been assigned to Bluetooth SIG by the Promoter Members.
Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early Adopters Agreement (each such person or party, a “Member”) is prohibited. The use of any portion of a Bluetooth Specification may involve the use of intellectual property rights ("IPR"), including pending or issued patents, or copyrights or other rights. Bluetooth SIG has made no search or investigation for such rights and disclaims any undertaking or duty to do so. The legal rights and obligations of each Member are governed by the applicable Membership Agreements, Early Adopters Agreement or Promoters Agreement. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein.
Any use of the Specification not in compliance with the terms of the applicable Membership Agreements, Early Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result in (i) termination of the applicable Membership Agreements or Early Adopters Agreement and (ii) liability claims by Bluetooth SIG or any of its Members for patent, copyright and/or trademark infringement claims permitted by the applicable agreement or by applicable law.
THE SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR ANY WARRANTY ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE, PROPOSAL, SPECIFICATION OR SAMPLE.
Each Member hereby acknowledges that products equipped with the Bluetooth wireless technology ("Bluetooth Products") may be subject to various regulatory controls under the laws and regulations applicable to products using wireless non licensed spectrum of various governments worldwide. Such laws and regulatory controls may govern, among other things, the combination, operation, use, implementation and distribution of Bluetooth Products. Examples of such laws and regulatory controls include, but are not limited to, airline regulatory controls, telecommunications regulations, technology transfer controls and health and safety regulations. Each Member is solely responsible for the compliance by their Bluetooth Products with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for their Bluetooth Products related to such regulations within the applicable jurisdictions. Each Member acknowledges that nothing in the Specification provides any information or assistance in connection with securing such compliance, authorizations or licenses. NOTHING IN THE SPECIFICATION CREATES ANY WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING SUCH LAWS OR REGULATIONS.
ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS EXPRESSLY DISCLAIMED. To the extent not prohibited by law, in no event will Bluetooth SIG or its Members or their affiliates be liable for any damages, including without limitation, 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, arising out of or related to any furnishing, practicing, modifying, use or the performance or implementation of the contents of this Specification, even if Bluetooth SIG or its Members or their affiliates have been advised of the possibility of such damages. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES ANY CLAIM AGAINST BLUETOOTH SIG AND ITS MEMBERS OR THEIR AFFILATES RELATED TO USE OF THE SPECIFICATION.
If this Specification is an intermediate draft, it is for comment only. No products should be designed based on it except solely to verify the prototyping specification at SIG sponsored IOP events and it does not represent any commitment to release or implement any portion of the intermediate draft, which may be withdrawn, modified, or replaced at any time in the adopted Specification.
Bluetooth SIG reserves the right to adopt any changes or alterations to the Specification it deems necessary or appropriate.
Copyright © 2015. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. All copyrights in the Bluetooth Specifications themselves are owned by Ericsson AB, Lenovo (Singapore) Pte. Ltd., Intel Corporation, Microsoft Corporation, Motorola Mobility, LLC, Nokia Corporation and Toshiba Corporation. Other third-party brands and names are the property of their respective owners.
Document Terminology
The Bluetooth SIG has adopted Section 13.1 of the IEEE Standards Style Manual, which dictates use of the words “shall’’, “should’’, “may’’, and “can’’ in the development of documentation, as follows:
The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (shall equals is required to).
The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations.
The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.
The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).
The term Reserved for Future Use (RFU) is used to indicate Bluetooth SIG assigned values that are reserved by the Bluetooth SIG and are not otherwise available for use by implementations.
1. Introduction
The Automation Profile is used to enable a device to access analog and digital signals exposed by the Automation IO Service.
1.1. Profile Dependencies
This profile requires the Generic Attribute Profile (GATT).
1.2. Conformance
If conformance to this profile is claimed, all capabilities indicated as mandatory for this profile shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated. All mandatory capabilities, and optional and conditional capabilities for which support is indicated, are subject to verification as part of the Bluetooth qualification program.
1.3. Bluetooth Specification Release Compatibility
This specification is compatible with any Bluetooth Core Specification [2] that includes the Generic Attribute Profile (GATT).
2. Configuration
2.1. Roles
The profile defines two roles: Automation IO Server and Automation IO Client. The Automation IO Server is the device that exposes the analog and digital signals of an Automation IO Module (later called IOM) and the Automation IO Client is the device that reads and writes analog and digital signals from the Automation IO Server.
-
The Automation IO Server shall be a GATT Server.
-
The Automation IO Client shall be a GATT Client.
2.2. Role/Service Relationships
The following diagram shows the relationships between Automation IO Service and the two profile roles.
 |
Note: Profile roles are represented by yellow boxes and service is represented by orange boxes.
An Automation IO Server shall instantiate one Automation IO Service [1].
2.3. Concurrency Limitations and Restrictions
There are no concurrency limitations or restrictions for the roles imposed by this profile.
2.4. Topology Limitations and Restrictions
The Automation IO Server should use the GAP Peripheral role.
The Automation IO Client should use the GAP Central role.
2.5. Transport Dependencies
This profile can operate over BR/EDR/HS and LE transports.
3. Automation IO Server Role Requirements
The Automation IO Server shall instantiate one and only one Automation IO Service [1] including devices that support multiple bonds.
The Automation IO Service shall be instantiated as a «Primary Service».
|
Service |
Automation IO Server |
|---|---|
|
Automation IO Service |
M |
See Section 5.1 and Section 6.1 for additional requirements for the Automation IO Server role.
3.1. Incremental Automation IO Service Requirements
This section describes additional Automation IO Server requirements beyond those defined in the Automation IO Service. This section is only applicable when the Automation IO Service is used over an LE transport.
3.1.1. Service UUIDs AD Type
While in GAP Discoverable Mode, the Automation IO Server should include the «Automation IO Service» UUID defined in [3] in the Service UUIDs AD type field of the Advertising Data. This enhances the user experience, as an Automation IO Server may be identified by the Client before initiating a connection.
3.1.2. Local Name AD Type
While in GAP Discoverable Mode, the Automation IO Server 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.
3.1.3. Writable GAP Device Name Characteristic
The Automation IO Server may support the write property for the Device Name characteristic in order to allow an Automation IO Client to write a device name to the Automation IO Server.
4. Automation IO Client Role Requirements
This section describes the profile procedure requirements for an Automation IO Client.
The Automation IO Client shall support the Automation IO Service.
|
Service |
Support in Automation IO Client |
|---|---|
|
Automation IO Service |
M |
|
Profile Requirement |
Section |
Support in Automation IO Client |
|
|---|---|---|---|
|
Service Discovery |
M |
||
|
- Automation IO Service Discovery |
M |
||
|
Characteristic Discovery |
M |
||
|
- Automation IO Service Characteristic Discovery |
M |
||
4.1. GATT Sub-Procedure Requirements
Requirements in this section represent a minimum set of requirements for an Automation IO Client. Other GATT sub-procedures may be used if supported by both client and server.
The table below summarizes additional GATT sub-procedure requirements beyond those required by all GATT clients.
|
GATT Sub-Procedure |
Automation IO Client (Client) 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 |
- C.1:
-
Mandatory to support at least one of these sub-procedures when using the LE transport. Excluded when using the BR/EDR transport since SDP shall be used in this case.
- C.2:
-
Mandatory to support at least one of these sub-procedures.
4.2. Service Discovery
In order for the Automation IO Client to discover the characteristics of the Automation IO Service, it shall perform primary service discovery using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure.
When using the BR/EDR/HS transport, the Automation IO Client shall perform service discovery by retrieving the SDP record of the Automation IO Service [1].
4.2.1. Automation IO Service Discovery
The Automation IO Client shall discover the Automation IO Service.
4.3. Characteristic Discovery
4.3.1. Automation IO Service Characteristic Discovery
The Automation IO Client may 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 Automation IO Service.
The Automation IO Client may perform the GATT Discover All Characteristic Descriptors sub-procedure in order to discover the characteristic descriptors described in the following sections.
4.3.1.1. Digital Characteristic
The Automation IO Client may discover the Digital characteristic. A server may expose zero, one, or more Digital characteristics.
The Automation IO Client may discover the Number of Digitals descriptor of the Digital characteristics if the Client needs to know the number digital signals exposed by each Digital characteristic in the Server.
The Automation IO Client may discover the Client Characteristic Configuration descriptor of the Digital characteristic if the Client wants to configure the characteristic to indicate or notify if one of the optional Indicate or Notify properties is set.
The Automation IO Client may discover the optional Value Trigger Setting descriptor of the Digital characteristic if one of the optional characteristic’s properties, Indicate or Notify, is set.
The Automation IO Client may discover the optional Time Trigger Setting descriptor of the Digital characteristic if one of the optional characteristic’s properties, Indicate or Notify, is set and the Value Trigger Setting descriptor is present for this characteristic.
The Automation IO Client may discover the optional Characteristic Presentation Format descriptor of the Digital characteristic.
The Automation IO Client may discover the optional Characteristic User Description descriptor of the Digital characteristic.
The Automation IO Client may discover the optional Characteristic Extended Properties Description descriptor of the Digital characteristic.
4.3.1.2. Analog Characteristic
The Automation IO Client may discover the Analog characteristics. A server may expose zero, one, or more Analog characteristics.
The Automation IO Client may discover the Client Characteristic Configuration descriptor of the Analog characteristic if the Client wants to configure the characteristic to indicate or notify if one of the optional Indicate or Notify properties is set.
The Automation IO Client may discover the optional Value Trigger Setting descriptor of the Analog characteristic if one of the optional characteristic’s properties, Indicate or Notify, is set.
The Automation IO Client may discover the optional Time Trigger Setting descriptor of the Analog characteristic if one of the optional characteristic’s properties, Indicate or Notify, is set and the Value Trigger Setting descriptor is present for this characteristic.
The Automation IO Client may discover the optional Characteristic Presentation Format descriptor of the Analog characteristic.
The Automation IO Client may discover the optional Characteristic User Description descriptor of the Analog characteristic.
The Automation IO Client may discover the optional Characteristic Extended Properties Description descriptor of the Analog characteristic.
4.3.1.3. Aggregate Characteristic
The Automation IO Client may discover the Aggregate characteristic. The server may expose zero or one Aggregate characteristics.
The Automation IO Client may discover the Client Characteristic Configuration descriptor of the Aggregate characteristic if the Client wants to configure the characteristic for indication or notification if one of the optional Indicate or Notify properties is set.
4.4. Digital Characteristic
When the Automation IO Client is bonded to an Automation IO Server and a Digital characteristic has the Indicate or Notify property set (Indicate and Notify are not supported simultaneously), the Automation IO Client may configure the Digital characteristic for indication or notification (i.e., via the Client Characteristic Configuration descriptor). If a Value Trigger Setting descriptor is present, the conditions for triggering the indication or notification can be set by writing conditions and values to Value Trigger Setting and Time Trigger Setting descriptors. The Time Trigger Setting descriptor may exist if the Value Trigger Setting descriptor exists. If the Value Trigger Setting descriptor is not present, the conditions for triggering indications or notifications are assumed to be predefined or configured offline.
The Automation IO Client shall be able to receive multiple indications or notifications of the Digital characteristic if the Digital characteristic is configured to use indication or notification respectively.
If the Digital is part of an Aggregate characteristic, the Digital characteristic shall not have the Indication or Notification property set, but the Value Trigger Setting and Time Trigger Setting descriptors may still be present and the condition for triggering is valid for the Aggregate.
4.5. Analog Characteristic
When the Automation IO Client is bonded to the Automation IO Server and the Analog characteristic has one of the Indicate or Notify properties set (Indicate and Notify are not supported simultaneously), the Client may configure the Analog characteristic for indications or notifications (i.e., via the Client Characteristic Configuration descriptor). If a Value Trigger Setting descriptor is present, the conditions for triggering the indication or notification may be set by writing conditions and values to Value Trigger Setting and Time Trigger Setting descriptors. The Time Trigger Setting descriptor may exist if the Value Trigger Setting descriptor exists. If the Value Trigger Setting descriptor is not present, the conditions for triggering indications or notifications are assumed to be predefined or configured offline.
The Automation IO Client shall be able to receive multiple indications or notifications of the Analog characteristic if the Analog characteristic is configured to use indication or notification respectively.
If the Analog is part of an Aggregate Characteristic, the Analog characteristic shall not set any of the Indicate or Notify properties but the Value Trigger Setting and Time Trigger Setting descriptors may still be present and the condition for triggering is valid for the Aggregate.
4.6. Aggregate Characteristic
When the Automation IO Client is bonded to the Automation IO Server and the Aggregate characteristic has the Indicate or Notify property set (Indicate and Notify are not supported simultaneously), the Client may configure the Aggregate characteristic for indications or notifications (i.e., via the Client Characteristic Configuration descriptor).
If a Value Trigger Setting descriptor is present for the included Digital and Analog, the conditions for triggering the indication or notification can be set by writing conditions and values to the individual Value Trigger Setting and Time Trigger Setting descriptors. If the Value Trigger Setting descriptor is not present, the conditions for triggering indications or notifications are assumed to be predefined or configured offline.
The Automation IO Client shall be able to receive multiple indications or notifications of the Aggregate characteristic, if the Aggregate characteristic is configured to use indication or notification respectively.
5. Connection Establishment
This section describes the connection establishment and connection termination procedures used by an Automation IO Server and Client based on the topology limitations and restrictions defined in Section 2.4.
5.1. Automation IO Server Connection Establishment for LE Transport
5.1.1. Connection Procedure for Unbonded Devices
This procedure is applicable when the Automation IO Server connects to an Automation IO Client to which it is not bonded (i.e., initial connection). This may be initiated through user interaction when a user intends to bond the Automation IO Server with a Client or during the commissioning of an automation system.
The Automation IO Server should accept any valid values for connection interval and connection latency set by the Automation IO Client until service discovery and encryption is complete. Only after this has been completed should the Automation IO Server 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 Automation IO Server, the Automation IO Server may exit the GAP Discoverable mode.
The Automation IO Server should be in a bondable mode during this procedure to optimize connecting to the Automation IO Client 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 Automation IO Server 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 Automation IO Server should perform the GAP Terminate Connection procedure. This allows the Automation IO Client to perform any additional required actions.
5.1.1.1. Mains-powered Automation IO Server
There are no other specific requirements or recommendations for a mains-powered Automation IO Server. The choice of connection parameters are decided by the use case.
5.1.1.2. Battery-powered Automation IO Server
The Automation IO Server 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.
|
Advertising Duration |
Parameter |
Value |
|---|---|---|
|
First 30 seconds (fast connection) |
Advertising Interval |
20 ms to 30 ms |
|
After 30 seconds (reduced power consumption) |
Advertising Interval |
1 s to 2.5 s |
Notwithstanding the above, the advertising interval and time to perform advertising should be configured with consideration for user expectations of or system latency requirements on connection establishment time.
5.1.2. Connection Procedure for Bonded Devices
An Automation IO Server should enter the GAP Undirected Connectable Mode either when commanded by the user or application to initiate a connection to an Automation IO Client or when an Automation IO Server has one or more indications or notifications to send to a previously connected Automation IO Client.
The Automation IO Server should write the address of the target Automation IO Client in its White List and set its controller advertising filter policy to ‘process scan and connection requests only from devices in the White List’.
The Automation IO Server 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 or system latency requirements on connection establishment time.
Once connected, the Automation IO Server 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 Automation IO Server, the Automation IO Server may exit the GAP connectable mode.
If the Client Characteristic Configuration descriptor has been configured to enable indications or notifications and the Automation IO Server 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 Automation IO Server should perform the GAP Terminate Connection procedure. This allows the Automation IO Client to perform any additional required actions.
Refer to Section 5.1.5 for additional requirements related to support for multiple bonds.
5.1.2.1. Mains-powered Automation IO Server
There are no specific requirements or recommendations specified for mains-powered Automation IO Server.
5.1.2.2. Battery-powered Automation IO Server
This procedure is applicable after the Automation IO Server has bonded with the Automation IO Client using the connection procedure in Section 5.1.1 and either when the user or the application initiates a connection or autonomously when a notification or indication is pending.
5.1.3. Link Loss Reconnection Procedure
When a connection is terminated due to link loss, an Automation IO Server should attempt to reconnect to the Automation IO Client by entering the GAP Undirected Connectable Mode using the recommended advertising interval values shown in Table 5.1.
5.1.4. Idle Connection
5.1.4.1. Mains-powered Automation IO Server
There are no specific requirements for mains-powered Automation IO Server.
5.1.4.2. Battery-powered Automation IO Server
The Automation IO Server should perform the GAP Terminate Connection procedure if the connection is idle for more than 5 seconds.
5.1.5. Multi-Bond Considerations
This section is applicable when an Automation IO Server supports multiple bonds.
An Automation IO Server supporting multiple bonds may use GAP Directed Connectable Mode using the recommended advertising interval values shown in Table 5.1. This is used to avoid a situation where a bonded Automation IO Client unnecessarily responds to the Automation IO Server advertisement intended for another bonded Automation IO Client.
5.2. Automation IO Client Connection Establishment for LE Transport
This section includes recommendations for the Automation IO Client Connection establishment.
The recommendations are based on the assumption of a battery-powered client (e.g., a portable device). If there are other recommendations for a mains-powered device it is specifically mentioned in the text below.
5.2.1. Connection Procedure for Unbonded Devices
This procedure is applicable for connection establishment when the Automation IO Client connects to an Automation IO Server to which it is not bonded (i.e., initial connection). This is typically initiated at system setup when the user intends to bond the Automation IO Client with the Automation IO Server.
An Automation IO Client should use the GAP Limited Discovery procedure to discover an Automation IO Server.
The Automation IO Client should use the recommended scan interval and scan window values shown in Table 5.2. For the first 30 seconds (or optionally continuously for mains-powered devices), the Automation IO Client should use the first scan window / scan interval pair to attempt fast connection. However, if a connection is not established within that time, the Automation IO Client should switch to one of the other scan window / scan interval options as defined in Table 5.2 to reduce power consumption.
Once the Automation IO Server is discovered, the Automation IO Client should initiate connection using the Direct Connection Establishment procedure.
|
Scan Duration |
Parameter |
Value |
|---|---|---|
|
First 30 seconds (fast connection) |
Scan Interval |
30 ms to 60 ms* |
|
Scan Window |
30 ms |
|
|
After 30 seconds (reduced power) - Option 1 |
Scan Interval |
1.28 s |
|
Scan Window |
11.25 ms |
|
|
After 30 seconds (reduced power) - Option 2 |
Scan Interval |
2.56 s |
|
Scan Window |
11.25 ms |
- *
-
A scan interval of 60ms is recommended when the Automation IO Client is supporting other operations to provide a 50% scan duty cycle versus 100% scan duty cycle.
Option 1 in Table 5.2 uses the same background scanning interval used in BR/EDR/HS so the power consumption for LE will be similar to the power consumption used for background scanning on BR/EDR/HS. Option 2 uses a larger background scanning interval (e.g., twice as long) than used in BR/EDR/HS so the power consumption for LE will be less than the power consumption used for background scanning on BR/EDR/HS. Connection times during background scanning will be longer with Option 2.
After the connection is established, the Automation IO Client should bond with the Automation IO Server to optimize reconnecting to the Automation IO Server for future connections. If a bond is created, the Automation IO Client should write the address of the Automation IO Server in the Automation IO Client controller’s White List.
The Automation IO Client should configure the Client Characteristic Configuration descriptor to enable indications or notifications as needed.
A battery powered Automation IO Client cannot depend on the Automation Server to terminate the connection and should terminate the connection when its intended work is finished.
5.2.2. Connection Procedure for Bonded Devices
This procedure is applicable after the Automation IO Client has bonded with the Automation IO Server using the connection procedure in Section 5.2.1, and either when the user initiates a connection or autonomously when an Automation IO Client requires to read from or write to an Automation IO Server.
An Automation IO Client may use one of the following GAP connection procedures based on its connectivity requirements:
-
General Connection Establishment Procedure. The Automation IO Client may use this procedure when it needs to read from or write to one or more Automation IO Servers. This procedure allows an Automation IO Client to connect to an Automation IO Server discovered during a scan without using the White List.
-
Selective Connection Establishment Procedure. The Automation IO Client may use this procedure when it requires to read from or write to one or more Automation IO Servers. This procedure allows an Automation IO Client to connect to an Automation IO Server discovered during a scan while using the White List.
-
Direct Connection Establishment Procedure. The Automation IO Client may use this procedure when it requires to read from or write to a single (or specific) Automation IO Server. The Automation IO Client may also use this procedure for link loss reconnection described in Section 5.2.3.
-
Auto Connection Establishment Procedure. The Automation IO Client may use this procedure when it requires to read from or write to one or more Automation IO Servers. This procedure will automatically initiate connection to an Automation IO Server in the White List.
The Automation IO Client should use the recommended scan interval and scan window values shown in Table 5.2. When initiating connection, the Automation IO Client should use the first scan window / scan interval pair to attempt fast connection. However, if a connection is not established within 30 seconds, the Automation IO Client should switch to one of the other scan window / scan interval options as defined in Table 5.2 to reduce power consumption.
If the Automation IO Client 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 Automation IO Client 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 or system latency requirements of connection establishment time.
The Automation IO Client should 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 Automation IO Client must, after user interaction, re-bond, perform service discovery, and set the Automation IO Server Client Characteristic Configuration descriptor again before using any of the services referenced by this profile.
A battery-powered Automation IO Client cannot depend on the Automation Server to terminate the connection and should terminate the connection when its intended work is finished.
5.2.3. Link Loss Reconnection Procedure
When a connection is terminated due to link loss, an Automation IO Client should attempt to reconnect to the Automation IO Server using any of the GAP connection procedures with the parameters in Table 5.2.
5.2.4. Fast Connection Interval
To avoid very long service discovery and encryption times, the Automation IO Client should use the connection intervals defined in Table 5.3 in the connection request.
|
Parameter |
Value |
|---|---|
|
Minimum Connection Interval |
50 ms |
|
Maximum Connection Interval |
70 ms |
At any time a lower latency is required (e.g., 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.3 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 Automation IO Server using the GAP Connection Parameter Update procedure.
5.2.5. Multi-bond Considerations
The Automation IO Client may initiate a connection to the Automation IO Server using the Direct Connection Establishment procedure.
5.3. Connection Establishment for BR/EDR/HS
This section describes the connection establishment and connection termination procedures used by an Automation IO Server and Client using a BR/EDR/HS transport. Unlike the LE Connection procedures which describe specific connection parameters, BR/EDR/HS connection establishment does not state requirements beyond those described in GAP based on potential interactions with other BR/EDR/HS profiles operating concurrently on the Automation Server and Client. Therefore, power consumption may not be optimized for the BR/EDR/HS transport as compared to an LE transport when no other profiles are operating over the BR/EDR/HS transport.
When using BR/EDR/HS, devices can utilize sniff mode to reduce power consumption; however, no particular parameters are recommended.
5.3.1. Connection Procedure
The procedures for establishing a connection between an Automation IO Server and Client 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 the Generic Access Profile 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 Automation IO Server should use the GAP General Discoverable Mode when it is not bonded with any Collectors and is ready for a connection.
The Automation IO Client should use the GAP General Discovery procedure to discover an Automation IO Server to establish a connection to an Automation IO Server to which it is not bonded.
Either the Automation IO Server or the Automation IO Client can establish a BR/EDR/HS link to a remote peer device.
Once a link is established, the Automation IO Client shall discover the Automation IO Service using SDP procedures prior to establishing a GATT connection.
Once the Automation IO Service is discovered and a GATT connection is established, the Automation IO Client shall discover the Automation IO Service characteristics exposed by this service using GATT Discovery procedures.
The Automation IO Client should initiate bonding between the two devices. If a bond is created, the Collector should cache the SDP Service Record for the Automation IO Service.
The Automation IO Server may disconnect the link, depending on the use cases of the devices.
5.3.1.2. Connection Procedure for Bonded Devices
The Automation IO Server should use the GAP Link Establishment procedure to connect to any bonded Automation IO Client when it is ready for a connection.
The Automation IO Client should be Connectable to accept a connection from an Automation IO Server to which it is bonded.
Either the Automation Server or the Automation IO Client can establish a BR/EDR link to a remote peer device.
If authentication fails upon connection establishment (i.e., the bond no longer exists), the two devices shall re-bond.
The Automation IO Server may disconnect the link, depending on the use cases of the devices. When the Automation IO Server is disconnected and it is ready for reconnection, the Automation IO Server should initiate a connection with the Automation IO Client.
5.3.2. Link Loss Reconnection Procedure
When a connection is terminated due to link loss, an Automation IO Server should reconnect to the Automation IO Client by attempting, for an implementation-specific time, to reestablish an ACL link between the two devices. The Collector should remain Connectable for an implementation-specific time so that an Automation Server can reestablish an ACL link.
6. Security Considerations
This section describes the security considerations for an Automation IO Server and Automation IO Client.
6.1. Automation IO Server Security Considerations for Low Energy
All supported characteristics specified by the Automation IO Service shall be set to Security Mode 1 and Security Level 2 or higher.
The Automation IO Server shall bond with the Automation IO Client.
6.2. Automation IO Client Security Considerations for Low Energy
The Automation IO Client shall bond with the Automation IO Server.
The Automation IO Client shall accept any request by the Automation IO Server for LE Security Mode 1 and Security Level 2 or higher.
6.3. Security Considerations for BR/EDR/HS
As required by GAP, Security Mode 4 shall be used for connections by Automation IO Client and Server.
-
Acceptance of bonding should be supported by all Automation IO Clients and Servers.
-
Automation IO Clients should initiate bonding.
7. Generic Access Profile for BR/EDR/HS
This section defines the support requirements for the capabilities as defined in the Generic Access Profile of the Core Specification [2] when BR/EDR/HS is used.
7.1. Modes
The Mode procedures as defined in GAP describe requirements for both Automation IO Servers and Clients involved. This profile further refines the requirements.
-
General Discoverable mode should be supported by Automation IO Servers supporting BR/EDR.
-
Bondable mode should be supported by Automation Servers and Clients.
7.2. Idle Mode Procedures
The Idle Mode procedures as defined in GAP describe requirements for both Automation IO Servers and Clients involved. This profile further refines the requirements.
-
General inquiry should be supported by all Automation IO Clients.
-
General bonding should be supported by all Automation IO Servers and Clients.
8. Acronyms and Abbreviations
|
Acronyms and Abbreviations |
Meaning |
|---|---|
|
AD |
Advertising Data |
|
BR/EDR/HS |
Basic Rate / Enhanced Data Rate / High Speed |
|
GAP |
Generic Access Profile |
|
GATT |
Generic Attribute Profile |
|
HS |
High Speed |
|
LE |
Low Energy |
|
RFU |
Reserved for Future Use |
|
SM |
Security Manager |
|
UUID |
Universally Unique Identifier |
|
IOM |
IO Module which may be a physical module or embedded functionality |
9. References
Bibliography
[1] Automation IO Service D09.18
[2] Bluetooth Core Specification v4.0 or later
[3] Characteristic and Descriptor descriptions accessible via the Bluetooth SIG Assigned Numbers