Chapter 2. Basic Concepts

In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

—IETF RFC 1925, Rule 12

To understand Bluetooth low energy is to understand how low power consumption can be achieved in a short-range wireless system. The most basic design decisions are all built around enabling low power consumption in typical use cases.

Bluetooth low energy is not trying to optimize Bluetooth classic; instead, it is targeted at new market segments that haven’t previously used open wireless standards. These market segments are those that require devices to send a few octets of data from once a second to once every few days. These are monitoring and control applications that perform tasks, such as detecting whether windows are open or closed for Smart Home heating applications, turning on and off appliances in response to electricity price fluctuations, or changing to a different TV channel.

2.1. Button-Cell Batteries

Button-cell batteries are the primary design goal for Bluetooth low energy. These batteries (see Figure 2–1) have very strict limits on how they can be used. The figure shows a CR2032, although other battery sizes are also available. The “CR” part of the battery label indicates it’s a 3-volt battery made using lithium manganese dioxide. The “20” denotes that the battery is 20mm in diameter, and “32” specifies that it’s 3.2mm in height.

Figure 2–1. A button-cell battery.

For such small batteries, the maximum energy that can be stored in one manufacturer’s battery is very similar to any other. A typical CR2032 will have a quoted energy capacity of 230mAh at 3 volts. Just to put this into context, this is about the amount of energy required to power a human being for just over 20 seconds. So by the time you’ve read this paragraph, you’ll have used more energy than a typical CR2032 has available to power a Bluetooth low-energy device for a few years.

Even though 230mAh is a comparatively tiny amount of energy, a device will never be able to obtain all of it. First, the energy available is dependent on the temperature of the battery. The colder the battery, the less energy will be available. A button-cell battery at would only be able to provide 80 percent of the energy that is available at room temperature.

Second, if the battery is used aggressively, the total energy available will be significantly reduced. Typically, most button-cell batteries have a peak current that should not be exceeded without damaging the battery. This is typically 15mA. If this high-level current is drawn from the battery for extended periods of time, the total energy available would be reduced. Therefore, any successful radio design would need to manage this and allow the battery time to recover after a large or long current draw.

Finally, the battery itself has its internal leakage current that must also be taken into account. Even if a device is drawing no power from the battery, the battery is still losing charge. When the battery is used sparingly, the leakage current will start to become significant in the total energy budget.

2.2. Time Is Energy

Another basic concept that is used throughout the design of Bluetooth low energy is that time is energy. If the radio is doing something, even if it’s nothing more than checking whether it needs to send or receive something, it’s using energy. Consequently, it is important to reduce the time required to do anything useful.

A number of important and repetitive actions must be optimized. These include robustly discovering devices, connecting to devices, and sending data. By reducing the time required for these activities, the energy consumption is reduced, lengthening the life of the battery.

Robust device discovery requires a minimum of two devices: a device that is looking for other devices, and one or more devices that are discoverable. In Blue-tooth low energy, for a device to be discoverable, it must transmit a very short message three times every few seconds, and if it needs to see if any other device wants to talk to it, it must listen immediately after broadcasting its message. A device that is looking for devices opens up its receiver and listens for devices that are transmitting.

Three transmits are done because three frequencies are used for robustness. The number three is chosen as a compromise between robustness and low power. If the number of frequencies was just one, like a lot of other technologies, then as soon as that frequency is blocked, the whole system would break. If the number of frequencies was, for instance, 16, the device would spend so much time just transmitting that it would not be low power anymore.

The choice about which device transmits and receives is also very deliberate. To search for a device that is transmitting requires you to listen for a long period of time; this uses a lot of energy and therefore should be done on the device with the bigger energy budget or a good reason to use the low-energy device. In Bluetooth low energy, the discoverable devices transmit, and the devices that are looking for the other devices receive.

The packet itself is very short. Short packets are good for three reasons. First, by using efficient encoding, short packets can send the same quantity of data faster, using less energy. Second, by restricting the devices to only use short packets, the requirements to constantly recalibrate the radio within the controller as the packet is transmitted are removed. Radios, when transmitting or receiving, will heat up, changing the characteristics of the silicon chip, and therefore changing the frequency of the transmissions. If the packets are kept short, the chip doesn’t have enough time to heat up; thus, this energy-expensive procedure can be ignored. In addition, the requirement for a short packet also reduces the chip’s peak power consumption a little. Finally, you can get more energy out of a button-cell battery by taking it in short-duration bursts and not a long continuous draw of current. Therefore, using several short packets with a sufficient space between them to allow the battery time to recover is better for the battery than using one longer packet.

