NO20130662A1 - A protocol bridge between Bluetooth Low Energy and wireless sensor networks - Google Patents

Abstract

The invention relates to a solution for wireless ad-hoc communication between BLE devices (5) and devices in a wireless sensor network (7) using the ZigBee, ISA100.11a or WirelessHART protocol. The solution is realized by using one or more bridge devices that support both the BLE and the protocol used in the wireless sensor network (ZigBee, ISA100.11a or WirelessHART). All standard functionality defined for the application level in the wireless sensor network protocol used will be available for a BLE device connecting to the bridge device. This is realized by encapsulating function calls and return values in GATT characteristics. The BLE will have all the features of the wireless sensor network protocol used available through an application interface. The bridge unit will perform the actual function calls requested by the BLE, as well as provide return values, as a full participating node in the wireless sensor network.

Description

INTRODUCTION

Networks of wireless sensor and actuator nodes are used today to control and monitor a wide range of applications within, among other things, the process and automation industry. When several wireless sensors are connected in a wireless sensor network (Wireless Sensor Network (WSN)), data can be sent via intermediate nodes in the network to reach the destination. WSNs represent a major advance compared to traditional wire-based sensor networks, as they do not necessarily depend on communication infrastructure or power grids. A WSN can cover large areas by allowing intermediate nodes to forward the messages.

A drawback of existing protocols for WSNs is the limited ability to include mobile devices such as smartphones, tablets and laptops. Such devices have become multifunctional systems that can perform a very wide range of tasks. The mobile devices often support wireless communication using ad-hoc protocols such as Bluetooth, Bluetooth Low Energy(BLE) and Wi-Fi, but not the most common protocols used in WSNs; ZigBee, ISAlOO.lla or WirelessHART.

BLE was introduced as part of the Bluetooth 4.0 standard as a new type of Bluetooth. It introduces a completely new protocol stack with features such as low energy consumption, low latency and low bandwidth. BLE is therefore intended for a different area of use than the classic Bluetooth.

There are no known standards for communication between BLE and WSN protocols such as ZigBee, ISAlOO.lla or WirelessHART. A technology bridge between BLE and ZigBee, ISAlOO.lla or WirelessHART will enable the use of mobile devices, such as smartphones and tablets, to monitor and control all systems that use ZigBee, ISAlOO.lla or WirelessHART. The invention presents a technology bridge that enables communication between BLE and networks of the type ZigBee, ISAlOO.lla or WirelessHART. The solution allows devices that support BLE to connect to ZigBee, ISAlOO.lla or WirelessHART networks and make use of functions available to nodes in the network.

KNOWN TECHNOLOGIES

We are not aware that there is currently any technology that solves the presented problem without adding external hardware to mobile devices to support the protocols ZigBee, ISAlOO.lla or WirelessHART. Nearby solutions exist for extracting data from wireless sensor networks where a gateway is used, [Dl] and [D2]. Both [Dl] and [D2] mention a solution for using a smartphone as a gateway to get data from a wireless sensor network to the Internet. In Di's case, this is done using 6L0WPAN as the upper layer of the current protocol in the wireless sensor network. The mentioned solution in [Dl] cannot therefore be used in an existing network that already uses ZigBee, ISAlOO.lla or WirelessHART without extensive changes to the entire network. Each node will then require a new stack. The mentioned solution in [Dl] also differs significantly from the solution presented in this application in that those in [Dl] want to use a common protocol from end to end, while in this solution it is allowed to combine already existing available protocols at each end . The solution described here also takes advantage of the documented characteristics BLE brings in accordance with resource requirements for both master unit and peripheral units.

[D2] uses normal Bluetooth (Basic Rate) between mobile and gateway, and in addition they connect to the WSN via a proprietary protocol.

DESCRIPTION OF THE INVENTION

