CEN/TR 17311:2019
(Main)Public transport - Interoperable fare management system - Bluetooth low energy ticketing use cases and guidelines
Public transport - Interoperable fare management system - Bluetooth low energy ticketing use cases and guidelines
The intention of this document is to review what was done to envision the limits of the proposed technique and related schemes which will be described and to define what could be submitted to standards. Concepts which are to be used for BLE in IFM are based on a highly spread technology which is BLE. This is not limited to any trademark or proprietary scheme. Therefore any person having a smartphone can use this technology with prerequisite to have a Bluetooth version greater than 4.0 and a dedicated application on board the smartphone.
The background of this document is related to usage in Account Based Ticketing frame (see related document made in ISO/TC 204/WG 8). There is no information related to the IFM itself.
Öffentlicher Verkehr - Interoperables Fahrgeldmanagement System - Niedrigenergie-Bluetooth Anwendungen und Vorgaben für den Fahrkartenverkauf
Transport public - Système de gestion tarifaire interopérable - Cas d'utilisation et lignes directrices pour l’usage du Bluetooth faible énergie dans les applications de billetterie
Javni prevoz - Medobratovalni sistem upravljanja voznin - Primeri in smernice za uporabo vozovnic, ki temeljijo na tehnologiji BLE (bluetooth low energy)
Namen tega dokumenta je pregled opravljenega, predvidevanje omejitev predlagane tehnike in sorodnih shem, ki bodo opisane, ter določanje tega, kaj bi lahko bilo predloženo v standardizacijo. Pojmi, ki bodo uporabljeni za tehnologijo BLE v IFM, temeljijo na zelo razširjeni tehnologiji BLE. To ni omejeno na nobeno blagovno znamko ali lastniško shemo. Zato lahko vsaka oseba, ki ima pametni telefon, uporablja to tehnologijo pod pogojem, da v pametnem telefonu uporablja Bluetooth različice, novejše od 4.0, in namensko aplikacijo.
Ozadje tega dokumenta se nanaša na uporabo v okviru izdaje vozovnic na podlagi računa (glej sorodni dokument v TC204 WG8). Informacij, ki se nanašajo na sam IFM, ni.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-april-2019
Javni prevoz - Medobratovalni sistem upravljanja voznin - Primeri in smernice za
uporabo vozovnic, ki temeljijo na tehnologiji BLE (bluetooth low energy)
Public transport - Interoperable fare management system - Bluetooth low energy
ticketing use cases and guidelines
Öffentlicher Verkehr - Interoperables Fahrgeldmanagement System - Niedrigenergie-
Bluetooth Anwendungen und Vorgaben für den Fahrkartenverkauf
Ta slovenski standard je istoveten z: CEN/TR 17311:2019
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
CEN/TR 17311
TECHNICAL REPORT
RAPPORT TECHNIQUE
January 2019
TECHNISCHER BERICHT
ICS 35.240.60
English Version
Public transport - Interoperable fare management system -
Bluetooth low energy ticketing use cases and guidelines
Transport public - Système de gestion tarifaire Öffentlicher Verkehr - Interoperables
interopérable - Cas d'utilisation et lignes directrices Fahrgeldmanagement System - Niedrigenergie-
pour l'usage du Bluetooth faible énergie dans les Bluetooth Anwendungen und Vorgaben für den
applications de billetterie Fahrkartenverkauf
This Technical Report was approved by CEN on 30 December 2018. It has been drawn up by the Technical Committee CEN/TC
278.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 17311:2019 E
worldwide for CEN national Members.
Contents Page
European foreword . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Symbols and abbreviations . 5
5 Introduction to BLE . 5
5.1 What is BLE . 5
5.2 BLE ecosystem analysis . 7
5.2.1 Introduction . 7
5.2.2 Key Features of the Bluetooth Low Energy . 7
5.2.3 Bluetooth single mode and Bluetooth dual mode . 7
5.3 Bluetooth Low Energy Architecture . 8
5.3.1 General . 8
5.3.2 The controller . 9
5.3.3 Physical layer . 9
5.3.4 Link Layer . 10
5.3.5 Host Controller interface . 11
5.3.6 Host . 11
5.3.7 Logical Link Control and Adaptation Protocol . 11
5.3.8 Security manager protocol . 11
5.3.9 Attribute protocol . 11
5.3.10 Attribute database, server and client . 13
5.3.11 Generic attribute Profile. 13
5.3.12 Generic Access Profile . 14
6 BLE usage in IFM systems: concept description . 15
6.1 Introduction . 15
6.2 Overview: building blocks and network topology . 16
6.2.1 Building blocks of BLE . 16
6.2.2 Network topology . 17
6.3 How BLE can work: description of the different approaches . 18
6.3.1 Introduction . 18
6.3.2 Walk-In/ Walk-Out and Be-In/Be-Out . 18
6.4 Technical features according on usage concepts . 20
6.4.1 Validation by Embedded in frame location — Location Management . 20
6.4.2 Validation by URL - Repository location . 20
6.5 Advantages and drawbacks . 21
6.5.1 Introduction . 21
6.5.2 Main advantages . 22
6.5.3 Main drawbacks . 23
6.6 BLE vs competitive technologies . 24
7 How to ensure co-existence and migrations from or to other IFMS technologies . 26
8 Use cases description . 26
8.1 Norway use case: Oslo Ruter operator . 26
8.2 ACTV-Venezia use case . 27
8.3 Usage of BLE in bus system . 28
8.4 Use Case EILO – Rhein-Main-Verkehrsverbund, Germany . 30
Bibliography . 31
European foreword
This document (CEN/TR 17311:2019) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
1 Scope
The intention of this document is to review what was done to envision the limits of the proposed
technique and related schemes which will be described and to define what could be submitted to
standards. Concepts which are to be used for BLE in IFM are based on a highly spread technology which
is BLE. This is not limited to any trademark or proprietary scheme. Therefore any person having a
smartphone can use this technology with prerequisite to have a Bluetooth version greater than 4.0 and a
dedicated application on board the smartphone.
The background of this document is related to usage in Account Based Ticketing frame (see related
document made in ISO/TC 204/WG 8). There is no information related to the IFM itself.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
4 Symbols and abbreviations
TR Technical Report
EN European Standard
5 Introduction to BLE
5.1 What is BLE
Bluetooth low energy (BLE) is a wireless personal area network technology designed and marketed by
the Bluetooth Special Interest Group aimed at novel applications in the healthcare, fitness, beacons,
security, and home entertainment industries. Compared to Classic Bluetooth, BLE is intended to provide
considerably reduced power consumption and cost while maintaining a similar communication range.
The Bluetooth Low Energy identifies a number of markets for low energy technology, particularly in the
smart home, health, sport and fitness sectors. Cited advantages include: low power requirements,
operating for “months or years” on a small size button cell and low cost compatibility with a large
installed base of mobile phones, tablets and computers.
Compared to classic Bluetooth technology, BLE has the characteristics as shown in Table 1.
Table 1 — Comparison between classic Bluetooth and Bluetooth Low Energy
Technical specification Classic Bluetooth technology Bluetooth Low Energy
Distance/range (theoretical
100 m > 100 m
max.)
Over the air data rate 1 Mbit/s to 3 Mbit/s 125 kbit/s – 1 Mbit/s – 2 Mbit/s
Application throughput 0,7 Mbit/s to 2,1 Mbit/s 0,27 Mbit/s
Active slaves 7 Not defined; implementation dependent
56/128-bit and application layer 128-bit AES with Counter Mode CBC-
Security
user defined MAC and application layer user defined
Adaptive frequency hopping, Lazy
Adaptive fast frequency hopping,
Robustness Acknowledgement, 24-bit CRC, 32-bit
FEC, fast ACK
Message Integrity Check
Latency (from a non-
Typically 100 ms 6 ms
connected state)
Minimum total time to send
100 ms 3 ms
data (det. battery life)
Voice capable Yes No
Network topology Scatternet Scatternet
0,01 W to 0,50 W (depending on use
Power consumption 1 W as the reference
case)
Peak current consumption < 30 mA < 15 mA
Service discovery Yes Yes
Profile concept Yes Yes
Mobile phones, gaming, headsets,
Mobile phones, gaming, smart homes,
stereo audio streaming, smart
wearable, automotive, PCs, security,
Primary use cases homes, wearable, automotive, PCs,
proximity, healthcare, sports and fitness,
security, proximity, healthcare,
Industrial, etc.
sports and fitness, etc.
BLE uses the same frequency band as Bluetooth (2,4 GHz to 2,5 GHz) and shares this frequency band with
other uses (notably WiFi which uses the frequency band 2,4 GHz to 2,6 GHz). To allow for less sensitivity
to disturbances, BLE implements a frequency hopping mechanism, thus ensuring clear data
transmissions even in rich media of radio links.
Moreover, BLE allows a varied use in terms of implementation since this protocol can be used:
— In connected mode: 2 interlocutors dialogue once paired;
— In network mode: 1 master allows the establishment of a communication with several slaves in a
pico-network;
— In beacon mode: 1 element transmits information that anyone who wants to hear can hear.
Last mode looks to be the most popular to applications used in IFM systems even if some implementations
in connected mode have been tested.
BLE interest increases because Bluetooth function is present on all smartphones whatever the
manufacturer is. Different approaches were made to envision BLE usage in the IFM world. Several usages
have already been described as well as POCs were made with different concepts.
The use of BLE is covering specifically the functionality. It can apply to open systems with surface vehicle
(bus, tramways, BRT [Bus Rapid Transit: bus with high service level]) as well as closed systems used in
metro with physical gates.
5.2 BLE ecosystem analysis
5.2.1 Introduction
Bluetooth is a standard for Personal Area Networks (PAN) which was developed by Ericsson research
group in 1994. This technology is considered to be a short range and low power technology. This operates
in the Industry Security Medical (ISM) frequency band of 2,4 GHz. Bluetooth has been adopted by most
of the Information and Communication Technology industry since its acceptance by the Bluetooth special
interest group (SIG) in 1998. The SIG board members include mobile manufacturing giants at that time
(e.g. Apple, Microsoft and Motorola) and silicon chip manufacturers (e.g. Intel, Nordic semi-conductor).
The term Bluetooth has evolved since 2000. First standard was Basic rate which focused on short range
networks like Personal Area Networks. It typically had ranges from 10 m to 100 m. It was using frequency
hopping spread spectrum techniques. Data rates of 1 Mbps were achieved. The next standard was
introduced as enhanced data rate. This updated standard offered higher data rates of 2 Mbps to 3 Mbps.
In 2008, the High Speed was introduced, which offered data rates up to 24 Mbps.
However ICT industry also felt a need for low energy version which would facilitate short distance and
low power networks. Advances in battery technology also imposed challenges on these earlier versions
of Bluetooth. There was a need for advanced version of Bluetooth which would be used in accessories
that uses less battery and required less power which lead to the latest additions in Bluetooth, known as
Bluetooth Low Energy (BLE).
5.2.2 Key Features of the Bluetooth Low Energy
Bluetooth Low Energy is the newly designed and a complementary technology to the classic Bluetooth. It
is the current lowest possible power wireless technology. This technology borrows its name from its
parent which had a basic rate of 1 megabit per second (Mbps) and was known as Basic Rate (BR).
Enhanced Data Rate (EDR) was version 2 which had a data rates to 3 Mbps. Version 3 which is known as
Alternate MAC PHY (AMP) delivered data rates up to hundreds of megabits per second. However, BLE
provides lesser data rate compared to AMP but instead optimized for ultra-low power consumption by
virtue of its design which means that the Bluetooth connection can be maintained for a longer duration,
say hours or days.
5.2.3 Bluetooth single mode and Bluetooth dual mode
Since Bluetooth devices came into existence in the late 1990´s. There are already several devices in the
market which support versions 1, 2 and 3. These are called the Bluetooth classic only devices. They have
architecture as shown in Figure 1. Two new devices are also built which are known as dual mode and
single mode devices. A single mode device is a Bluetooth device that supports just the BLE. Devices that
support both BLE and the classic Bluetooth are called dual mode devices. Their architectures are as
shown in Figure 1 respectively.
Figure 1 — Bluetooth Dual Mode and Single Mode Architectures
In the market the dual mode and single mode devices are sold as Bluetooth smart ready and Bluetooth
smart devices. Each of these modes has its own architecture as shown in Figure 3. Since Dual mode
devices support both Classic and LE, these devices can talk with all the versions of Bluetooth. However,
single mode also known as Bluetooth smart devices can only communicate with the Bluetooth smart
ready also known as dual mode devices.
Dual mode devices are new in the market and they require new hardware and firmware in the controller
and software in the host. It is because of this reason that existing Bluetooth Classic controller cannot be
upgraded to support low energy. The single mode devices are highly optimized for low power
consumption which is powered by button cell batteries. Since applications like public transport systems
rely very much on low power and less battery consumption an attempt is made in this frame to implement
BLE usage in ticketing systems. The following section will introduce the complete architecture of the
Bluetooth Low Energy.
5.3 Bluetooth Low Energy Architecture
5.3.1 General
The BLE architecture can be divided into three main parts:
— Controller
— Host
— Profiles.
The controller is a Radio which has Physical Layer (PHY), Link Layer (LL) and a Host Controller Interface
(HCI).
Figure 2 — Architecture
Figure 2 represents the layered architecture. It is termed layered because it consists of so many layers
which are placed on top of each other. Physical layer is the bottom most layer which receives and
transmits bits of information. The link layer considers these bits as packets of data and it controls these
packets and sends this data in various procedures and protocols. The Host Controller interface (HCI) is
the next layer which acts as an interface between the Controller and the Host. The logical link control and
adaption protocol also known as L2CAP acts as a multiplexer to the number of channels which are present
on top of the controller. The attribute protocol which is on top of L2CAP is the protocol which is used to
access the data on a device. It helps in reading, writing and various other functions on the device. The
generic access profile provides various services which are present in the device. It gives first-hand
information of how things are organized on the device. It also consists of Meta attributes and various
characteristics of the device which define the organization. On top of these lie the applications. Various
applications like battery profiles, temperature profiles, proximity, heart rate monitor, etc. are defined and
developed over this space.
5.3.2 The controller
The controller can physically be represented as a hardware which is a Bluetooth chip or radio. It consists
of analog and digital parts which are embedded onto a silicon chip which supports the transmission and
reception of the data packets. Companies like Nordic semiconductor, Texas instruments manufacture the
controller and sell them in the market with various commercial names. An example of the same is the
Nordic semiconductor kit. It is to be understood that the physical layer is an nrf51822 Radio.
5.3.3 Physical layer
This layer is responsible for transmitting and receiving the data in the form of bits using the 2,4 GHz radio.
BLE uses Gaussian frequency shift keying (GFSK) which means ones and zeroes are coded onto the radio
by slightly shifting the frequency up and down. Whenever there is an abrupt frequency shift, at that
moment a pulse of energy spread’s out over a wider range of frequencies. To enable to stop the energy
spreading into these high and low end frequencies a Gaussian filter is used. This is called Gaussian
because the transfer characteristics of this filter looks like a Gaussian curve. This also implies that low
energy signal spreads out more than a standard Bluetooth classic radio signal since it doesn’t use a tighter
filter. Due to this reason the BLE is governed under the spread spectrum radio regulations as against
frequency hopping mechanisms used by its parent technology.
So the modulation index used in the case of BLE is slightly higher than the classic Bluetooth which implies
more number of channels to be used. In this case, the 2,4 GHz band in case of BLE is split into 40 separate
RF channels each of them are 2 MHz apart from each other. In 40 RF channels three channels are fixed
channels which are used for advertising data. The remaining 37 channels are used for transmitting
application data and are dynamic in nature. In this band channel 37, channel 38 and channel 39 are the
advertising channels and the remaining channels are the data channels used to send data. So when a
device is adverting data it implies that the data are being sent over one of the 3 adverting channels. And
the reason the advertising channels are placed in this manner is to avoid the WiFi channels which operate
on the other frequencies.
One of the main reasons that BLE uses 3 advertising channels is that it allows the devices to be discovered
and connectable over a given period of time. It also makes the system more robust which also means it
gives low power. Another reason being, if one device needs to be connected than one of the advertising
channels is used and the device which is scanning discovers this advertisement than it takes around
1,3 ms to complete this connection. So with 3 channels it gives a very fast connection, which implies its
duty cycle is ten to twenty times better than classic Bluetooth which also proves that BLE is more power
efficient.
5.3.4 Link Layer
Link layer is the next layer which is on top of the physical layer and is below the L2CAP layer. This is more
complex layer which ensures that the packets are structured so that the key functionalities like
advertising, scanning and creation and maintenance of the connection is taken care of. To enable the link
layer to perform these functionalities channels, packets and procedures are defined in the Bluetooth
specifications. Various channels, packets and their structures will be explained in detail in the next
chapters.
The best way to visualize the link layer is to understand it as a state machine. This state machine has five
different states. Standby state is the first state where nothing is done. As soon as a device is switched on,
it is assumed that it is in standby state. It is possible to move into advertising, scanning or initiating states
from this state. So this is in the Centre state and the most important and inactive state in the state
machine.
Advertising state: from the stand by state it is possible to get into advertising state. By doing this the
device transmits advertisement data packets. If a device needs to be discovered or connectable, the device
shall get into this state. This state is also mandatory if the device has to broadcast some data. From this
state it is also possible to respond to scan requests from devices which are actively scanning the device
under test.
A device in scanning state will receive advertising data packets from the advertiser. Passive and active
scanning are two types of scanning sub states. In passive scanning it is just possible to hear the
advertisements. However in active scanning, scan requests can be sent to obtain additional scan response
data. As the state machine suggests, it is only possible to get back to the stand by state from scanning
state.
To initiate a connection with any device, the state machine shall be in the initiating state. In this case the
device will listen to the initiators message. If an advertisement packet is received from this device than
link layer will send a connect request to the advertiser. So the device gets connected. In case the
connection shall be dropped then the initiator can stop initiating and get back to stand by state by just
stopping a initiating a connection.
The final state of the link layer state machine is the connection state. This can be achieved either via
advertising state or through the initiating state. It is performed under the initiator state than the device
is said to take the role of master. Once the connection is established through the advertisement, it takes
the role of slave. Master and slave are the two sub states in this connection state. Also the connection
state is achieved by making use of the data channels. All other states make use of advertising channels.
To send data on any of the above mentioned channels through any of these states, it is done through
packets. A packet is a small encapsulation of data that is sent from transmitter to receiver over a short
period of time, which structure is shown in Table 2.
Table 2 — Link Layer - Packet Structure
Preamble Access Header Length Data CRC
Address
8 Bits 32 Bits 8 Bits 8 Bits 0 to 296 Bits 24 Bits
5.3.5 Host Controller interface
This is an interface which connects the host and the controller. It is to be noted that Bluetooth classic had
around 60 % of Bluetooth controllers which used HCI interfaces. It allows the host to send commands
and data to the controller and the controller to send events and data back to the host. So it consists of two
separate parts, the logical interface and the physical interface. Logical interface typically include
Application programming interface on the controller. Physical interfaces typically include Universal
Serial Bus, Secure Digital Input output etc.
5.3.6 Host
The Host part is mainly divided into logical link control and adaptation protocol (L2CAP) layer, Attribute
ATT layer, Generic Attribute Protocol (GATT) and Generic Access Profile (GAP). The host performs
multiplexing of data, follows protocols and various procedures so that data flows. Each layer of the host
will be elaborated in detail in the following section. To simply things host can be any tablet, PC which has
an operating system. Or it can be visualized as an environment which exposes host API´s.
5.3.7 Logical Link Control and Adaptation Protocol
This layer acts as a multiplexing layer in BLE. It defines two concepts known as L2CAP channels and
L2CAP signalling commands. An L2CAP channel is a bi directional data channel that is terminated on a
profile or particular protocol in a peer device. In the case of BLE, fixed channels are used which are in the
form of one signalling channel, one security manager and one attribute protocol. So with respect to the
packet structure the L2CAP looks like as shown in Table 3 here below.
Table 3 — L2CAP Packet Structure
Length Channel ID Information Payload
2 bytes 2 bytes Length bytes
Each payload in the advertisement packet can be included with the L2CAP packet structure. So each
channel ID follows a particular operation which are clearly defines in the Bluetooth specification with
separate channel ID´s.
5.3.8 Security manager protocol
To pair up with any device and to retain trust on it, the security manager protocol is used. It provides
authentication for the device. Pairing is usually followed by link being encrypted and also by the
distribution of the key. Using this scheme, the shared secrets can be distributed from a slave to master
for the purpose of reconnection during a later date. This protocol is not used when beacon are used.
5.3.9 Attribute protocol
The main usage of this protocol is to get the information regarding the device. It defines the rules for
accessing data in a device. Attribute is just a piece of data. It can be small piece of data, which has a value
that has meaning. Attributes are usually stored in attribute servers, which can be read by an attribute
client which can in turn perform reading, writing operations. Attribute usually defines six types of
different messages:
1) requests sent from the client to server;
2) responses sent from the server to the client in reply to a request;
3) commands sent from the client to the server that have no responses;
4) notifications sent from server to client that have no confirmations;
5) indications sent from server to client;
6) confirmations sent from client to server in reply to an indication.
BLE is all about transmitting small pieces of data. These data are usually accessed by many devices.
Typical data could be signal strength of a mobile device, temperature in a room, current time in a city, the
number of times the equipment is opened or closed, etc. To represent this data attribute has a value,
universally unique identifier and a handle.
Handle is the memory location associated in the BLE controller. It is a 16-bit address which accesses the
memory location of a piece of data. Attribute data handles start from 0x0001 to 0xFFFF. Each of these
handles represents a memory address, port number or hardware register address for the attribute value.
Value is the type of data that is exposed by a device. It can be of size starting from 0 bytes to a maximum
of 512 bytes in length. Attribute also has a type which exposes the type of data. For example it might be
temperature, pressure, volume, distance, power, time, charge, Boolean state. Since there are many
different types of data, each type of data are exposed by a 128-bit number. These unique identifiers are
called universally unique identifier (UUID´s). These require 16 bytes of data to be sent across, so that
devices identify the type of data. Bluetooth SIG has defined 128-bit UUID known as Bluetooth Base UUID
which can be combined with a 16-bit number. The reason for introducing this 16-bit number which leads
to derived UUID is to follow the rules for allocating UUID´s. This also ensures that sending UUID´s across
devices is done through short UUID´s and then can be recombined with Bluetooth base UUID when
received.
The Bluetooth base UUID is defined as following:
00000000-0000-1000-8000-00805F9B34FB
To understand the concept of attributes consider an example: 25 °C is an attribute. It might be displayed
in a BLE device. In order to process this, it is split into the following: 25 is value, degree Celsius is
represented by a UUID, and the handle would be the memory address which is allocated in the BLE
controller. The address would be identified from the look up table where the attribute is present. So the
attribute just exposes data on a remote device.
These types of data are usually present in a server which can be represented as shown in the figure below.
Figure 3 — Types of data stored in a server; which are used as clients
Attribute server and attribute client are the two main roles associated with attributes. Attribute server
contains all the data; it receives requests, executes those requests and responds to them. It can also
indicate values. Attribute client usually communicates with server; it sends requests and waits for
response. It can also send confirmations to indications. For the efficient usage of attribute protocol the
following operations are usually performed. They are Pull, Push, Set, Broadcast, and Get.
Whenever the data changes in a server, it pushes the data using attribute push. In such case the client can
also configure the server to indicate the change. Whenever there is a need for client to request a data
from the server, attribute pull is requested. In such case, the client polls the server for the attribute value.
This operation might be inefficient when the data doesn’t change quite often. Client can also set attributes
to the server using attribute set operation. It uses write request command to do so. Typical examples
might include setting up a room Temperature to 22 °C. There is a possibility for the server to broadcast
data to any listening devices which can be performed using attribute broadcast. Commands like Read
information request can be used to identify if the data exists in the server.
5.3.10 Attribute database, server and client
A collection of attributes is called a database. Table 4 gives an example of database. Attribute database
can be large and complex or it can also be very small.
Table 4 — Attribute Data Base
Handle Attribute Type Value
0x0001 Primary Service GAP
0x0002 Characteristic {r, 0x0003, Device Name]
0x0003 Device Name Temperature Sensor
0x0004 Characteristic {r, 0x0006, Appearance}
0x0006 Appearance Thermometer
0x000F Primary Service GATT
0x0010 Characteristic {r, 0x0012, Attribute Opcodes Supported}
0x0012 Attribute Opcodes Supported 0x00003FDF
0x0020 Primary Service Temperature
0x0021 Characteristic {r, 0x0022, «Temperature Celsius»}
0x0022 Temperature Celsius 0x0802
Various operations can be performed to access the attributes. It might include Find requests, read
requests, write requests, write command, notifications and indication. To find a particular attribute from
a database, find attribute is used by the client. Read request is used to read an attribute from a database.
A single attribute, a range of attributes can be read using this command. Write request is used to write a
value onto the attribute. Multiple values in a database can also be written using this operation. In some
cases, there might be a situation where a response from write request is not needed, in such cases write
command is used. This enables the client to send a write command without any response in return to the
client. There is also an option of notifying any changes in the attributes, which can be performed using
notification command. Indication also has a same attribute handle and value, but this command causes
an attribute confirmation to be sent back.
5.3.11 Generic attribute Profile
Attribute protocol introduced in the previous section had a flat structure. It consisted of pieces of data
which had handles to get them located in the memory. However this attribute table gets quite complex
when there’s a lot of data which doesn’t have any shape or form. So in order to bring a grouping into the
data, profiles are created. These profiles have services, sub services and characteristics embedded into
them. Typical examples of profiles include a Temperature profile, battery profile, device profile, etc. In
order to process these profiles, there’s a need for hierarchical structure. In order to achieve this, services
are used which gives a simple form of structure to them.
In BLE, Generic attribute profile (GATT) defines two forms of grouping known as services and
characteristics. Services are synonymous to objects in object oriented systems which is unchanging over
a period of time. Services typically include one or more characteristics and also sub services. The
characteristic is a unit of data or exposed behaviour. These characteristics are self-describing, such that
generic clients can read and display these characteristics. To simplify things, a service just consists of
characteristics and their associated behaviours (see Figure 4).
Figure 4 — Service consisting of characteristics and behaviours
For the attribute database represented in Table 5, grouping can be performed in the following way. The
name of the service is GAP which defines a device called Temperature sensor. It consists of two
characteristics which can be read by looking into the memory location as indicated by the handle values.
It can be different.
Table 5 — Grouping
Handle Attribute Type Value
0x0001 Primary Service GAP
0x0002 Characteristic {r, 0x0003, Device Name]
0x0003 Device Name Temperature Sensor
0x0004 Characteristic {r, 0x0006, Appearance}
0x0006 Appearance Thermometer
Characteristic is just a single value. In Table 5 for the corresponding handle of 0x0002 a characteristic is
defined. It refers to memory location 0x0003 which has a device name of Temperature sensor. The
characteristic in memory location 0x0004 refers to the thermometer in memory location 0x0006. This is
how reading of characteristic data takes place.
5.3.12 Generic Access Profile
This is the top most layers in the host and this layer acts as an interface to the application layer. This layer
governs the advertising and connection parameters and ascertains roles to the devices.
A BLE device is either given a Central or a Peripheral role. This role is administered based on the initiator
of the BLE link. The Central is always the device that initiates the connection, while the Peripheral is the
device that is connected to. When the Central and the peripheral are in connection the terms Master and
Slave are used extensively. Bluetooth Core Specification also defines Observer and Broadcaster roles.
Observers listen to what’s happening on the air medium and Broadcasters send but don’t receive
information.
If the central connects with a peripheral, the Peripheral is said to be advertising state. Peripheral sends
advertising packets with a time interval, known as the advertising interval. It is between 20 ms and
10,24 s. The advertising interval defines the time taken to initiate a connection. The Central shall receive
an advertising packet before it can send a connection request to initiate a connection. The Peripheral only
listens for connection requests for a short while after sending an advertising packet. An advertising
packet can contain up to 31 bytes of data. It usually contains a user readable name, preamble, information
about the device sending packets, some flags used to know whether the device is connectable or not.
When a Central receives an advertisement packet, it can also send a request for more advertising data,
using a Scan Request, if it is configured as an Active Scanner. In such a case, the peripheral might be
sending additional data to prove its identity. A Peripheral responds to the request by sending a Scan
Response that can contain an additional 31 bytes.
Scanning is used by the Central to listen for advertising packets and to send scan requests. There are two
additional timing parameters known as scan window and scan interval. For each scan interval, the Central
scans for a time equal to the scan window. This implies that if the scan window is equal to the scan
interval, the Central will do a continuous scan. The scan duty cycle (measured in percentage) of the
Master is also known as the scan window divided by the scan interval.
When the Central wants to enter a connection, it will use the same procedure as when scanning to listen
for advertising packets. When initiating, the Central will send a connection request to the Peripheral
when it receives an advertising packet.
By definition it is to be understood that the Central and Peripheral are in a connection from the first data
exchange. When in a connection, the Central will request data from the Peripheral at specifically defined
intervals. This interval is known as the connection interval. It is decided and applied to the link by the
Central. However the peripheral has the authority to send connection parameter updates to the central
and can choose its connection interval. According to the Bluetooth Core Specification, the connection
interval is between 7,5 ms and 4 s.
If in any case the Peripheral doesn’t respond to data packets from the Central within the time-frame called
connection supervision timeout, the BLE link is lost. It is possible to achieve higher data throughput by
transmitting multiple packets in each connection interval. Each packet transferred can be up to 20 bytes.
There is also a term known as slave latency. It is used when the peripheral chooses to ignore the data sent
by the central than the number of ignored intervals is called the slave latency.
6 BLE usage in IFM systems: concept description
6.1 Introduction
The main use for BLE is Account Based Ticketing (ABT) systems. Figure 5 shown below shows an example
of architecture in which BLE can be used.
Figure 5 — Layers in proposed BLE concept
BLE beacons are used within the IFM system architecture. The beacons can also be used for several types
of functionality. It is important to see the whole customer experience as seamless and integrated across
IFMS and different steps in the customer process (travel planning, deciding the right ticket product,
payment, ticket distribution, ticket use, real time information, general information flow to passenger
before, during and after the journey). The same beacons may play different roles for different purposes
during the journey. Even though the IFMS traditionally have focused on the fare part, it is becoming more
important to see the different aspects of the customer journey as a whole.
6.2 Overview: building blocks and network topology
6.2.1 Building blocks of BLE
BLE is organized in 3 major building blocks: Application, Host and Controller. The Application block is, as
the name suggests, the user application which interfaces with the Bluetooth protocol stack. The Host
covers the upper layers of the Bluetooth protocol stack; and the Controller covers the lower layers. The
Host can communicate with the BLE module with an addition of something called HCI – the Host
Controller Interface. The purpose of HCI is, obviously, to interface the Controller with the Host, and this
interface makes it possible to interface a wide range of Hosts with the controller. The MCU runs the
Application, and talks to a Connectivity Device. The Connect
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...