Exploring Bluetooth 5 - Going the Distance

Posted on February 13, 2017 by Martin Woolley

The Age of IoT

According to a paper by Goldman Sachs, in the 1990s there were approximately 1 billion devices connected to the internet. In the 2000s, the “age of the smartphone”, this figure rose to 2 billion. ABI Research now forecast that by 2021 there will be 48 billion devices connected to the internet, in what we’re likely to term “the age of IoT”. Of those 48 billion devices, 30% are forecast to be Bluetooth devices.

This is no coincidence. Bluetooth low energy has been actively developed to make it a key enabler of the Internet of Things (IoT). Bluetooth 5 brings some major advances to the technology and makes it ideal for an even broader range of IoT scenarios than ever.

Range and Bluetooth 4

Bluetooth low energy has a much longer range than is popularly believed to be the case, even at version 4. Informal testing by the author, using a basic Android smartphone and a Bluetooth low energy MCU demonstrated the successful receipt of Bluetooth notifications by the smartphone at a distance of over 350 metres from the MCU. The test was carried out in an environment which was sub-optimal with respect to radio communication, containing as it did, numerous people and trees. And there are commercial Bluetooth modules on the market whose data sheets state that a range of 500 metres is possible.

testing of Bluetooth 4 and range

More is More

Given the fact that Bluetooth 4 has a remarkably healthy range for a low power wireless communications technology, why increase it still further?

There are many use cases where greater range is necessary or simply advantageous. The Smart Home sector is one example and it has, to a degree, informed some of the key goals behind Bluetooth 5 and its increased range.

Imagine a large home, with sensors of various types in every room, in the wall spaces, under the floors, in the attic and on every door and window. Imagine systems such as lighting, heating and air conditioning, all controlled by Bluetooth. Go further and think about outdoor lights and yet more sensors in the garden, on perimeter fences and gates. This is a fairly accurate description of the truly smart Smart Home, able to monitor its own occupancy, security status, energy efficiency and more, and able to support automated and manual control over key systems and devices.

The Smart Home places significant demands on wireless technology

The Smart Home places significant demands on wireless technology. Whole home coverage is a mandatory requirement and one way to achieve this is to ensure the peer to peer range between directly communicating devices is sufficient, even after signals have been attenuated as a consequence of passing through the usual physical barriers in the home such as interior and exterior walls.

A Tale of Three PHYs

The PHYsical Layer

Bluetooth is a full protocol stack. The bottom layer of the stack is called the Physical Layer and is normally referred to as “PHY”. 

The Bluetooth low energy protocol stack

Bluetooth 5 adds two new PHY variants to the PHY specification used in Bluetooth 4. Each PHY variant has its own particular characteristics and was designed with specific aims in mind. The three PHYs have been named to allow them to be referenced in specifications. Their names are LE 1M, LE 2M and LE Coded.

LE 1M

LE 1M is the PHY used in Bluetooth 4. It uses Gaussian Frequency Shift Keying and has a symbol rate of 1 mega symbol per second (Ms/s). Higher up the stack, this correlates to a bit rate of 1 Mb/s since one symbol corresponds to one data bit. LE 1M continues to be available for use in Bluetooth 5 and in fact its support is mandatory.

LE 2M - DOUBLE THE SPEED

The new LE 2M PHY allows the physical layer to operate at 2 Ms/s and thus enables higher data rates than LE 1M and Bluetooth 4. Its support in a stack implementation is optional. We’ll be publishing another article all about Bluetooth 5’s higher speed PHY in this blog later on.

LE Coded - 4 X RANGE

The LE Coded PHY allows range to be quadrupled (approximately), compared to Bluetooth 4 and this has been accomplished without increasing the transmission power required. This latter point is of course important.

To understand how this has been accomplished requires the question of what we mean by “range” in wireless communications systems to be examined.

Bluetooth is a radio technology and radio is a form of electromagnetic radiation. In the context of telecommunications, the question of maximum range is better expressed as “what is the maximum range at which data can be correctly extracted from the received signal” rather than “how far can this electromagnetic energy travel and still be detected”.