2.3. Memory Is Expensive

Everybody knows that the more memory a computer has, the more expensive it is. However, every little bit of memory in a computer not only costs money but also costs energy. Memory typically requires dynamic refreshing—every so often the memory in the chip is refreshed. This dynamic refreshing requires energy. So the more memory that a device requires, the more energy is required to power the device. Therefore, the whole of Bluetooth low energy has been designed to reduce the amount of memory that is required in every layer.

For example, keeping the packets small in the Link Layer helps because it reduces the memory requirements for the radio when transmitting and receiving packets. For example, the Attribute Protocol Layer does not require any packets larger than 23 octets to be processed. It also does not require any state information to be saved between transactions. All this reduces the memory needed to do something useful.

Another burden for memory is the multitude of protocols that are required to be active when a device can do multiple things. For example, imagine a headset that does hands-free, remote control, and battery status reporting. If each of these use cases required a separate protocol, the memory required for each of those protocols would have to be added together. In Bluetooth low energy, there is only one protocol. The Attribute Protocol is used for name discovery, service discovery, and for reading and writing information required to implement a given use case. By having only one protocol, the overheads of multiple protocols are significantly reduced.

2.4. Asymmetric Design

One of the obvious design concepts in Bluetooth low energy, once the architecture has been understood, is the asymmetry that is evident at all layers. This asymmetric design is very important because the device with the smaller energy source is given less to do.

At the Physical Layer, there are two types of radios: transmitters and receivers. A device can have both a transmitter and a receiver. However, a device can implement only a transmitter or only a receiver. If one device only has a transmitter, and the other device only has a receiver, this is an asymmetric network.

This asymmetric design is all based on the fundamental assumption that the most resource-constrained device will be the one to which all others are optimized.

At the Link Layer, devices are divided into advertisers, scanners, slaves, and masters. An advertiser is a device that transmits packets; a scanner is a device that receives the advertiser’s packets. A slave is connected with a master, but even here the asymmetry is evident. A slave cannot initiate any complex procedures, whereas a master has to manage the piconet timing, adaptive frequency hopping set, encryption, and a number of other complex procedures. The slave only does what it is told and doesn’t have to perform complex processing at all. This keeps the slave very simple and therefore low cost, low memory, and using the lowest possible power.

At the Attribute Protocol Layer, the two types of devices are called client and server. The server holds data and the client sends requests to the server for this data. The server, like the slave at the Link Layer, just does what it is told. The client has the hard job of working out what data the server has and how to use it.

Even the security architecture for low energy is asymmetric. The security architecture works on a key distribution scheme by which the slave device gives a key to the master device for it to remember. The burden is on the master to remember this bonding information; the slave doesn’t have to remember anything. This means that it’s simple for a slave device to support security, yet for a master device it is more complex.

This all implies that the most resource-constrained devices will want to be advertisers, slaves, and servers. These types of devices have the lowest possible memory and processing burden; therefore, the asymmetric design is beneficial to the goal of ultra-low power consumption on these types of devices.

The other types of devices—scanners, masters, and clients—have lots of resources to play with. These devices are typically associated with larger batteries, rich user interfaces, and possibly even an electric supply. It is right to move the burden then from the slave to the master, from the advertiser to the scanner, and from the server to the client. This reduces the power consumption of the most resource-constrained devices, to the cost of the most resource-abundant devices.

2.5. Design For Success

So many wireless standards fall down at the first hurdle because a great radio design just doesn’t work when it starts to become popular due to congestion from many other radios. If there is one thing that Bluetooth does well, it is operating in a very congested environment. Three times a year, the Bluetooth Special Interest Group (SIG) organizes UnPlugFest testing events at which engineers from many competitive companies come together to test their devices before they are released to the market. These events highlight the fact that Bluetooth still works even when hundreds and even thousands of wireless devices come together in a single hotel ballroom. And Bluetooth low energy has learned from this.

Designing for success means that every person who gets on a crowded commuter train or bus or goes to a busy sports stadium or concert should be able to operate several low-energy devices. This means that thousands of devices could be within a few meters of a device, and device discovery and connections should function as expected. It also means that there should be no inherent limit to the number of devices a given device can talk to at the same time. If a device wants to talk to another device, then it should just be able to do that, not worry that there are only seven possible slaves that can be connected at the same time, which is the limit imposed by classic Bluetooth.

