AXA Stenman Nederland AXA ERL 01 User Manual

BLUETOOTH LOW ENERGY E-RL LOCK

DRAFT INTERFACE SPECIFICATION

AXA Stenman

Version 0.9

25/01/2016

Page 2 of 46

Disclaimer

The information contained in this document is believed to be correct and complete. However, Axa-Stenman does not give any representations or warranties, expressed or implied, as to the accuracy or completeness of such information and shall have no liability for the consequences of use of such information. In no event shall Axa-Stenman be liable for any indirect, incidental, punitive, special or consequential damages (including - without limitation - lost profits, lost savings, business interruption, costs related to the removal or replacement of any products or rework charges) whether or not such damages are based on tort (including negligence), warranty, breach of contract or any other legal theory.

Notwithstanding any damages that customer might incur for any reason whatsoever, AxaStenmans’ aggregate and cumulative liability towards customer for the products described herein shall be limited in accordance with the Terms and conditions of commercial sale of Axa-Stenman

Customers are responsible for the design and operation of their applications and products using Axa-Stenmans products, and Axa-Stenman accepts no liability for any assistance with

applications or customer product design. It is customer’s sole responsibility to determine

whether the Axa-Stenmans product is suitable and fit for the customer’s applications and

products planned, as well as for the planned application and use of customer’s third party

customer(s). Customers should provide appropriate design and operating safeguards to minimize the risks associated with their applications and products.

Axa-Stenman reserves the right to modify any of the documentation at any time and without notice. Axa-Stenman assumes no responsibility for any infringements of patents or other rights of third parties that may result from the use of any product or documentation of Axa-Stenman. Information in this document is believed to be accurate and reliable.

Page 3 of 46

Page 4 of 46

Table of Contents

1. INTRODUCTION ..................................................................................................................................... 6

1.1 QUICK OVERVIEW OF BLUETOOTH LE ..................................................................... 6

1.1.1 Application Perspective ..................................................................................... 6

1.1.2 Services .............................................................................................................. 9

1.1.3 Profiles ............................................................................................................. 10

1.1.4 Attributes and Characteristics ......................................................................... 10

1.1.5 Advertising and Connections ........................................................................... 11

1.1.6 Pairing and Bonding ........................................................................................ 12

1.1.7 Radio Communication ..................................................................................... 13

1.2 SYSTEM DESCRIPTION ........................................................................................... 15

2. E-RL PROFILE ....................................................................................................................................... 16

2.1 BATTERY SERVICE ................................................................................................... 16

2.2 DEVICE INFORMATION SERVICE ............................................................................... 16

2.3 LINK LOSS SERVICE ................................................................................................. 17

2.4 IMMEDIATE ALERT SERVICE ..................................................................................... 17

2.5 TX POWER SERVICE ................................................................................................. 17

2.6 PROXIMITY PROFILE ................................................................................................. 17

2.7 LOCK COMMAND CONTROL SERVICE ....................................................................... 18

2.8 DEVICE FIRMWARE UPDATE SERVICE ...................................................................... 18

3. OPERATION ........................................................................................................................................... 19

GENERIC ACCESS PROFILE ............................................................................................. 19

UNLOCKED MODE – SECURED / UNSECURED / UNEXPECTED ......................................... 20

BLUETOOTH LE MODE – UNLOCKING / LOCKING ........................................................... 20

4. APP REQUIREMENT SPECIFICATION ........................................................................................... 24

5. ELECTRICAL CHARACTERISTICS ................................................................................................. 26

APPENDIX A – BATTERY SERVICE ..................................................................................................... 27

APPENDIX B – DEVICE INFORMATION SERVICE .......................................................................... 29

APPENDIX C – TX POWER SERVICE ................................ ................................ ................................... 35

APPENDIX D – LOCK COMMAND CONTROL SERVICE ................................................................ 37

APPENDIX D.1 – LOCK STATE ATTRIBUTE ..................................................................... 40

APPENDIX D.2 – LOCK COMMAND ATTRIBUTE .............................................................. 41