Referring to Figure 1, the invention relates to a device that enables communication between a mobile device and a wireless sensor network. Communication between the mobile device (5) and the network (7) is done using a bridge device (1) in the network (7) which supports both BLE and the network protocol. The bridge unit (1) contains communication systems for both BLE (2) and the network protocol used (3). The network protocol can be of the type ZigBee, Wireless HART or ISAlOO.lla. The two systems in the bridge unit have a dedicated communication channel (4). The communication system for the network protocol (3) must support the same protocol used in the wireless network (7), and is connected as a node in the network.

According to Figure 2, the invention allows the bridge unit (1) to be connected to a BLE unit (5) and one or more ZigBee, ISAlOO.lla or WirelessHART units (9) at the same time. There can also be one or more bridge units (1) connected to the network (7) at the same time to achieve several BLE connection points (6).

Referring to Figure 3, the BLE device (5) should have a BLE stack (12) and a BLE transceiver (13). The BLE device (5) must also have a programming interface (API) (10) which enables stack functionality for the protocol used in the network (7). BLE unit (5) must have a separate protocol (11) for communication with the bridge unit (1). The protocol (11) encapsulates stack functionality for ZigBee, ISAlOO.lla or WirelessHART using BLE GATT characteristics.

Referring to Figure 3, the bridge unit (1) includes a BLE stack (12), a BLE transceiver (13), a ZigBee, WirelessHART or ISAll.lla stack (14) and a ZigBee, WirelessHART or ISAll .lla transceiver (15). The bridge unit (1) also contains a protocol (11) for communication with the BLE unit (5). The protocol (11) running on the bridge unit (1) extracts information from GATT characteristics, and forwards to the ZigBee, WirelessHART or ISAlOO.lla system (15) which stack functions have been called from the interface (10) on the BLE unit ( 5). The ZigBee, WirelessHART or ISAlOO.lla system (15) performs the call that is conveyed from the protocol (11).

Referring to Figure 3, other nodes (9) in the network (7) shall have a ZigBee, WirelessHART or ISAll.lla stack (14) and transceiver (15).

Referring to figure 4, the bridge unit (1) can be realized with a BLE system chip (SoC) (18), a ZigBee, WirelessHART or ISAll.lla SoC (19) and a wired communication channel (4) between the two systems. The system chip for BLE (18) must contain a BLE stack (12), a UART/SPI/I2C driver (20) and a bridge protocol (11). The system chip for ZigBee, WirelessHART or ISA11.11a (19) must contain a stack (14), UART/SPI/I2C driver (20) and a bridge protocol (11). The communication channel (4) must use UART, SPI or I2C as communication protocol between the two systems, (18) and (19).

Referring to Figure 5, the bridge unit can be realized with ZigBee, WirelessHART or ISAll.lla SoC (19), a BLE transceiver (13) and a communication channel (21) between the two systems. The system chip (19) must contain stacks for both BLE and ZigBee, WirelessHART or ISAll.lla.

Referring to Figure 6, the bridge unit can be realized with the BLE SoC (18), a ZigBee, WirelessHART or ISAlOO.lla transceiver (15) and a communication channel (21) between the two systems. The system chip (18) must contain stacks for both BLE and ZigBee, WirelessHART or ISAll.lla.

Referring to Figure 7, the bridge unit can be realized with a microcontroller (22), a BLE transceiver (13), a ZigBee, WirelessHART or ISAlOO.lla transceiver (15) and a wired communication channel (21) between them. The microcontroller (22) must contain stacks for both BLE and ZigBee, WirelessHART or ISAlOO.lla and the bridge protocol (11).

Referring to Figure 8, the bridge unit can be realized with two microcontrollers (22), a BLE transceiver (13), a ZigBee, WirelessHART or ISAlOO.lla transceiver (15), a communication channel between the microcontrollers (4), and a communication channel (21) from each of the microcontrollers to each transceiver. One microcontroller must contain a stack for BLE and the other must contain a stack for ZigBee, WirelessHART or ISAlOO.lla. Both microcontrollers (22) must contain the bridge protocol (11).

