whitepapers

Internet of Things – The Münchhausen Trilemma

With Internet of Things becoming a reality, companies tend to underestimate the challenges hidden in the local communication networks (HAN/PAN) assuming the chipset and software stack vendors will be able to guarantee the needed interoperability and by adopting the ‘Münchhausen trilemma’ assumes that the management and monitoring messages embedded into the protocols will be enough to support and maintain these complex networks.

While some IoT application issues may be identified and resolved using the built in management and control features of the IoT system itself. This is like an episode taken from the Baron Münchhausen, where he and his loyal horse sink in a swamp. Münchhausen gets out of the swamp by pulling himself out by his long hair.

Munchausen

Baron Munchausen’s remarkable leap Painted by Alphonse Adolphe Bichard.

Read More…

Single vs. Multi dongle capture of Bluetooth Low Energy Traffic

Background
Bluetooth Low Energy (also known as Bluetooth Smart, Bluetooth 4.0 or just BLE) uses 40 channels within the 2.4GHz band. 3 of these channels (numbered 37, 38 and 39) are defined as advertisement channels.

When a device (usually the Slave) wishes to set up a connection, it starts transmitting messages over the 3 advertisement channels (usually one after the other).

The other party (usually the Master) listens to the advertisement channels. Once it received the advertisement message sent by the initiating device, it replies with a Connection Request message. The Connection Request message defines the frequency hopping and other parameters of the connection. When receiving it, the initiating party starts frequency hopping sequence that matches the responder device parameters.

The frequency hopping is done over the remaining 37 channels (numbered 0 to 36).

 

BLE1

Read More…

Challenges in analyzing 6LoWPAN/ZigBeeIP networks

Background
While IP protocols are widely spread over broadband wireline and wireless communication means, transferring IP data over lower bit rate protocols has been always a challenge. The long headers of the IP layer and the layers on top of it made the use of IP over narrow band protocols such as IEEE 802.15.4, mostly inefficient.

Yet using IP instead of proprietary or application protocols designed specifically for low bit rates (e.g. ZigBee and Thread) has major advantages such as interoperability with other devices, possibility to use tools, applications and software stacks, use of standard Internet browsers, etc.

First introduced in 2007, the 6LoWPAN protocol is designed as an optimization method for efficient transmission of IP layers on top of IEEE 802.15.4 networks. The 6LoWPAN documents define ways to compress various IP layer headers into very small packets by removing redundant information, and optimizing the number of bits allocated to fields with common values. 6LoWPAN provides some additional adaptation layer services such as fragmentation to handle long IP packets sent on top of relatively short 802.15.4 packets, mesh routing etc.

A typical structure of IP over IEEE 802.15.4 with 6LoWPAN is sown in Figure 1.

 

Analyzing6LoWPAN-Networks
Analyzing 6LoWPAN/ZigBeeIP/Thread with the Perytons™ Protocol Analyze When analyzing and debugging an IP network/s running on top of IEEE 802.15.4, there are several challenges expected:

Read More…

Architecture of the Perytons™ Protocol Analyzer

The various Perytons™ Protocol Analyzer models are based on a similar core engine, a fact that enables the easy upgrade between the different models and ensures easy cross operation and work between all models of the Perytons™ Protocol Analyzer family.

The Perytons™ Protocol Analyzer is built-up of two main components – the analyzer core and the protocol specific elements.

The Perytons™ Protocol Analyzer core includes the GUI (Graphical User Interface), analysis engine and analysis toolbox. This part is shared by all Perytons™ Protocol Analyzer models.

The protocol specific elements include RF front-end, data capture interface, and the protocol processor. This part is protocol-specific.

With the exception of the RF front-end, which requires dedicated hardware (supplied with the analyzer), all other elements are implemented via software running on the user’s PC.

 

AnalyzerArchitecture

Read More…

Perytons™ Protocol Analyzer Overview

Perytons™ Protocol Analyzers allow analyzing and debugging wireless and wire line communication networks such as 802.15.4, ZigBee, ZigBee RF4CE, 6LoWPAN, PLC and Bluetooth Smart.

AnalyzerOverview

The Perytons™ Protocol Analyzer includes various views for exploring data behavior like: Time View, Network View, Message View, Message Tree View, Message Sequence and Devices View.