The distinction relates to how we use radio to encode and transmit data and how background noise can impact the decoding of that data by a radio receiver. Symbols, created by modulating a carrier signal to represent binary zeroes or ones, get transmitted. The receiver must receive the signal and turn it back into the same symbols and by extension, the same binary values higher up the stack. A transmitted zero, decoded by the receiver as a one or vice versa, represents an error.

The receiver has its work complicated by the fact that there is background radiation, or “noise” in the environment. The closer the level of the background noise to that of the received signal, the harder it becomes to decode the received signal and at some point, errors in the decoding process start to be experienced.

Formally, we term the ratio of the signal strength to that of the background noise, the Signal to Noise Ratio (SNR). The strength of the received signal diminishes as the receiver moves further away from the transmitter and consequently, with a more or less constant background noise level, the SNR reduces. As such, the probability of decoding errors occurring increases.

We can quantify the level of errors experienced and we call this the Bit Error Rate (BER). BER is essentially the probability that a transmitted bit will be incorrectly decoded by the receiver. We can then state the limit to the BER which we will tolerate at a given receiver input level. Bluetooth defines a BER of 0.1% as the limit which a receiver must achieve. The specified BER limit and input receiver level is often referred to as the receiver sensitivity.

So, increasing the range of Bluetooth without increasing the transmitter power was really a problem concerned with achieving the same maximum permitted BER at a greater distance from the transmitter and hence at a lower SNR. To put it another way, it’s all about increasing the receiver’s sensitivity. 

Relationship between SNR and BER

Dealing with Errors

In communication systems, errors are dealt with via two broad strategies. The first is Error Detection and the second is Error Correction.

Error Detection

There are various schemes which allow a receiver to detect errors. Parity bits were first used many decades ago in both paper and magnetic tape systems. Wired, serial communications systems still rely on parity bits to allow the receiver to detect that one or more bits has been incorrectly decoded.

There are also several types of checksum which can be used. Bluetooth uses a type of checksum known as a Cyclic Redundancy Check (CRC). All packets have a 24-bit CRC value calculated for them by the transmitter and appended to the packet. The receiver recalculates the CRC and compares the calculated value with the value appended to the packet. If they are not the same, an error has occurred.

CRC on the end of a Bluetooth low energy v4 packet

In the event that errors are detected, systems may respond in one or two different ways. They could regard the error as fatal and abandon the communication or they could request or hint that the transmitter should send the data again, in the hope that a subsequent attempt will be successful. Bluetooth, both version 4 and version 5, causes the transmitter to retransmit data when a CRC check has failed, simply by not acknowledging the packet at the link layer. Failure to receive an acknowledgement, causes the transmitter to send the data again.

Error Correction

It is possible to not only detect errors at the receiver but also, up to certain limits, to correct them so that the receiver does not need to have the data retransmitted to it.

Bluetooth low energy at version 4 does not perform error correction, only error detection. Bluetooth 5 introduces an error correction capability.

Correcting errors using advanced error correction techniques has the major advantage that data can be correctly decoded at a lower SNR and hence, at a greater distance from the transmitter.

Imagine the maximum BER is experienced at a certain range without having applied any form of error correction. If we now “magically” correct some or all of those errors, then the BER will have been reduced and hence our effective range increased. There will still come a point, of course, where even with error correction being applied, the BER hits the maximum permissible and at this point, we’re at the new, longer effective range.

This is the basis upon which Bluetooth 5’s increased range has been built and the magic I referred to is in fact mathematics, not magic at all. Sorry Harry Potter fans!

FEC

The LE Coded PHY uses Forward Error Correction (FEC), a particular approach to error correction. It works by adding additional, redundant bits to the transmitted packets. The sole purpose of those bits is to support the application of the FEC algorithm so that error correction can be performed.

The new error correction capability in the LE Coded PHY adds two stages to the bit stream processing performed by the Link Layer in Bluetooth low energy and this is depicted below.

