TIP OpenWiFi supports Wi-Fi 5 (802.11ac), Wi-Fi 6 (802.11ax) and Wi-Fi 6E (6GHz 802.11ax) in a mix of indoor and outdoor, ceiling to wall, desk, pole and strand environments.

For TIP OpenWiFi, a mix of ODMs deliver a diverse portfolio including CIG, Actiontech, EdgeCore, Cybertan, Arcadyan, Wallys, Lindsay, HFCL and Inventum.

Currently supported hardware

The list of supported hardware continues to grow. TIP members can access the Confluence site that lists all currently supported hardware.

Supported OpenWiFI AP Hardware

To access the list of supported hardware and other important information on the member's Confluence site, become a TIP member.

Established in Q42019, the TIP OpenWiFi solution goal has been to break vendor lock-in through disaggregation architectures, open APIs—with common embedded software and management that is both community- and commercially-supported.

Available for use as a completely Open Source reference, ODM vendors can easily adopt TIP OpenWiFi platforms as either a complimentary addition to hardware offers or as an entirely TIP OpenWiFi based hardware offer.

Vendors and operators can use the community project as a complete solution, extend the software stack based on design goals, or use only the components desired for deployment. The OpenWiFi community includes hardware ODM vendors, software DevOps, OEM, and System Integrators.

For more information on Telecom Infra Project and the Open Converged Wireless - OpenWiFi initiative please visit:

TIP OpenWiFi is a community-developed, disaggregated Wi-Fi software system, offered as free open-source software that includes a cloud SDK and an enterprise-grade Access Point (AP) firmware, designed and validated to work seamlessly together.

Contribute to the project

Membership to the TIP OpenWiFi project is free with the request to contribute as code, test, documentation or deployment. Participation and focus is governed by the PG Charter, Antitrust Guidelines and IPR Policies.

Meta Connectivity, is a PG champion of TIP OpenWiFi. All source code in the program is subject to BSD-3 license and in the public domain. No internal Meta tooling or IP is involved in the project.

Membership has its privilege

To contribute to the project, you must become a member of TIP and the OCW PG.

After you become a member, you can access the following resources:

• OpenWiFi project WiKi in Confluence

• Development information in JIRA

• Team collaboration and communication via TIP Slack

• Team meetings

The TIP OpenWiFi group holds regular meetings with Meta Connectivity Development team members with stand up calls every Monday. PG member meetings are monthly on first Monday.

To order OpenWiFi APs, be sure you're a TIP OpenWiFi member and then contact ODM manufacturers who participate in the TIP OpenWiFi eco-system. AP vendor contact information is listed on the pages.

If your organization is not already a TIP Open Converged Wireless Project Group (OCW PG) member, consider signing up. Joining the OCW PG is free as a Software Participation Tier in TIP.

For more information please visit:

TIP OpenWiFi enables a turnkey-from-factory experience for the managed Wi-Fi ecosystem.

As a TIP member, an ODM or OEM can offer a TIP SKU direct from the factory. This opportunity has numerous advantages including scale of supply, ease of distribution, partner branding, and use of standard software including device certificates direct from your factory.

Step 1 : Join

If your organization is not already a TIP Open Converged Wireless Project Group (OCW PG) member, consider signing up. Joining the OCW PG is free as a Software Participation Tier in TIP.

For more information please visit:

Step 2 : Slack, Keys & Atlassian Tools

Introduce your organization to the Community on Slack. All Community members have access to Telecom Infra Project Slack. Send a message to "general" and "open-wifi-ucentral" channels.

Send an email to licensekeys@telecominfraproject.com to request onboarding as a supplier for OpenWiFi SKU devices.

Ensure your GitHub account was linked in your Telecom Infra Project user profile, this will enable write access to OpenWiFi repositories. Also confirm Atlassian link is also present in user profile.

Step 3 : Build your device profile

Devices follow standard Linux patch process for enhancements and bug fixes. A development branch should be defined, perform work necessary to add support for the new device including a new profile for the build system.

Test your work locally, when confident push and submit a pull request for the next branch.

Follow the guidance posted:

Step 4 : Submit Device for Community Lab Testing

To obtain access to TIP OpenWiFi support and regression, devices must be sent to the Community Test Lab for QA sanity automation. A formal process for obtaining a TIP OpenWiFi Logo mark will be launched in 2022.

Summary

If the pull request review is successful the new device will be merged.

When an ODM or OEM device vendor has been onboarded with license keys, the device will be included in nightly builds.

What is OpenWiFi?

TIP OpenWiFi is an open source community project that believes in democratizing premium Wi-Fi experiences for multiple market use cases. The TIP approach to OpenWiFi creates an open source disaggregated technology stack without any vendor lock in.

Features normally only present in commercial enterprise WLAN offerings are available in TIP OpenWiFi. These premium Wi-Fi features enable a number of market solutions for developers, integrators and operators to explore.

TIP OpenWiFi stack enables commercial integrations via cloud native open source services for management and network visibility combined with an open source AP firmware operating system tested nightly.

TIP OpenWiFi Continuous Integration quality testing runs nightly exercising thousands of Wi-Fi performance, conformance and feature unit tests.

Support for a broad range of device platforms with the ability for Community to contribute additional device support and or cloud features sets TIP OpenWiFi apart from all other open projects.

Joining TIP and the OpenWiFi project is both free and easy.

Learn more here: https://telecominfraproject.com/openwifi/

Getting Started

The most common use cases for TIP OpenWiFi are managed WLAN most often associated with premium enterprise Wi-Fi service offerings. TIP OpenWiFi presents these premium features over a number of deployment options.

TIP OpenWiFi devices have management and telemetry exposed via a single websocket to the OpenWiFi Gateway (OWGW) microservice. The OWGW is supported by database, message bus, and the OpenWiFi Security (OWSEC) microservice for northbound API integration. This represents the minimum to deploy TIP OpenWiFi.

This minimum set of services enables commercial vendor integration adding TIP OpenWiFi device support to existing Wi-Fi controllers.

Refer to the sections on SDK Installation and Overview for further information.

For additional value added services, TIP OpenWiFi also provides User Interface, Firmware Management, Provisioning and Analytics services. All services are independently deployed and integrated based on commercial adoption model.

See Developer Resources for API level information and Code Repositories for source code guidance.

High Level Features

Each OpenWiFi AP offers:

• Multiple topologies including :

  • Local Breakout

  • Overlay including PPPoE, L2TP, L2oGRE

  • IEEE802.11s Mesh and Wireless Distribution System

  • Bridging, Virtual LAN, VxLAN, NAT Gateway

• Multiple authentications including WPA, WPA2, WPA3, Enterprise Radius models, M-PSK

• Passpoint R1 and R2 Mobile Offload

• Encrypted Zero Touch Provisioning and Cloud Discovery

• Autonomous RRM and Channel Control

• Wi-Fi Agile Multiband

• Multi-VAP including topology features per VAP

• Dynamic Air Time Fairness

• Over the air EDCH QoS, WMM QoS, 802.11-2016 Enterprise QoS

• Captive Portal

• Station and Network Telemetry

Cloud SDK in OpenWiFi offers:

• Zero Touch Provisioning & Discovery

• Integration Northbound Interface (NBI) RESTful

• Data model driven OpenAPI design

• Enterprise Message Bus data access

• Cloud Native & Agnostic micro services

  • Gateway Southbound

  • Security Northbound

  • Firmware Management

  • Web User Interface

  • Provisioning

  • Analytics

OpenWiFi AP Detail List:

• Wi-Fi 5 (ac) Wi-Fi 6 (ax) Wi-Fi 6E

• Dual Bank Bootloader

• Multi-SSID per Radio

• SSID Authentications: WPA/WPA2/WPA3 - Mixed, Personal, Enterprise

• 802.1Q VLAN per SSID

• 802.1d Bridge Mode per SSID

• RADIUS Accounting, Interim-Accounting, NAS-IP, CUI

• Network Address Translation Gateway Mode Operation

• Network Time Protocol Client

• Management VLAN

• Wi-Fi 6 (ax) Specific

  • BSS Coloring

  • UL/DL OFDMA sub-carrier allocation

  • Channel Switch Announcement

• Wi-Fi General Features

  • WMM® - Wi-Fi Multi Media

    • UAPSD Procedures (Unscheduled Power Save)

    • Upstream/Downstream Queues & L3 DSCP

    • Over The Air QoS EDCH Procedures

• WMM-Admission Control (AC)

• WMM-Power Save (PS)

• Wi-Fi Optimized Connectivity

  • (ai) Fast Initial Link Support

• Wi-Fi Agile Multiband

  • (k) Client Radio Resource Management - Directed Steering

  • (v) Network Assisted Roaming

  • (r) Fast BSS Transition

• Protected Management Frames (PMF)

  • (w) Management Frame Encryption

• Channel Switch Announcement (CSA)

• Dynamic Frequency Selection & Transmit Power Control (DFS/TPC)

• Beacon Rate

• Min Client Noise Immunity

• Basic Rate Control

• De-Auth RSSI Control

• Burst Beacon Support

• Per SSID Client Rate Limiting

• Promiscuous Mode Support

• Additional TIP AP NOS Features

  • ISP WAN Profiles ( PPPoE, L2TP, L2oGRE )

  • Embedded Captive Portal (Local Splash non-auth)

  • Link Layer Discovery Protocol (LLDP)

  • Dynamic Airtime Fairness

  • Service Flow QoS

  • Wireline & Wireless Tracing (PCAP Cloud Remote Troubleshooting)

  • Health Check Reports

  • Local Provisioning over SSID (when Cloud or WAN down)

  • Multimedia Heuristics (Detection of Unified Communication Sessions)

  • SSID Rate Limiting

  • GPS Reporting

  • Autonomous RRM Client Steering

  • Client / AP / Network Metric Telemetry

Cloud SDK additional features

• Provisioning

  • Device Identity (Model, MAC, Serial Number)

  • Device Software Upgrade

  • Multiple SSID Configuration

  • Bandwidth Rate Control per SSID

  • Multi-Radio 2.4/5/6GHz control

  • AP Network Mode Control (Bridge/NAT mode)

  • Security (WPA-Personal/WPA & WPA2/3 Personal Mixed/WPA & WPA2/3 Enterprise Mixed/WPA2/3 Personal/WPA2/3 Enterprise/WEP)

  • VLAN per SSID

  • VxLAN port configuration

  • NTP Enable/Disable

  • RTLS (Location Services) Enable/Disable

• RF Control

  • IEEE802.11r Fast BSS Transition per Radio Control

  • IEEE802.11k RRM Radio Information per Radio Control

  • IEEE802.11v Network Assisted Roaming per Radio Control

  • RRM Location AP Channel (uChannel) Provisioning

  • RRM Location Client Steering (uSteer) Threshold Provisioning

• Remote Troubleshooting and Service Assurance

  • Syslog

  • Health Check Reports

    • Remote DHCP, RADIUS, UE Network Analysis

  • Remote TTY Shell

  • Remote Packet Capture Analysis

How to contribute

If you or your company are interested in contributing to TIP Open Wi-Fi, please join the Wi-Fi Product Group by visiting Telecom Infra Project to become a member.

The OpenWiFi SDK is designed to enable Cloud Partners to consume basic southbound device management and device discovery. This is similar to augmenting a southbound device adapter for many orchestration or automation systems.

OpenWiFi Microservices

The OpenWiFi SDK also offers microservices for Cloud Partners including the following:

• Firmware Management

• Device Provisioning

• Subscriber Portal

• Analytics

• User Interface

This independent microservice approach has numerous advantages including ease of integration, ability to leverage more of the stack to accelerate product availability or support only device communication and discovery for partners who seek to maintain more functionality within their own application.

Step 1 : Join

If your organization is not already a TIP Open Converged Wireless Project Group (OCW PG) member, consider signing up. Joining the OCW PG is free as a Software Participation Tier in TIP.

For more information please visit: Becoming a Member

Step 2 : Slack, Keys & Atlassian Tools

Introduce your organization to the Community on Slack. All Community members have access to Telecom Infra Project Slack. Send a message to the #general and #open-wifi-ucentral Slack channels.

Send an email to licensekeys@telecominfraproject.com to request onboarding as a supplier for OpenWiFi Cloud. All OpenWiFi Gateway services in the SDK require a signed key to terminate incoming device connections in the southbound interface.

Ensure your GitHub account is linked in your Telecom Infra Project user profile. Linking your GitHub account to your TIP user account enables write access to OpenWiFi repositories. Also confirm that the Atlassian link is also present in your user profile.

Step 3 : Integration

The OpenWiFi SDK uses OpenAPI 3.0 compliant northbound Rest API and Kafka for message bus topics. Typical CRUD actions occur via the Rest API. Kafka presents topics for device discovery and all telemetry captured from the network edge.

Please consult the API topics to begin with integration work.

Summary

Integrations that use the published interfaces are the easiest approach to starting with OpenWiFi SDK.

As a Cloud Partner who intends to contribute a new SDK microservice, please announce the idea on the #general and #open-wifi-ucentral Slack channels for the Community to provide feedback. There is a skeleton microservice example to help you build new services that inherit the SDK service discovery and security design. For more information about building a service, see the API section in the Developer Resources section. An example used for building a service is located in GitHub.

Our community feature intake process is outlined here.

These feature backlog are then used to create release buckets. Our community release planning is outlined here.

You can extend deployment opportunities using third-party integrations with the TIP OpenWiFi SDK. For example, with third-party integrations, you can create a controller of multiple services. The services can include device provisioning, firmware management, network management, service assurance, subscriber authentication, captive portal services, IoT and amenity networks all commonly deployed across the MDU market. All of these traditional functions are supported in part by the OpenWiFi API and Telemetry data from the OpenWiFi SDK.

Integration by Vertical

Service Provider Access

The simplest SDK integration is to integrate operator OSS/BSS systems for device provisioning, firmware management, and telemetry reporting.

In this scenario, the operator back office systems including and not limited to assurance and monitoring, inventory management and billing systems, will integrate with the OpenWiFi API and message bus interfaces of the SDK.

In service provider access, commonly non-fixed subscribers are served using the same technologies present in WLAN Controllers however the network may be provisioned to direct such traffic to stand alone appliances or applications including authentication (AAA) and walled garden / captive portal systems. TIP OpenWiFi systems support such variations.