Device density is just one metric that was used during the design of the controller. Another was the security system. Any very popular radio system will become a target for people who want to try to break its security. This becomes even more important when monetary value is involved. So state-of-the-art security and encryption engines must be used.

Beyond security, if a person is going to be carrying around many devices, all of which are resource constrained and therefore advertising continuously, the issue of privacy must also be addressed. In Bluetooth low energy, privacy is dealt with as a major design goal. Every connection that is made uses a different signature that has no relation to any identifying information of these two devices. It is not possible to know who is walking down the street by just listening to the packets being transmitted during connections. Also, when advertising, it is possible to use a private address, which is a resolvable address that allows a friendly device to resolve the address if they have the identity resolving key but denies unfriendly devices the ability to resolve or track the address.

Another factor taken into account was that when the radio is used everywhere, even a single bit error can become significant. If you have a sewage outflow valve, for example, protecting your nice public park from being swamped by effluent, you really don’t want to have a single bit error that causes that sewage outflow valve to open when you really wanted to make sure it was still closed. To protect against this, all packets have a strong cyclic redundancy check (CRC) value that can protect against all 1, 2, 3, 4, 5, and all odd bit errors. Also, if you want more robustness, you can start encryption. Then a different message authentication code is appended to the data to ensure that the data was sent from the device that you think it was sent from; no attacker will be able to reply to messages to the sewage outflow valve. And for the really vigilant, at the Attribute Protocol Layer, there is the ability to prepare a write into an attribute and only perform the execute of that write after the value to be written has been returned and verified. This means that for this single bit state for the valve, a total of 14 octets of CRC and authentication codes protect this data. Bluetooth low energy is robust.

2.6. Everything Has State

One of the basic concepts behind Bluetooth low energy is that everything has state. This state is exposed by using the Attribute Protocol in an attribute server. The state could be anything: the current temperature, the state of the battery of the device, the name of the device, or the description of where the temperature is being measured.

State doesn’t just have to be readable state; it can also be written. A thermostat can have a set-point temperature by which another device can set the temperature to which this room should be heated or cooled. If you can expose state, you can also expose the state of a state machine. By using explicit state machine attributes, the state of the device can be clearly exposed. This offers the capability for clients to disconnect whenever they want, because when they reconnect, they can quickly determine the current state by just reading it.

Some state is variable and can change frequently. To enable an efficient transfer of state information from the server to the client, direct notifications of the state information from the server to the client are possible. These notifications don’t require the client to poll the server, allowing very efficient application designs. The battery state could be notified only when something interesting happens; thus, a device wouldn’t need to worry about the battery state at all until the notification arrives.

This simple-state–based model makes it possible for a very efficient client server architecture to be constructed. This also allows an object-oriented approach to state to be designed into applications, with reusable data types and service behavior. This reduces the quantity of code that a device needs to contain, which consequently reduces the power consumption of the device because memory doesn’t need to be provided for that code. And there is another significant benefit to having less code: fewer bugs. Simpler systems are cheaper and faster to develop. A simpler system also typically contains fewer errors, making it more robust. Finally, simpler systems are easier to maintain. As Robert Browning said, “Less is more.”

2.7. Client-Server Architecture

The client-server architecture has one additional basic design element that is fundamental to the design of Bluetooth low energy. When low energy was being designed, the problem of connecting devices to the Internet was considered. It could have been possible to put an Internet Protocol (IP) stack on every single resource-constrained device and just expose all the devices over the Internet. Unfortunately, even the simplest of IP stacks takes more memory and energy than is desirable on the simplest of devices. Therefore, the decision was made to not allow any IP packets to be routed directly to slave devices.

Instead, smart gateways allow the interconnection between the Internet and very efficient low-energy slaves. This interconnection is possible because of the pure client-server architecture. A server is just a repository of data, and it does not care who the client is. A client could be directly connected to the server or it could be connected via an Internet gateway from the other side of the planet.

This affords the ability for individuals to monitor and control their home when they are on vacation. And given that low energy will be used for everything from security alarms to set-top boxes and heating systems, it would be possible to check that all the windows are secure on the way to the beach, set up a recording of your favorite television program while you’re lying back in the sand, and then turn the heat back up while flying home.

