BLE 4.2 4.1 4.0区别

The Bluetooth Special Interest Group (SIG) announced the adoption of updates to the Bluetooth 4.0 standard that shift it to version 4.1. A point iteration sounds uninteresting, but it is the first significant update since Bluetooth 4.0 was introduced back in 2010 and comes with a great weight of expectation.

The job of Bluetooth 4.1 is to drive the ‘Internet of Things’ (Io, namely the thousands of smart, web connected devices – from fridges to toothbrushes – that are expected to enter our lives over the next decade. This includes smartwatches, a continuing topic of interest among manufacturers and tech enthusiasts.

Bluetooth 4.1 vs Bluetooth 4.0: What is new?

There are three major improvements at the heart of the Bluetooth 4.1 specification:

1. Coexistence

Bluetooth and 4G (LTE) famously don’t get on: their signals interfere degrading one another’s performance and draining battery life. Bluetooth 4.1 eliminates this by coordinating its radio with 4G automatically so there is no overlap and both can perform at their maximum potential. Given most phones will come with 4G next year this is a vital improvement.

2. Smart connectivity

Rather than carry a fixed timeout period, Bluetooth 4.1 will allow manufacturers to specify the reconnection timeout intervals for their devices. This means devices can better manage their power and that of the device they are paired to by automatically powering up and down based on a bespoke power plan.

In short: devices are no longer all treated the same and the randomness of Bluetooth connections / disconnections and the power drain this causes should reduce dramatically.

3. Improved Data Transfer

Bluetooth 4.1 devices can act as both hub and end point simultaneously. This is hugely significant because it allows the host device to be cut out of the equation and for peripherals to communicate independently.

For example, whereas previously a smartwatch would need to talk to your phone to get data from a heart monitor, now the smartwatch and heart monitor can talk directly saving your phone’s battery and then upload their compiled results directly to your phone. This is crucial to the Internet of Things concept: peripherals become independent and can build their own networks before bringing the collation of all their data to you.

Bluetooth 4.1 vs Bluetooth 4.2

Bluetooth 4.2 is an important update to the Bluetooth Core Specification with many new features and benefits designed specifically for Bluetooth Smart technology, and advantages when comparing Bluetooth 4.2 vs. Bluetooth 4.1 (also known as Bluetooth Low Energy or Bluetooth Smart).

Bluetooth 4.2 introduces several new features that improve speed and privacy over Bluetooth 4.1 but the main advantage is allowing chips to use Bluetooth over Internet Protocol version 6 (IPv6) for direct Internet access. With this, the possibilities expand beyond thoseof current designs and markets to include any type of Bluetooth device requiring speed and security in the IoT.

Why use BLE 4.2 instead of BLE 4.1? The Bluetooth SIG recommends implementing Bluetooth 4.2 in all new designs and requires the same qualification process as all other Bluetooth designs. Devices using Bluetooth Smart will be backward compatible with Bluetooth 4.0 or 4.1 devices that also implement the low energy features. Devices implementing the (BR/EDR) Core Configuration will be backward compatible to all adopted Bluetooth Core versions beginning with 1.1 that also implement Bluetooth BR/EDR.

IoT Capabilities:

• Low-power IP (IPv6/6LoWPAN)
• Bluetooth Smart Internet Gateways (GATT)

With BLE 4.2 Bluetooth Smart sensors can transmit data over the internet.

Security:

• LE Privacy 1.2
• LE Secure Connections

With new, more power efficient and highly secure features, BLE 4.2 provides additional benefits allowing only trusted owners to track device location and confidently pair devices.

Speed:

• 250% Faster
• 10x More Capacity

Compared to previous versions, BLE 4.2 enables 250% faster and more reliable over-the-air data transmission and 10x more packet capacity.

LAYERS

Channel Manager

The channel manager is responsible for creating, managing, and destroying L2CAP channels for the transport of service protocols and application data streams. The channel manager uses the L2CAP protocol to interact with a channel manager on a remote (peer) device to create these L2CAP channels and connect their endpoints to the appropriate entities. The channel manager interacts with its local link manager to create new logical links (if necessary) and to configure these links to provide the required QoS for the type of transported data.

L2CAP Resource Manager

The L2CAP resource manager block is responsible for managing the ordering of submission of PDU fragments to the baseband and some relative scheduling between channels to ensure L2CAP channels with QoS commitments are not denied access to the physical channel due to Bluetooth controller resource exhaustion. This is required because the architectural model does not assume that the Bluetooth controller has limitless buffering, or that the HCI is a pipe of infinite bandwidth.

L2CAP resource managers may also carry out traffic conformance policing to ensure that applications are submitting L2CAP SDUs within the bounds of their negotiated QoS settings. The general Bluetooth data transport model assumes well-behaved applications, and does not define how an implementation is expected to deal with this problem.

Device Manager

The device manager is the functional block in the baseband that controls the general behavior of the Bluetooth enabled device. It is responsible for all operation of the Bluetooth system not directly related to data transport, such as inquiring for the presence of other nearby Bluetooth enabled devices, connecting to other Bluetooth enabled devices or making the local Bluetooth enabled device discoverable or connectable by other devices.

The device manager requests access to the transport medium from the baseband resource controller in order to carry out its functions.

The device manager also controls local device behavior implied by a number of the HCI commands, such as managing the device local name, any stored link keys, and other functionality.

Link Manager

The link manager is responsible for the creation, modification, and release of logical links (and, if required, their associated logical transports), as well as the update of parameters related to physical links between devices. The link manager achieves this by communicating with the link manager in remote Bluetooth devices using the link management protocol (LMP).

The LMP allows the creation of new logical links and logical transports between devices when required, as well as the general control of link and transport attributes such as the enabling of encryption on the logical transport, the adapting of transmit power on the physical link or the adjustment of QoS settings for a logical link.

Baseband Resource Manager

The baseband resource manager is responsible for all access to the radio medium. It has two main functions. At its heart is a scheduler that grants time on the physical channels to all of the entities that have negotiated an access contract. The other main function is to negotiate access contracts with these entities. An access contract is effectively a commitment to deliver a certain QoS that is required in order to provide a user application with an expected performance.

The access contract and scheduling function must take account of any behavior that requires use of the Bluetooth radio. This includes, for example, the normal exchange of data between connected devices over logical links and logical transports, as well as the use of the radio medium to carry out inquiries, make connections, be discoverable or connectable, or to take readings from unused carriers during the use of AFH mode.

In some cases, the scheduling of a logical link results in changing to a different physical channel from the one that was previously used. This may be, for example, due to involvement in scatternet, a periodic inquiry function, or page scanning. When the physical channels are not time slot aligned, then the resource manager also accounts for the realignment time between slots on the original physical channel and slots on the new physical channel. In some cases, the slots naturally align due to the same device clock used as a reference for both physical channels.

Link Controller

The link controller is responsible for the encoding and decoding of Bluetooth packets from the data payload and parameters related to the physical channel, logical transport and logical link.

The link controller carries out the link control protocol signaling (in close conjunction with the scheduling function of the resource manager), which is used to communicate flow control and acknowledgement and retransmission request signals. The interpretation of these signals is a characteristic of the logical transport associated with the baseband packet. Interpretation and control of the link control signaling is normally associated with the resource manager's scheduler.

RF

The RF block is responsible for transmitting and receiving packets of information on the physical channel. A control path between the baseband and the RF block allows the baseband block to control the timing and frequency carrier of the RF block. The RF block transforms a stream of data to and from the physical channel and the baseband into required formats.