Capturing data is accomplished by using external hardware as PHY front-end. For IEEE802.15.4 and Bluetooth Smartrelated traffic this is accomplished using IEEE802.15.4 or BLE USB dongles as RF receivers, while for other protocols an external relevant box is used.

Read More…

Flexibility

The Perytons™ Protocol Analyzers provide a variety of flexibility levels for the user. Starting with the basic look and feel preferences available to all users, and all through to a full environment allowing the user to build his own protocol into the analyzer, create charts and more.

Preferences

Available in all basic Perytons™ Protocol Analyzer models.

Allows the user to set the colors of different message types, connections (colors and line thickness), etc.

Preferences

 

Using User Defined Scripts written by Perytons™ or by Peryton-Scripting Add-On holders

Available in all basic Perytons™ Protocol Analyzer models.

Any Perytons™ Protocol Aanalyzer user can use User Defined Scripts written for the analyzer. Such a Script can generate charts, filter messages in Time View and Message View windows, change the device icon in the Network View, generate events and alarms, and more (for further information regarding Perytons™ User Defined Scripts see the Perytons™ User Defined Scripts whitepaper).

Read More…

User Defined Scripts

User Defined Scripts are practically small pieces of code that enable the user (or Perytons™ support) to add features to the Perytons™ Protocol Analyzer, or to modify existing analysis,
without the need to add these features into the Perytons™ Protocol Analyzer core. Such features are aimed to serve specific needs or requirements by the user of the standard Perytons™ Protocol Analyzer platform. After they have been written and signed, Scripts can be incorporated as an additional layer of the analysis process and into the different Perytons Protocol Analyzer active licenses of choice.

The User Defined Scripts enhance capabilities of the Perytons™ Protocol Analyzers’ environment in different dimensions like monitoring of live-networks; change the look and feel of the existing views (Time, Message, Network, etc.), definition of customizable statistic charts, interconnection and reports to external applications through numerous communication ports and protocols, e-mail alerts, and more.

Scripts run whenever a new message is analyzed or when a new message is displayed as explained within the following diagram:

 

OSR

 

The various Perytons™ Protocol Analyzers basic models already include some User Defined Scripts examples (the list of these basic Scripts included in the standard products may change from time to time without prior notice).

Read More…

Perytons™ Protocol Analyzers – Time View

Background

802.15.4/ZigBee/6LoWPAN and Bluetooth Low Energy (Bluetooth Smart) wireless as well as narrow-band PLC wire-line networks such as PRIME, usually comprise of several devices that communicate with each other over a specified communications medium. In some of the protocols, each network has a unique ID (PAN ID) and each station (device) has its own unique Device ID or specific addressing methods. Several networks may coexist in the same proximity, sharing the same environment (as with the Power Line in PLC networks or a single RF channel in the wireless case) or using different or multiple RF channels when dealing with wireless networks.

For increased efficiency, a network coordinator station may transmit a repetitive beacon, or predefined parameters in the protocol may define special time or channel change time slots for the different network members’ transmissions.

Additionally each of the network devices may transmit messages in the different protocol layers, etc.

One thing is obvious, as wireless and wire-line network protocols evolve, the time-related events become more difficult to analyze by just going over a list of messages with the content (or even time stamp) of each of the messages.

The Perytons™ Protocol Analyzers Time-View window

The Perytons™ Protocol Analyzers provide a unique Time View window that displays color coded messages in a two dimensional grid. In a beacon or time-slotted network, gridlines are displayed together with their received or expected allocation (for protocols with beacon transmissions or time-slot calculation respectively), for both uplink and downlink messages.

The detection of devices transmitting out of the allocated slots as well as additional time related phenomena and measurements, becomes easy.

TimeView

The grid’s vertical axis can be used to group messages by channel, source ID, IP address, Protocol Layer or PAN ID to allow easier understanding of traffic patterns and transactions. The following figure shows the same set of messages group according to different criteria:

Read More…

Antenna Diversity

Wireless communications at 2.4 GHz is subject to packet loss due to multi-path interference. This is especially severe in an indoor environment due to reflections from walls and fading due to other objects (e.g. people moving about).