The ability to connect with gateways also allows sports and fitness devices to instantly update their associated web sites with their collected data, even before the exerciser has had a chance to finish her drink of water. It would also provide the ability to monitor elderly people so that they can stay in their own homes, safe in the knowledge that people are available should they need help.

The client-server gateway model also enables full Internet security to be used from the client to the gateway and allows the gateway to perform access control, firewall, and authorization of the client before granting it access to anything beyond the gateway. These are proven technologies used today in many homes and businesses.

2.8. Modular Architecture

One basic concept that is often overlooked is future-proofing the architecture. Most wireless standards are created in a rush, trying to get the technology out as quickly as possible, without much concern about how the technology will function in 10 or 20 years’ time. This causes problems, because poor architectural decisions made under the duress of “time to market” damage the long-term viability of the platform. To solve this, the Bluetooth SIG created a special architecture working group just for the Generic Attribute Profile–based architecture to ensure a future-proof design.

The main outcome of this group has been the modular service architecture that builds on top of the generic attribute profile. This allows atomic encapsulatable bits of behavior to be wrapped up in a single service and exposed on a device in a standard way. (In this context, an atomic service is one that just does a single thing, and encapsulatable means that it can be separated from other functions and wrapped up by itself.) These services can reference other services, so a battery service can reference a temperature service if the battery has its own temperature sensor; this same temperature service can be reused for a home thermometer, a freezer temperature sensor, or a car engine coolant temperature sensor.

An interesting side effect of this architecture is that the services exposed on a device do not have to be directly related to a given profile. Profiles will require a given set of services on a given device, but that is about as much of a link as needed. This means that if another profile can be created to use a different combination of services on a device, it can combine the existing services in a different way without a problem. This is true, even if that profile was written after the services were designed and implemented in a device.

This is a highly flexible and modular architecture that can enable the building up of ecosystems over time. For example, smart meters could be deployed into homes to allow current and future price information and usage information to be exposed. Later, smart appliances can be deployed that allow themselves to be remotely turned on and off; using the gateway model, this could be controlled outside the home. Even later, a smart energy broker can be deployed that uses the information from the smart meter and the information from the smart appliances to save the homeowners money by scheduling energy use that takes into account the pricing information from the meter.

2.9. One Billion Is a Small Number

Any new technology faces a serious challenge trying to obtain market traction. For a technology to be successful, it has to be low cost. To be low cost, you need volume. To have volume, you need to be successful. Today, the single largest consumer electronics device that is sold is the cell phone. Any technology that makes it into the cell phone will be successful. Bluetooth is the classic example of this. Bluetooth low energy builds on Bluetooth’s attach rate in cell phones to create an instant market.

The technology has the opportunity to have over one billion devices in the field within the first couple of years as the cell phone manufacturers update their platforms to include Bluetooth low energy. The interesting thing about this is that it creates a huge market for accessories for phones. And it is not just phones that can have Bluetooth low energy designed in quickly; computers, televisions, in fact, any devices that have Bluetooth classic, are likely to be updated to add Bluetooth low energy because of the extremely low cost associated with incorporating the new technology to an existing Bluetooth system.

2.10. Connectionless Model

Bluetooth classic was all about cable replacement: headset cables, mouse cables, file transfer cables. This implies an architecture where the cost of setting up a link is not that important because the link will be maintained for a few minutes, hours, or even days. The odd second delay at the start of the connection is not that important. Bluetooth low energy changes all this.

The basic concept with low energy is that connections are transient. When you need to do something or check something, you quickly create a connection, do what needs to be done, and then disconnect. A device that is only notifying some state information once every five minutes would only need the radio on for less than one second a day. This means that the radio is off 99.999 percent of the time; or to four significant digits, the radio is off 100 percent of the time. Any delay in each connection setup will cause a significant increase in power consumption.

Bluetooth low energy can create a connection, send data, and gracefully disconnect in about three milliseconds. This means that many devices that have some state information, but until now couldn’t afford to add wireless technology because of the cost of energy requirements, can finally consider adding Bluetooth low energy. Even something as simple as a button can be enabled, possibly using scavenged power, and therefore never need a battery.

2.11. Paradigms

Most successful technology is built around sets of paradigms, and Bluetooth low energy is no different. Bluetooth low energy uses two main architectural paradigms: client-server architecture and service-oriented architecture.

