Bluetooth Low Energy or Bluetooth Smart is a comparatively new wireless communication technology that was introduced by the Bluetooth Special Interest Group in 2010. Although the technology itself was being developed way earlier by Nokia around 2001 to 2006 under the name Wibree, it was not until 2007 that an agreement was reached with the various members of Bluetooth SIG that Wibree should now be included in the Core Bluetooth Specification, a task which was completed in 2010, when Wibree became a part of Bluetooth Core Specification version 4.0 as Bluetooth Smart, commonly known as Bluetooth Low Energy (its original name). The first mobile device to incorporate the 4.0 specification was iPhone 4S. However, as it is almost always with early adopters, the then iPhone 4S operating system did have some bugs regarding Bluetooth connectivity and range sometimes being poor. Bluetooth Smart technology has matured rapidly since then and come a long way. In fact, the dawn of the current IoT revolution is relying significantly on Bluetooth Low Energy for its success. According to an analysis done by IndustryArc.

Bluetooth Low Energy device shipments are forecast to increase to 8.4 billion units by 2020 at a mean annual growth rate of 29% which eventually will also lead to a surge in the number of IoT devices (things, if spoken semantically). We are seeing the early stages of this revolution all around us as a result of which, almost every handheld device and wearable nowadays has BLE capabilities.