APPENDIX E – DEVICE FIRMWARE UPDATE SERVICE ................................................................ 42

APPENDIX F – TEST SCENARIOS ......................................................................................................... 43

APPENDIX G – INSTALLING APPS ON ANDROID ............................................................................ 44

Page 5 of 46

ANDROID 4.X ................................................................................................................. 44

ANDROID 5.0 .................................................................................................................. 45

INSTALLATION PHASE ..................................................................................................... 45

APPENDIX H – APP REQUIREMENT SPECIFICATION ................................................................... 46

Page 6 of 46

1. Introduction

The Bluetooth Low Energy Wireless eRL lock can be controlled directly through standard Bluetooth LE communication without the need for a proprietary communication stack. Bluetooth Low Energy sometimes referred to as Bluetooth 4.X or Bluetooth Smart is a new technology completely different and not compatible with Classic Bluetooth that has been around since 2001. Classic Bluetooth is well known for its use in hands free car kits and wireless earphones remote controls for GSM and smart phones.

The Bluetooth Low Energy (BLE) based eRL takes all complicated lock handling, timing and key management out of the hands of the App builder and offers a simple straightforward standard interface to control and monitor the eRL. The eRL employs an extreme smart low power saving mode minimizing current consumption to maximize battery life while offering selective response to control commands. The eRL remembers and learns the user’s behavior and automatically adopts itself to the user’s needs maximizing the time it’s asleep. The net effect will be that when the user is asleep the eRL will be asleep as well and before the user comes to take his bicycle the eRL will wake up and prepares for just another day at the office. All this is done with only one sole purpose and that is to maximize battery life while minimizing the negative effects for the user.

1.1 Quick Overview of Bluetooth LE

Bluetooth Low Energy (BLE) is a Bluetooth technology which was released into the main Bluetooth standard in 2010 along with the Bluetooth Core Specification Version

4.0. Classic Bluetooth devices had suffered from being extremely energy greedy, and the need for a better energy management was necessary. BLE solved this problem and has since been used on most modern devices (all Apple iPhone since the 4S, Samsung phones since the Galaxy SIII, and many more). BLE allows us to use the bluetooth communication for small data exchanges and hence to avoid consuming as much energy.

1.1.1 Application Perspective

Before we get into the description of how the eRL works in detail, let’s simply review a couple characteristics of Bluetooth LE devices and how the eRL fits in these:

 Servers vs. Clients: these definitions are fairly classic. The Client emits

requests and receives responses while the Server listens for requests and sends responses.

 Central vs. Peripheral: The peripheral device has valuable information to

share with central devices. The central device treats the received data to fulfill specific tasks.

Page 7 of 46

Figure 1.

Figure 1 is giving an overview of the different roles, so what is the difference between a client and a server? First let me remind you that a client and a server is not interchangeable with master/slave.

Figure 2.

Standard Bluetooth LE peripherals broadcast their presents in order to be found by centrals like smartphone’s and tablets, see Figure 2. The eRL is no exception to this, when not connected by a central its broadcasting its presents so other centrals can find it during a scan and make a connection if the peripheral allows connections that is.

Apart from the higher power consumption this introduces a security risk for some product like bicycle locks, thieves will be able to locate bicycles in garages and/or sheds by simply using one of the many freely available Bluetooth LE scanner/localizer apps for smartphones. In order to overcome this kind of problems and to extend the battery lifespan the BLE eRL uses a smart sleeping mechanism, during a sleeping period it’s not broadcasting and undetectable even for the bicycle owner’s app.

Exiting this particular sleeping state the eRL needs to be woken-up by a subtle movement to start it advertising again during a set period. The smartphone app will now be able to detect the advertising packets and act accordingly depending on the relationship with the eRL.

Page 8 of 46

Figure 3.

In real-life situations smartphones (Central) will be surrounded by peripherals broadcasting (Advertising) their presents, see Figure 3.

A master (or Central) is the BLE device that initiates an outgoing connection request to an advertising peripheral device.

A slave (or Peripheral) is the BLE device which accepts an incoming connection request after advertising.

A slave can only be connected to one master, but a master can be connected to multiple slaves. In the smartwatch example, your iPhone can theoretically connect to

multiple smartwatches at the same time. However, your smartwatch can only ever connect to one smartphone at a time.

There is no limit in the Bluetooth SIG on the number of slaves a master can connect to. Generally this will be limited by the BLE technology or Bluetooth stack you use.

Devices such as smartphones or tablets would generally (but not exclusively) adopt

the role of “Scanner” and would “discover” other devices that have adopted the

“Advertiser” role by a process called discovery which can be active (“are there any devices out there?”) or passive (“I’ll listen whilst devices advertise their presence”).

Devices that adopt the “Advertiser” role are generally (but not exclusively) smaller

footprint devices such as heart rate monitors or temperature sensors. Once devices have discovered one another one will act as an “Initiator” (typically the

smartphone or tablet type device) and attempt to connect to one of the devices that it

has discovered. If successful it will adopt the role of “Master” and the other will adopt the role of “Slave”. “Master” devices will initiate commands and requests to “Slave” devices which will respond.

One of the first task of a Bluetooth LE application, such as on a smartphone app, is to discover other Bluetooth LE devices that it can connect to.

Page 9 of 46

1.1.2 Services

Once a device has been discovered the next task is to figure out what services are offered by the device. So, what’s a service? Well, a service consists of:

 A Service Specification, which consists of:

o A collection of characteristics; o References to other service.

Figure 4 is giving an visualization to help cement the concept of services and characteristics. When talking about services we use the names:

 GATT Server  GATT Client

This highlights the client/server model that is used at this level of the architecture.

Figure 4.

Let’s move on to the differences between a GATT server and a GATT client A GATT client is a device which accesses data on the remote GATT server via read,

write, notify, or indicate operations. A GATT server is a device which stores data locally and provides data access

methods to a remote GATT client. You can easily see that it is possible for a device to be a GATT server and a GATT

client at the same time. While it is most common for the slave (peripheral) device to be the GATT server only and the master (central) device to be the GATT client, this is not required. The GATT functionality of a device is logically separate from the master/slave role. The master/slave roles control how the BLE radio connection is managed, and the client/server roles are dictated by the storage and flow of data.

Page 10 of 46

1.1.3 Profiles

A GATT database implements one or more profiles, and each profile is made up of one or more services, and each service is made up of one or more characteristics.

Figure 5.

GATT servers can implement as many profiles, services, and characteristics as needed by the product, figure 5. When using a non-standard profile, a 128bit UUID is required and must be provided by the peripheral producer offering this unique profile. You can also adhere to any Bluetooth SIG profiles (services, and characteristics) currently supported, in which case the profile UUID is 16bit long. Every BLE device acting as a GATT server must implement the official Generic Access service. This includes two mandatory characteristics: Device Name and Appearance.

1.1.4 Attributes and Characteristics

Remember that a service is made up of one or more characteristics. However, one characteristic may be comprised of many different attributes.

Each attribute is given a unique numerical handle which the GATT client may use to reference, access, and modify it. Every characteristic has one main attribute which allows access to the actual value stored in the database for that characteristic. When

you “write a value to a characteristics” or “read the value of the characteristic” you are

doing read and write operations on the main data attribute (of said characteristic). Some other related attributes are read-only (such as a Characteristic User

Description attribute), some control the behavior of the characteristic (such as the Client Characteristic Configuration attribute which is used to enable notify or indicate operations).

Page 11 of 46

Every attribute has a UUID. These may be either 16 bits (e.g. “0x180A“) or 128 bits (e.g. “0x23D1BCEA5F782315DEEF121200000000“). All 16-bit UUIDs are defined by the Bluetooth SIG and are known as adopted UUIDs. All 128-bit UUIDs are custom and may be used for any purpose without approval from the Bluetooth SIG. Two very common 16-bit UUIDs that you will see are 0x2901, the Characteristic User Description attribute and 0x2902, the Client Characteristic Configuration attribute (to enable either “notify” or “indicate” on a characteristic).

One important note is that some attribute UUIDs do not technically need to be unique. Their handles are always unique, but the UUIDs occasionally overlap. For example, every Client Characteristic Configuration attribute has a UUID of 0x2902, even though there may be a dozen of them in a single GATT database.

1.1.5 Advertising and Connections

The Generic Access Profile (GAP) specifically describes behaviors and procedures for device discovery, connection establishment, security, authentication, and service discovery, and this along with performing a single defining role. In essence, a Bluetooth device may incorporate either initiating or accepting procedures, and the peer device must support the corresponding functionality. One of the most important things to understand with Bluetooth low energy is how two devices first find one another, work out what they can do with one another, and how they can find and connect with one another repeatedly. This is really what GAP defines.

There are four GAP roles defined for a Bluetooth low energy device:

 Broadcaster  Observer  Peripheral  Central

A broadcaster is a device that sends advertising packets. Typically, this is used to broadcast some data from a service to other devices that happen to be in an observer role. A broadcast must have a transmitter but does not need a receiver. A broadcastonly device, therefore, only needs a transmitter.

An observer is a device that scans for broadcasters and reports this information to an application. An observer must have a receiver; it can also optionally have a transmitter.

A peripheral is a device that advertises by using connectable advertising packets. As such, it becomes a slave once connected. A peripheral needs to have both a transmitter and a receiver. The eRL has adopted the role of peripheral device and as such is sending advertising packets while not connected.

Page 12 of 46

A central is a device that initiates connections to peripherals. As such, it becomes a master when connected. Just like a peripheral, a central needs to have both a transmitter and a receiver. We explained before that since the eRL has adopted the role of peripheral device the smartphone will need to accept the role of central in this

system. The role that is already normal for smartphone’s since most other BLE

peripherals connected to the smartphone are peripheral’s, for example smartwatches or other body sensors that measure vital signs while cycling. A device can support multiple GAP roles at the same time. For example, a device can be a broadcaster and a peripheral at the same time.

1.1.6 Pairing and Bonding

Just a quick writeup on the difference between pairing and bonding, since these terms get used interchangeably. This has to do with the usage of ‘pairing’ in Bluetooth Classic, or BR/EDR.

As far as Bluetooth LE is concerned, pairing and bonding are two very distinct things. The short explanations are that pairing is the exchange of security features each device has, and creating temporary encryption for the livecycle of the connection. Bonding is the exchange of long term keys after pairing has occurred, and storing those keys for later use. Pairing is not the creation of permanent security between devices, that is called bonding. Pairing is the mechanism that allows bonding to occur.

Pairing Pairing is the exchange of security features. This includes things like i/o capabilities,

requirement for man-in-the-middle protection, etc. The client side begins this

exchange. The client essentially says ‘hey, i’d like it if you had these features’. The

server replies, ‘yeah, well, this is what I can do’. Once this exchange is made, the

security that will be used has been determed. For example, if a server supports just noInput/noOutput for i/o capabilities, the Just Works pairing mechanism is going to be used. Once the pairing feature exchange is complete, a temporary security key is exchanged and the connection is encrypted, but only using the temporary key. In this encrypted connection, long term keys are exchanged. These keys are things like the (long term) encryption key to encrypt a connection, and also things like a digital signature key. The exact keys exchanged are determined by the security features of each device.

Bonding This really just means that after the pairing features exchange and the connection has

been encrypted (these two together are called ‘pairing’), and keys have been

exchanged, the devices store and use those keys the next time they connect. Keys can be exchanged using the bonding procedure, but that does not mean they are bonded if the keys are not stored and used the next time.

Page 13 of 46

If a device is bonded with another device, like a heart rate monitor and a smartphone, they can encrypt the connection without exchanging any sensitive security information. When the smartphone connects to the heart rate monitor, it can just issue a ‘turn on encryption’ request, and both sides will use the keys already stored, so nobody snooping can see a key exchange and therefore decode the messages being sent, as is done when pairing.

Certificate

