AXA Stenman Nederland AXA-ERL-01 AXA E-RL Bycicle lock User Manual eRL Wireless Bluetooth LE Datasheet

AXA Stenman Nederland B.V. AXA E-RL Bycicle lock eRL Wireless Bluetooth LE Datasheet

User Manual

BLUETOOTH LOW ENERGY E-RL LOCK DRAFT INTERFACE SPECIFICATION Version 0.9 25/01/2016 AXA Stenman EnergieStraat 2 3903 AV Veenendaal Netherlands http://www.axa-stenman.com/ T: +31 318 536 111 F: +31 318 595 535 Copyright © 2016, AXA Stenman
Page 2 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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, Axa-Stenmans’ 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. Copyright This document is copyrighted. All rights are reserved. Copyright © 2013 - 2016 Axa-Stenman Veenendaal, Netherlands.
Page 3 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9
Page 4 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 ANDROID 4.X ................................................................................................................. 44 ANDROID 5.0 .................................................................................................................. 45 INSTALLATION PHASE ..................................................................................................... 45 APPENDIX H – APP REQUIREMENT SPECIFICATION ................................................................... 46
Page 6 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 broadcast-only 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 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 Wi-Fi 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 Wi-Fi 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,
Page 15 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 1.2 System Description Making the complicated system setup of the eRL Keysafe cloud service and its operation clear a visualization in Figure 7 is helping cement the concept of the Keysafe cloud service. The app on the smartphone (1) is detecting the presents of bikes available for renting and offering this to the customer. The customer is making his or her selection and the app is sending renting details to the renting companies’ computer system for availability. When approved by the renting agent computer system an eKey will be requested (2) for this particular bike, the cloud computer is generating a certificate holding information regarding the bike, renting time and smartphone. The cloud will forward this information (3) including a freshly generated passkey to the requesting rental agent computer who will forward this information to the app (4). Figure 7. It’s up to the app to present the certificate (5) to the eRL on the selected bike for verification and approval and send the passkey using an API call to the OS on the smartphone. When the certificate is accepted by the eRL a secure pairing/bonding sequence will follow providing a permanent bond during the specified renting time period, 48h in the given example. When the renting period has expired it will not automatically close the eRL but will not allow the renting customer to unlock the Bike anymore. The permanent bond with the smartphone is not transferable to a different smartphone since its using unique markers to identify the smartphone from all others.
Page 16 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 2. e-RL Profile The eRL profile is offering the following 9 Standardised and non-standard services:  The Standardised Service, which consists of: o Generic Access Service. (Mandatory for all BLE devices) o Generic Attribute Service. (Mandatory for all BLE devices) o Battery Service. o Device Information Service. o Link Loss Service. (Implemented in next software release) o Immediate Alert Service. (Implemented in next software release) o Tx Power Service.  The Non-standard Service, which consists of: o Lock Command Control Service. o Device Firmware Update Service. All services are explained in the following sections and furthermore specified in detail in the Appendices of this document. 2.1 Battery Service The Battery Service is a standardized Bluetooth service that exposes the Battery State and Battery Level characteristic (as defined in Appendix A) of the CR123A (CR17335) primary lithium battery in the eRL lock. The Battery Level characteristic returns the current battery level as a percentage from 0% to 100%; 0% represent a battery that is fully discharged, 100% represents a battery that is fully charged. 2.2 Device Information Service The Device Information Service is a standardized Bluetooth service that exposes the eRL device specific information characteristics (as defined in Appendix B) including the following version specific information:  Manufacturer Name String: o “Axa Stenman Nederland BV”  Model Number String: o “eRL 2016 Beta”  Serial Number String: o “0000000000000000”
Page 17 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9  Hardware Revision String: o “V1.00”  Software Revision String: o “V0.80” This information shall be used by the client application (e.g. APP) on how to proceed with the connection and which services and features can be expected from the eRL. 2.3 Link Loss Service The Link Loss Service is a standard Bluetooth service that exposes an Alert Level Characteristic that continues until the radio link is disconnected. The service will notify the eRL when the link has been lost, and which Alert Level has been set. 2.4 Immediate Alert Service The Immediate Alert Service is a standard Bluetooth service that exposes an Alert Level Characteristic that continues until the radio link is disconnected. The service will notify the eRL when the Alert Level characteristic value changes. 2.5 Tx Power Service The Tx Power Service is a standard Bluetooth service that exposes the Tx Power Level characteristic (as defined in Appendix C) to expose the current transmit power level of the eRL when in a connection. 2.6 Proximity Profile The Proximity profile is based on the services offered by the Link Loss Service, Immediate Alert Service and Tx Power Service to build a proximity profile. The Proximity profile defines the behavior when a device moves away from a peer device so that the connection is dropped or the path loss increases above a preset level, causing an immediate alert. This alert can be used to notify the user that the devices have become separated. As a consequence of this alert, a device may take further action, for example to lock one of the devices so that it is no longer usable. The App can notify the user that he or she is leaving the bike unlocked while unattended. The Proximity profile can also be used to define the behavior when the two devices come closer together such that a connection is made or the path loss decreases below a preset level.
Page 18 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 2.7 Lock Command Control Service The device specific eRL Lock Command Control Service is a is a non-standard Bluetooth service that exposes 2.8 Device Firmware Update Service The device specific eRL Device Firmware Update Service is a is a non-standard Bluetooth service that exposes an secure interface for FOTA
Page 19 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 3. Operation Bluetooth Low Energy works with standard profiles and custom profiles every profile can have a number of attributes as explained in chapter 1, attributes can have different characteristics like read only, write only, notify and many others not relevant at this moment. Standard GATT based profiles, like the Battery and Proximity profiles and many more have a universally unique identifier (UUID) of 16 bits, custom UUID’s are 128 Bit long. All UUID’s that are custom and not standardised by the Bluetooth SIG have a length of 128 Bits, the Axa UUID used in the Demo is no exception to this since no standard Bluetooth SIG profile and hence UUID has been defined for Locks and in particular Bicycle Locks. The Axa Base UUID used for the Demo is: 0x23D1BCEA5F782315DEEF121200000000 Figure 3. – Base UUID All BLE Axa eRL Locks have the same UUID and hence follow the same custom profile specification. The profile currently holds two attributes, one attribute is used to control, opening and closing of the lock while the other attribute is to read the current lock state. The following attributes are used by the eRL Lock:  UUID_SERVICE 0x1523  UUID_LOCK_CHAR 0x1525 (Lock Control)  UUID_STATE_CHAR 0x1524 (Lock Status) Generic Access Profile The Generic Access Profile (GAP) is the cornerstone that allows Bluetooth Low Energy devices to interoperate with each other. It provides a framework that any BLE implementation must follow to allow devices to discover each other, broadcast data, establish secure connections, and perform many other fundamental operations in a standard, universally understood manner. To identify and connect the Bluetooth LE eRL is advertising using GAP its presents when woken-up by a disturbance like a double tick during a set period, this period is currently fixed at 30 seconds. During this advertising period it’s the apps responsibility to identify the eRL and connect to it if the Axa marker matches. In the advertising packet every eRL lock will send a marker in the following format: AXA eRL Demo Figure 8. – Axa Marker
Page 20 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Unlocked Mode – Secured / Unsecured / Unexpected Figure 9 presents the condition the leaver is in when the lock is Unlocked and the leaver is secured. This is the normal condition the lock is in when Unlocked. Figure 9. – Unlocked Figure 10. – Unsecured Figure 11. – Locked The status reported to the user will be “Unlocked”. Figure 10 presents the condition the leaver is in when the lock is Unlocked and the leaver is unsecured and is still able to move. This condition happens when the user Unlocks the lock and the spring inside the lock is not able to move the leaver completely in the Unlocked condition of Figure 9 due to an object (eq. spokes, hand) blocking this. This is an abnormal condition since the lock can now either be put in the Unlocked secured leaver condition from Figure 9 or in the Locked condition from Figure 11. The status reported will be Unlocked in both the Unlocked secured (Fig 9) and Unlocked unsecured conditions (Fig 10), if the leaver is moved from the Unlocked unsecured into the Locked condition from Figure 11 the status reported will be updated and reports Locked. This status update, the unexpected locking can happen in the Demo lock anytime when the lock is in the Unlocked condition and the software designer should be ignoring this condition since the hardware will be modified to cope with this condition. Bluetooth LE Mode – Unlocking / Locking The Unlocking / Locking sequence is controlled by the attribute property UUID_LOCK_CHAR sending a 0x00 will open the eRL Lock when closed and sending a 0x01 will close the eRL Lock when open. The status attribute property UUID_STATE_CHAR will reflect the current eRL Lock status, 0x01 will represent “closed” and 0x00 will represent “open”. LOCK_OPEN_STATUS 0x00 LOCK_UNSECURED_OPEN_STATUS 0x08 (child safety removed) LOCK_WEAK_CLOSED_STATUS 0x09 LOCK_STRONG_CLOSED_STATUS 0x01 LOCK_ERROR_STATUS 0xFF
Page 21 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 This document specifies the messages exchanged between the eRL device and the smartphone or table application trough Bluetooth Low Energy (BLE). We will call the smartphone or tablet application the client application in this document. Bluetooth Low energy main functions Connectivity • Scanning of the BLE devices available. • Recognizing eRL BLE devices. • Establish a link with a eRL BLE device. • Handle the disconnections started by the eRL device. Monitor live data • Retrieve Battery status. • Retrieve current device state. • Configure the eRL. • Retrieve Control the eRL Lock • open/close the Lock at user’s request. Connectivity The eRL device communicates with the client application using BLE. It will act as a peripheral and uses GAP and GATT profiles. The client application should configure its BLE stack as central. eRL device Scan When not connected, the eRL device is in advertising mode. The configured connection interval is 0.5 second, which means that an advertising frame will be sent every 500 mseconds on each of the 3 advertisement channels. The client application should scan for all BLE devices. Identify that a device is an eRL device --‐ The client application must identify a BLE device as a eRL device when: • It declares to support the live service in the advertisement data (39e1FA00--‐84a8--‐11e2--‐afba--‐ 0002a5d5c51b is included in the list of available service UUID). --‐ The scan response data is obtained by performing active scanning. Retrieve the eRL device system ID A eRL Lock is identified by its System ID. This is a unique identifier assigned to eRL devices. It can be retrieved in two ways: • By building it from the device Bluetooth address (preferred method). • By building it from the advertisement frame information (for Firmware version 1.1 or higher).
Page 22 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 • By reading the “system ID” characteristic which is part of the device information service (0x180A). This method shall only be used when the current Bluetooth implementation does not give access to the device Bluetooth address. The system ID is an 8 bytes buffer. When retrieved, it should be converted into a string representing the system ID encoded in hexadecimal format. The following table describes the correspondence between the Bluetooth Mac address and the eRL system ID. Connect to the desired device When one or several devices have been identified as eRL devices, the application could establish a connection to one of them. There are 3 reasons for the application to connect to the eRL device: --‐ The “move detected” flag is set on the scan response data (see Appendix B for scan response description). --‐ The “unread entries” flag is set on the scan response data. --‐ The user starts a live session on that device. Disconnecting from a device For now the Apple devices stay connected to the devices event when the application requested a disconnection. In order to limit connection time, the eRL device may disconnect from the application after a certain amount of time without incoming BLE request. It has been decided (arbitrary) to set this time to 1 second, but we may change this timeout value if needed. Control and monitor the eRL devices Identify a eRL device A eRL sensor is identified by its System ID. This is a unique identifier assigned to eRL devices. It can be retrieved in two ways: • By building it from the device Bluetooth address (preferred method). • By reading the “system ID” field of the device information BLE service. This method shall only be used when the current Bluetooth implementation does not give access to the device Bluetooth address. The system ID is an 8 bytes buffer. When retrieved, it should be converted into a string representing the system ID encoded in hexadecimal format. The following table describes the correspondence between the Bluetooth Mac address and the Flower Power system ID. Retrieve Battery status The eRL device includes the Battery service UUID as specified by the Bluetooth specification: http://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.batter y_service.xml
Page 23 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 The battery service implemented in the eRL device allows to retrieve the current battery status (in %), and has the ability to send a notification when the battery level is critical. --‐ When connecting to the device, the application reads the battery status (the characteristic with UUID 0x2A19). --‐ When connecting to the device, the application registers to notifications for the battery status notifications. --‐ When a notification is received for the battery status from the eRL device, the client application should report it to the user.
Page 24 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 4. App Requirement Specification TBD
Page 25 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 4. Test Scenarios Test scenarios are test cases designed for the software designers that ensure that all possible situations and conditions are tested from end to end. The scenarios are independent tests; or a series of tests that follow each other, where each of them depends upon the output of the previous one. The scenarios were prepared by reviewing general functional requirements, and are designed to represent both typical and unusual situations that may occur in the user case. The test scenarios are executed through the use of test procedures given in Appendix A, the procedures define a series of steps necessary to perform one or more test scenarios.
Page 26 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 5. Electrical Characteristics Absolute Maximum Electrical Ratings(†) Characteristic Ambient temperature under bias -25°C to +85°C Ambient temperature during operation -20°C to +55°C Supply Voltage Vdd pin with respect to Vss (Idle) 3V Supply Voltage Vdd pin with respect to Vss (Running) 3V Supply Voltage Vdd pin with respect to Vss (Stall) 3V Supply Current Vdd pin 250mA Peak (10s) Supply Current Vdd pin @ 3V (Stall) 500mA ESD protection on all pins (HBM; MM) ≥ 2kV; ≥ 400V Standard Electrical Operating Conditions (unless otherwise stated) Operating temperature -20°C TA +55°C Characteristic Min Typ. Max units Conditions Supply Voltage (Vdd) 2.2 3 3.6 V Normal Mode Supply Voltage (Vdd) 2.8 3 3.6 V BLE FOTA Mode Supply Current 90 mA Motor Running Peak Supply Current 350 mA Motor Startup < 100ms Motor Stall Current 500 mA Motor Stall < 10s @ 3V Power-saving Current1 7 15 µA Vdd = 3V, (Sleep mode) Start-up Time 290 500 ms Power up Unlocking Time 1.5 1.8 2.1 s Locked -> Unlocked Locking Timeout 14.9 15 15.1 s Unlocked -> Unlocked Stall Timeout 9.9 10 10.1 s Vdd = 3V
Page 27 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix A – Battery Service Name: Battery Service Type: org.bluetooth.service.battery_service Assigned Number: 0x180F Abstract: The Battery Service exposes the state of a battery within the eRL lock. Summary: The Battery Service exposes the Battery State and Battery Level of the CR123A (CR17335) primary lithium single battery in the eRL lock. Service Dependencies This service has no dependencies on other GATT-based services. GATT Requirements Sub-Procedure Server Requirement Read Characteristic Descriptors Mandatory Notifications C1: Mandatory if the Battery Level characteristic properties supports notification, otherwise excluded. Write Characteristic Descriptors C1: Mandatory if the Battery Level characteristic properties supports notification, otherwise excluded. Transport Dependencies Transport Supported Classic true Low Energy true High Speed
Page 28 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Error Codes This service does not define any application error codes that are used in Attribute Protocol. Service Characteristics Overview Properties Security Descriptors Name: Battery Level Description: The Battery Level characteristic is read using the GATT Read Characteristic Value sub-procedure and returns the current battery level as a percentage from 0% to 100%; 0% represents a battery that is fully discharged, 100% represents a battery that is fully charged. Type: characteristic.battery_level Requirement: Mandatory Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Optional Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None Overview Permissions Name: Characteristic Presentation Format Type: descriptor.gatt.characteristic_presentation_format Requirement: if_multiple_service_instances Permission Requirement Read Mandatory Write Excluded Name: Client Characteristic Configuration Type: descriptor.gatt.client_characteristic_configuration Requirement: if_notify_or_indicate_supported Permission Requirement Read Mandatory Write Mandatory
Page 29 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix B – Device Information Service Name: Device Information Type: org.bluetooth.service.device_informationDownload / View Assigned Number: 0x180A Abstract: The Device Information Service exposes manufacturer and/or vendor information about a device. Summary: This service exposes manufacturer information about a device. The Device Information Service is instantiated as a Primary Service. Only one instance of the Device Information Service is exposed on a device. Service Dependencies This service is not dependent upon any other services. Transport Dependencies Transport Supported Classic true Low Energy true High Speed Error Codes This service does not define any application error codes that are used in Attribute Protocol.
Page 30 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Service Characteristics Overview Properties Security Descriptors Name: Manufacturer Name String Description: This characteristic represents the name of the manufacturer of the device. Type: org.bluetooth.characteristic.manufacturer_name_string Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None Name: Model Number String Description: This characteristic represents the model number that is assigned by the device vendor. Type: org.bluetooth.characteristic.model_number_string Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None
Page 31 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Overview Properties Security Descriptors Name: Serial Number String Description: This characteristic represents the serial number for a particular instance of the device. Type: org.bluetooth.characteristic.serial_number_string Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None Name: Hardware Revision String Description: This characteristic represents the hardware revision for the hardware within the device. Type: org.bluetooth.characteristic.hardware_revision_string Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None
Page 32 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Overview Properties Security Descriptors Name: Firmware Revision String Description: This characteristic represents the firmware revision for the firmware within the device. Type: org.bluetooth.characteristic.firmware_revision_string Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None Name: Software Revision String Description: This characteristic represents the software revision for the software within the device. Type: org.bluetooth.characteristic.software_revision_string Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None
Page 33 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Overview Properties Security Descriptors Name: System ID Description: This characteristic represents a structure containing an Organizationally Unique Identifier (OUI) followed by a manufacturer-defined identifier and is unique for each individual instance of the product. Type: org.bluetooth.characteristic.system_id Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None Name: IEEE 11073-20601 Regulatory Certification Data List Description: This characteristic represents regulatory and certification information for the product in a list defined in IEEE 11073-20601. Type: org.bluetooth.characteristic.ieee_11073-20601_regulatory_certification_data_list Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None
Page 34 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Overview Properties Security Descriptors Name: PnP ID Description: The PnP_ID characteristic is a set of values used to create a device ID value that is unique for this device. Type: org.bluetooth.characteristic.pnp_id Requirement: Optional Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None
Page 35 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix C – Tx Power Service Name: Tx Power Type: org.bluetooth.service.tx_powerDownload / View Assigned Number: 0x1804 Abstract: This service exposes a device’s current transmit power level when in a connection. Summary: The Tx Power service is instantiated as a Primary Service. There is only one instance of the Tx Power service on a device. There is exactly one instance of the Tx Power Level characteristic Service Dependencies This service has no dependencies on other GATT-based services. Transport Dependencies Transport Supported Classic false Low Energy true High Speed Error Codes This service does not define any application error codes that are used in Attribute Protocol.
Page 36 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Service Characteristics Overview Properties Security Descriptors Name: Tx Power Level Description: The Tx Power Level characteristic represents the current transmit power level of a physical layer for which the characteristic is associated. Type: org.bluetooth.characteristic.tx_power_level Requirement: Mandatory Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Excluded Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None None
Page 37 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix D – Lock Command Control Service Name: Lock Command Control Type: Proprietary, Non-standard Assigned Number: 0x1523 Abstract: This service exposes the state and allows the control of the Lock when in a connection. Summary: The Lock Command Control service is instantiated as a Primary Service. There is only one instance of the Lock Command Control service on a device. There is exactly one instance of the Lock State and Lock Control characteristic GATT Requirements Sub-Procedure Server Requirement Read Characteristic Descriptors Mandatory Notifications C1: Mandatory if the Lock State characteristic properties supports notification, otherwise excluded. Write Characteristic Descriptors C1: Mandatory if the Lock State characteristic properties supports notification, otherwise excluded. Transport Dependencies Transport Supported Classic false Low Energy true High Speed
Page 38 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Service Characteristics Overview Properties Security Descriptors Name: Lock State Description: The Lock Command Control characteristic is read using the GATT Read Characteristic Value sub-procedure and returns the current Lock state as a binary value; 0x00 represents an open lock, 0x80 represents an open lock with child safety removed. 0x01 represents a closed lock, 0x81 represents a weak closed lock state. Type: characteristic.lock_state Requirement: Mandatory Property Requirement Read Mandatory Write Excluded WriteWithoutResponse Excluded SignedWrite Excluded Notify Optional Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None Overview Permissions Name: Characteristic Presentation Format Type: descriptor.gatt.characteristic_presentation_format Requirement: if_multiple_service_instances Permission Requirement Read Mandatory Write Excluded Name: Client Characteristic Configuration Type: descriptor.gatt.client_characteristic_configuration Requirement: if_notify_or_indicate_supported Permission Requirement Read Mandatory Write Mandatory
Page 39 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Overview Properties Security Descriptors Name: Lock Command Control Description: The Lock Command Control characteristic is read using the GATT Read Characteristic Value sub-procedure and returns the current Lock state as a binary value; 0x00 represents an open lock, 0x80 represents an open lock with child safety removed. 0x01 represents a closed lock, 0x81 represents a weak closed lock state. Type: characteristic.lock_command Requirement: Mandatory Property Requirement Read Mandatory Write Mandatory WriteWithoutResponse Excluded SignedWrite Excluded Notify Optional Indicate Excluded WritableAuxiliaries Excluded Broadcast Excluded ExtendedProperties None Overview Permissions Name: Characteristic Presentation Format Type: descriptor.gatt.characteristic_presentation_format Requirement: if_multiple_service_instances Permission Requirement Read Mandatory Write Mandatory Name: Client Characteristic Configuration Type: descriptor.gatt.client_characteristic_configuration Requirement: if_notify_or_indicate_supported Permission Requirement Read Mandatory Write Mandatory
Page 40 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix D.1 – Lock State Attribute Name: Lock State Bit Field Type: Proprietary Assigned Number: 0x1524 Abstract: Categories of alerts/messages. Summary: The value 0x00 is interpreted as “Lock is open”. The value 0x80 is interpreted as “Lock has been opened and child safety is removed, waiting for user to close. 15 seconds timeout applies”. The value of 0x01 is interpreted as “Lock has been closed by user, lock in closed and locked state” The value of 0x81 is interpreted as “Lock has been closed by user but lock is in error, lock will try to remove the error automatically” Value Fields Names Field Requirement Format Minimum Value Maximum Value Additional Information Lock State Bit Field Mandatory uint8 N/A N/A Bit Field Bit Size Name Definition Key Value 0 1 Lock State 0 Open 1 Closed 7 1 Alerts 0 Normal 1 Warning / Error
Page 41 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix D.2 – Lock Command Attribute Name: Lock Command Bit Field Type: Proprietary Assigned Number: 0x1525 Abstract: Categories of alerts/messages. Summary: The value 0x00 is interpreted as “Force the Lock to open”. The value 0x01 is interpreted as “Force the Lock to remove the child safety mode, the user should now close the lock manually. 15 seconds timeout applies before the lock returns to the open state and the user is unable to close the lock manually”. Value Fields Names Field Requirement Format Minimum Value Maximum Value Additional Information Lock Command Bit Field Mandatory uint8 N/A N/A Bit Field Bit Size Name Definition Key Value 0 1 Lock Command 0 Opening 1 Closing
Page 42 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix E – Device Firmware Update Service TBD.
Page 43 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix F – Test scenarios Test Case Title Current Status Description Expected Status Muralis Comments Test Completed Unlocked/Locked Unlocked/Locked Failed / Passed Power-Up Sequence Unlocked Don't give any command and wait for 20 seconds. Unlocked The Lock shall remain idle. Uncompleted Locking Sequence Unlocked Give a Locking command and don’t move the leaver, wait for 20 seconds timeout. Unlocked The Lock shall return to unlock secured after timeout. Making it impossible to move the leaver again Interrupted Locking Sequence Unlocked Give a Locking command, move the leaver halfway and wait for 20 seconds. Unlocked The Lock shall return to unlock secured after timeout. Making it impossible to move the leaver again Completed Locking Sequence Unlocked Give a Locking command and move the leaver to Locked position. Locked The Lock shall Lock successfully. Uncompleted Unlocking Sequence Locked Give an Unlocking command, block the leaver from opening into the Unlocked secured position. Locked The Lock shall put itself into the Locked condition again. Status always remained Locked during the test. Blocked Unlocking Sequence Locked Give an Unlocking command, block the leaver halfway from opening completely and move the leaver after sometime into the Locked position again. Locked Status will be “Unlocked” when lock is halfway and updated again when Lock is put into Locked position. Completed Unlocking Sequence Locked Give an Unlocking command. Unlocked Spring inside the Lock shall pull the leaver into the Unlocked secured position.
Page 44 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix G – Installing apps on Android Installing apps on Android is relatively straightforward with the app store for Android, known as Google Play. You search for an app, select it and click install. These Android Apps are all signed and check for viruses and other harmful software before they are uploaded into the Google Play store. However, the Axa eRL Bluetooth Demo App is not available in the Android app store, not because it’s not check and/or signed but because it’s a demo App. In this case you will have to manually download the App and install an .apk file. An .apk file behaves in a similar manner to an “.exe” file on Windows, you need to copy it to your devices Download directory and run it by clicking on it from your phone. Before you do this you have to enable installing apps from “Unknown Sources” explained in the following paragraphs. Android 4.X Here are some ways that you can manually install an application on Android without going through the app store. However, this is disabled by default for security reasons. Enable “Unknown Sources” Fig 1. Before attempting a manual installation of apps using the .apk files, you must first allow your phone to install from “Unknown sources” (i.e. non-app-store apps). To do this on Android 4.3 and 4.4, navigate to Menu -> System settings -> General -> Security and check the box marked “Unknown sources”. In Dutch this is Menu-> Systeeminstellingen -> Algemeen -> Beveiliging and check the box marked “Onbekende bronnen”. Figure 1.
Page 45 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Android 5.0 Installing the Demo App on Android 5.0 Lollipop is going a little bit different and easier.  Go to your Android device’s “Settings” and then “Security Settings”  Search for an option “Unknown Sources”  Check the box. A warning will appear, accept and allow the change  You’re all done! Manually installing an application on Android without going through the app store, is disabled by default for security reasons. Enable “Unknown Sources” Fig 2. Before attempting a manual installation of apps using the .apk files, you must first allow your phone to install from “Unknown sources” (i.e. non-app-store apps). To do this on Android 5 Lollipop use the steps described above and mark the box “Unknown sources”. Figure 2. Installation phase When you have enabled installation from “Unknown Sources” you can proceed to installing de Axa Demo .apk file. Connect your phone to a computer via the USB interface and enable it to work like a memory stick. Now copy the .apk file to the Download directory on your phone, once it is copied and saved you should browse on your phone to the Download directory and click on the Axa Demo .apk file. Agree with the messages you get from the phone and the Axa Demo app will be installed. When installed you can delete the .apk file in the download directory since it’s no longer being used.
Page 46 of 46 © copyright Axa-Stenman, 2016, Bluetooth eRL Datasheet V0.9 Appendix H – App Requirement Specification TBD

Navigation menu