2.11.1. Client-Server Architecture

The client-server architecture is a paradigm by which clients can send requests to servers over a network and the servers send back responses. It is the main paradigm behind the Internet, which is arguably the most successful networking technology ever released.

For example, when you type a URL address into a web browser, it first sends the address to a DNS server. This server responds with the IP address of the server that has been assigned to that name. The client then sends a hypertext transport protocol (HTTP) request to that server and, once connected, sends a request for the server to get the resource identified in the request. The server then responds with the appropriate resource, typically a text file that contains markup (HTML) information about how to display the information.

This file can also include additional URLs with which the client can fetch other resources, such as pictures or other pages. These additional links are really the reason HTML pages are thought of as being linked together into a web, hence the terms web page and web server.

There is a clear distinction between what a server does and what a client does. The server has information, typically in a structured form. This data is really why the server exists. This data can be anything, the current weather in Kona, Hawaii, the time of the next train from Seoul to the airport, or just some inane chatter between friends. The client, on the other hand, doesn’t have any data. It just sends requests to servers. Once it receives the replies from a server, it can carry out the task it was assigned to do, such as display information to the user or notify the user that somebody they know has posted something on a wall or tweeted.

The main benefit of the client-server architecture is this defined split between the client and the server. This split is necessary when the different parts of the system are on different devices. By defining one of these parts as a server and one as a client, the explicit relationship between these two parts of the system can be determined.

The main benefit of this architecture is that it can scale. A client doesn’t need to know anything except the URL to be able to access a resource. There can be many clients. Some sites on the Internet will have millions of requests made each day from millions of clients. The server doesn’t really care what or where these clients are; it just responds to each request as it comes in.

This server architecture can also be scaled. A single machine responding to millions of requests a day might become overloaded and start to fail. The solution is to place many identical servers, all having access to the same information. This is further assisted when clients are given multiple IP addresses for a single name so that the load is spread evenly among each server. This is known as load balancing.

2.11.2. Service-Oriented Architecture

A further abstraction on top of the client-server architecture is the service-oriented paradigm. This is a model that organizes the information in a server into services. These services can be discovered, interacted with, and used with known semantics. This means that the services have a defined behavior that will always produce the same result, given the same preconditions.

This paradigm is the foundation of the most highly successful Internet systems, such as SOAP, REST, COBRA, RPC, Web Services, and so on.

A way to illustrate this is to relate it to a real-world example. Suppose that you have a package that needs to be delivered to another company quickly. The first thing you will probably do is call a courier company, arrange a pickup of the package, and then pay for the service. The key concept is that you know what is going to happen. There is an implicit set of behaviors that the courier company will be following. On any day, given the same package to be delivered, the courier company will do exactly the same thing—deliver it to its destination, on time. This service has known semantics with defined behavior that produces predictable results.

An interesting part of this is that you are interacting with two different people at the courier company: the person who answered the phone and took your request and the delivery driver who collected your package. You also used, although unknowingly, a third person who dealt with the financial transaction. Each of these people provide a subservice that, when combined, results in the primary service offering of the courier company.

Some of these subservices are also generic; they could be used interchangeably by many different types of companies. The processing of financial transactions is something that is done pretty much the same way in every company. Similarly, the function of taking phone calls for picking something up at one location and dropping it off at another could also be applied to taxi companies.

For all this to work, everything must adhere to a set of rules and conventions that are outlined in the sections that follow.

2.11.2.1. Formal Contract

For a service to be considered a service, it must follow a formal description of both its exposed functionality and how it behaves. For example, the courier company driver wears the company uniform, drives the company vehicle, and greets the customers in a pleasant manner. He will also drive between locations quickly and safely, and deliver the packages intact. Any violation of these rules would break the contract that the customer has with the courier company. Most courier companies therefore also require customers to agree to this formal contract before picking up their packages.

A side effect of having a formal contract is that it becomes easy for one instance of a service to be replaced by another instance of the service. This is possible only if the two instances of the service both expose the same functionality and behavior. For example, if the financial person left the company, it should be easy to find a replacement who knows the same accounting rules.

In Bluetooth low energy, these formal contracts are captured in service specifications that are formally adopted by the Bluetooth SIG. These specifications also have test specifications that ensure that the behavior of an implementation is valid.

2.11.2.2. Loose Coupling