Referring to Figure 9, the bridge protocol (11) receives an API call (35) from an application on the BLE device (5). The protocol encapsulates the function call as a data segment (25) in a BLE GATT characteristic (26). The bridge protocol then sends the GATT characteristic using functionality available in the BLE stack (12). The BLE stack (12) sends the GATT characteristic according to the BLE standard in a BLE packet (27).

Referring to Figure 9, return values on function calls are sent back to the BLE device as standard BLE packets (27). Received BLE packets (27) with GATT characteristics belonging to the bridge protocol (11) are sent (26) from the stack to the bridge protocol (11). The bridge protocol extracts the data segment from the GATT characteristic (28) and sends it back to the API as the return value of the original function call (36).

Referring to Figure 10, when the bridge unit (1) receives a BLE packet (27) with characteristics belonging to the bridge protocol, the data segment is sent from the BLE stack to the bridge protocol (26). The bridge protocol evaluates which ZigBee, ISAlOO.lla or WirelessHART function the data segment contains and calls the respective function (32) in the ZigBee, ISAlOO.lla or WirelessHART stack (14).

Referring to Figure 10, when the ZigBee, ISAlOO.lla or WirelessHART stack (14) of the bridge unit (1) receives a ZigBee, ISAlOO.lla or WirelessHART packet (34) as a callback of a function that was originally called through the bridge protocol, it forwards the data in the recall (33) to the bridge protocol. The bridge protocol encapsulates the data in associated GATT characteristics (26) and sends it back to the BLE device (5) through the BLE stack (12) as a BLE packet (27).

In the following, an example of the information flow in an existing system is given. Given a wireless sensor network using the ZigBee protocol, a bridge device connected to the ZigBee network and a smartphone with BLE support. It is further assumed that a BLE connection has been established between the smartphone and the bridge unit. The smartphone runs an application with access to the bridge protocol and an API that presents all functions available in the ZigBee standard.

The standard for ZigBee defines, among other things, a function to detect all nodes in a ZigBee network. This will therefore also be available for the application on the smartphone through the APP. In the case of a call to the function from the application through APFet, the information flow described in Figure 9 and Figure 10 will lead to the function call being conveyed from the phone, through the bridge protocol, and actually executed from the bridge unit as a full participant in the ZigBee network. According to the ZigBee standard, each detected node in the network gives a recall as a result of this function. The bridge protocol relays all callbacks back to the application on the phone, as illustrated in Figures 9 and 10.

With information about all the nodes in the ZigBee network, the phone can call other ZigBee functions that require addressing to individual nodes, through the API. For example, reading and writing values on a given node in the network.

As the smartphone has access to call all available ZigBee functions, it will be able to act as a peripheral end node in the ZigBee network.

Claims (6)

1. Technology bridge where a bridge unit (1) enables ad-hoc communication between a BLE device (5) and a wireless sensor network (7) that uses communication protocol ZigBee, ISAlOO.lla or WirelessHART, where the bridge unit (1) has support for communication with both BLE and ZigBee, ISAlOO.lla or WirelessHART. 2. Technology bridge according to claim 1, characterized in that applications on the BLE unit (5) have access to perform all standard functionality at the application level defined for the protocol used in the wireless sensor network. 3. Technology bridge according to claims 1-2, characterized in that the bridge unit has a communication system for BLE and a communication system for ZigBee, ISAlOO.lla or WirelessHART. 4. A communication system according to claim 3 is realized in that both a stack and a compatible transceiver are available for the protocol to be used in the system. 5. Technology bridge according to claims 1-3, characterized by the fact that the different communication systems on the bridge unit can communicate with each other. 6. Technology bridge according to claims 1-5, characterized by the fact that the BLE unit and the bridge unit use GATT characteristics for encapsulation of function calls and return values belonging to the protocol used in the wireless sensor network.