Standard BLE does not use certificates for setting up a secure connection between the master and slave, the eRL does however use certificates signed by the cloud certificate authority KeySafe for setting up secure connections. Without the certificate handover by the master (e.g. smartphone) and positive outcome of the verification the eRL will not allow any device to pair, all pairing requestes by the master will be rejected with an insufficient authentication error code. When the certificate is accepted by the eRL it will initiate the setup of a secure link between the devices and allows the user to input the 6 digit passkey on older smartphones or on the more modern smartphones allows the app to input the 128 bit passkey for the user automatically. Entering the passkey is only required once during pairing and bonding, all other times the smartphone will remember the saved bonding information and connects flawlessly with the eRL until the certificates time has expired. Both the certificate and passkey are provided by the KeySafe cloud service upon requesting for an eKey. The system will be completely compatible with the future revisions of BLE which will introduce

Diffie–Hellman key exchange to secure the pairing and bonding even further.

1.1.7 Radio Communication

Classic and Bluetooth LE operates in the 2.45 GHz band which it shares with Wi-Fi, Zigbee and microwave ovens worldwide!. Bluetooth LE still retains its fundamental resilience by splitting its radio traffic across 40 channels as shown below (Figure 6).

Figure 6.

Page 14 of 46

The Bluetooth low energy channels differ from classic channels because of the relaxed modulation index. This means that the radio energy for each channel is spread wider; therefore, to prevent interference between adjacent Bluetooth low-energy channels, they are separated by 2MHz, instead of the classic 1MHz. In the Link Layer, these channels are divided into two types: advertising channels and data channels. These channel types are aligned with the advertising packets and data packets, as described earlier. When a packet is transmitted, if the packet is sent on an advertising channel, it is an advertising packet. If the packet is sent on a data channel, it is a data packet. There are 3 advertising channels and 37 data channels, as shown in Figure 6 (the advertising channels are rendered in light blue shading). The 3 advertising channels are not all placed in the same part of the ISM band because that would mean that any deep fade in a single part of the band would stop all advertising. Instead, the advertising channels are placed a minimum of 24MHz apart from one another.

The advertising channels are placed strategically away from significant interferers such as a Wi-Fi access point. These public access points typically use one of three

802.11 channels, either channel 1, channel 6, or channel 11. These channels have center frequencies of 2412MHz, 2437MHz, and 2462MHz and a width of approximately 20MHz. This means that channel 1 extends from 2402MHz to 2422MHz, channel 6 extends from 2427MHz to 2447MHz, and channel 11 extends from 2452MHz to 2472MHz. The advertising channels are placed at 2402MHz, 2426MHz, and 2480MHz. This means that the first advertising channel is below WiFi channel 1, the second advertising channel is between Wi-Fi channel 1 and channel 6, and the third advertising channel is above Wi-Fi channel 11. This is illustrated in Figure 6, in which 3 Wi-Fi channels have blocked the use of data channels 0 to 8, 11 to 20, and 34 to 32. The 3 advertising channels, 37, 38, and 39, are all interference free. Bluetooth LE Radio traffic hops around these channels in a pseudo random

manner so that the data with get through even though it’s in an areas shared by a

number of Wi-Fi networks, or microwave ovens. One of the differences between Bluetooth LE and classic Bluetooth is the number and use of these channels.

When in a data connection, an adaptive frequency-hopping algorithm is used. Adaptive frequency hopping makes it possible for a given packet to be remapped from a known bad channel to a known good channel so that the interference from other devices is reduced. To do this, a channel map of good and bad channels is kept in both devices. If the channel that would have been chosen by the master device is a good channel, then that channel is used; if the channel that would have been chosen is a bad channel, then it is remapped onto the set of good channels. A minimum of two data channels must be marked as good by a master.

Suppose, for example, that a Bluetooth low energy device is in the same area as a WiFi channel 1 access point that is streaming data to another Wi-Fi device. The Bluetooth low energy device would mark Link Layer data channels 0 to 8 as bad channels. This means that when the two devices are communicating, they would cycle through the channels and remap these channels to a set of good channels,

+ 32 hidden pages