Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
TIP OpenWiFi 2.0
OpenWiFi 2.0 Minimum Viable Product at the end of July, 2021 enables a cloud native and cloud agnostic Software Development Kit (SDK) with management and deployment support for a wide range of Access Point and PoE network switch platforms.
Zero Touch Cloud Discovery
Firmware Management
User Interface
Device List
Device Reboot
Device LED Blink
Device Remote Packet Capture
Device Configuration
Device Factory Reset
Device Remote TTY shell
Remote Wi-Fi Scan
Associations
UE (Wi-Fi Clients)
Mesh and WDS Clients
MCS, NSS, RSSI, Channel, SSID, Tx/Rx
Device Health Check
Interface Statistics
Device Command History
Upcoming sprint for August includes Dynamic Provisioning service support for template based device configuration.
OpenWiFi 2.0 SDK is deployable as both a Docker Compose or a Helm on Kubernetes model. See Release 2.0 SDK section for installation instructions.
Firmware
Basic Features for OpenWiFi Switching
Passpoint
NAPTR Functionality
Proxy Static Routing
HSP Auth / Acc Service Discovery
Last Resort Proxy
RADIUS OpenRoaming Compliance
External 3rd Party Captive Portal Redirect
Burst Rate Ad-Hoc Telemetry
Static Routing
CS1 Merge - Wi-Fi 6
IEEE802.1d STP Control
Timestamp on Health Check messages
L2 DHCP Relay
Station Association Idle and Session time
SDK
OpenWiFi Provisioning Service
OpenWiFi Inventory Service
Multi Tenant Support
Service Group - Venues
Logical Regions - Entities
TIP OpenWiFi 2.0
All TIP OpenWiFi devices use the same cloud discovery mechanism on initial boot.
OpenWiFi devices ship from factory with a unique device certificate signed by the Telecom Infra Project Certificate Authority.
When a device boots for the first time, or is factory reset, a 'first-boot' process occurs within the device. First-boot initiates a connection over HTTPs to the Certificate Authority requesting the unique device record information. All connections to the Certificate Authority occur over mTLS encrypted session. Devices use their unique certificate identity to authenticate and retrieve the location of the assigned cloud.
Once the cloud location has been learned from first-boot, the device no longer depends on this cloud discovery and will return to the assigned cloud learned from first-boot.
Devices may periodically initiate connection to the Certificate Authority to validate their unique certificate status. This is a normal process involved in mutual TLS security models.
When an operator or end customer seeks to change the cloud associated with their device(s), the value of the cloud stored in the Certificate Authority device record is updated. A factory reset of the device will cause first-boot to re-occur which will then discover the new cloud.
TIP OpenWiFi ODM partners are able to manage device records directly using the Certificate Authority portal. All other users should send an email to licensekeys@telecominfraproject.com to request update of cloud discovery.
TIP OpenWiFi 2.0
Release 2.0 SDK offers a number of ways to consume OpenWiFi. Available as a single Docker for just the uCentralGW or as a set of micro services offering increasing value to consume helps multiple eco-system partners use as much or as little as desired to integrate with or build a commercial product on the TIP OpenWiFi SDK.
Features of the 2.0 SDK at July MVP include:
RBAC based security framework
OpenAPI compliant Northbound
Kafka Message Bus
PGSql HA Cluster
Firmware Manager
Central Logging Dashboard
User Interface
Docker Compose & Helm DevOps Deployment Automation
OpenWiFi 2.0 Devices
When OpenWiFi devices are unable to connect to the cloud during their initial power on from factory, this may be a result of Internet connectivity issues.
Certain WAN connections may require credentials such as a username and password or a mobile configuration or simply static address assignment instead of dynamic.
OpenWiFi 2.0 supports these scenarios. When a device does not have an existing configuration and is unable to contact the cloud for provisioning it enters "Maverick" mode.
For all Wi-Fi devices this means a Wi-Fi network with the SSID 'Maverick' will become available. Association with and logging in to the device will permit initial WAN connectivity to be entered.
After association to the Maverick SSID, open a web browser to http://192.168.1.1
Log into the OpenWiFi device with username: root
and password: openwifi
When the page above is displayed, begin to configure Uplink based on the WAN requirements of the deployment.
If connection uses Point to Point over Ethernet (PPPoE) username and password credentials, enter those values and save.
If the OpenWiFi device has a Cellular connection which is possible on device models with 4G and 5G radios, the network Access Point Name (APN) and PIN will be required. These values are supplied by your mobile network provider.
When dynamic address allocation is not available, static IP address assignment may be required. IPv4 and IPv6 are supported, enter these values with DNS address and save.
Otherwise leave the Uplink configuration to DHCP or cloud defaults.
If under rare circumstances it is not possible to discover the OpenWiFi cloud associated with the device or there is a need to replace device certificates, this may be configured in Settings.
It is possible to reset the device to defaults, or locally update firmware using the commands available from System.
****
TIP OpenWiFi 2.0
Initial Minimum Viable Product Release 2.0 does not include template driven device provisioning, this will be available in the next sprint.
Given many cloud and ODM partners wish to consume the 2.0 reference stack early, some with their own device provisioning logic as part of commercial cloud controllers, the following describes uCentral based management and telemetry, interactions with the OpenWiFi SDK processing provisioning and telemetry data.
OpenWiFi 2.0 follows the uCentral system. Complete data model is available here. Upon discovery of the cloud, a device default or specific configuration is transferred.
All devices are known to the cloud by their unique id and provisioned based on advertised capabilities. Each configuration generates a new unique hash value to ensure as devices report back to the cloud, their configuration state is guaranteed.
If the cloud sends invalid configuration data or the device has insufficient ability to complete the provisioning commands, the error handling process will send this response back to the cloud.
For example results returned to SDK from a device configuration error:
TIP OpenWiFi 2.0
There could be reasons cloud discovery does not complete. These include:
Lack of Internet Connectivity
Device may require additional WAN settings
Network may not be connected to Internet
No Configuration of Cloud in Certificate Authority
Manufacturer may have left this value blank in the device record stored in Certificate Authority
When the cloud can not be automatically discovered, OpenWiFi devices will turn on a local admin web UI made available via SSID "Maverick".
For non-Wi-Fi devices such as PoE access switches, the same cloud location information may be configured using local management interface.
The Maverick UI will support configuring WAN interface parameters, including DHCP, Static, PPPoE, and LTE/5G settings. Please see for details on using Maverick. Additionally the Maverick UI supports direct entry of the cloud for cases when the cloud value has not been supplied during manufacture.
2.4 Repository Information
Access Point Network OS (APNOS)
License: BSD-3-Clause
Openwrt based APNOS: https://github.com/Telecominfraproject/wlan-ap/tree/release/v2.4.0
Controller SDK
License: BSD-3-Clause
Provisioning Service:https://github.com/Telecominfraproject/wlan-cloud-owprov/tree/main
Testing
License: BSD-3-Clause
Open Test Harness and Test cases: https://github.com/Telecominfraproject/wlan-testing/tree/master
SDK Load Simulator
License: BSD-3-Clause
OpenWiFi Load Simulator (OWLS): https://github.com/Telecominfraproject/wlan-cloud-owls/tree/main\
Deployment
License: BSD-3-Clause
Helm and Docker Compose Deployments: https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/tree/release/v2.4.0