Geekly Articles each Day
📜 ⬆️ ⬇️

Bluetooth v4.2: what is really new and how does it work?



Hello.

On December 3, 2014, the Bluetooth SIG officially announced the bluetooth version 4.2 specification.
The press release lists 3 major innovations:

The main thesis of the press release: version 4.2 is ideal for the Internet of Things (IoT).
In this article I want to tell how these 3 points are implemented. Who are interested in welcome.
')
Everything described below applies only to BLE, let's go ...

1. Increase the speed of reception and transmission of user data.


The main disadvantage of the BLE was the low data rate. Although which side to look at, originally BLE was invented for the sake of saving energy of the source feeding the device. And in order to conserve energy, it is necessary to get in touch with interruptions and transmit some data. However, all the same, the entire Internet is filled with indignations about low speed and questions about the possibility of increasing it, as well as increasing the size of the transmitted data.

And with the advent of version 4.2, the Bluetooth SIG announced an increase in the transmission speed by 2.5 times and the size of the transmitted packet by 10 times. How did they do it?

I’m saying that these 2 figures are connected with each other, namely: the speed has increased because the size of the transmitted packet has increased.

Let's look at the PDU (protocol data unit) of the data channel:

Each PDU contains a 16-bit header. So, this title in version 4.2 is different from the title in version 4.1.

Here is the heading of version 4.1:

But the header of version 4.2:

Note: RFU (Reserved for Future Use) is a field denoted by this abbreviation reserved for future use and filled with zeros.

As we can see, the last 8 bits of the header are different. The “Length” field is the sum of the payload lengths and the MIC (Message Integrity Check) field located in the PDU (if the latter is included).
If in version 4.1 the “Length” field has a size of 5 bits, in version 4.2 this field is 8 bits in size.

From here it is easy to calculate that the “Length” field in version 4.1 can contain values ​​in the range from 0 to 31, and in version 4.2 in the range from 0 to 255. If we subtract the length of the MIC field (4 octets) from the maximum values, we get The payload may be 27 and 251 octets for version 4.1 and 4.2, respectively. In fact, the maximum amount of data is even smaller, since in the payload are also overhead L2CAP (4 octets) and ATT (3 octets), but we will not consider this.

Thus, the size of the transmitted user data has increased approximately 10 times. As for the speed, which, for some reason, did not increase 10 times, but only 2.5 times, then we cannot talk about proportional increase, because everything also rests on the guarantee of data delivery, because the delivery of 200 bytes is a little more difficult to guarantee than 20.

2. Ability to connect to the Internet.


Perhaps the most interesting innovation, because of which the Bluetooth SIG announced that version 4.2 makes the Internet of things (IoT) better precisely because of this feature.

Even in version 4.1, the LE Credit Based Flow Control Mode appeared in L2CAP. This mode allows you to control the flow of data using the so-called. credit based scheme. The peculiarity of the scheme is that it does not use signaling packets to designate the number of transmitted data, but requests a credit from another device for a certain amount of data for transmission, thereby speeding up the transfer process. At the same time, the receiving party every time it receives a frame, reduces the frame counter, and when the last frame is reached, it can break the connection.

There are 3 new codes in the list of L2CAP commands:
- LE Credit Based Connection request — request for a connection using a credit scheme;
- LE Credit Based Connection response - response to the connection according to the credit scheme;
- LE Flow Control Credit - a message about the possibility to receive additional LE-frames.

In the package "LE Credit Based Connection request"

there is a “Initial Credits” field of 2 octets in length indicating the number of LE frames that the device can send at the L2CAP level.

In the response package "LE Credit Based Connection response"

the same field indicates the number of LE frames that another device can send, and the result of the connection request is indicated in the “Result” field. A value of 0x0000 indicates success, the other values ​​indicate an error. In particular, a value of 0x0004 indicates a connection failure due to lack of resources.

Thus, in version 4.1, it became possible to transfer a large amount of data at the L2CAP level.
And so, almost simultaneously with the release of version 4.2, it is published:

The main profile requirement for the L2CAP layer is “LE Credit Based Connection”, which appeared in version 4.1, which, in turn, allows sending packets with MTU> = 1280 octets (I hope the hint of the figure is clear).

The profile defines the following roles:
- the role of the router (Router) - used for devices that can route IPv6 packets;
- node role (Node) - used for devices that can only receive or send IPv6 packets; have a service discovery function and have an IPSS service that allows routers to discover this device;

Devices with the role of a router that need to connect to another router may have the role of a node.

Oddly enough, the transmission of IPv6 packets is not part of the profile specification, and is specified in the IETF RFC "Transmission of IPv6 packets over Bluetooth Low Energy" . This document defines another interesting point, namely that the transfer of IPv6 packets uses the 6LoWPAN standard - this is the standard for IPv6 interworking over low-power IEE 802.15.4 wireless personal networks.

Look at the picture:

The profile specifies that IPSS, GATT and ATT are used only for service discovery, and GAP is used only for device discovery and connection establishment.

But highlighted in red, just says that the transfer of packets is not included in the profile specification. This allows the programmer to write his own implementation of packet transfer.

3. Improving privacy and security.


One of the responsibilities of a security manager (Sequrity manager) (SM) is to pair two devices. The pairing process creates keys that are then used to encrypt the connection. The pairing process consists of 3 phases:

In version 4.2, the 2nd phase was divided into 2 parts:

And the 1st phase was added by another way of pairing: “Numeric Comparison” which only works with the second version of the 2nd phase: “LE Secure Connections”.

In this regard, in addition to the 3 existing functions, in the cryptographic toolbox of the security manager, 5 more appeared and these 5 are used only to service the new LE LE Connections pairing process. These functions generate:
All functions use AES-CMAC encryption algorithm with a 128-bit key.

So, if during the mating in the 2nd phase, 2 keys were generated using the LE legacy pairing method:

then, using the LE Secure Connections method, 1 key is generated:

The result of this innovation we received:

Strange as it may seem, but due to improved security, we have improved energy efficiency.

4. Is there an opportunity to touch?


Yes there is.
NORDIC Semiconductor has released the "nRF51 IoT SDK" which includes a stack, libraries, examples, and an API for nRF51 series devices. These include:

Under the link you can download:

5. Conclusion.


Personally, the most anticipated for me, of course, was an increase in the transmission speed and size of the packet of transmitted data.
In the first quarter of 2015, the first chips that support version 4.2 should appear, then there will be updates of mobile platforms and all this will allow adding new features to the world of the Internet of Things.

Thanks for attention.

Source: https://habr.com/ru/post/248499/

More articles:


All Articles