TIP OpenWiFi is a local-breakout based approach therefore user traffic is not multiplexed through the SDK, the native local network provides access for the provisioned and billed use. For operators who do wish to aggregate subscriber traffic to a Wireless Access Gateway (WAG) the AP NOS has multiple network encapsulation options to choose from.

WLAN Controller

WLAN controllers typically expose network visibility, subscriber management including authentication, roaming and RRM control, visualization of per Wi-Fi client performance including client session information, client session throughput, client session quality. Most controllers will implement some SON functionality where managing RF resources and channel planning are provided centrally at the controller and pushed across the managed WLAN.

While TIP OpenWiFi is a local breakout enabled solution, vendors who wish to aggregate all subscriber traffic through the WLAN Controller should provision the use of one of the AP NOS supported network encapsulations.

Network Access Controller

Another model that is found in venue, enterprise and some service providers is a Network Access Controller (NAC). The NAC often appears as a decoupled controller where service assurance is less visible such as SON or RRM with focus instead on security, captive access, authentication of nomadic and or BYoD (Bring Your own Device) control.

In scenarios where the deployment is a venue, hotspot or service provider, the NAC will also offer a payment gateway enabling the solution to monetize network access. Common to the NAC solution is the ability to manage various headless devices, IoT elements, and provide DPI (Deep Packet Inspection ) capabilities based on knowledge of the Wi-Fi client, device type, how it authenticated and from where in the network it currently resides. These systems may be inline or more preferably out-of-band based and in the latter is where integration to the SDK is intended for synchronizing provisioned Wi-Fi devices via the SDK with authentication and security offerings of the NAC platform.

Device provisioning occurs through the SDK, which in turn includes provisioning of Virtual Access Point (VAP) to direct authentication to the NAC. Subscriber device authentication traffic arrives at the NAC which manages this according to the operator defined policies. In the case of a captive portal, NAC systems typically include portal redirection that may be WISPr based, or Coova based and some may include Passpoint support.

Integration by Partner

TIP OpenWiFi has a diverse and rich ecosystem of members who solve a number of operator deployment and subscriber service challenges. In each of these cases and for any integrator, all the types of SDK integration are possible via APIs and message bus paths.

JoinDigital

JoinDigital is an MDU Managed Service Provider. Within the JoinDigital portfolio are Small Medium Business (SMB) customers served as part of an MSP for the entire building. JoinDigital offers all the services a building requires including security, amenity networks, IoT integration, subscriber / tennant vlan management, hotspot services for common areas and more.

JoinDigital is an example of an MDU managed service provider who leverages their own OSS/BSS systems much the way a service provider would provide broadband provisioning of subscriber services. As such, JoinDigital integrated their existing billing, network management, assurance and inventory with the SDK directly.

Indio Networks

Indio offers a diverse range of wireless network solutions for service provider and venue operator markets. They serve markets worldwide for Wi-Fi management, hotspot and IoT solutions.

Indio WiOS cloud platform was integrated with the SDK to bring device provisioning, firmware management and telemetry into the WiOS cloud management platform. This enabled Indio to simultaneously offer support for their own hardware devices running OpenWiFi in addition to the full range of platforms available via all the ODM partners, all possible from the WiOS interface. In this model Indio appears to OpenWiFi as a disaggregated WLAN Controller when integrated to the SDK offering a variety of wireless features.

EdgeCore

EdgeCore provides a WLAN Controller that is more closely aligned to the enterprise or venue market. There are features such as hotspot enablement, and built-in subscriber authentication with strong focus on Wi-Fi quality both in AP device and subscriber client device. Dashboards offer strong service and network management capabilities with integration to the SDK at the device provisioning, firmware management and telemetry level.

Lindsay Broadband

Lindsay Broadband is a direct supplier to the Cable MSO industry. A strong focus on outdoor wireless and wireline products, Lindsay has been enabling Wi-Fi in particular from the Cable MSO aerial strand for years. As the Cable MSO exhibits the service provider model of OSS/BSS integration to device provisioning, it has been simple for Lindsay to define a solution using just the SDK with support from the ecosystem.

The cable strand device has been hardware engineered to include a TIP OpenWiFi industrial based board offering Wi-Fi services for venues and mobile offload use cases.

Lindsay is currently manufacturing several dozen strand based devices for their customer trials of OpenWiFi.

For the Cable MSO deployment, the MSO OSS/BSS system is involved from the standpoint of network management and device provisioning integration to the SDK. The MSO may complement the subscriber management and services offered by adding NAC style out of band captive portal systems integrated via the SDK in addition to enabling OpenRoaming and Passpoint services for mobile offload and secure client access.

The TIP OpenWiFi SDK supports multiple hardware platforms for Wi-Fi and PoE switching. Commercial controllers are also integrating the OpenWiFi SDK with their go to market offers. This presents great opportunities for many operators. A full SDK for those who seek to work directly with the Open Source project to a full commercial vendor - operator model.

The OpenWiFi SDK provides a web UI for OpenWiFi administrators. The OpenWiFi UI shows all running services and configurations You can optionally show provisioning, management, and analytics for active deployed networks. All device interactions occur southbound using the OpenWiFi Gateway service. The Gateway implements the uCentral interface standard.

Subscriber self care is possible at a per-end-customer level. This provides an end-customer a view of their own premises with the ability to configure common settings of their devices.

All inter-service and NBI relationships are OpenAPI 3.0 compliant.

You can integrate OSS/BSS (Operations Back Office Support Software) systems with the OpenWifi SDK as a high performance provisioning and device management system.

Device Dashboard

The SDK dashboard shows all devices deployed, their current state, and simplified reports of overall device health.

Given many cloud and ODM partners wish to consume the 2.x 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.

Device Interactions with SDK

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:

"results": { 
  "serial": "aabbcc00120a",  
       "status": {    
          "error": 0,  
                "rejected": [   
                             "[W] ("A Reason will be given"
                             ],

Access Point Firmware

License: BSD-3-Clause

• Openwrt based APNOS:

• ucentral schema:

• ucentral client:

Controller SDK

License: BSD-3-Clause

• Gateway Service:

• Gateway UI:

• Security Service:

• Firmware Service:

• Provisioning Service:

• Provisioning UI:

• Analytics Service:

• Subscriber Service:

• RRM Service:

Testing

License: BSD-3-Clause

SDK Load Simulator

License: BSD-3-Clause

Deployment

License: BSD-3-Clause

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.

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.

Using Maverick

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.

Manual Redirector and Certificate Upload

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.

System

It is possible to reset the device to defaults, or locally update firmware using the commands available from System.

****

Release 2.x SDK offers a number of ways to consume OpenWiFi. Available as a single Docker for just the uCentralGW or as a set of microservices 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.

Initial features of the 2.0 SDK at 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

The TIP OpenWiFi SDK micro services and the AP network operating system (AP NOS) firmware enable many use cases. With TIP OpenWiFi, the entire 'stack' from the cloud to the firmware can be consumed—lowering the cost of entry and time to market of a new entrant.

TIP OpenWiFi architecture works specifically to enable choice in device and cloud. Multiple operators have indicated legacy lock in models present with enterprise WLAN systems are lowering deployment velocity, limiting innovation and introducing artificial barriers to new market use cases.

Ensuring lock in is not present is not enough for a mass market solution. It is also necessary to provide customer choice in the cloud whether that customer is the operator or an end user.

TIP OpenWiFi offers choice in cloud provider of managed Wi-Fi services. Deployed OpenWiFi based APs initially connect to the internet, dynamically determine the management cloud that will control their operation. If at a later stage it is desired to change the management cloud provider to another operator, OpenWiFi base devices may be redirected to any other TIP OpenWiFi ready cloud.

This enables multi-vendor device and cloud options given TIP OpenWiFi architecture of common data model and interface for provisioning and telemetry with mutual TLS security.

Cloud or On-Premises

As operators of many sizes, service and network complexities require more Open Source options in their production environments, TIP OpenWiFi presents the opportunity to deploy managed Wi-Fi services either from the cloud or on premises.

Security

In the TIP OpenWiFi solution, all devices may be registered to any TIP OpenWiFi cloud. This is achieved using a unique certificate per device and a first boot process that discovers the serving cloud for the device. TIP works with Digicert, the industry leader in digital security signing infrastructure to ensure a globally redundant and available registrar for TIP OpenWiFi members. The presence of these unique device trust certificates enables a variety of advanced Zero Touch features beyond discovery including device provisioning, mesh, and wireless distribution link onboarding and more.

Quality and Development—Continually

The OpenWiFi team implemented a Continuous Integration / Continuous Deployment (CI/CD) development pipeline that integrated feature development with continuous builds. Recognizing a large factor for operators is the break-fix cycle common in network vendors, OpenWiFi continuous builds are automated into a Quality Assurance (QA) pipeline.

At this time, 1,500 nightly tests exercise sanity for all builds of AP NOS and the cloud SDK across the majority of OpenWiFi hardware portfolio.

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 :

Organization

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.

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.

Release 2.6 SDK includes:

• Zero Touch Cloud Discovery

• Firmware Management

• Venue Provisioning

• Analytics Aggregation

• Venue Dashboards

• User Interface for Provisioning & Analytics

• Gateway Service - RADIUS Proxy

OpenWiFi 2.0 SDK is deployable as both a Docker Compose or a Helm on Kubernetes model. See section for installation instructions.

Find out what is in our current release.

Access Point Firmware

The Access Point firmware for all supported devices are built on every pull request to the wlan-ap repository. Please see this github workflow for current supported devices:

These images are then pushed to jfrog in each device specific target directory:

Controller SDK

The SDK micro-services are built on every pull request on their respective repositories. These images are then containerized and pushed to jfrog here:

NOTE: For additional details on CI&CD and Testing pipelines please click .\

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.

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.

Gateway

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.

Entities represent a collection of resources for which certain business logic rules apply.

Entities may hold:

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.

Start with Location and Radios

We will set the unit location and timezone, then proceed to configure radios.

{
    "uuid": 2,
    "unit": {
        "location": "TIP Lab Network",
        "timezone": "EST+5EDT,M3.2.0/2,M11.1.0/2"
    },
    "radios": [
        {
            "band": "5G",
            "country": "CA",
            "channel": "auto",
            "channel-mode": "HE",
            "channel-width": 80,
            "require-mode": "HT",
            "rates": {
                "beacon": 6000,
                "multicast": 24000
            }
        },
        {
            "band": "2G",
            "country": "CA",
            "channel": 11,
            "channel-mode": "HE",
            "channel-width": 80,
            "require-mode": "HT",
            "rates": {
                "beacon": 6000,
                "multicast": 24000
            }
        }
    ],

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.

Interfaces

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.

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "services": [ "lldp", "dhcp-snooping" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            }
        },

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.

Common Config - VLAN on WAN for SSID

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.

           {
                "name": "WAN100",
                "role": "upstream",
                      "services": [ "lldp", "dhcp-snooping" ],                
                "vlan": {
                    "id": 100
                },
                "ethernet": [
                    {
                        "select-ports": [
                            "WAN*"
                        ]
                    }
                ],

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.

            "ssids": [
                {
                    "name": "TIP OpenWiFi",
                    "wifi-bands": [
                        "5G", "2G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWiFi",
                        "ieee80211w": "optional"
                    }
                },
                "services": [ "wifi-frames"]

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.

Sending Data

Add metrics to our configuration that will help expose state of the Wi-Fi network and its services to the cloud.

    "metrics": {
        "statistics": {
            "interval": 120,
            "types": [ "ssids", "lldp", "clients" ]
        },
        "health": {
            "interval": 120
        },
        "wifi-frames": {
            "filters": [ "probe",
                "auth",
                "assoc",
                "disassoc",
                "deauth",
                "local-deauth",
                "inactive-deauth",
                "key-mismatch",
                "beacon-report",
                "radar-detected"]
        },
        "dhcp-snooping": {
            "filters": [ "ack", 
                                    "discover", 
                                    "offer", 
                                    "request", 
                                    "solicit", 
                                    "reply", 
                                    "renew" ]
        }        
    },

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.

Global Services

The final section of the simple configuration example turns on LLDP and SSH where those services were associated to interfaces listed above.

    "services": {     
        "lldp": {
            "describe": "TIP OpenWiFi",
            "location": "LivingLab"
        },
        "ssh": {
            "port": 22
        }
    }
}

The complete simple configuration file as described in this page may be downloaded here:

Within a Venue, devices inherit the sum of Configurations present in the Venue, and Entity structure holding the Venue matching their device type.

Within the example Venue, creating configuration templates for SSIDs and or other configuration sections are possible. These configurations are inherited by device memberships at the Venue level.

It is therefore possible to define many Venues, Child Venues, and Inventory associations that will then inherit global templates from entities in addition to aggregation of Venue templates.

The latest release includes the following new features.

Version: v2.10.0

Date: June 30, 2023

What’s New:

• APNOS

  • Schema: Roaming “Auto” support

  • 5.4 Kernel/Firmware Update

  • Dual Boot: pstore/pmsg support

  • Schema: cpu statistics added

  • Advanced Captive: Multiple captive SSID support

• SDK

  • Device Table Enhancements

  • Support viewing and searching radius client

  • Radius Accounting Stop support when AP is disconnected from controller

  • OWLS○support for concurrent simulations

  • support latest state message

The OpenWiFi solution can be applied to a diverse number of use cases from enterprise networks, service provider access, and hotspots. OpenWiFi offers a variety of managed services from small to very large venues of roaming, client shared-key management, client steering, mobile offload, QoS-based services, and Layer 2 and Layer 3 breakout and overlay options.

The Provisioning service provides a view into the network as a whole, and venues with entity-based control.

The provisioning service for OpenWiFi supports weighted order inheritance of configuration templates. These services and networks provide the greatest level of flexibility.

The system functions from a starting point of managed inventory assigned into entities, venues and optionally end subscribers. From this association, inheritance of entity, venue and subscriber configuration becomes possible where one to many configurations are processed including one to one when an inventory device such as a P2P link or Subscriber Gateway have unique operating data.

These features are present from the service over the web interface as well as via API for controller integration and OSS/BSS integration purposes.

With template inheritance, the aggregate of all inherited templates in the device association to Entity, Child, Venue, Child, Device Specific is possible. Overlapping configuration is controlled by the inherited template weight.

Entities

Initial deployment of the Provisioning service will have an empty Entities tree. The Top Entity may be used for a number of actions or simply as a description for structure below this level.

For example, an operator may choose to simply rename this Top Entity as "Operator Name" and set Firmware Upgrade and RRM policies to no actions accordingly. Creating child entities from this point defining perhaps an operational break down such as divisions within the operator, within which setting Firmware and or RRM rules may apply per division is possible.

Release 2.0 user interfaces (UI) are designed as a Single-Page Application (SPA). The UI serves as an example user interface built using React to demonstrate several interactions using the northbound OpenAPI. Release 2.0 to 2.5 had a first generation of the UI framework. This first generation UI framework is seen for the Gateway and Firmware service. With the introduction of 2.6 and the Provisioning and Analytics services, a new UI for those specific SDK services has been introduced.

All UI interactions consume the OpenAPI of the SDK services.

The following describes the likely starting point for an Administrator. Using the Provisioning service to define how the Wi-Fi networks in Entity, Venue and device provisioning terms may optionally be defined.

Login to OpenWiFi SDK - Provisioning

Default username is: tip@ucentral.com and password is: openwifi

On first login, the default user account will prompt to change password. This behavior is also available for all admin defined accounts added to the system.

Base Navigation

On initial login the Provisioning service places the user on the Inventory screen.

Inventory enables the admin to visually identify OpenWiFi devices not currently assigned to an Entity, Create a new device, execute commands per device, inspect device details and view the device active state as shown in the Gateway service.

Device Actions

View Details

Within Device Details, found via the magnifying glass per Inventory row, association to an Entity Parent is possible. Additionally setting the device Firmware policy to inherit the rule assigned based on its membership to a Parent and to require Release Candidates or permit any nightly build upgrade to apply. Additionally the device may be enrolled within RRM should its Entity and Venue membership be part of RRM processing. Device Class determines if the device should be restricted to an Entity, Venue, and an end Subscriber.

Device-Specific Configuration will expose any overriding configuration data present for this specific device. Device specific configuration will override inherited configurations from lower priority templates.

Computed Configuration will display the enumeration of all provisioned templates the device is associated with. These templates are inherited as a result of device membership within an Entity, Child Entity, Venue and or Child Venue from which configuration templates may have been defined based on the admin deployment.

Bulk Inventory API

The service API could be used to bulk load record formats in a common .csv structure using JSON. For example

```

"SerialNumber",Name,Description,DeviceType,NoteText for example: d1300f7b0732,Manufacturer,Desc, edgecore_spw2ac1200,OutdoorAP

```

For each inventory record, the ```deviceType``` must match a valid OpenWiFi device type. For example:

```

"deviceTypes": [ "cig_wf160d", "cig_wf188", "cig_wf194c", "edgecore_eap101", "edgecore_eap102",

"edgecore_ecs4100-12ph", "edgecore_ecw5211",

...]

```

When inventory is assigned to a Venue, it can be allocated into a top-level parent such as the operator. Then, based on role access, operation's teams may choose to assign the device to a child entity within an operating division, or setup the device as a tenant of a managed Wi-Fi service for example.

Choosing to assign the device to a specific MDU location as an example can be done in one step from above.

A common example is to inherit the desired telemetry for all devices spanning all types, at a top level.

It remains possible to override the values shown here, perhaps to a faster interval, for the required telemetry data defined at the top level.

Create Configuration

Create a general configuration, select Metrics as the Configuration Section.

Within the Subsections select all metrics types to be included and a weight for this template.

Available metrics:

Device provisioning occurs based on inventory association to configuration templates.

Creating a template begins with the Configurations tab and creating a new template.

Create

Create Configuration dialog requires a name and one or multiple device types to apply configuration with. If device inventory within an Entity or a Venue exist with no configuration templates matching Device Types of the associated inventory, no associated provisioning will apply to those devices. This is the basic logic that enables unique Wi-Fi device type configurations to be layered through the system.

Limiting the configuration to a subset of device types is done through selection of available Device Types via pull down menu.

A possible scenario may be that at such a top level, the operator wishes to set transmit power, MIMO operation where the Wi-Fi 6 2x2 top level configuration is defined.

To include configuration parameters, select Add Subsection and choose the appropriate values.

In this example we will choose Radios and define the MIMO and Tx Power.

Begin with describing the Radio operating mode, assign a weight that may be either low enough to be overridden by further entity or venues or high enough to not be overridden, then Add Radio.

OpenWiFi supports all possible Wi-Fi radio bands. Select the desired radio(s) and continue.

Radio General

General properties, the following may be configured:

Radio Advanced

Advanced Settings, the following may be configured:

When complete, Save the "Top Level Wi-Fi 6 2x2" configuration for the device types chosen that align to such a radio mode.

Inheriting Advanced Radio Configuration

For purpose of demonstration, if the admin were to create another Configuration template with the same weight as the previous template defining the Advanced parameters, these could then be broken down for example by device type.

Create another template as described for only one of the Wi-Fi 6 2x2 APs we have shown thus far.

Setting specific configuration for the EAP 101 advanced radio parameters. For example, if a device in this entity is an EAP 101, it will have advanced radio properties of 12Mb/s beacon rate, 24Mb/s multicast rate, random BSS color and require HE mode.

With these settings saved, multiple configuration templates are now shown that will influence radio operating parameters equally yet separately based on device type.

Venues are an important concept in OpenWIFi Provisioning. Venues inherit access to Analytics where incoming telemetry and client events are aggregated from the message bus, transformed and correlated based on the members of the Venue resulting in Venues Dashboard, Live Client quality connection analysis, and client tracking through the venue.

Create a Venue

Within a non-root entity, Create a Venue.

Once the Venue exists, navigate into the Venue.

Venue Configurations

Within a Venue, the RRM and Firmware management rules may be defined. Note Analytics are now an available option within the Venue. To track device and client statistics, enable Analytics.

Choose Edit and Start Monitoring. This will enable the admin to determine the interval of analytic data aggregation, and the data retention window in days.

When Analytics are enabled, the Dashboard is populated. As devices are associated to the Venue, their telemetry data is aggregated by Analytics service and correlated for display via Dashboard, Live View and Client Lifecycle.

Configure WAN interface as an upstream interface role type.

OpenWiFi has the concept of a virtual dataplane where the definition of the interface role as upstream or downstream defines if the port involved will be mapped to WAN or LAN operation.

It is possible to re-map any LAN port to function as a normal WAN port in this way.

When the above Interfaces configuration section is created, respond to the dialog prompt to define an upstream WAN then select from the available configuration options to suit the local environment.

Within WAN(upstream) select the port(s) for use as WAN.

A variety of Services features may be associated to logical interfaces. For this example, enable LLDP.

IP Addressing set as IPv4 Dynamic will cause the WAN port to use DHCP for its provisioned internet access. IPv6 dual stack is also supported.

The OpenWiFi solution can be applied to a diverse number of use cases from enterprise networks, service provider access, and hotspots. OpenWiFi offers a variety of managed services from small to very large venues of roaming, client shared-key management, client steering, mobile offload, QoS-based services, and Layer 2 and Layer 3 breakout and overlay options. The Provisioning service provides a view into the network as a whole, and venues with entity-based control.

The provisioning service for OpenWiFi supports weighted order inheritance of configuration templates. These services and networks provide the greatest level of flexibility.

The system functions from a starting point of managed inventory assigned to entities, venues and optionally end subscribers. From this association, inheritance of entity, venue and subscriber configuration becomes possible where one to many configurations are processed including one to one when an inventory device such as a P2P link or Subscriber Gateway have unique operating data.

These features are present from the service over the web interface as well as via API for controller integration and OSS/BSS integration purposes.

Device provisioning is highly configurable and scalable.

Inventory

You can manage device inventory for both assigned and unassigned states. As devices are added to the system, they become available to venues for association and service provisioning.

Each inventory record, regardless of assignment state can be viewed in the OpenWifi dashboard.

Bulk Inventory API

The TIP OpenWiFi inventory service API could be used to bulk load record formats in a common .csv structure using JSON. For example

```

"SerialNumber",Name,Description,DeviceType,NoteText for example: d1300f7b0732,Manufacturer,Desc, edgecore_spw2ac1200,OutdoorAP

```

For each inventory record, the ```deviceType``` must match a valid OpenWiFi device type. For example:

```

"deviceTypes": [ "cig_wf160d", "cig_wf188", "cig_wf194c", "edgecore_eap101", "edgecore_eap102",

"edgecore_ecs4100-12ph", "edgecore_ecw5211",

...]

```

When inventory is assigned to a venue, it can be allocated into a top-level parent such as the operator. Then, based on role access, operation's teams may choose to assign the device to a child entity within an operating division, or setup the device as a tenant of a managed Wi-Fi service for example.

Choosing to assign the device to a specific MDU location as an example can be done in one step from above.

Creating Entities and Venues

Devices can be assigned to the MDU—which may be an actual venue such as a building or a tenant operator with child venues.

Provisioning Templates

Use the Create Configuration window to create a configuration template for a specific venue or device.

For example, a configuration template for a local area network could include: address translation and local DHCP for on-premises devices, WAN interface with DHCP for IPv4/IPv6 service, and a basic Wi-Fi configuration.

An SSID may be associated to any defined interface. This association ties the dataplane of the VAP together with the underlying interface services.

Most common SSID configuration parameters have been exposed via the Provisioning UI. Consult the OpenWiFi data model for the full list of available configurations.

From an interface select Add SSID.

Assigning the name of the SSID is also the name of the Wi-Fi network itself. Operating band of the SSID is configurable by radio.

SSID Configuration Options

Firmware management service integrates across all OpenWiFi Gateways deployed in a cluster enabling updates to running firmware either from the latest published version, or any other released version.

Dashboard

Firmware dashboard provides a single view for overall health of deployed device firmware. Latest firmware charts, device firmware version distribution, distribution of device by type and current connected devices.

Device Table

From the Devices table, any device with a newer firmware published by TIP OpenWiFi is indicated with a yellow icon. Selecting this icon presents the option to upgrade to latest or specify which firmware to use.

When the upgrade has been sent successfully, a green Success dialog will display in the upper right on the screen. Devices with latest firmware version will show a green firmware icon in the Devices row.

Firmware Management Service

Viewing the contents of Firmware Management Service is available from the left navigation, select Firmware.

Once in Firmware, it is possible to search by device model for all known firmware revisions.

If in the Device Table reference above, instead of selecting Upgrade to Latest, the specific URI location of any available firmware is found using the Firmware table.

Selecting Details will present information for any firmware row, including the URI which may be copied into the Choose Custom Firmware dialog prompt accordingly.

Each device page presents statistics in traffic terms per interface as a line graph of bandwidth over time.

The generated image may be downloaded for offline use.

Accessing Wi-Fi Analysis and Last Statistics may be found at the top right of Statistics tile.

Wi-Fi Analysis

Operating channels, channel width, noise floor and transmit power are the first values reported in Radios table.

Viewing associations, from the Associations table, and their use is important in terms of bandwidth and connection quality. Wi-Fi Analysis helps visualize each client association, this could be an end user device or a WDS or Mesh association.

Each association is known by their MAC address or BSSID value. The mode of connection will indicate if an end user client device entering the "ap" or if a client is associated as "wds" or "mesh.

The access point view of RSSI, Rx and Tx Rate, Modulation Coding Scheme and Number of Spatial Streams are exposed for each association.

Using the slider along the top, the last 15 to 30 minutes of performances data may be viewed.

Latest Statistics

The option to view Latest Statistics is at time of the MVP release, intended to help the Community see on a per device basis how much, or how little depending on device configuration, is being sent to the OpenWiFi Gateway in terms of telemetry.

Multiple events are recorded in the Command History tile. Each line item will have a Result, Details, and Delete action.

When an rTTY session is executed, this is a displayed command history. Selecting the Result icons will display the Success or Fail of the command.

Each provisioning event is reflected as a configure command history. To see the entire JSON payload and the result, including success or error with message, simply select Details to expand the dialog below with this data. A date and time in the third column indicates when the configure command was executed successfully.

If a provisioning event has failed to complete, its command history for configure will show as pending.

Remote packet capture is shown as the trace command history. When packet captures are persisted in the OpenWiFi SDK, they may be downloaded again through the cloud download icon.

Within the devices view, the Commands tile offers a number of features and administrative actions. Each of these represent API calls exposed on the OpenAPI northbound interface from the SDK.

Reboot

Selecting the Reboot action will prompt the below dialog. Options presented permit an immediate reboot or a scheduled reboot based on date and time.

Firmware Upgrade

Multiple methods exist to execute a remote Firmware Upgrade of a device. When selecting Firmware Upgrade via the Commands tile, a simple dialog to upgrade immediately or at a scheduled time is presented. Alternatively using the Firmware Management Service provides a complete solution including managed access to all TIP firmware images.

Wi-Fi Scan

OpenWiFi devices may perform channel scanning and return this neighbor and RF data to the SDK in an on demand or ongoing manner.

Wi-Fi Scan Results

Scan operations function over all channels. If 5GHz channels do not display in the returned results ( either via the UI or over API ) this indicates the device is configured in a DFS channel for which it may not return survey scans at this time.

Connect

OpenWiFi enables remote connection to any managed device using rTTY encrypted shell session. Selecting Connect will cause a browser tab to open with the login session to current device.

Blink

To assist with remote identification of devices in the network, it is possible to turn the LED lights On, Off, of continuous blinking. This may be run on-demand or scheduled.

Trace

Trace feature enables a remote packet capture to occur on the managed device, over a specified period of time or amount of traffic, returning the "pcap" packet capture file locally to the OpenWiFi admin user.

Once complete the user is asked to open or save the packet capture file locally.

Factory Reset

It is possible to revert a device to initial out of box state from the OpenWiFi SDK. Sending a Factory Reset will remove all configuration on the device and optionally reset the discovered cloud stored as the 'Redirector' in the device configuration.

Configure

Prior to the introduction of OpenWiFi 2.0 Provisioning Service, device configuration is done through creation of the JSON provisioning file and either loading that file or applying its contents using the dialog presented via Configure. The same options exist when using the API directly.

TIP OpenWiFi software stack is envisioned to have a rich telemetry data that can be extracted, transformed and stored for analytics purposes. This section will outline various integration using the current capabilities of the OpenWiFi release. These integrations will provide examples for the community to enrich, adopt and productize.

The current release of OpenWiFi utilizes both a rich open API and Kafka for retrieving telemetry information from Access Points and SDK services. For the purpose of this section and Release 2.0 we will be showcasing Kafka integration with 3rd-party monitoring subsystems.

Kafka Data Source

The current release of 2.0 SDK architecture contains a Kafka broker for the purposes inter-services communication, state, healthcheck, device provisioning state producing and consuming Kafka topics. You can find the latest information related to Kafka topics here:

The current Kafka topics used for this monitoring integration are:

• state

• healthcheck

All Kafka messages carry a JSON payload, example of a healthcheck message is as follow:

A state Kafka message looks like:

{
   "system":{
      "id":179033843641952,
      "host":"https://gw-ucentral-dev01.cicd.lab.wlan.tip.build:17002"
   },
   "payload":{
      "serial":"112233445566",
      "state":{
         "interfaces":[
            {
               "clients":[
                  {
                     "ipv6_addresses":[
                        "fe80:0:0:0:206:aeff:fee0:69ad"
                     ],
                     "mac":"07:06:06:06:06:06",
                     "ports":[
                        "eth1"
                     ]
                  },
                  {
                     "ipv4_addresses":[
                        "192.168.4.1"
                     ],
                     "mac":"01:02:03:04:05:06",
                     "ports":[
                        "eth1"
                     ]
                  }
               ],
               "counters":{
                  "collisions":0,
                  "multicast":63,
                  "rx_bytes":14725,
                  "rx_dropped":0,
                  "rx_errors":0,
                  "rx_packets":209,
                  "tx_bytes":13571,
                  "tx_dropped":0,
                  "tx_errors":0,
                  "tx_packets":80
               },
               "dns_servers":[
                  "1.1.1.1",
                  "9.9.9.9"
               ],
               "ipv4":{
                  "addresses":[
                     "192.168.4.33/24"
                  ],
                  "leasetime":600
               },
               "location":"/interfaces/0",
               "name":"up0v0",
               "uptime":31349
            },
            {
               "counters":{
                  "collisions":0,
                  "multicast":0,
                  "rx_bytes":0,
                  "rx_dropped":0,
                  "rx_errors":0,
                  "rx_packets":0,
                  "tx_bytes":1058,
                  "tx_dropped":0,
                  "tx_errors":0,
                  "tx_packets":5
               },
               "ipv4":{
                  "addresses":[
                     "192.168.1.1/24"
                  ]
               },
               "location":"/interfaces/1",
               "name":"down1v0",
               "uptime":31355
            }
         ],
         "radios":[
            {
               "active_ms":24459917,
               "busy_ms":1173593,
               "channel":149,
               "channel_width":"80",
               "noise":4294967198,
               "phy":"soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0",
               "receive_ms":4647,
               "transmit_ms":88272,
               "tx_power":30
            },
            {
               "active_ms":24456321,
               "busy_ms":11878205,
               "channel":11,
               "channel_width":"20",
               "noise":4294967204,
               "phy":"platform/soc/a000000.wifi",
               "receive_ms":1329,
               "transmit_ms":73228,
               "tx_power":30
            },
            {
               "active_ms":24458178,
               "busy_ms":1162312,
               "channel":36,
               "channel_width":"80",
               "noise":4294967192,
               "phy":"platform/soc/a800000.wifi",
               "receive_ms":12339,
               "transmit_ms":86904,
               "tx_power":23
            }
         ],
         "unit":{
            "load":[
               0.190921,
               0.263188,
               0.240726
            ],
            "localtime":1627418941,
            "memory":{
               "free":348540928,
               "total":520409088
            },
            "uptime":31386
         }
      },
      "uuid":1627357625
   }
}

The following pipeline is used to leverage Kafka messages being emitted from OpenWiFi 2.0 for ELK (Elastic Logstash Kibana) stack integration :

TIP OpenWiFi project has deployed an ELK stack for community members to access .

The key for this integration is to use a plugin that enables Kafka to be used as an input for Logstash. This plugin can be found . Once installed then Logstash can be configured to listen to the input source of the Kafka broker that is deployed as part of OpenWiFi SDK 2.0 release and its appropriate topics. Here is a Logstash configuration.

It is important to note that Logstash provides the ability to transform messages which then can be pushed to Elasticsearch for storage with effective indexing. Finally Kibana is used to create visualization such as this:

The wlan-cloud-ucentral-deploy repository contains two packaging options:

• Docker Compose

• Helm

The repository is managed using branches where:

• main branch: contains references to the latest development SDK images

• release/v_X.Y.Z_ branch: contains image references specific to the release artifacts. For example: release/v2.4.0 branch will contain references to SDK images related to 2.4.0 release candidates (RC) and GA.

// Clone the repo (if not already done so)
// The default branch is main.
git clone git@github.com:Telecominfraproject/wlan-cloud-ucentral-deploy.git

// Use either main or release branch. Recommend to use release branch once a release is
// GAed.
git checkout -b v2.7.0 origin/release/v2.7.0

All releases undergo a rigorous amount of testing that include:

• Sanity

• Performance

• RF Testing

• Regression

• Testing with real devices (Interop)

Our current community test result dashboards:

Sanity: http://openwifi-allure-reports.s3-website-us-east-1.amazonaws.com/sanity/overview/

Interop: http://openwifi-allure-reports.s3-website-us-east-1.amazonaws.com/interop/overview/

Regression: http://openwifi-allure-reports.s3-website-us-east-1.amazonaws.com/regression

Performance: http://openwifi-allure-reports.s3-website-us-east-1.amazonaws.com/performance/overview/

RF Testing: http://openwifi-allure-reports.s3-website-us-east-1.amazonaws.com/advanced/overview/

Here are the results of our testing results for our current release.

Here are the security details for v2.8 release.

Here are the outstanding items for this release.

Bug

WIFI-6853 Rate limiting feature is not working with multi-psk

WIFI-6932 Dynamic ATF/ QoS related query to Dev

WIFI-7228 EAP-101: some tx/rx byte counts are showing up as negative

WIFI-10082 Provision UI: Venue level firmware upgrade is not upgrading the device to latest version

WIFI-10245 Microservice internal endpoint auth errors return wrong error message

WIFI-10609 Hostapd gets incorrect wpa value for wpa3-mixed encryption

WIFI-10771 After De-authentication of a station, The status of QBSS is updated approximately after 50 beacon frames

WIFI-10885 QOS: classifier is not working consistently

WIFI-10899 uspot captive service not working on "udaya_a5-id2" AP

WIFI-10957 Gateway service: Statistics graph is not showing accurate data

WIFI-10965 Unable to connect clients with TLS auth method with gw proxy enabled but it works with gw proxy disabled

WIFI-11043 Analytics service got restarted multiple times

WIFI-11143 RADIUS requests are sent to both the RADIUS Servers configured in gw pool at the same time by the gateway

WIFI-11203 Session-timeout configured in the radius for Advanced Captive Portal is not working as expected.

WIFI-11208 Idle-timeout is not working as expected in Advanced Captive Portal

WIFI-11209 External captive portal traffic limit(Quota) is not working as expected

WIFI-11213 WISPr Bandwith-Max-Up and WISPr Bandwith-Max-Down configured in radius are not working as expected in Advanced Captive Portal

WIFI-11214 URL redirection is not happening after authentication. [External captive portal]

WIFI-11238 Multiple Gateway restarts Happening on the v2.7.1-Rc2 image

WIFI-11251 Gateway service: Gateway starts restarting while checking previous statistics on AP

WIFI-11258 Gateway Service: Negative time interval and lesser time interval (1 second) in statistics in metrics is leading to GW restart

WIFI-11294 Prov UI: ieee80211w should be "required" for WPA3 personal and enterprise security mode

WIFI-11299 Radius RateLimit is applying for every SSID

WIFI-11306 Prov UI: There is no option for Key caching under SSID subsection

WIFI-11333 Gateway should be able to rewrite the new RADSEC config applied on the previous configuration

WIFI-11397 Firmwares are not added when we delete and re-add AP through Post man

WIFI-11428 Observing RADIUS Proxy logs though Gateway is configured as RADSEC Proxy

WIFI-11429 Gateway Service: Gateway Restart due to exit code 139 (SIGSEGV)

WIFI-11456 Unable to login to provisioning UI with the verified user credentials

WIFI-11462 OWLS UI: docker builds are failing

WIFI-11464 GW & OWLS UI: UCENTRALSEC endpoint env file is not created

WIFI-11469 Unable to login to gateway UI with the verified user credentials

WIFI-11472 GW UI: crash on unrecognized device type in device table

WIFI-11473 Not able to upgrade the firmware image of AP (903cb36c472a) from TIP-v2.4.0-rc1-a4806f7

WIFI-11474 Some of the options in gateway have the prefix word "common"

WIFI-11475 Naming in gateway login page have the prefix word "common"

WIFI-11491 Prov UI: Access Control List field under the SSIDs is not present

WIFI-11538 Indio AP randomly changing its mac address on the staging images

WIFI-11539 Redirect URL not passed to the external portal from Open Wi-Fi APs

WIFI-11544 Gateway Service: Logs section in GW is recording only reboot and trace commands

WIFI-11545 Event Queue is not showing the buffer the events that happen on the AP

WIFI-11546 DTIM count is not updating as per config code in AP

WIFI-11555 APs using 6G band return State messages with "radio.channel" field as an array instead of a single value

WIFI-11563 Gateway Service: Config push by uploading a JSON file is removed from GW

WIFI-11566 Gateway Service: Copy option is not working for configure in GW

WIFI-11582 Ratelimiting feature is not working on the staging image 0fee3d6

WIFI-11583 Quali Reservation: Unable to reserve Scale testbeds

WIFI-11584 Gateway Service: Search option in devices is not functioning

WIFI-11585 Gateway Service: Unable to set a previously used password for a user in GW

WIFI-11590 Rate limiting with radius feature is not working on the staging image 0fee3d6

WIFI-11594 Gateway Service: Column selection is not happening in Wi-Fi Analysis and Associations tabs in GW

WIFI-11595 Provisional UI displaying configuration successfully pushed for invalid configurations.

WIFI-11599 Gateway Service: Rx NSS and Tx NSS is reporting wrong data in WiFi analysis in GW

WIFI-11648 We don't see the restricted parameters in the capabilities in Gateway for cig-wf188n AP

WIFI-11691 Gateway Service: GW is going to unresponsive state

WIFI-11700 Gateway Service: Unable to perform all the commands from gateway when MAC is replaced with capital letters in the gateway URL.

WIFI-11704 Gateway Service: Unable to delete notes in AP device page

WIFI-11713 Radius cannot be enabled for open security SSID through Provisional UI

WIFI-11723 Advanced Captive Portal is not working on multiple interfaces

WIFI-11724 Advanced Captive Portal not working on NAT mode

WIFI-11730 GW UI: duplicate device statistics API calls

WIFI-11741 ASB: AP is failing to upload the file to GW after triggering bundle script

WIFI-11743 Unable to ping b/w STA's belongs to same vlan

WIFI-11749 Gateway Service: Search bar is expanding out of the page while entering lengthy characters as serial number

WIFI-11750 Prov UI: Changes in configuration are not seen unless the page is refreshed or reopened again.

WIFI-11751 Prov UI: No error is seen when FILS Discovery Interval value is configured above 20

WIFI-11752 Provisioning: Restrictions should be applied on static IP assignment for class D and class E ipv4 networks

WIFI-11754 GW does not remove old uploaded files

WIFI-11755 MicroService Poco library update to 1.12.4 for several security fixes.

WIFI-11760 Gateway Service: Getting lot of error messages after visiting a device page which is left idle for a long time

WIFI-11761 Provision UI: Provisioning is not restricting a config if the static ipv4 address specified is out of range (e.g.: 1234.1234.1234.1234/16)

WIFI-11777 GW returns a bad default default configuration

WIFI-11778 GW reports device as not connected while waiting for statistics

WIFI-11779 GW Shows RunTimException Timeout and may become unstable.

WIFI-11800 Memory leak with ucentral-wifi

WIFI-11803 Prov UI: Allow-DFS option is not present in the Radios Subsection in Provisional UI

WIFI-11804 Frequent disconnections are happening between APs and ucentral GW

WIFI-11824 802.1x RADIUS Unknown attributes

WIFI-11861 Stations associated to AP with mpsk and DVLAN config are not shown up in association list in the gateway

WIFI-11865 GW Trace returns the wrong content-type

WIFI-11866 GW UI: user role fixes

WIFI-11867 FMS Dashboard may cause restart

WIFI-11868 GW UI: firmware dashboard average age is never calculated

WIFI-11871 cig_wf188n AP is overriding any configured country code to US

WIFI-11873 Gateway Service: Logout option is not displayed properly

WIFI-11874 Gateway Service: Size of display page should be increased to full in telemetry results

WIFI-11875 Gateway Service: Need custom timeframe for command history, health checks and logs to load the complete data

WIFI-11876 ASB: Unable to extract tar file after triggering shell script

WIFI-11877 ASB: Unable trigger any other commands upto 10mins after triggering shell

WIFI-11879 DFS is not restricted with dfs:true and developer =0 in env variables

WIFI-11880 Unable to trigger default(diagnostics) script ASB [Error Invalid base64]

WIFI-11881 ASB: Unable to provide signature for diagnostics script [Didn't find userInput box for signature]

WIFI-11882 Error specifying the AP is DFS restricted should only come up for 5G radio but not 2G radio in the Gateway UI

WIFI-11883 With commands: false with developer 0 we are unable to trigger ASB scripts

WIFI-11892 Prov UI: Select Ports option in Interfaces subsection are not configured as per schema docs

WIFI-11906 Prov UI: SSID name length restrictions are not enforced

WIFI-11908 Advanced Captive - active flows do not get purged when session/bandwidth expires

WIFI-11924 Firmware upgrade is not functioning with sysupgrade: true and with valid signature

WIFI-11927 AP stops sending wireless statistics of captive portal authenticated wireless devices

WIFI-11934 The responses from Radius Server are not reaching the Gateway (when the config is changed).

WIFI-11935 MPSK 802.1X access request packet does not contain the NAS-IP-ADDRESS

WIFI-11936 Gateway Service: Unable to open the device in a new tab from device table

WIFI-11956 Gateway Service: RTTY doesn't work if successive sessions are opened on a single AP within less time duration

WIFI-11965 Rate-Limiting Is not working as expected for Multiple SSID's Interfaces In Single radio

WIFI-11966 RRM Service: Multiple restarts are observed on RRM service due to exit code 1 (Application Error)

WIFI-11969 The AP model type is not reported to cloud controller

WIFI-11970 Prov UI: Modification of dtim period from radio attribute to per SSID attribute

WIFI-11974 IPv6 missing on ALB and micro-services interconnect

WIFI-11976 In cig_wf196 AP models, The BSSID of the interface are changing when we reboot to the same applied config.

WIFI-11978 Gateway Service: Channel number is wrongly displayed in wifi analysis tab in device page

WIFI-11980 Could not fetch RRM details

WIFI-11981 GRE : gretap interface silently drops fragmented packets

WIFI-11983 In Cig_194c4 AP model, We doesn't have a latest firmware upgrade.

WIFI-12002 Wireguard tunnel is not setup after reboot

WIFI-12010 OWLS-UI: device types are not selectable when an FMS service is not available

WIFI-12020 Packets drop(More than 40%) between 2G and between 2G to 5G

WIFI-12060 wifi-frame and dhcp-snooping metrics when enabled, AP stops sending state kafka messages

WIFI-12086 metrics stopped reporting after moving from v2.7.2 to v2.8.0

Improvement

WIFI-10560 Add 6G radio support in Subscriber Portal

WIFI-11206 Develop RESTAPIs in the provisioning module to configure VLANs on LAN ports on access points

WIFI-11261 WLAN Security Issues

WIFI-11960 Bring up files for OAP101

WIFI-12013 Update to support version 1.0 of state message

WIFI-12046 Kernel backports from 4.4 for performance

WIFI-12047 Backport vxlan support

WIFI-12048 NAPI Threading patch backport

WIFI-12049 OpenWrt config generation fixes for targets

WIFI-12050 Kernel oops handling using pstore

WIFI-12051 update for ipq60xx

WIFI-12052 update for ipq807x

WIFI-12053 update for ipq50xx

WIFI-12054 edgecore eap104 - BDF update

WIFI-12056 edgecore eap104 - WAN port has no RX

WIFI-12059 CI for supporting builds from a new next branch

WIFI-12061 update hfcl wifi 6 boards

WIFI-12069 test WDS functionality on latest drivier

WIFI-12089 drop Q14 support as there are no active users

WIFI-12270 GW should show the AP is in developer mode or not

WIFI-12377 allow more than one external captive portal definition per AP

WIFI-12378 OWLS: Update to support the latest version of the Health Check message

WIFI-12433 Gateway UI: IP address display when AP is behind a NAT router

WIFI-12435 GW UI: device table column size reductions and standardizations

WIFI-12436 GW UI: add uptime, GPS location and provisioning status columns to device table

WIFI-12437 GW UI: commonly used actions should be available with one click in the device table

WIFI-12474 AP: Add Public IP reporting support in state message

WIFI-12492 PROV UI: Venue/Entity page layout rework

WIFI-12511 BSSID MAC address issue in EAP104

WIFI-12525 2.10 Framework updates

WIFI-12539 Support multiple S3 providers

WIFI-12570 add roaming 'auto' button to data model

WIFI-12571 OWLS UI: theme update

WIFI-12572 Allow a configurable session timeout for APs

WIFI-12573 reduce AP WSS Ping timeout to 60

WIFI-12574 GW UI: theme improvements

WIFI-12575 PROV UI: theme improvements

WIFI-12590 Improve sysupgrade to better cover failures

WIFI-12593 report btime from AP proc stat interface

WIFI-12596 rtty: allow disabling mTLS for backward GW compatibility

WIFI-12603 GW UI: add support for device types which include country codes

WIFI-12610 Add support for APNOS connect reason

WIFI-12612 GW UI: display device connectReason on device table and page

WIFI-12613 GW UI: display reboot logs on device page

WIFI-12614 GW UI: adding VLAN to device statistics display

WIFI-12618 GWUI should show all AP-RC firmware Images all the time

WIFI-12630 Add the ability to delete devices in bulk

WIFI-12651 GW UI: Device FW Upgrade page to include a Toggle Option

WIFI-12660 Prov UI: Add Push Configuration option next the actions drop menu

Bug

WIFI-11723 Advanced Captive Portal is not working on multiple interfaces

WIFI-12019 EAP101: unable to configure more than 8 SSIDs

WIFI-12305 Captive Portal: Radius-Rate-limiting is not applying if the client disconnect and connect back

WIFI-12380 AP stuck in unaccessible/unrecoverable mode sometimes due to inability of loading config json at boot time

WIFI-12419 EAP104: BSSIDs are not derived from eth0

WIFI-12420 API7340: eth0 MAC address doesn't get set properly

WIFI-12461 Unable to restrict AP after reboot: restrictions.json file is not adding in the /etc/ucentral/ folder

WIFI-12500 Bad temperature on edgecore 5410

WIFI-12502 WF196: FTM and qca-diag fail to compile under v5.4 kernel support

WIFI-12505 a number of APs lost connection with the controller while using v2.9.0

WIFI-12507 Device serial number is missing in AP events.

WIFI-12521 multiple APs at same site disconnected from controller and some never recovered

WIFI-12529 EAP102: Scan for short duration makes client lose Internet connectivity

WIFI-12534 2.9.0 AP NOS: Radius Request attribute with Hex value not configurable from controller

WIFI-12538 CIG WF-196 BDF for 6G, CA version is not correct

WIFI-12576 GW, PROV & SIM UI: cache invalidation not working

WIFI-12579 Add OpenWiFi support for Cybertan EWW 631 APs

WIFI-12582 state message doesn't show the vlan interface for dynamic vlan using radius feature

WIFI-12584 Configurations not retained after Firmware upgrade

WIFI-12585 Redirecting to incorrect URL instead of PROVUI from GW

WIFI-12586 Processes hang with CoA DM on RADIUS mac-filter SSIDs

WIFI-12591 cig wf-660a bringup

WIFI-12597 Unable to click and choose Custom option for RRM in Prov UI

WIFI-12600 Not getting all the list of firmwares available for CIGWF196 AP

WIFI-12604 Certificate problems working with a remotely deployed OW Controller

WIFI-12616 CIG WF-186w :Set ethernet/wireless mac address

WIFI-12634 Large number of auto-configuration updates may cause slow GW

WIFI-12639 Not getting crash or reboot logs in the GWUI

WIFI-12640 Some stations get zero throughput on 80+ station upload test.

WIFI-12641 APs Disconnecting and Failing to Renew IP Address

WIFI-12646 EAP101: loses IP address after dhcp lease time expires

WIFI-12648 Port enable / disable does n't work correctly on Edgecore EAP 101 AP

WIFI-12664 Gateway UI showing unordered Firmware Images.

WIFI-12665 Ratelimit with RADIUS is not working

WIFI-12670 Datapath: No ping session / traffic is running between wired and wireless client.

WIFI-12671 Gateway UI: WiFi Analysis Showing Opposite and wrong values(TX/RX) for Upload and Download scenarios

WIFI-12672 ECW5211 AP radio 0/1 interface down after upgrading to 2.10RC1 image

WIFI-12674 some configurations appear to prevent metrics reporting in v2.10-rc1

WIFI-12675 AP is upgrading without signature when sysupgrade: true in the restrictions.json file

WIFI-12676 Not getting state message data If we have valn Interface

WIFI-12689 Uable to push config from GW. Error: 1008: Configuration block type invalid.

WIFI-12693 Cert Portal: Access Denied error trying to load certificate

WIFI-12694 PROV UI: adding new SSID roaming configuration option

WIFI-12696 Unable to authenticate client with captive-local-credentials ERROR: Invalid credentials

Task

WIFI-12578 add pstore/pmsg support

WIFI-12581 Add Support for HFCL WallPlate WiFi6 model ( HFCL ION4xi_wp )

WIFI-12601 pstore: make console logging work.

WIFI-12645 AP: Add Public IP reporting support in state message

WIFI-12650 CIG WF-186w : mac addr&rtl 8367s switch patch

WIFI-12656 CIG WF-186w : Update 5G BDF

WIFI-12679 CIG WF-186w : update uart pin setting for commuciation between ble and soc

Epic

WIFI-12016 CloudSDK GW Service

WIFI-12407 RADIUS-ACCOUNTING-STOP when AP is disconnected from controller

New Feature

WIFI-12366 Multiple captive ssid's are not working with single AP.

WIFI-12382 Onboarding CIG WF-186W

WIFI-12411 CIG WF-186w : Add WF-186w support

WIFI-12423 create ability to capture username/mac mapping during radius authentication

WIFI-12440 add “cpu” statistics to the metrics collection

WIFI-12501 GW UI: add ability to change table column order

WIFI-12506 GW UI: support viewing and searching radius clients

WIFI-12516 OWLS UI: add support for concurrent simulations

OpenWiFi device features are configurable through understanding the uCentral device data model.

For integrators of commercial controllers, these feature examples may help guide development of device provisioning within a partner controller products.

Experimentation with device features often occurs initially through static configuration as JSON document sent to a device using the OpenWiFi Gateway.

Commercial products with OpenWiFi device provisioning will be using the northbound API to create, update, delete per device configurations. These APIs are then inter-worked southbound via the OpenWiFi Gateway to devices.

Some of the available device features are exposed in this same manner using the OpenWiFi Provisioning service. This provisioning service offers an additional way for commercial partners to consume OpenWiFi and integrate a controller or back office environment that may require device provisioning when that functionality is not present as part of a controller or other commercial product.

The following pages guide the user to understanding each of these features individually including example configuration information.

Basic Examples

One of the benefits of the new data plane in OpenWiFi 2.0 is the flexibility of physical port to logical forwarding that is easily conveyed through configuration structures.

New protocol support is both easily added to the system as well as associated with interfaces by their role in the device.

The following sections offer feature configuration examples.

For complete reference to the device data model please refer here.

Creating logical bridges may be done through association to named "interfaces". To associate a logical SSID interface directly to the WAN, place SSID configuration within the interface have a "role" of upstream.

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "services": [ "lldp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            },
            "ssids": [
                {
                    "name": "OpenWifi",
                    "wifi-bands": [
                        "2G", "5G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    }
                }
            ]

"interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "services": [ "lldp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            },
            "ssids": [
                {
                    "name": "OpenWifi_2GHz",
                    "wifi-bands": [
                        "2G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    }
                },
                {
                    "name": "OpenWifi_5GHz",
                    "wifi-bands": [
                        "5G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    }
                }
            ]

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "services": [ "lldp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            },
            "ssids": [
                {
                    "name": "OpenWifi_2GHz",
                    "wifi-bands": [
                        "2G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    },
                    "rate-limit": {
                        "ingress-rate": 100,
                        "egress-rate": 100
                    }
                },
                {
                    "name": "OpenWifi_5GHz",
                    "wifi-bands": [
                        "5G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    },
                    "rate-limit": {
                        "ingress-rate": 250,
                        "egress-rate": 250
                    }
                }
            ]

SDK can be deployed to Kubernetes using a Helm package. The Helm package code is located at https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/ repository.

Each microservice in the OpenWiFi SDK system has its own Helm chart that is managed in the microservice’s own repository. The assembly chart collects all the relevant microservice charts and other external dependencies like kafka, rtty, etc. and deploys them together as one cohesive release.

You can review the full list of all the assembled microservices and related dependencies here: https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/blob/main/chart/Chart.yaml#L6

Installation

There are multiple ways you can install OpenWiFi SDK with assembly charts:

1. One way is by installing directly from the assembly chart’s repository. For that, you’ll need to install and extra Helm plugin that is used to pull the latest charts code from all the referenced microservices: https://github.com/aslafy-z/helm-git.

2. Another way, which is considered more stable, is by installing from a prepackaged bundle that is published to https://tip.jfrog.io/ui/native/tip-wlan-cloud-ucentral-helm/ on every official uCentral release. For this approach to work, you don’t need to install any additional plugins or dependencies, just to make sure you’ve got Helm installed on your local system.

Directly from the Assembly repository

1. Install the helm-git pluging according to the official documentation

2. Run helm upgrade --install tip-ucentral git+https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=main

3. You can also reference any other open branch from the deployment repository. For example, if you want to deploy using the assembly code from the v2.0.0-rc1 branch, you can just run helm upgrade --install tip-ucentral git+https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=v2.0.0-rc1

Using the pre-built Helm package

1. This method doesn’t require to install anything locally other than Helm

2. Start by adding the wlan-cloud-ucentral Helm repository to your local list of repositories by running helm repo add tip-ucentral https://tip.jfrog.io/artifactory/tip-wlan-cloud-ucentral-helm/

3. helm upgrade --install tip-ucentral wlan-cloud-ucentral to install the latest version, or specify the release you want to install by adding the --version x.y.z flag.

Chart configuration using the Values file

The configuration of OpenWiFi SDK using Helm chart may be separated into layers:

1. Micro services default values - values files that are stored in microservice helm charts (i.e. https://github.com/Telecominfraproject/wlan-cloud-ucentralgw/blob/master/helm/values.yaml ). These values are used by default if no other parameters are supplied, so in case you have any microservice-related variables that need to be added in default installation (for example new application configuration properties), add them in the related helm chart values as they will be applied in next release update.

2. Assembly chart values - values that are stored in the assembly repository (https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/blob/main/chart/values.yaml ) – these are values that override default microservices values so that all uCentral components could connect to each other correctly, and the whole system can be installed as one bundle. These parameters are environment specific, and can differ between and installation of the bundle on an EKS cluster or a MicroK8s local setup.

3. Helm upgrade/install flag overwrites - these values cam be specific for each specific helm install command during execution and usually contain installation-specific values like TLS certificates, security credentials, loadbalancer configuration parameters and so on. These may be passed using --set flag or --values flag (details may be found in https://helm.sh/docs/chart_best_practices/values/ and in microservices helm charts), or you can also save them into one file and reference this file during the helm upgrade command using the --values flag.

During deployment all values are merged as maps with priority to the level of deployment (so Environment-specific values will override any overrides from Assembly chart values and so on).

Example: Let’s pass environment-specific ucentralgw.properties configuration parameter (which is probably quite common thing to test). For example, we have an environment that requires to set parameter ucentral.websocket.host.0.backlog to 1000. For that we would need to run following command, extending our base command:

helm upgrade --install tip-ucentral git+https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=main --set ucentralgw.configProperties."ucentral\.websocket\.host\.0\.backlog"=1000

Automated community deployment

OpenWiFi SDK can also be deployed to an AWS labs environment using a Github actions workflow: https://github.com/Telecominfraproject/wlan-testing/actions/workflows/ucentralgw-deployment.yaml.

The configuration is dynamic, and new namespaces (a.k.a environments) may be created by adjusting the json configuration in the workflow.

The json format allows to deploy or upgrade and existing environment using the latest Docker images or to specify a specific version of each microservice.

To deploy specific version to the specific environment a list of things must be done:

1. First, you need to make sure that the Docker image with the correct version exists in Artifactory, otherwise, the Helm upgrade will fail.

2. Update the json configuration in the workflow to reference the require version for the require microservice (examples are attached in the json file itself)

3. Re-run the deployment in Github actions. You can also make all the above changes in a separate branch, and re-run the workflow from that branch (using a drop-down in the top left corner in Github’s UI).

When operators of enterprise or service provider networks seek to influence or control the allocation of dynamically assigned IP address, typically the network edge has been provisioned to encode information in DHCP Relay packets that help identify the access device through which a subscriber is attached, the logical sub-interface of that network edge or the subscriber directly.

TIP OpenWiFi supports DHCP Relay with encoding of client Circuit-Id information containing any of:

• Interface

• VLAN-Id

• SSID

• Encryption Mode

• Device Name

• Device Model

• Device Location

• Access Point MAC Address

• Access Point MAC in Hex

• Client MAC Address

• Client MAC Address in Hex

TIP OpenWiFi Relay-Agent remote-id may be configured to contain any of the following:

• VLAN-Id

• SSID

• AP-MAC

• AP-MAC-Hex

• Client MAC

• Client MAC Hex

The remote-id originates from a configured IPv4 interface address.

		{
			"name": "LAN",
			"role": "downstream",
			"services": [ "ssh", "lldp" ],
			"ethernet": [
				{
					"select-ports": [
						"LAN*"
					]
				}
			],
			"ipv4": {
				"addressing": "static",
				"subnet": "192.168.1.1/24",
				"dhcp": {
					"relay-server" : "192.168.100.20",
					"circuit-id-format": "{Interface}:{SSID}:{AP-MAC}:{Location}",
					"remote-id-format": "{AP-MAC}:{SSID}"
				}
			}
		}
	]

In the above example, when the IPv4 downstream interface 192.168.1.1 has DHCP enabled for relay-server a DHCP relay process associates to the IP interface of the subnet. When DHCP DISCOVER packets arrive as broadcasts, they will be copied to a unicast packet from the 192.168.1.1 interface as the relay-id source address and unicast forwarded to the defined relay-server address. Additional parameters are encoded for inspection at the DHCP server as present in circuit-id-format and remote-id-format options.

OpenWiFi devices have global services that operate either independently system wide or as an association to a physical or logical interface.

Within the "services" configuration block, define the operating mode for each service, then associate a service with an interface.

SSH

Secure shell may optionally be enabled on OpenWiFi devices, associated to specific interface(s), and optionally support operator defined keys or password authentication.

    "services": {
        "ssh": {
            "port": 22,
            "authorized-keys": {
                "items": [
                "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC0ghdSd2D2y08TFowZLMZn3x1/Djw3BkNsIeHt/Z+RaXwvfV1NQAnNdaOngMT/3uf5jZtYxhpl+dbZtRhoUPRvKflKBeFHYBqjZVzD3r4ns2Ofm2UpHlbdOpMuy9oeTSCeF0IKZZ6szpkvSirQogeP2fe9KRkzQpiza6YxxaJlWw== user@example",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ4FDjyCsg+1Mh2C5G7ibR3z0Kw1dU57kfXebLRwS6CL bob@work",
          "ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBP/JpJ/KHtKKImzISBDwLO0/EwytIr4pGZQXcP6GCSHchLMyfjf147KNlF9gC+3FibzqKH02EiQspVhRgfuK6y0= alice@home"
                ]
            }
        }
    }

Associate Service to Interface

        {
            "name": "LAN",
            "role": "downstream",
            "services": [ "ssh" ],
            "ethernet": [
                {
                    "select-ports": [
                        "LAN*"
                    ]
                }
            ],

Operator Key Management

For production deployments, it is recommended to assign operator SSH key from the OpenWiFi Provisioning configuration of the Venue or Entity which the device associates.

In this way, an operator may ensure their standard SSH key is delivered to all devices on a network operating region basis. All keys remain base64 encoded when added to the device.

NTP

Network time protocol for OpenWiFi devices may be configured to listen for time synchronization from NTP sources and may also be configured to supply NTP source.

    "services": {
        "ntp": {
            "servers": [
            "0.openwrt.pool.ntp.org",
            "1.openwrt.pool.ntp.org"
            ]
        }
    }

Associate to an Interface

        {
            "name": "WAN",
            "role": "downstream",
            "services": [ "ntp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            }
    },

LLDP

Link Layer Discovery Protocol describes interfaces and capabilities between directly attached neighbors over Layer 2.

        "lldp": {
            "describe": "OpenWiFi",
            "location": "Stadium Level 2"
        },

Associate "lldp" as a services attribute to any interface.

MDNS

To assist in device or service discovery over smaller networks, multicast DNS (mDNS) protocol if often used. In an mDNS environment there is no local name server for resources to leverage. mDNS zero-configuration service effectively behaves as unicast Domain Name Service (DNS).

        "mdns": {
            "enable": true
        },

Associate "mdns" as a services attribute to any interface.

Syslog

Remote syslog systems may be configured to receive device logs in a central location. This content is standard device log and not related to telemetry for metrics and service information received by the OpenWiFi Gateway. Valid port range is from 100 - 65535 with operation over UDP or TCP.

        "log": {
            "host": "Syslog Server IP",
            "port": 514,
            "proto": "udp"
        },

Associate "log" as a services attribute to appropriate interface.

IGMP

When enabled the OpenWiFi device will process IGMP Proxy.

        "igmp": {
            "enable": true
        },

Associate "igmp" as a services attribute to any interface participating in IGMP Proxy.

OpenWiFi device features are configurable through understanding the uCentral device data model.

For integrators of commercial controllers, these feature examples may help guide development of device provisioning within a partner controller products.

Experimentation with device features often occurs initially through static configuration as JSON document sent to a device using the OpenWiFi Gateway.

Commercial products with OpenWiFi device provisioning will be using the northbound API to create, update, delete per device configurations. These APIs are then inter-worked southbound via the OpenWiFi Gateway to devices.

Some of the available device features are exposed in this same manner using the OpenWiFi Provisioning service. This provisioning service offers an additional way for commercial partners to consume OpenWiFi and integrate a controller or back office environment that may require device provisioning when that functionality is not present as part of a controller or other commercial product.

The following pages guide the user to understanding each of these features individually including example configuration information.

For complete reference to the device data model please refer here.

The most common use case for VLANs and Wi-Fi is likely the service provider, venue, enterprise where Wi-Fi traffic is not subject to address translation. This is the example that will be shown, however it is entirely possible to create multiple downstream VLANs with SSIDs as well. Simply replace the logic of upstream to downstream where desired.

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "services": [ "lldp", "dhcp-snooping" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            }
        },
            {
                "name": "WAN100",
                "role": "upstream",
                "vlan": {
                    "id": 100
                },
                "ethernet": [
                    {
                        "select-ports": [
                            "WAN*"
                        ]
                    }
                ],         
            "ssids": [
                {
                    "name": "VLAN 100 Wi-Fi",
                    "wifi-bands": [
                        "2G", "5G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    }
                }
            ]
        },

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "services": [ "lldp", "dhcp-snooping" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            }
        },
            {
                "name": "WAN100",
                "role": "upstream",
                "vlan": {
                    "id": 100
                },
                "ethernet": [
                    {
                        "select-ports": [
                            "WAN*"
                        ]
                    }
                ],         
            "ssids": [
                {
                    "name": "VLAN 100 Wi-Fi",
                    "wifi-bands": [
                        "2G", "5G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    }
                }
            ]
        },
            {
                "name": "WAN200",
                "role": "upstream",
                "vlan": {
                    "id": 200
                },
                "ethernet": [
                    {
                        "select-ports": [
                            "WAN*"
                        ]
                    }
                ],         
            "ssids": [
                {
                    "name": "VLAN 200 Wi-Fi",
                    "wifi-bands": [
                        "5G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    }
                }
            ]
        },

In all cases the WAN port without VLAN id is using DHCP to obtain a management IP address. Each additional "upstream" role interface with an SSID associated have no IP configuration.

Quality of service for Wi-Fi involves multiple functions.

IEEE802.11e says stations will send multiple QoS data frames followed by a block ack request (BAR). The AP will send a block ack frame back that includes a bitmap that indicates which frames were received.

The 802.11ac-2013 standard states that all data frames be sent as QoS data frames.

IEEE802.11-2016 Enterprise QoS Includes action frames for many categories such as spectrum management, QoS, HT, VHT, radio measurements, and more 802.11 QoS is achieved by giving high priority queues a statistical advantage at winning contention.

TIP OpenWiFi implements IEEE802.11-2016 Enterprise QoS features in the following way:

• Traffic Classifiers fully mapping Wireless Multi-Media with DSCP in 802.11-2016 terms

• Matches by port, range, and or DNS FQDN

• Designed as eBPF Traffic Classifiers TIP OpenWiFi QoS works in Bridge, NAT & VLAN modes

• Enables total Bandwidth to rate-cap forwarding Future per SSID based Traffic Classifiers

OpenWiFi additionally implements standard buffer bloat control when handling queue behavior during shaping. This feature is known as Qosify. Qosify will set Cake queue discipline behavior using an eBPF classifier to set DSCP per packet as part of wirespeed operations in the Linux kernel.

How it works

Follow the OpenWiFi data model for QoS rules bound to interface via select-ports setting upstream and downstream bandwidth, DSCP marking, protocol and port with an optional FQDN dynamic application match via DNS. Define the wireless-multimedia chosen behavior to set air interface queues.

TIP OpenWiFi enumerates defined QoS provisioning, as applications or port and protocol matches occur, the Wi-Fi Traffic Identifier (TID) value is set accordingly.

OpenWiFi WMM Supports the following class selector profiles:

• Enterprise

• RFC8325 - default

• 3GPP

Example QoS Definition

     "globals": {
                "wireless-multimedia": {
                        "profile": "rfc8325"
                }  
                
     "services": {
              "quality-of-service": {
                        "select-ports": [ "WAN" ],
                        "bandwidth_up": 1000,
                        "bandwidth_down": 1000,
                        "bulk-detection": {
                                "dscp": "CS1",
                                "packets-per-second": 500
                        },
                        "classifier": [
                                {
                                        "dscp":  "CS1",
                                        "ports": [
                                                { "protocol": "any", "port": 53 },
                                                { "protocol": "tcp", "port": 80 }
                                        ],
                                        "dns": [
                                                { "fqdn": "telecominfraproject.com", "suffix-matching": false }
                                        ]
                                }, {
                                        "dscp":  "AF41",
                                        "dns": [
                                                { "fqdn": "zoom.us" }
                                        ]
                                }
                        ]
                }

In the above example, select-ports was set as WAN. Should the access point have an SSID associated to the WAN interface, the defined QoS settings become applied to both Wi-Fi air interface and the Ethernet interface. By default WAN is chosen for all classification and shaping.

Bulk detection functions to optimize bulk traffic flows measured in average packet size and packets per second. When bulk-detection is triggered, marking with Diffserv Code Point (DSCP) is possible. Default is CS0.

Classifier works to specifically trigger on conditional criteria of ports, dns matching individually or in combination with either or both tcp or udp protocols for classification in DSCP terms. When port is set it may be individual or up to an end port when setting range-end value.

If matching traffic enters already classified in DSCP terms, OpenWiFi by default will reclassify based on the classifier conditions defined unless reclassify is set to false.

The docker-compose directory within the deploy repository contains all the relevant files for various modes of SDK.

Modes

The following two modes are currently supported by docker-compose:

• Deployments without a Load Balancer

  This model contains single instances of SDK micro-services. Non-Load Balancer is suitable for scenarios where load given number of APs is below 10,000 or design for network availability is not required. Additionally this deployment includes options to use either self-signed certificates or user provided certificates:

  • Non-LB deployment with self-signed certificates

  • Non-LB deployment with own certificates

• Deployments with a Load Balancer

  This model is suitable for deployments where there is a need to scale performance and/or use Letsencrypt certificates for northbound service interactions. This deployment allows the user to scale up number of instances of micro-services to handle a larger load than listed here. The repository contains the instructions here:

  • LB deployment with self-signed certificates

  • LB deployment with Letsencrypt certificates

The docker-compose yaml files are related as follows to the modes above:

• docker-compose.yml : manages Non-LB deployment with self-signed and own certificates

• docker-compose.lb.selfsigned.yml: manages LB deployment with self-signed certificates

• docker-compose.lb.letsencrypt.yml: manages LB deployment with Letencrypt certificates

Docker Compose Environment Variables

The deployments are managed using different environment files for docker-compose:

• .env : used for non LB deployments with either self-signed or own certificate deployments executed by docker-compose. For additional information please read this.

• .env.selfsigned: used for LB with self-signed deployments executed by alias docker-compose-lb-selfsigned. For additional information please read this.

• .env.letsencrypt: used for LB with letsencrypt deployments executed by alias docker-compose-lb-letsencrypt. For additional information please read this.

Volumes

The deployment creates local volumes to persist mostly application and database data. In addition to that several bind mounts are created:

docker-compose/certs/ directory used by multiple services

docker-compose/{microservice}_data/ directory used by each service for configuration and data. Where {microservice} is one of: owgw, owsec, owfms and owprov.

Configuration Variables

Localizing the installation to the production environment is done through configuration information environment files per microservice. These files are: owgw.env, owgw-ui.env, owsec.env, owfms.env, owprov.env and owprov-ui.env. These env files are used to generate runtime configuration (properties) file when no configuration is found in their respective {microservices}-data directory.

Ports

Exposed port dependencies by application are listed below:

127.0.0.1:80/443 tcp - OpenWiFi-uCentralGW-UI 127.0.0.1:8080/8443 tcp - OpenWiFi-Provisoning-UI 127.0.0.1:5912/tcp - rttys dev 127.0.0.1:5913/tcp - rttys user 0.0.0.0:15002/tcp - OpenWiFi-uCentralGW websocket 127.0.0.1:16002/tcp - OpenWiFi-uCentralGW REST API public 0.0.0.0:16003/tcp - OpenWiFi-uCentralGW fileupload 127.0.0.1:16102/tcp - OpenWiFi-uCentralGW alivecheck 127.0.0.1:16001/tcp - OpenWiFi-uCentralSec REST API public 127.0.0.1:16101/tcp - OpenWiFi-uCentralSec alivecheck

Default Certificates

When cloning the repository, by default the southbound websocket certificate signed by TIP Root CA is provided for the *.wlan.local domain. Additionally a self-signed certificate for the northbound REST API is present. These enable creating a local deployment out of the box. Production deployments will replace both the southbound websocket and northbound API certificates.

The supplied certificates are valid for the *.wlan.local domain.

How to

1. First you'll have to install Docker Compose according to your platform specific instructions. After that clone the repository with git clone https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy.

2. The Docker Compose uCentral microservice configs use openwifi.wlan.local as a hostname, so make sure you add an entry in your hosts file (or in your local DNS solution) which points to 127.0.0.1 or the IP of the host running the SDK.

3. Switch to the Compose project directory with cd docker-compose/.

4. Default user is: tip@ucentral.com and password is: openwifi

   1. Service enforces a password change on first login

5. Initialize the deployment with docker-compose up -d. If your deployment was successfully created, you should see the following output with docker-compose ps:

          Name                      Command               State                                                   Ports
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
openwifi_kafka_1       /opt/bitnami/scripts/kafka ...   Up      9092/tcp
openwifi_owfms_1       /docker-entrypoint.sh /ope ...   Up      0.0.0.0:16004->16004/tcp,:::16004->16004/tcp, 0.0.0.0:16104->16104/tcp,:::16104->16104/tcp, 17004/tcp
openwifi_owgw-ui_1     /docker-entrypoint.sh ngin ...   Up      0.0.0.0:443->443/tcp,:::443->443/tcp, 0.0.0.0:80->80/tcp,:::80->80/tcp
openwifi_owgw_1        /docker-entrypoint.sh /ope ...   Up      0.0.0.0:15002->15002/tcp,:::15002->15002/tcp, 0.0.0.0:16002->16002/tcp,:::16002->16002/tcp,
                                                                0.0.0.0:16003->16003/tcp,:::16003->16003/tcp, 0.0.0.0:16102->16102/tcp,:::16102->16102/tcp, 17002/tcp
openwifi_owprov-ui_1   /docker-entrypoint.sh ngin ...   Up      80/tcp, 0.0.0.0:8080->8080/tcp,:::8080->8080/tcp, 0.0.0.0:8443->8443/tcp,:::8443->8443/tcp
openwifi_owprov_1      /docker-entrypoint.sh /ope ...   Up      0.0.0.0:16005->16005/tcp,:::16005->16005/tcp, 0.0.0.0:16105->16105/tcp,:::16105->16105/tcp, 17005/tcp
openwifi_owsec_1       /docker-entrypoint.sh /ope ...   Up      0.0.0.0:16001->16001/tcp,:::16001->16001/tcp, 0.0.0.0:16101->16101/tcp,:::16101->16101/tcp, 17001/tcp
openwifi_rttys_1       /rttys/rttys                     Up      0.0.0.0:5912->5912/tcp,:::5912->5912/tcp, 0.0.0.0:5913->5913/tcp,:::5913->5913/tcp

1. When the certificate for the REST API and other components is self-signed, accepting trust for the self-signed REST API certificate on your local machine is required. Add certs/restapi-ca.pem to your trusted browser certificates or add certificate exceptions in your browser by visiting each of the following URLs (one per port) : https://openwifi.wlan.local:16001 and ports :16002 :16003 :16004 and :16005 Using the browser, accept the self-signed SSL certificate warnings (make sure to visit both and add the exceptions).

2. Connect to your AP via SSH and add a static hosts entry in /etc/hosts for openwifi.wlan.local which points to the address of the host the SDK deployment runs on.

3. While staying in the SSH session, copy the content of certs/restapi-ca.pem on your local machine to your clipboard and append it to the file /etc/ssl/cert.pem on the AP. This way your AP will also trust the self-signed certificate. This step is necessary for rtty features and only required when using self-signed test deployment.

4. Navigate in a web browser to https://openwifi.wlan.local to access the UI and login with default username and password. You will now be prompted to change this default password to something more secured.

1. To use the curl test scripts which are included in the microservice repositories make sure to set the following environment variables before issuing a request:

export UCENTRALSEC="openwifi.wlan.local:16001"
export FLAGS="-s --cacert <your-wlan-cloud-ucentral-deploy-location>/docker-compose/certs/restapi-ca.pem"

Upgrading Compose Deployments

Stop the running containers with docker-compose down

Check out the new branch by repeating Step 1 from How to above for the given release and docker-compose up -d.

Don’t forget to re-add the self-signed certificates to the containers with the provided script. Also be aware that you may have to change back some file permissions. To obtain the most recent changes as the files are under version control, you may have to change the ownership to your user again before pulling changes.

OpenWiFi supports Zero Touch Provisioning in a number of ways.

• Zero Touch Mesh

• Zero Touch WDS

• Zero Touch Provisioning ( Provisioning Services in upcoming 2.5/2.6 Release )

Onboarding

OpenWiFi makes use of TIP device certificates present on every access point as a secure identity from which to automate a number of Zero Touch operations.

Onboarding is a local EAP-TLS based authentication service available on any OpenWiFi device that works together with default OpenWiFi firstboot behavior to scan for "OpenWifi-onboarding" SSID, associate to that SSID, when challenged supply TIP root signed device certificate.

Onboarding Steps

1. Provision an Access Point for onboarding role as an SSID config { "purpose": "onboarding-ap", "bss-mode": "ap", "encryption": { "proto": "wpa2", "ieee80211w": "required" }, "certificates": { "use_local_certificates": true }, "radius": { "local": { "server-identity": "uCentral-EAP" } }, "name": "OpenWifi-onboarding", "wifi-bands": [ "2G" ] }

2. Ensure the SSID for onboarding use provides network connectivity for clients

   • Any topology such as NAT, Bridge, VLAN may be used

   • Any radio(s) may be used

3. Firstboot devices with no WAN wired port detected will

   • Enable all radios

   • Scan for SSID "OpenWifi-onboarding"

   • Associate and when challenged use TIP certificate as identity

   • Obtain IP connection using DHCP over wireless interface association to onboarding AP

   • Connect to SDK, obtain provisioning from OpenWiFi Gateway service

   • Reload configuration

Zero Touch Mesh

Deployment of Mesh may have multiple Mesh Client access points with no wired connectivity. These devices use IEEE802.11s Mesh participating interface(s) as transit for WAN / LAN connections.

Mesh Client Access Points needing to associate wirelessly for initial provisioning to join the mesh network, may be served using the onboarding feature of OpenWiFi.

Adding an SSID to the Mesh Gateway Access Point configuration to advertise "OpenWifi-onboarding" enables initial boot of any OpenWiFi Access Point to reach the OpenWiFi Gateway.

Upon connection to Onboarding, the Access Point obtains management network access from the upstream Access Point providing "onboarding-ap" service.

With management network access, reachability for the Mesh Client Access Point to the OpenWiFi Gateway should be possible, device provisioning stage will initiate with the production configuration being loaded to the client device.

Once processed, client Access Point will have receive provisioning to join the Mesh network as a Mesh Client Access Point.

Zero Touch WDS

Deployment of WDS links may have multiple WDS client devices with no wired WAN connectivity. WDS Access Points use the 4-tuple frame header with participating WDS Clients. Therefore WDS Clients must first receive provisioning from the OpenWiFi Gateway for their production state as a WDS link participant.

WDS Client Access Points needing to associate wirelessly for initial provisioning to join the WDS network, may be served using the onboarding feature of OpenWiFi from the WDS Root Access Point at the top of the topology with a "bss-mode": "ap" SSID for onboarding.

Adding an SSID to the WDS Root Access Point configuration to advertise "OpenWifi-onboarding" enables initial boot of any OpenWiFi Access Point to reach the OpenWiFi Gateway.

Upon connection to Onboarding, the WDS Client Access Point obtains management network access from the upstream WDS Root Access Point providing "onboarding-ap" service.

Once processed, WDS Client Access Point will have receive provisioning to join the WDS link as a Client WDS node.

Each device presents Metrics and Health check data to the Gateway. Devices view displays this information in the following organization:

• Status

• Configuration

• Logs

• Health

• Commands

• Statistics

• Command History

Status

Connection status reflects the Gateway to Device current communications status. Uptime and Last Contact reflect communication state. Load indicates processing load on the device. Memory Used indicates free memory on the device.

Configuration

Device UUID, Serial Number, MAC Address and Device Type are displayed. Last configuration update date and timestamp reflects the last time a "configure" action completed on the device. Password may be set and device notes may be added.

Logs

Log history of the device is presented within Logs. Expand the tile selecting the down arrow.

Health

Health score is an active tile reflecting the device health out of a score reported by the device to Gateway. Health metrics are configured on the device based on chosen data model options. When the device falls out of 100%, this tile changes to red. Expanding the tile will present all health reports. Those with less than 100% score will contain reasons for the result from this interface.

Commands

Commands tile provides a number of administrative actions for the user:

VXLAN’s goal is allowing dynamic large scale isolated virtual L2 networks to be created for virtualized and multi-tenant environments. It does this by encapsulating Ethernet frames in VXLAN packets which when deployed in Wi-Fi topologies can create highly extensible Layer 2 inter-network domains over large campus, MDU, venue service networks.

VxLAN header uses a 24-bit VNID as a unique layer 2 forwarding domain value. VxLAN maintains layer 2 isolation between the forwarding domains and does not leak MAC addresses into upstream switches. Through the use of 24 bits in VNID VxLAN scales up to 16 million unique LAN forwarding domains.

The VXLAN encapsulation method is IP based and provides for a virtual L2 network. With VXLAN the full Ethernet Frame (with the exception of the Frame Check Sequence: FCS) is carried as the payload of a UDP packet. VXLAN utilizes a 24-bit VXLAN header, to identify virtual networks. This header provides for up to 16 million virtual L2 networks.

Frame encapsulation is done by an entity known as a VxLAN Tunnel Endpoint (VTEP.) A VTEP has two logical interfaces: an uplink and a downlink. The uplink is responsible for receiving VxLAN frames and acts as a tunnel endpoint with an IP address used for routing VxLAN encapsulated frames.

The VTEP in a TIP OpenWiFi device would be a management interface or designated uplink port(s). VTEP in an AP would be the AP WAN interface, or otherwise designated management interface (such as sub-interface on bridge wan).

In a traditional L2 switch a behavior known as flood and learn is used for unknown destinations (i.e. a MAC not stored in the MAC table). This means that if there is a miss when looking up the MAC the frame is flooded out all ports except the one on which it was received. When a response is sent the MAC is then learned and written to the table.

The next frame for the same MAC will not incur a miss because the table will reflect the port it exists on. VXLAN preserves this behavior over an IP network using IP multicast groups.

Configure VxLAN

OpenWiFi device will establish a VTEP adjacency to the upstream switch. It is anticipated that any Wi-Fi networks in a VxLAN topology are associated to "upstream" interface(s).

The following example creates a VxLAN endpoint from a WAN upstream port that will participate in VLAN 100, encapsulate this into VxLAN where it may be distributed across the campus or venue transparently.

Creating a NAT Gateway is easily done via association to an interface having a role of "downstream".

Based on the above Dual SSID NAT configuration, a unique 2GHz and 5GHz SSID are created and logically bound to the same NAT LAN side network.

The NAT service is inherited by the downstream role with DHCP addressing defined according to the range set within the downstream "ipv4" configuration.

OpenWiFi Mesh has been designed to eliminate configuration complexity while also remaining capable of advanced topology designs including Multi-Gateway, Multi-SSID, VLAN, and Zero Touch Mesh onboarding.

The physical wired interface(s) to participate in the mesh topology egress are defined with the protocol "mesh".

The logical wireless interface(s) to participate in mesh topology are defined by their bss-mode set to "mesh".

In this basic mesh, dual SSIDs are configured for clients while an SSID for mesh transit is configured for IEEE802.11s client associations. Additional mesh clients simply use the same approach, no other configuration is required for the client to participate in this mesh.

Advanced examples with VLANs and roaming are all possible by adding additional configuration steps.

Metrics

Several metrics are reported during intervals to the OpenWiFi Gateway. In general metrics contain traffic counters, neighbor tables, discovered clients.

Each OpenWiFi device is capable of sending statistics on SSID, LLDP, and associated Clients learned by the device.

Additionally, OpenWiFi devices expose all 802.11 management data within wifi-frames and to assist network troubleshooting and client fingerprinting solutions OpenWiFi provides dhcp-snooping for all possible client exchanges over DHCP and DHCPv6.

The metrics data is sent to OpenWiFi Gateway at the intervals set where configurable.

Metrics must be associated with the interfaces they are to report on. For example, to send DHCP data from LAN to OpenWiFi Gateway, the following configuration would apply.

        {
            "name": "LAN",
            "role": "downstream",
            "services": [ "ssh", "lldp", "dhcp-snooping" ],
            "ethernet": [
                {
                    "select-ports": [
                        "LAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "static",
                "subnet": "192.168.1.1/24",
                "dhcp": {
                    "lease-first": 10,
                    "lease-count": 100,
                    "lease-time": "6h"
                }
            }
        }
    ],

Complimenting enterprise QoS in OpenWiFi is support for Dynamic Air Time Fairness.

Air Time Fairness (ATF) governs the Wireless Multimedia (WMM) operations on the air interface with influence of the scheduler based on the QoS classification that has been applied to the flow.

The Distributed Coordination Function (DCF) which is the underlying Media Access Control system to Wi-Fi is generally governed by equality rules at the air interface, every UE is equal.

Traffic handling in Wi-Fi is a balance of application of QoS marked flows to scheduling of contention access in certain queueing terms to the air interface medium.

OpenWiFi WMM Supports the following class selector profiles:

• Enterprise

• RFC8325 - default

• 3GPP

Air Time Fairness Example:

Airtime weights have a valid range of 0 - 511. Airtime Fairness works using sliding averages of total packets per second to approximate influence to the scheduler.

Voice weight operates as a multiplier of traffic marked CS5 / UP5 which is equivalent to DSCP EF. When voice-weight is set to 4 this directs the scheduler to assume it should set aside four (4) times the average bandwidth granted for this flow in order to move it through the air interface as quickly as possible.

Packet threshold will reclassify every number of packets from the UE station ( in the example every 100 ).

When arriving traffic for the UE are classified as bulk, and in the above example over 50% of total arriving traffic appear with the same QoS classification the UE airtime priority will fall into bulk-threshold.

When more than 30% of arriving traffic for the UE are classified as CS4 or equivalent to AC_VI / AF3x realtime interactive, the UE airtime priority will rise to priority airtime.

OpenWiFi 2.0 supports Generic Routing Encapsulation as an available "tunnel" protocol type.

This makes it possible to configure GRE for multiple types of deployments as any interface may be encapsulated by the "tunnel" parameter.

For example, to send all content of a specific SSID over an GRE tunnel, the following configuration would apply.

In the above example, the WAN untagged port will request DHCP in addition to present a VLAN interface with id 20 that both initiates the GRE tunnel as well as passes SSID traffic over that tunnel. Optionally the GRE tunnel itself may also carry a VLAN encapsulated payload. In the above example a WAN presentation of VLAN interface 20 has GRE tunnel. Within the GRE tunnel on WAN interface of VLAN 20 is a GRE payload with VLAN 30 in the payload header.

Layer 2 Tunneling Protocol may be associated to any interface using the "tunnel" configuration option.

This makes it possible to configure L2TP for multiple types of deployments as any interface may be encapsulated by the "tunnel" parameter.

For example, to send all content of a specific SSID over an L2TP tunnel, the following configuration would apply.

OpenWiFi supports WISPr Attribute Value Pairs (AVP)s for setting per authenticated subscriber bandwidth in uplink and downlink.

Provided the SSID has been configured for RADIUS authentication, any access-accept retuned with WISPr Max-Up and Max-Down values, OpenWiFi will restrict per subscriber traffic to these rates.

RADIUS Subscriber WISPr Speed Definition:

        WISPr-Bandwidth-Max-Up := 100,
        WISPr-Bandwidth-Max-Down := 100

Release 2.7 onwards, OpenWiFi supports a brand new implementation of captive portal leveraging user space application and eBPF based packet filtering. This new implementation allows the APNOS to support functionality previously supported by CoovaChili.

OpenWiFi support two types of captive portal:

• Internal/Local Captive Portal

• External Captive Portal

Local Captive Portal

The internal captive portal supports the following modes of authentication.

1. Click-to-continue : In this mode the client will be redirected to a page where the client needs to accept the terms of service before accessing data.

2. Credentials: In this mode the client needs to enter the valid credentials that are configured in the AP to access data.

3. Radius: In this mode the client needs to enter the valid credentials that are configured in the radius server being used to access data.

On authentication failures there is further functionality to limit access to the network by providing a wall garden feature. This includes a files of

Click-to-continue configuration

First define a captive service as part of the interface -> ssids.

"interfaces": [
    {
     :
      "ssids": [
        {
          "name": "OpenWifi-hotspot",
          "services": [
            "captive"
          ],
          "wifi-bands": [
            "5G",
            "2G"
          ],
          "bss-mode": "ap",
          "encryption": {
            "proto": "none",
            "ieee80211w": "optional"
          }
        }
      ]
    }
  ]

Then ensure there is a configuration present for the services section of the schema

  "services": {
    "captive": {
      "auth-mode": "click-to-continue",
      "walled-garden-fqdn": [
        "*.google.com",
        "telecominfraproject.com"
      ]
    }
  }

User credentials

After configuring a captive services inside interfaces -> ssids, the services block will look as follows

  "services": {
    "ssh": {
      "port": 22
    },
    "captive": {
      "auth-mode": "credentials",
      "credentials": [
        {
          "username": "user1",
          "password": "password1"
        },
        {
          "username": "user2",
          "password": "password2"
        }
      ],
      "walled-garden-fqdn": [
        "*.google.com",
        "telecominfraproject.com"
      ]
    }
  }

Radius based credentials

After configuring a captive services inside interfaces -> ssids, the services block will look as follows

  "services": {
    "ssh": {
      "port": 22
    },
    "captive": {
      "auth-mode": "radius",
      "auth-server": "10.28.3.100",
      "auth-port": 1812,
      "auth-secret": "testing123",
      "walled-garden-fqdn": [
        "*.google.com",
        "telecominfraproject.com"
      ]
    }
  }

When authenticating clients with back office RADIUS systems, the configuration of OpenWiFi permits this on a per SSID basis.

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            },
            "ssids": [
                {
                    "name": "OpenWifi",
                    "wifi-bands": [
                        "5G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "wpa2",
                        "ieee80211w": "optional"
                    },
                    "radius": {
                        "authentication": {
                            "host": "192.168.178.192",
                            "port": 1812,
                            "secret": "secret"
                        },
                        "accounting": {
                            "host": "192.168.178.192",
                            "port": 1813,
                            "secret": "secret"
                        }
                    }
                }
            ]
        },

            "ssids": [
                {
                    "name": "OpenWifi",
                    "wifi-bands": [
                        "2G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "wpa2",
                        "ieee80211w": "optional"
                    },
                    "certificates": {
                        "ca-certificate": "/etc/ucentral/cas.pem",
                        "certificate": "/etc/ucentral/cert.pem",
                        "private-key": "/etc/ucentral/key.pem"
                    },
                    "radius": {
                        "local": {
                            "server-identity": "OpenWiFi-Local-EAP",
                            "users": [
                                {
                                    "user-name": "open",
                                    "password": "wifi"
                                }
                            ]
                        }
                    }
                }
            ]
        },

Many parameters are possible with RADIUS authentications given the many methods in use worldwide. Many of the EAP methods have configuration options described below.

When an external access controller, such as a captive portal appliance or a Universal Access Method (UAM) redirector is required to handle subscriber login, OpenWiFi now supports ability to have a native implementation that is equivalent of CoovaChili.

As always first define a captive service as part of the interface -> ssids.

The captive service must have the auth-mode set to "uam"

"services": {
                "ssh": {
                        "port": 22
                },
                "captive": {
                        "auth-mode": "uam",
                        "uam-port": 3990,
                        "uam-secret": "xxxxxxx",
                        "uam-server": "xxxxxxx",
                        "nasid": "xxxxxxx",
                        "auth-server": "radius.xxxxxxxxx",
                        "auth-port": 1812,
                        "auth-secret": "xxxxxx",
                        "walled-garden-fqdn": [
                                "*.google.com", "telecominfraproject.com", "xxxxxxxxx", "youtube.com"
                        ]
                }
        }

For further details on how to configure with a external service please refer to this.

Radio Resource Management and Self Organizing Network features in OpenWiFi 2.0 operate by default in local mode from the Access Point device without dependency on the cloud. Data and state related to client steering and roaming is also possible in co-operation with the cloud when so configured.

Metrics and telemetry are sent to the cloud as desired based on configuration however operation of 802.11k/v/r behavior and autonomous channel control are built in features of all OpenWiFi 2.0 Access Points.

Steering

OpenWiFi services feature "wifi-steering" determines the operating parameters of RRM on the Access Point.

    "services": {
      "wifi-steering": {
            "mode": "local",
            "network": "upstream",
            "assoc-steering": true,
            "required-snr": -75,
            "required-probe-snr": -70,
            "required-roam-snr": -85,
            "load-kick-threshold": 90
        },

When mode is set to local, the Access Point handles steering decisions autonomously with the surrounding OpenWifi devices. Which network association, in this case "upstream" will steering be operating on. Note in prior examples most service provider, venue, enterprise services operate on the WAN side upstream network of the Access Point.

Apply Wi-Fi Steering to enable 802.11r Fast Roaming SSIDs

            "ssids": [
                {
                    "name": "OpenWiFi Roaming",
                    "wifi-bands": [
                        "2G", "5G"
                    ],
           "bss-mode": "ap",
           "encryption": {
                "proto": "psk2",
                "key": "OpenWiFi",
                "ieee80211w": "optional"
                 },                   
                    "roaming": {
                        "message-exchange": "air",
                        "generate-psk": true,
                        "domain-identifier": "EFAB"
                    },
                    "services": [ "wifi-steering" ]
                }
            ]
        },

Each SSID to participate in roaming must have "services" : [ "wifi-steering" ] associated.

Additional fast roaming configuration is possible including setting message-exchange either to "air" or "ds" to determine pre authenticated message exchange occurs over the air or distribution system.

The generate-psk option generates FT response locally for PSK networks. This avoids use of PMK-R1 push/pull from other APs with FT-PSK networks.

Configuring domain-identifier sets Mobility Domain identifier (dot11FTMobilityDomainID, MDID) permitting segmentation of fast roaming RF topologies.

When pmk-r0-key-holder and pmk-r1-key-holder are left un-configured, the pairwise master key R0 and R1 will generate a deterministic key automatically for fast mobility domain exchange over the air.

RRM 802.11k

To enable 80211k parameters, associate these on a participating SSID basis.

            "ssids": [
                {
                    "name": "OpenWiFi Roaming",
                    "wifi-bands": [
                        "2G", "5G"
                    ],
           "bss-mode": "ap",
           "encryption": {
                "proto": "psk2",
                "key": "OpenWiFi",
                "ieee80211w": "optional"
                 },                   
                    "roaming": {
                        "message-exchange": "air",
                        "generate-psk": true,
                        "domain-identifier": "EFAB"
                    },
                    "rrm": {
                        "neighbor-reporting": true,
                        "ftm-responder": true, 
                        "stationary-ap": true
                    },
                    "services": [ "wifi-steering" ]
                }
            ]
        },

In addition to 802.11k features for neighbor reporting, fine timing measurement responder and stationary ap indication, OpenWiFi also supports LCI measurement, Civic Location subelement as well.

Automatic Channel Balancing

As part of "wifi-steering" feature, autonomous channel management algorithm may be enabled to establish a self organizing Wi-Fi network.

The auto-channel setting operates in co-ordination with other OpenWiFi Access Points by enumerating the newest AP in the network, then running neighbor and RF scans to determine the best channel of operation. Once the newest AP completes this process, the next AP is sequence will run the same algorithm for channel balancing until all APs in the network complete. The entire process may take up to 5 minutes the first time a network is powered on. The algorithm will re-run every 12 hours.

    "services": {
      "wifi-steering": {
            "mode": "local",
            "network": "upstream",
            "auto-channel": true,
            "assoc-steering": true,
            "required-snr": -75,
            "required-probe-snr": -70,
            "required-roam-snr": -85,
            "load-kick-threshold": 90
        },

In many deployment scenarios, user authentication is centralized with RADIUS systems. In addition, users may have association to their own networks or private networks. A common approach for this is to dynamically assign VLANs to Wi-Fi subscribers as they join the OpenWiFi network.

To configure Dynamic VLANs with RADIUS, associate an SSID with RADIUS authentication, and associate the interface to "upstream" role as dynamic VLANs are most likely to be applicable across the service provider, venue, enterprise network.

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            },
            "ssids": [
                {
                    "name": "OpenWifi",
                    "wifi-bands": [
                        "5G", "2G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "wpa2",
                        "ieee80211w": "optional"
                    },
                    "radius": {
                        "authentication": {
                            "host": "192.168.178.192",
                            "port": 1812,
                            "secret": "secret"
                        },
                        "accounting": {
                            "host": "192.168.178.192",
                            "port": 1813,
                            "secret": "secret"
                        }
                    }
                }
            ]
        },

RADIUS Access-Accept

OpenWiFi devices will determine a VLAN is associated to the authentication of a subscriber when the access-accept message returns the following attribute value pairs:

• Tunnel-Type = 13

• Tunnel-Medium-Type = 6

• Tunnel-Private-Group-Id = VLAN Id Number

Upon return of an access-accept from RADIUS, based on any method chosen for security, OpenWiFi will dynamically create a VLAN Id as described in Tunnel-Private-Group-Id, associated to the interface role, in this example upstream.

When venue authentication will support client mobility it is desirable to not cause re-authentication from one AP to another.

As with the Multi PSK feature that locally provides this functionality to enable a subscriber to have a subscriber based PSK when authenticated creates a private network, this functionality may also be handled via RADIUS to support large venue topologies.

The authentication protocol type is psk2-radius . Add the RADIUS system appropriate for the network.

	"ssids": [
		{
			"name": "OpenWifi",
			"wifi-bands": [
				"2G"
			],
			"bss-mode": "ap",
			"encryption": {
				"proto": "psk2-radius",
				"ieee80211w": "optional"
			},
			"radius": {
				"authentication": {
					"host": "192.168.50.30",
					"port": 1812,
					"secret": "secret"
				},
				"accounting": {
					"host": "192.168.50.30",
					"port": 1813,
					"secret": "secret"
				}
			}
		}
	]

Passpoint® brings seamless, automatic and secure Wi-Fi connectivity using either pre-provisioned credentials or the SIM card in a mobile device. Passpoint provides simple, fast online sign-up and provisioning that is only required upon a user’s first visit to a Passpoint network. Once a Passpoint enabled device contains the Wi-Fi AP or network credentials, it will discover and securely connect when the user is nearby—without requiring additional user action. This makes staying connected while mobile infinitely easier, and because Passpoint employs enterprise-level security, users can feel confident their data is better protected.

Passpoint® also delivers more value to carriers, service providers, and IT managers of enterprise networks, enabling:

• Mobile data offload

• Wi-Fi networks for

  • Hospitality, venues and enterprise

  • Streamlined, enterprise-class device provisioning and credential management for enterprise and other private networks

• Wi-Fi–based services such as Wi-Fi calling, and collaboration tools

• Wi-Fi roaming agreements across carriers and service providers

• Opportunities to engage users and extract additional value from the network

Passpoint® is already supported by most enterprise-class APs on the market today, and natively supported by major mobile operating systems including Android, iOS, macOS, and Windows 10. With active support from a wide ecosystem of device manufacturers, mobile operators, and service providers, Passpoint® benefits both users and Wi-Fi network providers

Dynamic Air-Time Policy is a service to influence underlying co-ordination function of the Wi-Fi MAC domain per associated UE in terms of priority to use the air interface.

It is possible to govern certain application use cases such as streaming media or real time communications based on the resolution of those services through DNS.

This results in the UE, by its IP address having matched a specific fully qualified domain name or a wildcard therein, to having its air-time weighted priority to the value set in the weight parameter.

            "services": {     
                "airtime-policies": {
                    "dns-match": ["*.example.com", "host.example2.com" ],
                    "dns-weight": 256
                }
            }

Possible Uses

Any application a user may commonly use the OpenWiFi administrator seeks to prioritize air-time for may be triggered via the airtime-policies.

For example: