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: 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 "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: Source Code & Repositories

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.

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: https://telecominfraproject.com/openwifi/

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.

• Telecom Infra Project Bylaws

• Telecom Infra Project Organizational documents

• TIP Document IPR Policy

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.

For meeting schedules and additional information, see the OpenWiFi Project Confluence wiki.

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.

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 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.

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.

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.

****

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:

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:

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.

Summary

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

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.

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:

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.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.

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 this section for installation instructions.

Find out what is new in our current release.

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.

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 .

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

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.