FEC Encoding uses a convolutional encoder which generates 2 bits for every input data bit using the following generator polynomials:

LE Coded may be used with a choice of 2 different coding schemes, termed S=2 and S=8. The Pattern Mapper converts each bit from the convolutional FEC encoder into P symbols, where the value of P depends on the coding scheme in use. If S=2 then in fact there is no change (i.e. P=1) but if S=8 then each bit from the FEC encoder produces 4 output bits (i.e. P=4) from the Pattern Mapper.  Specifics are as shown below.

The choice of coding scheme, S=2 or S=8 with the LE Coded PHY has two consequences. With S=2, range will be approximately doubled whilst with S=8 it will be approximately quadrupled. But as can be seen, due to the requirement for redundant data to support the FEC algorithm at the receiver, it also impacts the number of symbols which must be transmitted and this reduces the overall data rate. Specifically, one bit which passed through both the FEC Encoder and the Pattern Mapper will become 2 bits when S=2 or 8 bits when S=8. I’ll explain the consequences this has below.

The LE Coded Packet Structure

The LE Coded PHY uses a modified packet structure which is depicted below.

Compared with Bluetooth 4 and LE 1M, the differences are as follows:

extended preamble: the preamble field is used by the receiver to set its gain control, to determine what frequencies are being used for the representation of 0 and 1 and to perform symbol timing estimation. Bluetooth 4 packets and LE 1M packets in Bluetooth 5 use an 8-bit preamble of alternating 1s and 0s. LE 2M uses a 16-bit preamble, which takes the same amount of time to arrive due to its increased symbol rate. LE Coded on the other hand, uses an 80-bit preamble consisting of 10 repetitions of the 8-bit pattern '00111100’. Critically, the preamble field is not subject to FEC coding. The preamble can also be used to determine which PHY the packet corresponds to.

FEC block 1:  The remainder of the packet is divided into FEC Block 1 and FEC Block 2. FEC Block 1 is coded with S=8 for maximum redundancy and includes the coding indicator (CI) which was used to code FEC Block 2 (i.e. S=2 or S=8). Each block ends with a TERM value which is a bit pattern of 000. During bit stream processing, the TERM value has the effect of resetting the FEC encoder.

FEC Block 2: The second FEC block contains the remainder of the packet, including the PDU itself and the CRC. It is coded with either S=2 or S=8 as indicated by the CI in FEC Block 1.

LE Coded Symbol Rate

The LE Coded PHY uses a symbol rate of 1 Ms/s i.e. the same as is used by LE 1M.

Comparing the three PHYs

The following table presents key metrics relating to the three PHYs in Bluetooth 5.

Changing the current PHY

The focus of this article has been on the new “long range” capability of Bluetooth 5, which makes use of the new LE Coded PHY. It’s worth adding further context at this point though. The new Host Controller Interface (HCI) “LE Set PHY” command allows hosts to select the PHY they wish to use for each of transmission (TX) and receiving (RX), independently of each other. It is envisaged that applications, for example, may wish to switch into “2Ms/s mode” for those use cases where the highest data rates are required or switch to “long range mode” when required (great for controlling that drone).

It’s also possible to set a default PHY using the HCI “LE Set Default PHY” command and to query the capabilities of remote peer devices using the HCI “LE Read Remote Features” command. The latter returns a variety of information and includes details of the PHYs that the remote device supports.

Conclusions

Bluetooth 5 represents a substantial step change in Bluetooth technology.

Whole home and building coverage is provided for with the new, long range LE Coded PHY. New industrial applications will become possible and some smart city applications too.

Bluetooth 5 will have a substantial impact in many sectors and further position it as the low power wireless technology of choice for the Internet of Things. Watch out for further articles on Bluetooth 5 in the blog!

And on that note, let’s enjoy a suitably named piece of music!

 

Part 1 of Exploring Bluetooth 5. Read Part 2

martin woolley

Martin Woolley

Martin is on the Bluetooth Developer Programs and Evangelism team. He specializes in mobile applications and technology, with over 30 years of experience in software development.

View all posts by Martin Woolley