uCentral Data Model Introduction
OpenWiFi 2.x makes it possible for integrators of the SDK to implement commercial products leveraging OpenWiFi Gateway service with vendor supplied provisioning above OpenWiFi SDK. As a minimum, the OpenWiFi 2.0 SDK framework offers a Security service which handles all OpenAPI authentication northbound, and the Gateway service which provides all uCentral websocket interface functionality southbound.
OpenWiFi also provides options to receive telemetry and events over both OpenAPI interface as well as Kafka message bus. When using Kafka, OpenWiFi Gateway directly publishes telemetry and event topics to the bus.
In future sprints of OpenWiFi dynamic device provisioning will be available as an added microservice.
OpenWiFi 2.0 Gateway implements the uCentral device management interface. uCentral specifies the data model and interface for management and telemetry of OpenWrt based devices. Gateway uCentral interface is a websocket JSON-RPC based design between OpenWiFi Gateway and the device running uCentral agent.
All communications from Gateway to Device are secured using mutual Transport Layer Security (mTLS). In mTLS systems each endpoint is a unique device sharing the same signed root or intermediate trust. In OpenWiFi each device has a signed certificate, key and device identifier. These are validated by the uCentral-Gateway to establish mTLS session.
Upon successful connection the device exchanges its capabilities with the OpenWiFi SDK. OpenWIFi SDK, via the Gateway microservice will send the entire device provisioning data as a JSON payload. Within OpenWiFi devices, the uCentral agent has a reader and renderer process providing serialization and validation of data sent from cloud. If any data presented can not be processed by the local agent, this is returned within an ERROR message using the same websocket connection.
If the device agrees with provisioning information presented, the render process builds calls into the operating system configuration sub-system known as UCI. The Unified Configuration Interface ensures OpenWrt compliant syntax is persisted within the device.
Configuration source of truth is the OpenWiFi SDK. Consistency of device configuration is handled with an applied hash compared by the Gateway for each device. If the value differs on device from that of the stored information in cloud, the device will be immediately resent its configuration from the OpenWiFi SDK Gateway service.
Once present, all configuration data is preserved on device restart.
It is possible to generate device configurations outside of the OpenWiFi 2.0 SDK as shown in the minimum SDK image at the start of this page. This may occur for some integrations or may occur when the OpenWiFi Provisioning microservice is not present. In this way, integrators of commercial products are welcome to build device provisioning outside of OpenWiFi and use the OpenWiFi cloud to manage the scale, state, security and validation of device websocket communications.
OpenWiFi 2.0 Device Configuration
To introduce the Community to the uCentral data model structure, the below illustrates a basic Access Point configuration that assumes a typical enterprise Wi-Fi scenario of a ceiling mount or wall mount device presenting a single WAN interface with a private management network and separate Wi-Fi network on a virtual local area network.
We will set the unit location and timezone, then proceed to configure radios.
In this example, a two radio device that indicates it is Wi-Fi 6 as the channel-mode values for both radios is "HE" which defines 802.11ax operation. Valid values are "HT" -High Throughput 802.11n mode, "VHT" - Very High Throughput 802.11ac mode, "HE" - High Efficiency 802.11ax mode.
Channel defines the specific channel number the radio shall operate on as an integer from 1 - 171 and may also be set to a string for "auto" mode. Channel width permits configuring the amount of RF channel the radio will operator over from 20-40-80-160 including 8080 mode (also known as 80+80) .
OpenWiFi radios may be set to require UE clients to associate to a minimum standard such as excluding any 802.11b associations depicted above with "require-mode" set to "HT" meaning 802.11n or higher clients may associate.
Control of beacon interval and multicast rates is possible per radio as shown in the "rates" section.
OpenWiFi 2.0 offers a highly flexible model for arranging network interfaces. Multi-port devices may be easily provisioned for numerous types of network segmentation and logical network configuration. We will start with a simple WAN that has a management IP and also a VLAN sub-interface for a logical SSID in a subsequent step.
In the above configuration block we have a WAN interface, its role is "upstream" meaning it faces the upstream in terms of service it provides (WAN). This has a direct alignment to how the device interprets a physical or logical port participates in bridge forwarding domains.
Note we want this port to have an IP address for its management, therefore the "ipv4" configuration is associated as a child of any Ethernet WAN ports and set to DHCP.
Imagine the OpenWiFi device is an enterprise Access Point mounted on a ceiling. These devices do not always have a LAN port. Also in an enterprise, it is likely the Wi-Fi services are in their own network segments and not subject to Network Address Translation (NAT). Since the enterprise would also not want Wi-Fi on the same network as Management, an 802.1Q Virtual LAN is used.
In this next section of configuration, an additional logical interface associated to the WAN ports for the VLAN id of "100" is shown. Note there is no IP address associated to this interface, it is a layer 2 interface that will emit on any and all WAN ports with VLAN id 100.
To associate the Wi-Fi with the VLAN interface define, we continue within the WAN100 interface adding SSID services.
Within the "ssids" configuration block we can process an array of SSIDs. Often there may be separate "2G" and "5G" configurations. We have grouped them in this introductory example for simplicity however "2G", "5G", "5G-lower", "5G-upper", "6G" are all valid options.
The "name" value is the advertised SSID clients will discover for this access point. Hidden is supported by setting the "hidden-ssid" to true. Which operating mode is determined by "bss-mode". The "bss-mode" is a highly flexible operating parameter to determine "ap", "sta", mesh", "wds-ap", "wds-sta", "wds-repeater" radio modes of operation.
Security of the SSID is determined using the "encryption" section. Many options are possible, in this initial example, a WPA-PSK2 shared key encryption is shown. Lastly, for devices that support, 802.11w protected management frames are defined as optional for this SSID. This may also be disabled or required.
Metrics for wifi-frames will be described next.
Add metrics to our configuration that will help expose state of the Wi-Fi network and its services to the cloud.
Within metrics it is possible to define the interval for sending information to the cloud. Additionally the type of information sent is defined here. In this example configuration there are associated services to interfaces along the way. This included LLDP and dhcp-snooping and wifi-frames.
Within each uCentral device, the agent has a global health check feature that includes memory, cpu, temperature operating states in addition to performing various network and service health tests. The interval at which these reports are sent to the cloud is configured within health.
For all SSIDs that have wifi-frames associated as a service, the listed management frame types will be gathered and sent to the cloud, on each interval.
To assist with fingerprinting and client troubleshooting, dhcp-snooping sends the cloud all current client DHCP and DHCPv6 state.
The final section of the simple configuration example turns on LLDP and SSH where those services were associated to interfaces listed above.
The complete simple configuration file as described in this page may be downloaded here:
OpenWiFi 2.0
OpenWiFi 2.0 data model for device management is based on uCentral.
uCentral is set to become a leading component of OpenWrt, as such will have a diverse, and worldwide developer and support base in open source.
Within the model it is possible to provision or return state for all aspects of an OpenWiFi based device easily structured as a JSON payload.
The complete data model may be found here :
Each device has a Universally Unique Identifier (UUID). For each device, the configuration presented either manually, via the future Provisioning service from OpenWiFi or via a commercial controller generation of provisioning data, the high level relationships of the schema may be understood as follows.
The unique device record has a set of top level configurations. A device is referred to as a 'unit' that may have a Description, Location, TimeZone as example. Each unit may have globals for IPv4 and IPv6 networks that are derived to lower lever interfaces in later generation.
Services and Metrics are associated with logical and physical interfaces. Services enable configuration of features such as LLDP or SSH, rTTY, IGMP, 802.1x, RADIUS Proxy, WiFi-Steering, or NTP and are then associated with Interfaces as desired.
Interfaces define upstream and downstream configuration over both Wi-Fi logical (SSID) and wired physical ports.
Metrics enable visibility to the cloud for numerous states of the device. These are associated per interface and may be sent in 60 second or greater intervals and include Statistics of SSID, LLDP, Clients. Also include Health check reports of device load, network reachability, temperature. To assist with fingerprinting DHCP-Snooping exposes numerous interactions of IP binding to clients. Additionally wifi-frames expose all 802.11 management frames to the SDK Gateway.
It is also possible to configure config-raw elements that will parse direct UCI commands once the device provisioning has been completed by the uCentral agent.