So, what is it that makes Bluetooth Low Energy so special? How is Bluetooth Low Energy different from the good old regular Bluetooth? Why is every other wearable device (for example, Fitbit, Nike Fuelband, Apple watch and maybe your own smartphone) on the market using Bluetooth Low Energy (Couldn't they just do away with regular bluetooth and be happy about it)? We will explore the answer to all these questions and many others in this chapter. Furthermore, we will also discuss the architecture and what lies under the hood that makes Bluetooth Low Energy live up to its name.

So, coming to the very first question, what makes Bluetooth Low Energy so special? We will have to go back in time a little bit to address this.
During the year 2001, the researchers at Nokia had already identified a number of scenarios, which were not being addressed by any of the existing Wireless Personal Area Network (WPAN) communication technologies,

The most common factors that came out as a result of studying these scenarios were:

• Low power usage
• Low cost
• Minimal differences with current Bluetooth technology

Hence, what started in 2001 ended up being Bluetooth Low Energy or Bluetooth Smart in 2010. The technology was given a descriptive name, which also describes its real purpose of existence. Bluetooth Low Energy was designed for devices which had:

• Low power requirements, operating on a coin cell for longer periods of time (months or even years)
• Low cost
• Industry standard wireless protocol, which can be easily adopted

And guess what? They finally succeeded in achieving all the set goals.
If you remember the age of early mobile phones, the ones which had classic Bluetooth only, then you might remember that classic Bluetooth was a battery-expensive feature and continuous usage used to drain the battery on the device pretty quickly. Also, there were not many low-cost Bluetooth accessories available as there are now. However, with the advent of Bluetooth Low Energy (which consumes low power), all these things are bygones. We can now buy a Bluetooth tag, which supports and operates on Bluetooth 4.0, similar to the ones shown next for as low as 1-2 euros (Don't worry too much if you do not yet understand what this tag is used for. In the later chapters, we will build an application around the usage of this tag.):

Fitbit, one of the most common and popular fitness trackers, used for recording the body vitals and daily activity, has a battery life of 7-10 days after a full charge (source: https://www.fitbit.com/charge). Please note that this is a device which is working continuously day and night and even records data when you are sleeping:

Lastly, Bluetooth Low Energy is now being incorporated in each and every smartphone being rolled out. Apple which was one of the early adopters of Bluetooth Low Energy was later joined by Samsung, LG, Motorola, and every other major mobile device manufacturer out there. The popularity and adoption rate of the technology has already seen exponential growth and with the announcement of Bluetooth 5, which promises double the speed and four times the range, we will continue to see an even larger wave of Bluetooth Low Energy and IoT devices hitting the market.

Although Bluetooth Classic and Bluetooth Low Energy share many important things such as architecture, and both operate in 2.4 GHz ISM Band, the fundamental difference between them is that BLE is designed to consume less power. Due to this caveat, BLE is not an ideal candidate for applications such as streaming voice data (talking over the phone); however it makes BLE an excellent choice when it comes to communicating via exchanging small amounts of data over short periods of time. We shall discuss the communication differences between Bluetooth Classic and Bluetooth Low Energy in detail below.

Under Bluetooth Classic, when two or more devices want to talk to each other, then they always need to pair first (although pairing does happen when two devices communicate over Bluetooth Low Energy too, however; it is not mandatory in the case of BLE). Once the pairing has succeeded, an ad hoc network is established also known as the piconet:

A piconet can consist of a single master and up to seven slave devices. The devices can switch role by agreement (a slave can become a master at a later stage during the timeline of communication). Although a master can have up to seven slaves, at any point in time the master is addressing a single slave and the slave is supposed to listen when this happens. Also, it is important to note that being a slave to more than one master is certainly possible. This often results in interconnected piconets, also known as a scatternet:

Whether it is piconet or scatternet, the communication channel between the master and slave remains established even if no data is being exchanged and is only terminated when one (or both) of the parties (master/slave) explicitly decides to terminate the connection.

On the other hand, communication over Bluetooth Low Energy can be abstracted away as interacting with a really intelligent database. During this type of communication, each of the devices involved either plays the role of the database (known as peripheral in Bluetooth Low Energy terminology) or a listener (known as central in Bluetooth Low Energy terminology) of that database updates. Whenever new data is available, the database magically notifies all its listeners that new data is available to use. This magic takes place via something known as Indications and Notifications which we shall elaborate on in an upcoming section:

Before moving on to rest of the differences between Bluetooth Low Energy and Bluetooth Classic (also known as Bluetooth BR/EDR), let's first discuss a few terms, the understanding of which is absolutely critical for the discussion ahead:

• ISM channels/radio bands: ISM bands are the portions of the electromagnetic frequency spectrum, which are reserved for industrial, scientific, and medical purposes only. For example, the 2.4GHz ISM band is available worldwide and spans 2400MHz to 2483.5MHz. This means a device operating in this band can be legally used anywhere in the world (provided it is certified).
• Data rate: This is the theoretical rate of data flow, which can be achieved in a system.
• Application throughput: This is the practical rate of data flow, which can be achieved in a system.

Both Bluetooth Classic (BR/EDR) and Bluetooth Low Energy operate in the 2400-2483.5 MHz range within the ISM 2.4 GHz frequency band. However, data exchange in Bluetooth Classic happens over one of the 79 designated channels, as opposed to that of Bluetooth Low Energy where the number of designated channels is 40:

The core technical specifications of Bluetooth Classic and Bluetooth Low Energy are tabulated as follows:

Technical specifications	Bluetooth Low Energy	Bluetooth Classic
Power consumption	Rated power Consumption of 0.01 to 0.5 W	Rated power consumption of 1 W
Data rate and throughput	Physical data rate is 1 MBit/s with an effective application data throughput of 0.3 MBit/s	Physical data rate is 1-3 MBit/s with an effective application data throughput of 2.1 MBit/s
Latency (from a non-connected state)	6 ms	100 ms
Voice capable	No	Yes
Distance/range (theoretical max.)	>100 m	100 m
Pairing mandatory	No	Yes
Frequency (GHz)	2.4	2.4
Active slaves	Up to 7	Undefined and implementation dependent
Security	128-bit AES and application layer user defined	56/128-bit and application layer user defined
Network topology	Point-to-point and Star	Piconet, scatternet, and point-to-point
Frequency channels	40	79
Minimum total time to send data (det. battery life)	3 ms	100 ms
Current consumption	<15 mA	<30 mA
Logo

The architecture of Bluetooth Low Energy is divided into three important layers:

• Application
• Host
• Controller

Refer to the following figure:

We shall touch on every segment/layer briefly before delving deeper into each of the layers.

We will develop multiple applications for several IoT and Bluetooth Low Energy use cases throughout the course of this book and these applications will be hosted in the application layer of a Bluetooth Low Energy compatible device. This is the layer which will contain the user interface, application logic, and the overall application architecture.

A working knowledge of this layer is necessary to start building Bluetooth Low Energy oriented applications. However, it is always good to know what goes under the hood and how our application talks to the underlying Bluetooth Low Energy hardware/chipset; hence, we will also explore the host and the controller layers.

Lying just the following Application layer is the Host layer, which has the following layers:

• Generic Access Profile (GAP): This defines how Bluetooth Low Energy devices access and communicate with each other. Bluetooth Low Energy devices can connect to each other in one of the following roles:
  • Broadcaster: Also referred to generically as peripheral, this is a role where a Bluetooth Low Energy device broadcasts/advertises information packets.
  • Observer: Also referred to generically as central, this is a role where a Bluetooth Low Energy device listens for the packets and then decides to initiate a connection, or not, depending on the use case.
• Generic Attribute Profile (GATT): This defines how data or attributes are formatted, packaged, and sent across connected devices according to its described rules. Similar to GAP, there are certain roles that interacting devices can adopt:
  
  • Client: This typically sends a request to the GATT server. The client can read and/or write attributes/data found on the server.
  • Server: One of the main roles of the server is to store attributes/data. Once the client makes a request, the server must make the attributes/data available.
• Attribute Protocol: This defines rules for accessing attributes/data on a device. A GATT profile is built on top of the attribute protocol. Although GATT implements the client server roles, these are defined by the Attribute Protocol. This protocol also defines the fact that data on a server will be arranged in the form of attributes each of which will have:
  • A 16-bit attribute handle
  • A UUID
  • A set of permissions
  • A value

Next, the protocol also defines various read and write operations for attributes also known as ATT operations:

• Read Operations
• Write Operations: These are of type Write Requests with Response (write to an attribute and expect a response), Write (write without expecting acknowledgement), Signed Write (similar to write but uses a signature to authenticate the data)
• Indications: These are asynchronous notification operations initiated by the server for the client. This is initiated if the client has subscribed to the updates of attribute values. It requires an acknowledgement from the client.
• Notifications: are similar to an indication. The only difference is that they do not require an acknowledgement from the client.

All in all, Attribute Protocol is just a set of rules related to accessing data. Don't worry if you don't understand the significance of it at this stage. We will be covering the significance of these characteristics/attributes and related operations in the upcoming sections:

• Security Manager Protocol: This defines rules regarding authentication processes such as pairing
• Logical Link Controller and Adaptation Protocol (L2CAP): This defines the following rules:
  • Fragmentation and defragmentation of application data
  • Multiplexing and demultiplexing of multiple channels over a shared logical link

The Host layer defines three very important specifications, that is, characteristics, services, and profiles, which help Bluetooth Low Energy devices to discover, identify, and talk to each other.

It really can't be stressed enough that a thorough understanding of these three specifications is absolutely imperative to design robust Bluetooth Low Energy oriented applications. We will go over each of these in detail, right after we have briefly touched on the controller layer.

Simply speaking, the controller is the actual Bluetooth chip or hardware, which facilitates transmission and receipt of Bluetooth signals:

It consists of the Link Layer and the Physical Layer. As the name already suggests, the Physical layer consists of all the complex analog circuits, which transmit and receive the digital data over the air. The Link Layer, on the other hand, is responsible for scanning, advertising, creating, and maintaining links (connections) between devices. The link layer can have five states: Standby, Advertising, Scanning, Initiating, and Connection (master- slave):

Delving deeper into the three main pillars of the Bluetooth Low Energy technology should have already given you an idea of what lies under the hood. Now, as promised, let's discuss the important specifications defined by the Host layer, starting with profiles.

Profile, in a generic sense as a verb, means to describe, and that is what actually Bluetooth Low Energy Profiles are. In a nutshell, A Bluetooth Low Energy Profile is a description of the behavior of a Bluetooth Low Energy device, and it is also an answer to questions like "What is the purpose of this device?" or "What can this device do?"

Perhaps, a conversation between a company executive and the software development team lead revolving around a Bluetooth Low Energy device will give you an idea of the importance of profiles for Bluetooth Low Energy devices:

Healthcare Company Executive: "We want to roll out a new series of health devices for recording and monitoring a user's blood pressure"

Software Development Lead: "Ok, sure. Do you have some specifics in mind about this device?"

Healthcare Company Executive: "Yes, this will be a small handheld device which can diagnose, record user's blood pressure and send the readings to an app installed on the user's smartphone. The app will then upload the data to our servers to be made available to the doctor for diagnosis."

Software Development Lead: "Since this is an on-demand connectivity device; that is, the user only has to connect to the smartphone to transfer the data; hence this can be built into a low power consumption device which uses Bluetooth Low Energy as a mode of communication with the smartphone. Also, the device will support Blood Pressure Profile to be recognized as a healthcare device, which can process blood pressure data."

After the decision committee has reached a conclusion:

Software Development Lead to Developers: "Our company is rolling out a Bluetooth Low Energy based medical device supporting Blood Pressure Profile and we need to write an app for that. More details in tomorrow's meeting. Please come prepared for the meeting."

Our seasoned developer, developing a newer profile, will now head over to the Bluetooth SIG website to read the specification about the Blood Pressure Profile in preparation for the upcoming meeting.

This is a very real example of an ideal IoT+BLE use case and devices like these already exist fulfilling similar use cases.

The preceding discussion might already have given you some vague idea regarding what a profile actually is and how it matters for a Bluetooth Low Energy device. To solidify it to some extent, here is a popular visualization of a profile:

As the diagram shows, the profile dictates what services each profile hosts and, before delving deeper into that, we would request you please go over the Blood Pressure Profile description document available at the link provided previously, since, not only will it give you a better understanding of what we just discussed, but it will also be very helpful in what we are about to discuss. Don't worry if you don't understand everything there (and in the preceding diagram) at once, as we will be delving much deeper into services and other acronyms, which might be puzzling you at this stage.

Going over the Blood Pressure Profile description document, a few things would have jumped out at you right off the bat:

• Blood Pressure Profile requires a GATT profile
• It defines two roles GATT Server (Sensor) and GATT Client (collector)

If you recall, this is exactly what we discussed when we went over the Host layer and briefly touched upon the role of the GATT profile. We are now seeing glucose profile building upon GATT and defining individual device roles for a connection to be established between two devices.

The Profile document also dictates what kind of services the sensor will contain by mentioning the following:

• The blood pressure sensor will instantiate one, and only one, blood pressure service
• The blood pressure sensor will instantiate the device information service

That exactly maps up if you look closely at the Profile diagram. The Blood Pressure Profile is already dictating the kind of services it will contain. And this brings us to the question, "What exactly are Services?", which will be our next topic of discussion.

Extending further from the previous section, we saw that the GATT profile imposes a client–server architecture to facilitate the communication between Bluetooth Low Energy devices (the sensor and the collector) and Bluetooth Low Energy technology. Following a service-oriented architecture, the blood pressure sensor (or any other Bluetooth Low Energy device playing a GATT Server role) exposes some services.

Remember, how we compared Bluetooth Low Energy to a very intelligent database in the previous section, and that is exactly what is happening here. The primary reason for the existence of a blood pressure device sensor (or any other Bluetooth Low Energy sensor/device) is extremely simple. It measures the correct data (blood pressure levels in this case), stores it, and then makes the data available when requested by a client. A service is a wrapper on top of this data (this data is also known as characteristics and more on characteristics later). Similar kinds of data or characteristics are bundled together in a single service. This is a key factor in understanding the design of services, which exist to bundle similar kinds of data together. Perhaps an example will provide further clarity to this. The Blood Pressure Profile indicated the existence of two kinds of services:

• Blood Pressure Service: This consists of Blood Pressure Measurement data/characteristics
• Device Information Service: This consists of device data (Manufacturer Name, Model Number, Serial Number, and Hardware Revision):

Did you notice how each service consists of different kinds of data, which is similarly pertaining to itself? If you want to get blood pressure data, you should go and interrogate the blood pressure service and if you need information about the device itself, then you should go and talk to the device service. This is the primary reason for the existence of services. We had already established in the previous section that a profile can have multiple services. Like Bluetooth profiles, the Bluetooth SIG defines a number of official services.

Each official service is assigned a unique 16-bit UUID so that it can distinguish itself from others; for example, a blood pressure service has a UUID of 0x1810 and a device information service has a UUID of 0x180A. You can also write your own custom service for a specific purpose, but then it will need to have a 128-bit custom UUID.

Once again, I will strongly advise you to go over the relevant documentation of Blood Pressure Service and Device Information Service. Not only will this be very helpful in the discussion ahead, it will also clarify the information indicated in the preceding diagram.

The documents outline what characteristics each of the services contain or what information can be found on interrogating relevant services. For example, the blood pressure service contains three distinct characteristics:

• Blood Pressure Measurement
• Intermediate Cuff Pressure
• Blood Pressure Feature

The documentation also indicates what kind of data each characteristic holds; for example, the Blood Pressure Feature characteristic is used to describe the supported features of the blood pressure sensor. And by that, we have already started touching base on characteristics which deserve a topic of their own.

Characteristics are the lowest and the most important echelon of the Bluetooth Low Energy technology. Encapsulated by a related service, these are the actual state variables, each of which stores a single piece of relevant measurement and information data:

Just like services, these have a UUID, which can be 16-bit or 128-bit based, depending on whether a characteristic has a standard or custom definition. For example, the blood glucose measurement characteristic has a UUID of 0x2A35. Also, just like services, a manufacturer is free to define custom characteristics of only his/her software, but to facilitate maximum interoperability between Bluetooth Low Energy devices, it is always better to follow the definition of standard characteristics. Bluetooth SIG defines a list of standard Bluetooth Low Energy characteristics here.

It is worthwhile taking a look at the collection of characteristics exposed by the Blood Pressure Service.

Remember how we previously discussed that we can abstract Bluetooth Low Energy as an intelligent database. To build all that intelligence, characteristics bundle much more than a single value. Although the value is of prime importance, it is important to understand what makes this intelligent database magical.

Each characteristic as a whole comprises the following:

• Characteristic declaration: The characteristic declaration is an important part of a characteristic as it contains the UUID and properties of a characteristic. The properties of a characteristic are 8-bits lined together, which determine how the value of the characteristic can be used and how the descriptors can be accessed. You should already have seen the properties associated with each characteristic of the Blood Pressure Profile service by visiting the preceding link. We discuss the relevance of each of these properties as follows:
  • Read: If this bit is set, then it means that clients are allowed to read this characteristic's value.
  • Write: If this bit is set, then it means that clients are allowed to write (and receive a response) to this characteristic's value.
  • Write without response: If this bit is set, then it means that clients are allowed to write (without response) to this characteristic's value.
  • Signed Write: If this bit is set, then it means that clients are allowed to do a signed write to this characteristic's value.
  • Notify: One of the important ones. If set then the server will asynchronously notify the client whenever the value of the characteristic gets updated on the server. We will discuss this more in the next section. Also, if set, then the client configuration descriptor will exist. We shall discuss descriptors in detail shortly.
  • Indicate: Similar to notify, the only difference is that an indication requires an acknowledgement from the client. We will discuss this more in the next section. Also, if set, then the client configuration descriptor will exist. We shall discuss descriptors in detail shortly.
  • Write auxiliaries: If set, then the client can write to the characteristic user description descriptor.
  • Broadcast: If this bit is set, then it means that the value of this characteristic will be broadcasted, that is, placed in advertising packets.
  • Extended properties: Is set, then additional properties are defined in the characteristic extended properties descriptor, which also means that the characteristic extended properties descriptor shall exist. We shall discuss descriptors in detail shortly.

These properties are essentially the guidelines for how clients can interact with this characteristic and also, how they can subscribe (listen) to indications and/or notifications of this characteristic. We will see how the indications and notifications can be enabled in the next section.

• Characteristic Value: This is self-explanatory. You can already see how the measurement data is packaged for a blood pressure measurement characteristic at the link provided in the upcoming information box.

• Characteristic Descriptor: Each characteristic can be followed by one or more descriptors. Descriptors contain more information regarding a characteristic and its value. Just like services and characteristics (and you might have already guessed it here), these can either have a standard definition or a custom definition. To help clarify, we shall discuss some standard descriptors defined by GATT.

• Client Characteristic Configuration Descriptor (CCCD): This is one of the most important and most commonly used descriptors. This descriptor is used when you need to configure (enable/disable) indications or notifications for the characteristic. It is this descriptor that makes our so-called database so intelligent. By correctly configuring it for a characteristic, a client (possibly your app J) can expect to be dynamically notified whenever the characteristic updates its value on the GATT Server (a Bluetooth Low Energy sensor such as a blood pressure or a blood glucose meter). The blood pressure measurement characteristic includes a client characteristic configuration descriptor.

• Characteristic User Description Descriptor: As the name already suggests, this descriptor contains a human-readable string that describes the characteristic's value, which also can be directly presented to the user.

• Extended Properties Descriptor: If this is present, it contains information about extended properties.

Starting with Profiles, we finally covered the lowermost echelon of the Bluetooth Low Energy communication, the characteristic. We saw that it is not just as simple as reading and writing to/from a characteristic. We also touched upon the magic of indications and notifications upon which the whole Bluetooth Low Energy communication relies heavily and, hence, they deserve a topic of their own.

We briefly touched upon indications and notifications in the previous section. Indications and notifications basically are server (GATT) side updates to a client. A client has to configure Indications and Notifications for a characteristic's value through its client characteristic configuration descriptor to get notified every time a characteristic's value gets updated on the server:

As shown in the preceding figure:

• Indications: They need to be acknowledged by the client. The server does not send the next indication until it gets the acknowledgement back from the client. Hence communication via indications is slower.
• Notifications: They do not need to be acknowledged by the client. Hence, communication via notifications is faster.

Indications and Notifications are a very important mechanism for receiving server-side data probably due to the fact that they are the only and fastest mechanism for receiving asynchronous server-side updates. Since Bluetooth Low Energy was designed to be energy efficient, this asynchronous method of receiving updates prevents continuous polling of the server by the client and, hence, is a huge energy saver too.

The retail market for connected things is projected to have a worth of 53.75 billion by 2022 and Bluetooth Low Energy is forecast to witness a substantial growth with a CAGR of over 25% during the forecast period.

In other words, this makes Bluetooth Low Energy a significant driver for this forecast growth and technology to be taken seriously. Bluetooth SIG is leaving no stone unturned to make the existing Bluetooth Low Energy technology a better fit for IoT Applications. The SIG recently finalized and released the specification for Bluetooth 5, which takes the existing technology to the next level by enabling quadrupled range, twice the speed and increasing the data broadcasting capacity by 800%. These new features are specifically focused on Internet of Things technology.

However, MCUs supporting Bluetooth Low Energy 5 like the one shown here are already available:

Bluetooth 5 is a new standard, which has been rolled out very recently (from the end of 2016 to the beginning of 2017). For the consumers, it may take some time to feel the difference between the older Bluetooth Low Energy 4.2 versus the Bluetooth Low Energy 5 as various device manufacturers will adopt this standard and manufacture Bluetooth Low Energy 5 compatible devices, which will then hit the market and eventually end up in the hands of the consumers. As of the writing of this book, Samsung has already taken the lead and has released Galaxy S8 worldwide during the period towards the end of April and beginning of May 2017, which is the first smartphone to support and an early adopter of Bluetooth Low Energy 5. However, another key update, which is not immediately included in the Bluetooth Low Energy 5 standard is the specification for Mesh Networking. It is still said to be in works and probably will arrive early next year. This update for Bluetooth Low Energy is crucial for the IoT paradigm as it can enable data to be transferred across even greater distances just via Bluetooth Low Energy nodes/hubs. We shall briefly touch upon Mesh Networking to see how this is possible.

Traditional Bluetooth Low Energy network topology looks something similar to the star topology such as shown in the following diagram:

Here, one device acts as the server and others access information (characteristics) from the server, if and when required. It goes without saying that this is the traditional way of communication, and it limits the networking capabilities in terms of the following:

• Limited range/distance of data transfer
• Nodes are not directly connected, all data goes through a central device (server)
• Single point of failure, if the server fails everything else fails too

The preceding factors mentioned can severely limit an IoT-based solution.

The solution to this is the eagerly awaited mesh networking update, intended to transforming each individual Bluetooth Low Energy node to a hub, where the node/hub can also transfer data to the nearby devices. This will change the network topology from a traditional star network to a Mesh as shown as follows:

This means each node of the network can accept and forward data to a neighboring node, allowing a network to scale more easily by just adding new nodes. A mesh network exhibits the following characteristics:

• Self Forming/Organising: As soon as a new node joins the network, all its adjacent nodes are notified so that an optimized path can be configured dynamically for the data packets.
• Self Healing: If one node fails in the network then surrounding nodes immediately become aware of this and an optimized path is configured dynamically for the remaining data packets. A single node cannot cause the failure of the complete network. The network continues to function without any downtime as long as the density of the devices is sufficient to keep the communication ongoing.
• Self Optimization: The network can self-optimize itself to have as large a coverage as possible.

Another pre-existing piece of hardware technology, which is greatly going to benefit with Bluetooth Low Energy 5 is Beacons. Beacons are small sized, Bluetooth Low Energy devices which broadcast information:

Bluetooth Low Energy Beacons are primarily used for proximity broadcasting or advertising. A very popular use case of beacons is to broadcast/advertise contextual information to nearby smartphones and handheld devices, which support Bluetooth Low Energy, in close proximity. The context of the information can be bus updates on a bus stop, new products in a store, or special delicacies available at a restaurant.

The other uses of Beacons include:

• Indoor Navigation: Since GPS does not work indoors, Bluetooth Low Energy can be used for indoor navigation by placing beacons at strategic places in a closed space (houses/offices)
• Tracking Things: Bluetooth Low Energy based Beacons/tags can be attached as trackers to things that are more prone to getting lost, such as keys. These items can then be monitored via a smartphone app
• Personal Monitoring: Monitoring patients, the elderly, and toddlers inside a home

There are already various preprogrammed beacons and respective development kits available in the market.

However, later in the course of this book, we will take the road less traveled and create a beacon of our own using a Raspberry Pi. Also, we shall discuss the two primary Beacon protocols namely, Eddystone and iBeacon.

Phew! We covered a lot of ground in this chapter, which although substantial is still just the tip of the iceberg. However, I feel pretty confident in saying that you as a reader should now be familiar with the answers to the following questions, which we asked before starting this chapter:

• Why was Bluetooth Low Energy designed or what is the need for Bluetooth Low Energy?
• What are the differences between Bluetooth Low Energy and Bluetooth Classic?
• What does the architecture of Bluetooth Low Energy look like?

Apart from delving deeper to answer these questions, we also briefly touched upon the advent of the latest Bluetooth Low Energy 5 specification and how it is going to help IoT to reach new levels of connectivity and data exchange between devices. Furthermore, we also scratched the surface of Mesh Networking and Beacons.

With all this theory under our belt, we are now going to apply it to gain hands-on knowledge over the course of this book. Going ahead, we will be setting up our development environment, sniffing a fit-bit device, brewing our very own homemade beacons, designing a personnel tracking system using iTags, and we'll then bring it all together by building a complete warehouse monitoring system. So put on your seat belts, here we go.