Posts Tagged ‘top-story’

The Bluetooth Special Interest Group (SIG) announced Bluetooth mesh technology in July. It targets industrial automation and smart buildings by extending the reach of a network, while maintaining the low energy consumption of Bluetooth technology.

The distinctive feature of Bluetooth mesh networking is that it enables many-to-many (m:m) device communication. Rather than a star topology, where one central device communicates with others in a point-to-point network (or piconet), the mesh topology allows a device to communicate with every other device in the mesh.

Bluetooth mesh networking is designed for building automation applications, such as lighting, heating, cooling, and security. It can be used to expand sensor networks, beacons and for asset tracking—locating and tracking goods in real-time across an area.

The Bluetooth mesh system is based on the Bluetooth Low Energy stack. Bluetooth Low Energy is the Wireless Personal Area Network (WPAN) technology used by smartphones, tablets, and computers in smart homes, healthcare, and entertainment.

On top of the Bluetooth Low Energy stack is a bearer layer that defines how mesh Protocol Data Units (PDUs) will be handled. This will be by either advertising or scanning to send or receive PDUs (the advertising bearer), or by communicating indirectly with nodes on a mesh network which support the advertising bearer; this is the Generic Attribute Profile (GATT) bearer.

Next is the network layer. This layer processes messages from the bearer layer and defines the network interface over which messages will be sent as well as the message address type and format. It can support multiple bearers.

The lower transport layer takes PDUs from the upper transport layer, where encryption, decryption, and authentication of application data take place. The lower transport layer may perform segmentation and reassembly if required.

Above the upper transport layer is the access layer, which defines the format of application data, defines and controls encryption and decryption performed in the upper transport layer, and verifies the data received from the upper transport layer before forwarding the data.

The foundation model layer implements the configuration and management of a mesh network. Finally, the model layer implements behaviors, messages, and states (e.g. on/off) to define the functionality of a particular element within a node. For example, a Light Emitting Diode (LED) luminaire may have three LED lights. Each light is viewed as one element.

Bluetooth SIG has opted for a managed flood message transmission system. Other mesh networks, (for example, ZigBee) use a routed mesh framework, where devices communicate on a defined path. Others, like Thread, use a flooding technique, where every device on the network communicates to every device. Managed flooding controls which device can pass messages. All devices will use Bluetooth Low Energy, but only mains-powered devices will relay messages, saving battery power.

The mesh’s multi-hop communication method extends the range of connections and allows for network scalability, while reducing power consumption due to shorter transmission distances between the nodes.

Emerging Markets

ABI Research predicts nearly one third of the 48 billion Internet-enabled devices installed by 2021 will include Bluetooth, which will find new applications.
“While smartphones and audio accessories remain Bluetooth’s largest markets, the technology is becoming more attractive to low-power IoT applications,” says Andrew Zignani, Industry Analyst at ABI Research. “Though Bluetooth still faces strong competition from the other standards, mesh networking will enable new opportunities for the technology in the smart home, building automation, and emerging IoT markets in which robustness, low latency, scalability, minimal power consumption, and strong security are all additional critical requirements.”

Three characteristics are particularly important for an industrial-grade network: reliability, scalability and security.

Reliability and Scalability

The peer-to-peer communication, where nodes communicate directly with each other, makes Bluetooth mesh connectivity reliable. The structure eliminates the need for a centralized hub or gateway, or routing nodes, so there are no single points of failure. Additionally, its managed flood message relay architecture is inherently multi-path and self-healing.

The Bluetooth mesh is specified to allow up to 32,000 devices, or nodes, per network, sufficient for high density lighting or sensor environments to scale in size as network demands increase.

Building automation uses multicast messaging, where messages are sent to various destinations simultaneously. Bluetooth mesh’s managed flood message relay architecture and the publish/subscribe (send/process) procedure for group messaging are designed to handle the volume of multicast messaging traffic typically found in building automation environments.

Large wireless device networks present security challenges. These are addressed by Bluetooth mesh technology with several architectural features. First, devices are added to a network using a 256-bit elliptic curve and out-of-band authentication. Within this provisioning process, security measures include an exchange of public keys between the provisioner and the device to be added, followed by authentication of the device and the issue of a security key, or NetKey, to add the device.

In operation, all mesh communication is encrypted and authenticated with 128-bit keys. Encryption and authentication is also implemented on both the network layer and the application layer. Content is secured with a separate application key for end-to-end security.

Each mesh packet is obfuscated so that identifying content is removed from the message. This prevents tracking and is particularly useful when devices move within range of other networks.

Figure 3: Silicon companies such as Toshiba Electronics have already announced Bluetooth mesh support in their Bluetooth products. (Source: Toshiba Electronics Europe)

Design Support

Silicon companies are already providing support for the Bluetooth mesh standard. Toshiba Electronics Europe has announced support for its Bluetooth Low Energy products.

Heiner Tendyck, System LSI Marketing Manager, Toshiba Electronics Europe, believes Bluetooth mesh will introduce the technology to new areas. “This standards-based approach means that new untapped markets, such as industrial and commercial, can now leverage ever-present Bluetooth cell phones or tablets to easily control and monitor their systems,” he says.

Silicon Labs has also announced that its Blue Gecko Bluetooth Wireless Starter Kit provides Bluetooth mesh connectivity as well as Bluetooth 5 capability. The company can also provide a Bluetooth mesh stack for Android, allowing smartphones to configure and control nodes on the mesh.

Caroline Hayes has been a journalist covering the electronics sector for more than 20 years. She has worked on several European titles, reporting on a variety of industries, including communications, broadcast and automotive.

The European Telecommunications Standards Institute (ETSI) develops Information and Communications Technologies standards deployed worldwide for fixed, mobile, radio, broadcast and Internet. This role naturally makes this standards organization the holder of a key role in the development of Network Functions Virtualization (NFV) technologies. Don Clarke, chairman of the Network Operator Council group in the ETSI NFV Industry Specification Group recently responded to e-mailed questions from EECatalog about the first NFV Plugtests Event organized by the ETSI Center for Testing and Interoperability, which will be held from January 23 to February 3, 2017, and other data center and virtualization topics. Edited excerpts follow.

EECatalog: What should our readers be aware of regarding the NFV Plugstests Event being held at the beginning of next year [January 23 to February 3, 2017]?

Don Clarke, ETSI: ETSI Plugtests are an essential source of feedback to our standardization activities, which allow us to validate and improve the quality of the specifications as they are being developed.

The first NFV Plugtest focuses on testing relevant ETSI Network Functions Virtualization (NFV) capabilities over a number of combinations of NFV infrastructure, Management and Orchestration (MANO) solutions and Virtual Network Functions (VNFs) provided by the industry and Open Source projects. This focus allows ETSI to evaluate and increase the interoperability among vendor and open source implementations.

Besides being a source of essential feedback for ETSI NFV, the NFV Plugtest is also a great opportunity for the industry and open source projects to learn how the rest of the NFV ecosystem uses their implementations.
EECatalog: Many open source communities have emerged to drive NFV implementation. Are standards still needed?

Clarke, ETSI: Open source is an excellent way for the common elements of an implementation to be created collaboratively, and for vendors to focus their individual commercial efforts on capabilities built on top of open source. But Telecommunications infrastructures require rigorous specifications to ensure interoperability and to support legacy services that are deployed at massive scale. Telecommunications networks must also meet numerous regulatory requirements including support for critical national infrastructures. Current open source governance models do not provide these guarantees. Ideally there is a model where Standards Development Organizations (SDOs) developing specifications work more quickly and hand-in-hand with open source communities.

ETSI NFV has led the way in converging and specifying operator requirements (38 operators are involved) and the ETSI NFV work is widely referenced by the industry including open source communities. ETSI consequently established the Open Source MANO (OSM) group in February 2016 to deliver an open source NFV MANO stack using best-in-class open source workflows and tools to ensure rapid development and delivery. The activity is closely aligned with the evolution of ETSI NFV and provides a regularly updated reference implementation of NFV MANO. OSM enables an ecosystem of NFV solution vendors to rapidly and cost-effectively deliver solutions to their users.
EECatalog: How would you say embedded virtualization differs from that used for data centers and enterprise IT networks?

Clarke, ETSI: I prefer to use the term Network Functions Virtualization (NFV). The objective of NFV is to use IT and Cloud techniques, including virtualization and management and orchestration, but to identify and specify additional requirements that will enable these technologies to be used to create “carrier grade” network solutions inside cloud environments. In this context, “carrier grade” means the ability to assure deterministic bandwidth, jitter and latency, and to enable configurations that can deliver the appropriate level of reliability and availability for the services being delivered via the virtualized infrastructure.

In addition, network operators require cloud infrastructures to be “distributed,” that is, extending beyond the data center. For example, instances of cloud infrastructure could be physically located in the access network, and even in the end user premises. Such virtualized infrastructures need to be managed end-to-end, which requires new standards and new tools.

EECatalog: What are some examples you have seen of embedded developers putting virtualization to innovative use?

Clarke, ETSI: We are seeing the early application of NFV to enable high-performance software implementations of network functionality previously only possible using hardware devices for such tasks as routers, firewalls and security monitoring. Implementing these functions purely in software enables automation and faster deployment, including customer self-provisioning.

EECatalog: How do you expect virtualization where the need for real-time response is also involved to look five years from now?

Clarke, ETSI: Achieving automation is key. There is still a lot of work to do to enable network operators to fully automate network design, provisioning and operations. Currently virtualized networks need a lot of manual intervention to design and deploy. This is why early NFV deployments are often in conventional data center environments where existing tools can be used. A key area of focus is to converge information modeling approaches across the industry to minimize complexity and simplify tooling and skill requirements. A collaborative multi-SDO effort is underway to do that.

EECatalog: What technology developments are you keeping especially close watch on?

Clarke, ETSI: The emergence of container technology as an alternative to virtual machines is of high interest. Containers are more resource efficient and faster to deploy than virtual machines, but there is more dependency on the host operating system version, which needs to be taken into account to ensure interoperability.

Today, commercial VNFs are often based on hardware appliances that have been re-purposed to run in a cloud environment. Such re-purposing can be inefficient in use of resources, so we are interested to see VNFs designed from the ground up to be more resource efficient and more optimized for automated deployment and operations.