January 21, 2015 at 23:46

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



    Hello.

    On December 3, 2014, Bluetooth SIG officially announced the bluetooth specification version 4.2.
    The press release indicates 3 major innovations:
    • increase in the speed of reception and transmission of data;
    • the ability to connect to the Internet;
    • improved privacy and security.

    The main thesis of the press release: version 4.2 - 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 drawback of BLE was the low data rate. Although which side to look at, BLE was originally invented to save the energy of the source that feeds the device. And in order to save energy, you need to intermittently communicate and transmit a little data. However, all the same, the entire Internet is filled with indignation about the 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, Bluetooth SIG announced an increase in transmission speed by 2.5 times and the size of the transmitted packet by 10 times. How did they achieve this?

    I’ll say to the battle that these 2 digits are connected with each other, namely: the speed increased because the size of the transmitted packet 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 title of version 4.1:

    Here is the title of version 4.2:

    Note: RFU (Reserved for Future Use) - the field indicated by this abbreviation is reserved for future use and is 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 found in the PDU (if the latter is enabled).
    If in version 4.1 the “Length” field has a size of 5 bits, then 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 MIC field length (4 octets) from the maximum values, we get that The payload can be 27 and 251 octets for version 4.1 and 4.2, respectively. In fact, the maximum amount of data is even less, because the payload also contains the L2CAP service data (4 octets) and ATT (3 octets), but we will not consider this.

    Thus, the size of the transmitted user data increased by approximately 10 times. As for the speed, which, for some reason, increased not 10 times, but only 2.5 times, then we can’t talk about a proportional increase, because everything also depends on the guaranteed delivery of data, because guaranteeing delivery of 200 bytes is a little more difficult than 20.

    2. The ability to connect to the Internet.


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

    Back 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. loan based scheme. The peculiarity of the scheme is that it does not use signal packets to indicate the number of transmitted data, but requests a loan from another device for a certain amount of data for transmission, thereby speeding up the transmission process. In this case, the receiving side each time a frame is received, decreases the frame counter, and when the last frame is reached, it can break the connection.

    3 new codes appeared in the list of L2CAP commands:
    - LE Credit Based Connection request - request for a connection according to a loan scheme;
    - LE Credit Based Connection response - response to the connection according to the loan scheme;
    - LE Flow Control Credit - a message about the possibility of receiving additional LE-frames.

    The LE Credit Based Connection Request request package has a

    2 octet “Initial Credits” field 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, as well as the result of the connection request is indicated in the "Result" field. A value of 0x0000 indicates success, other values ​​indicate an error. In particular, a value of 0x0004 indicates a connection failure due to lack of resources.

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

    The main profile requirement for the L2CAP level is “LE Credit Based Connection” introduced in version 4.1, which, in turn, allows you to transfer 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 a router role that need to connect to another router may have a host role.

    Oddly enough, IPv6 packet transmission is not part of the profile specification and is specified in the IETF RFC Transmission of IPv6 packets over Bluetooth Low Energy . Another interesting point is identified in this document, namely that when transmitting IPv6 packets, the 6LoWPAN standard is used - this is the standard for IPv6 communication over low-power wireless personal networks of IEE 802.15.4 standard.

    Take a look at the figure:

    The profile determines 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 specification of the profile. This allows the programmer to write his implementation of packet transfer.

    3. Improving privacy and security.


    One of the responsibilities of the Security Manager (Sequrity manager) (SM) is to pair the two devices. During pairing, keys are created that are then used to encrypt communications. The pairing process consists of 3 phases:
    • exchange of information on pairing methods;
    • generation of short-term keys (Short Term Key (STK));
    • key exchange.

    In version 4.2, the 2nd phase was divided into 2 parts:
    • Short Term Key (STK) generation called “LE legacy pairing”
    • Long Term Key (LTK) generation called “LE Secure Connections”

    And the 1st phase was added by another pairing method: “Numeric Comparison” which works only 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 Secure Connections pairing process. These functions generate:
    • LTK and MacKey;
    • confirming variables;
    • authentication verification variables;
    • 6-digit numbers used to display on connected devices.
    All functions use the AES-CMAC encryption algorithm with a 128-bit key.

    So, if during pairing in the 2nd phase by the “LE legacy pairing” method 2 keys were generated:
    • Temporary Key (TK): 128-bit temporary key used to generate STK;
    • Short Term Key (STK): 128-bit temporary key used to encrypt the connection

    then 1 key is generated by the LE Secure Connections method:
    • Long Term Key (LTK): A 128-bit key used to encrypt subsequent connections.

    The result of this innovation we have received:
    • tracking prevention because Now, due to "Numeric Comparison" there is an opportunity to control the ability to connect to your device.
    • improving energy efficiency, as now no additional energy is required for repeated key generations at each connection.
    • industry standard encryption for sensitive data.

    Oddly enough this sounds, but due to improved security, we got an improvement in energy efficiency.

    4. Is there already an opportunity to feel?


    Yes there is.
    NORDIC Semiconductor has released the “nRF51 IoT SDK” which includes the stack, libraries, examples, and APIs for the nRF51 series devices. These include:
    • nRF51822 and nRF51422 chips;
    • nRF51 DK;
    • nRF51 Dongle;
    • nRF51822 EK.

    According to the link , you can download:
    • short description;
    • archive with the described SDK;
    • kernel archive for Raspberry Pi, including its source.

    5. Conclusion.


    The most expected for me personally, of course, was an increase in the transmission speed and the size of the packet of transmitted data.
    In the first quarter of 2015, the first chips supporting version 4.2 should appear, then there will be updates to mobile platforms and all this will add new features to the world of Internet of things.

    Thanks for attention.
    Tags:

    Also popular now: