Generation “W” for wireless
In the modern world, wireless connectivity is considered a given in any more-or-less user-friendly device. In particular, local wireless connectivity has developed and successfully penetrated into many consumer products. The biggest leap to date is Wi-Fi: it is a standard feature in laptops, play stations, smart phones--you name it. Wi-Fi provides substantial bandwidth for data transfer, however it’s bulky based on the size of the protocol stack and it is definitely not lean in power consumption. Recent efforts to reduce Wi-Fi power requirements yielded Low Energy Wi-Fi, which is better suited to embedded M2M designs [1].
However, battery powered applications often do not require many data transfers; rather the opposite, wireless connectivity in such applications is used to send just a few bytes at very low duty cycles. IEEE 802.15.4 is a commonly used standard to create these types of networks. Yet, it only defines PHY/MAC layers, while actual network layers are determined independently. The ZigBee Alliance maintains the ZigBee standard, which is the best-known network layer running on top of 802.15.4. There are a number of other network protocols such as RF4CE, WirelessHART, and 6LoWPAN, optimized for different applications but that use common low layers defined by the 802.15.4 specification. In addition, a number of proprietary wireless protocols are successfully competing in the same space, such as Z-Wave in applications for home automation and ANT protocol in sports-related products.
The market for wireless solutions is still very segmented, not due to standardization difficulties, but because there are no “one-size-fits-all: solution.
Finding a place in the crowd
Bluetooth was considered to be in the Wi-Fi camp due to such factors as standardized data transfer with fairly high-power consumption. In its original release, Bluetooth supported 1Mbit/sec data transfer (Bluetooth 1.2). Since then, this number was increased to 3Mbit/sec with an Enhanced Data Rate version (Bluetooth 2.0 + EDR), and even further with a High-Speed version, Bluetooth 3.0 + HS. Now Bluetooth 4.0 moves to the other end of the spectrum targeting lower power, small size of data transfer with low duty cycle types of applications.
You may find yourself questioning if BLE even has a place in this game since applicable markets already have established technologies in both camps, proprietary and standard wireless protocols.
A place for BLE does exist, but it may not be easy to identify. BLE is intended for light duty cycle devices that support small data throughput and operate a long time on a coin-sized battery. Such wireless connectivity comes with a minimal price (inexpensive silicon, light MCU processing requirements, reduced memory footprint), and it can be used in applications related to the Body Area Network (BAN) which represents a connectivity bubble that moves along with the individual. After putting all requirements together it is easy to see that none of existing wireless solutions is a good fit in this case.
Let's first eliminate candidates that require a rechargeable battery or are capable of supporting streaming data--no Wi-Fi. The primary candidate for this job is an 802.15.4 based network and it has such multiple variations as ZigBee, 6LoWPAN, etc. In general, however, the average power consumption for a ZigBee node is in the range of 30ma, which is above the capacity of a coin cell battery.
Given that a ZigBee network with a 30ma power consumption budget allows nodes to be placed within a range of 100 feet, BLE is designed to work within a 30-foot range. BLE use cases circle around the user and their immediate surroundings. Since all devices are within a reachable distance, no retransmission using an intermediate node is required. It not only provides a cut in power consumption but also reduces network organization to a simple star type of connectivity.
It is fair to say that BLE has a respectable contestant from the camp of proprietary wireless technologies, the ANT protocol. Used with a Nordic ultra low power SoC, it operates within a required power budget and it has a compelling use case: ANT is used in Garmin devices that communicate with pedometers and other sport related products [2].
But, here is a rocket booster for BLE--under the Bluetooth umbrella, BLE is not only standardized, but will also inhabit over 2 billion cell phones, which will have regular Bluetooth and it smaller brother, Bluetooth LE.
Again, although it would rather artificially limit the BLE area of application, let╒s state that BLE is optimized to enable wireless communication between a smart phone and low data rate, coin battery operated, potentially disposable device located in a close vicinity. On the top of that, let╒s assume that BLE functionality comes virtually free and is already built into the cell phone as an addition to regular Bluetooth. Within this paradigm, BLE has an unbeatable stronghold against other contenders.
BLE Nuts and Bolts
BLE's over the air data rate is 1Mbit/s using GFSK modulation [3]. This is a less complex radio than the Direct Spread Spectrum (DSS) unitized in 802.15.4, but most importantly it allows the reuse of the majority of existing elements of Bluetooth radios. It operates in the 2.4GHz ISM band using a 40-channel partition space out 2MHz apart. Although the specification defines a range of output RF power the same as for regular Bluetooth, all the way up to +10dBm, it is assumed that for most of BLE applications, such as BAN, 0dBm is a more suitable level for RF output due to power constrains. To mitigate interference in such a crowded band, BLE uses frequency hopping, but in contrast to regular Bluetooth, BLE stays longer on the same channel and makes timing requirements much more relaxed compared to regular Bluetooth. Three RF channels are dedicated for advertising functions that allow the discovery of devices available in the vicinity. Upon a connection request, the same channels are used for initial connection parameter exchanges. Once a device is discovered and connection is initiated, regular data channels are used for communication (Figure 1).
Figure 1. Bluetooth LE channel arrangements. The channel plan consists of 37 data communication channels and 3 advertising channels used for device discovery. Advertising channels are allocated in different parts of the spectrum to provide immunity against interference from 802.11/Wi-Fi
A BLE device may operate in different modes depending on required functionality. The main modes of operation are called the advertising mode, scanning mode, master device, and slave device. In advertising mode, the BLE device periodically transmits advertising information and may respond with more information upon request from other devices. The scanner device, on the other hand, listens advertising information transmitted by other devices and may request additional information if active scan mode is enabled. A scanner-only device works in passive mode whereby it only listens for advertising packets. In that case, only receiver functionality is required in the RF part of the design. Similarly, an advertising-only device may just have a transmitter part of the design. It definitely enables additional use cases with cost-sensitive applications. The fact that a stack may be partitioned in sections, which could be excluded if not used in a particular application, is a great opportunity to optimize the stack's size and use the MCU with a smaller FLASH/RAM memory footprint.
In order to establish a connection, one device has to be in advertising mode (and allow for a connection) and the other device in Initiator mode. It is similar to the scanner mode but with the intention to establish a connection. The initiator scans for a desirable device-advertising packet and consequently sends a connection request. Once a connection is established, the initiator assumes the role of master device and the advertiser becomes a Slave device. Slave devices may have only one connection at a time, while master devices may have multiple connections with different slave devices simultaneously. This asymmetrical approach allows slave devices to be very small in the sense of resources and hardware cost. Such a combination perfectly fits BLE's application paradigm. The master device in this case is most likely a cell phone that has ultimately more computation power compared to a sensor and may support a number of connections simultaneously with slave devices.
Basic BLE over the air packets include a 1 byte preamble, 4 byte access codes correlated with the RF channel number used, a PDU that can be between 2 to 39 bytes and 3 bytes of CRC. Hence the shortest packet would have 80 bits transmitted within 80usec., and the longest packet of 376 bits will be transmitted within less than 0.3 millisecond. This number is important considering that BLE single mode devices have a very strict power budget (Figure 2).
Figure 2: Bluetooth LE over-the-air frame breakdown. Different PDU types are used for advertising and data channels: the advertising channel carries the device’s discovery and connection establishment information; after a connection is established, a data channel PDU provides link control data and payload for higher level protocols.
The PDU for the advertising channel consists of the 16-bit PDU header, and depending on the type of advertising, the device address and up to 31 bytes of information. Also, the active scanner may request up to 31 bytes of additional information from the advertiser if the advertising mode allows such an operation. It means that a sizable portion of data can be received from the advertising device even without establishing a connection.
Advertising intervals can be set in a range of 20 ms to 10 s. It specifies the interval between consecutive advertising packets. Advertising is done sequentially on all the enabled channels.
For scanner mode, BLE specifies a scan window, which determines the duration of the scan as well as the scan interval, meaning how often it repeats.
When a connection is established, the initiator device (which will become a master) supplies the advertising device (which will become a slave device) with a set of critical data defining the channel and timing of the master-slave data exchange. In particular, this data specifies two important parameters: connection interval and slave latency. The connection interval determines the time between the start of the data packet exchange sequence called connection events. Latency, on the other hand, is a number of communication intervals that a slave may ignore without losing the connection. It gives the slave an opportunity to optimize and preserve power consumption. Once a connection is established, the slave may request an update of communication parameters to better fit the slave application.
The data channel PDU consists of a data packet header and up to 37 bytes of payload trailed by 4 bytes of Message Integrity Check (MIC) data if the link layer connection is encrypted. The data channel payload, depending on the packet header, may carry link layer control information or actual data for higher-level protocols.
Each communication event is started by the master transmission and it serves as an anchor point to calculate the time for the next event. During a communication event, the master and slave alternate sending and receiving packets until either side stops sending packets. The current event is considered closed and the data exchange is suspended until the next communication event.
No comments:
Post a Comment