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 Virtual Switch (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:
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 wifi settings such as SSID and Password between the cloud and all extenders
Setting up data path to wifi extenders, including multiple VLAN support
Performing client and band steering actions
OpenSync advanced features rely heavily on OpenVSwitch (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 mosquitto to send data to the Plume cloud. Two components of OpenVSwitch 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 performing 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.
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:
30MB to 50MB RAM
1 to 5% CPU utilization on a system with a single ~750MHz processor
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.
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.
Overview document: OpenSync_1.2_Overview.pdf
Target layer API (doxygen generated): OpenSync_1.2_Target_lib.pdf
Traffic monitoring and control API: FSM Plugin API.pdf
Reference Target Layer: The Static Reference Target Layer emulates a typical chip target layer, providing static interaction with the OpenSync software. It allows developer to build and test OpenSync. The true chipset specific target layer should be obtained from the chipset vendor. Link to reference target layer: Reference Target Layer
Build instructions: How to build the SW using the Static Reference Target Layer: OpenSync_reference_build_instructions.pdf