Some 2.4 GHz protocols such as Bluetooth use frequency hopping to combat multi-path, which is frequency selective. They are therefore relatively robust, only suffering from the occasional loss of a single packet. 802.15.4, on the other hand, is more sensitive to multi-path since it uses a fixed channel.

A normal communication link between a pair of network nodes will use acknowledgements and retransmissions to recover lost packets. A receive-only element such as a protocol analyzer, on the other hand, has no way of asking for a retransmission due to its non-intrusive required nature.

The Perytons™ Protocol Analyzers overcome this problem by using multiple receiver dongles that are tuned to the same channel. The wavelength of the 2.4 GHz signal is 12.5cm (~5 inches), and a distance of 6cm (~2.5 inches) or more between the dongles tuned to the same channel drastically reduces packet loss due to multi-path, thus dramatically increasing the reliability of the data capture and analysis.

 

Diversity
Read More…

Perytons™ Monitoring for SOA (Service Oriented Architecture)

The Peryton-Monitoring Add-On allows to locally or remotely monitor operational networks for performance and potential failures.

Each of the remotely spread analyzers capturing live data, and using the User Defined Scripts, can generate statistics charts and events summarizing the performance and possible failures found in the specific local network being monitored.

 

WhitepapersSOA

The information from the different analyzers is polled by the Perytons™ SOA server (can be developed by the user, or can be a Perytons™ server) via dedicated Application Programming Interfaces (APIs). The results are available to authorized personal accessing the SOA server via a simple web browser.

Simultaneous Multi-Channel Data Capture

Background

The IEEE 802.15.4 PHY layer defines 16 possible channels in the 2.4GHz band (denominated as channel numbers 11 to 26). A 802.15.4 Personal Area Network (PAN) will typically use one of these 16 channels.

A given network will choose a channel either by user configuration or automatically according to channel noise level sensed.

A device looking to join a network would look for it in a process called “Scan” (unless it is manually pre-configured with the channel number). During a “Passive Scan” the device scans the channels and on each of them looks for a beacon transmission with the right PAN ID. During an “Active Scan”, the device transmits a beacon request message on each channel, and waits for the network coordinator to respond.

Analyzing 802.15.4/ZigBee network(s) with a conventional, single channel analyzer

A typical single-channel analyzer is capable of capturing only one of the 16 possible channels. The user needs to set the analyzer to the right channel, or the analyzer should actively or passively look for it.

The following figures show messages received in a single channel setup vs. the actual network topology where the messages have been received from:

MultiChannel

While this may be satisfactory for debugging a single network with a predefined channel, it raises a severe limitation when analyzing multiple networks or dynamic environments with dynamic channel assignments.

For example, two networks that currently use two separate channels but have some interaction in between them (e.g. mutual interference, or data transfer between them by using one of the devices as a relay) can’t be simultaneously analyzed by a traditional analyzer.

Similarly, an “Active Scan” captured by a single channel analyzer will only show occasional transmissions on the channel currently monitored by the analyzer.

Read More…

Challenges in capturing and analyzing ZigBee RF4CE networks

ZigBee RF4CE (RF for Consumer Electronics) is a new standard for enhanced control of home entertainment devices. With RF technology, larger range, higher flexibility, and enhanced topologies are supported.

As with any new standard, especially such that involves multi-vendor large scale consumer products, being able to quickly identify interoperability problems and implementation issues is an important requirement.

Unlike infrared controls that are limited by line of sight, when RF is involved, interference as well as coexistence of several networks in the same proximity (e.g. neighboring apartments, different rooms) imposes additional implementation challenges.

When looking for professional RF4CE analysis tools, on top of regular analysis features that allow understanding network topology, transactions, look into message details, etc, the above issues must be well addressed.

RF4CE

Use of multiple RF channels

The ZigBee RF4CE uses the unlicensed ISM (Industrial Scientific Measurement) 2.4Ghz frequency band. This band defines 16 possible channels. However, keeping in mind that typical RF4CE equipment will work in consumer in-door environment, that is most likely to have WiFi equipment, the 3 channels that are less affected by WiFi were chosen as possible RF4CE channels – i.e. channels 15, 20 and 25.

Read More…