In object-oriented software, each individual component of the system is meant to be designed as a separate object with no side effects. Those interactions that do occur between components can then be explicitly defined and tested.

By reducing the dependancies to a minimum, each service implementation can be changed without risk that unexpected side effects are either introduced or lost. Taking this to its logical conclusion, there should be a separation between the formal contract and its implementation. This then allows the implementation to be changed at will, as long as the formal contract is not broken and is unchanged.

For example, it is possible to add more drivers to the courier company, changing the implementation from a single driver doing everything to many drivers collecting packages from a small area of a city, bringing them back to a central warehouse, and then sending them back out, possibly with a different driver. From the customer’s point of view, the service is identical, packages are collected and delivered as required, but the implementation is completely different. And this was possible without changing the financial or order-taking services.

2.11.2.3. Abstraction

Service abstraction is an import design rule because of the consequences if this rule is not followed. If there were no abstraction and a client had full knowledge of how a given service was implemented, that client might start to use that service in a way that constrains how the service can evolve.

It is common knowledge that more information is good. However, in the context of a service-oriented architecture, the less knowledge that a client has about how a service is provided, the better it is. With too much knowledge, the client might obstruct the reuse or redesign of the service because the client is implicitly linked to the specific implementation. If the service implementation changes, the client might break.

To ensure that this rule is followed, only the absolute minimum of state must be exposed by the service. Also, only the external manifestation of the service behavior should be specified.

2.11.2.4. Reusability

The concept of reusability is a design goal that was one of the promises of object-oriented methodologies for many years. However, reusability is really the ability for a service to be designed so that it could be applied to multiple different applications. Without careful thought, it is always easier to design a service that only does one job. With good design, services can be designed to be independent of the actual process that is used. This means that the service can then be reused in another application, quickly and easily.

The Bluetooth SIG has responded to this challenge by setting up a working group that has but one job, which is to look out for generic functionality and then abstract the requirements to enable significant reuse.

2.11.2.5. Statelessness

To be able to scale services for many clients, the servers cannot hold any client state data. A service could be defined that remembers everything the client has told them so that the client doesn’t have to repeat this information on subsequent requests. The problem with this approach is that this information takes up a lot of memory and relies on this shared state information being in sync on both the client and server. This therefore leads to the server being reliant on the correct functioning of the client; this is a bad assumption.

Therefore, the statelessness design goal removes all the state from the interaction between the client and the server. There will still be some state information stored in the service, but this is always the server’s state and is never the client’s state. This means that any client can then send any request at any time and the server will respond to the same request in exactly the same way, regardless of which client made the request.

2.11.2.6. Composability

All the preceding goals imply that services should be designed to be both small and very simple. But the real world is never that simple. Real-world services are complex. To resolve this apparent conflict, a service-oriented architecture encourages the aggregation of smaller services to enable higher service interfaces.

The aforementioned design goals for services all encourage that they can be combined. For example, the courier company service was shown to be composed of three separate services. As long as each of these individual services followed the stated goals, these can be combined into a courier company. Similarly, some of these services could be combined to make a taxi company or an executive car service. The implementation might be different—a delivery van, a family car, or an executive limousine—but the services are essentially the same.

2.11.2.7. Autonomy

For services to be reused and combined, they must be reliable. A service that relies on other components within the system to perform received requests will not be as reliable as a service that has complete control over everything it does.

An autonomous service can stand alone and perform its task, regardless of what is going on around it. These services can be reused in other applications with very little difficulty. A service that is not autonomous would probably have to bring many other support services; these additional services might conflict with other services.

For example, the courier company drivers function autonomously, collecting and delivering packages, as they are told to do. They will continue to function autonomously even if there is a major malfunction in the office.

2.11.2.8. Discoverability

Finally, for services to be used, they must be discoverable. This might appear obvious at first glance, but service discoverability is essential for ad hoc networking. Without service discovery, all services must be statically programmed; a complex, burdensome, and error-prone task.

Typically, these use a separate protocol from the protocol used to interact with the service. For example, to find the courier company, somebody might have used a phone book or searched on the Internet; they would not just call random telephone numbers and hope that one would be a courier company.

Bluetooth low energy takes a different approach and uses a single protocol for both the discovery of services and interacting with these services. This protocol is called the Attribute Protocol, and service discoverability is described in its profile, the Generic Attribute Profile. Both of these are described in Chapter 10, Attributes.