Overview

OpenSync™ software consists of three major functions: telemetry, control, and networking. The telemetry portion is based on MQTT, and Protobuf. MQTT is a proven IoT framework that is efficient, and has been deployed successfully across the industry. There are open source broker implementations on both the device and cloud side, which makes it convenient to implement. These protocols were designed for frequent reports from millions of sensors, so it serves well in the OpenSync application. Protobuf as a format is simple, easily parsed, and flexible.

The control portion of OpenSync is based on OVSDB™. OVSDB provides synchronized, distributed database semantics with callbacks on transactions. It is robust, and can be used uniformly in the devices and in the cloud. There are several open source controller implementations. It can be exercised through CLI commands or applications on the device, aiding with development.

The networking portion of OpenSync utilizes Open vSwitch™ (OVS™), together with OVSDB and OpenFlow. The flexibility of OVS has been proven in applications from data centers to OpenWRT™ home routers. Its advantages in this application include the availability of open source, high performance implementation on chipsets including the use of HW acceleration, and flexibility via programmable capabilities.

The diagram above shows how the major software elements in an OpenSync enabled device relate. OpenSync includes the previously open sourced elements of MQTT, OVSDB, and OVS. OpenSync adds a new set of managers, and a target layer. The target layer can be viewed as an adaptation layer between the OpenSync managers and the low level drivers in the device. Because the OpenSync target layer acts as a hardware abstraction layer, it is generally specific to a particular chipset.

OpenSync has all the facilities to create and manage sophisticated Wi-Fi mesh networks. However, it would be possible to use OpenSync on top of Wi-Fi EasyMesh™. In that case EasyMesh would form the mesh networking layer, while OpenSync would act as the connection to the cloud, and manage additional services such as security or parental controls.

 

OpenSync should not be thought of as a standalone piece of software. It relies on certain prerequisites in order to provide its functionality. OpenSync sits on top of an SDK, which should be obtained from the chipset vendor for the given device. In addition to the drivers and BSP, the SDK should provide any required libraries or chipset specific modifications to OpenSync. These components should include the appropriate:

  • Cross-compiling toolchain

  • Wi-Fi and other drivers

In addition, the chipset supplier may provide library elements customized to its chipset, or standard versions of the libraries may be used:

The diagram below shows a more detailed view of the OpenSync components. OpenSync core functionality includes:

  • Tunable logging infrastructure

  • Establishing and maintaining cloud connectivity

  • Statistics gathering, processing, and reporting for things like:

    • CPU and memory usage

    • Associated client stats

    • Channel survey stats

    • Neighboring AP stats

    • Non-associated client stats

  • Virtualized network and wireless management

  • Synchronization of Wi-Fi settings such as SSID and Password between the cloud and all extenders

  • Setting up data path to Wi-Fi extenders, including multiple VLAN support

  • Performing client and band steering actions

 
 

OpenSync advanced features rely heavily on Open vSwitch (OVS) and Mosquitto libraries for core functionality. Mosquitto is a message broker, implementing the MQTT messaging protocol. The OpenSync component called Stats Manager (SM) collects statistics and uses MQTT and protobuf to send data to the Plume cloud. Two components of Open vSwitch enable OpenSync to operate: “ovs-vswitchd” is the OVS daemon that controls virtual switches and “ovsdb-server” is the OVS database server that contains configuration and state for various parts of OpenSync such as the Connection Manager, Wireless Manager and the Network Manager. The cloud and Opensync are connected through the openflow protocol. Editing entries in the OVSDB tables is the way the cloud and OpenSync exchange system information and instructions. Both sides use a predefined schema to set configuration values and monitor status values.

OpenSync consists of many managers which are running as a separate processes and perform their specific group of tasks. The diagram above shows four of the most important managers:

  • Stats: gathering statistics and preparing them for transmission to the cloud

  • Wireless: SSID/AP config, associated client reporting, radio configuration

  • Network: IPv4/IPv6 addresses, DNS, firewall, GRE tunnels, DHCP reservations

  • Connection: establishes backhaul connection and maintains connection with the cloud

Other managers include:

  • Diagnostics: spawns the rest of the OpenSync managers, and monitors their operation

  • Steering: responsible for band steering and client steering of Wi-Fi clients

  • Queue: responsible for sending messages to the cloud using Protobuf and MQTT

  • Log: collecting and uploading logs on demand for debugging and monitoring

  • OpenFlow: manages packet flow rules configured in OVS

  • Platform: naming and device typing, cloud managed device parental control/device freeze

The diagram below shows the flow monitoring and control portions of OpenSync. These portions of OpenSync provide the foundation of the access control service. In addition, they provide the required hooks for implementing cyber security, parental controls, and future services . The key to operation is the ability of OVS to monitor flows and collect statistics regarding those flows. OVS is also used to block, filter, forward, and prioritize messages. All of these OVS activities are programmable from the cloud using OVSDB.


Device Requirements

OpenSync has been ported onto a wide variety of gateway and extender devices. Representative resource requirements, including the footprint of the required open-source components (e.g. OVS) and libraries for an ARM processor are:

  • 6MB Flash

  • 30MB to 50MB RAM

  • 1 to 5% CPU utilization on a system with a single ~750MHz processor


Cloud Requirements

A complete system using OpenSync requires a cloud controller. Implementers may use their own, or make use of a development cloud that has been set up. The development cloud infrastructure includes a Network Operations Center (NOC) dashboard, as well as a mobile app which is available for either Android or iOS devices. Connecting to the development cloud requires device certificates for server-side client authentication and a development cloud account. The development cloud requires some device parameters to be known in advance prior to first connection, including the device ID (serial number), LAN and WAN interface MAC addresses, and Wi-Fi radio MAC addresses. It is also best to create a model specific capabilities file for the device, which can be added onto the model files that already exist in the development cloud. The development cloud also includes tools to help with the validation of stats and debugging. Use the info@OpenSync.io contact address to request connection to the development cloud.


Detailed Documentation

The following documents go into greater detail and should be consulted when working on OpenSync. Be aware that OpenSync was originally called PML. In the documentation below, references to PML can still be found. PML and OpenSync are equivalent terms in all cases.


A target layer implementation is available for the RDK™ unified platform: