added 2.5 content

updated 2.5 to 2.6 version numbers
added new About OpenWifi section
added What's New page
Updated summary.md to include the new pages
This commit is contained in:
Christine Zak
2022-06-17 19:29:03 -07:00
parent e80334cdd8
commit f0f49e6e78
44 changed files with 295 additions and 2 deletions

View File

@@ -2,7 +2,7 @@
description: Telecom Infra Project OpenWiFi
---
# OpenWiFi Release 2.5 In Progress
# OpenWiFi Release 2.6 In Progress
## What is OpenWiFi?

View File

@@ -1,6 +1,15 @@
# Table of contents
* [OpenWiFi Release 2.5 GA](README.md)
* [OpenWiFi Release 2.6 GA](README.md)
* [What's New](whats-new.md)
* [About OpenWifi](about-openwifi/about-openwifi.md)
* [Open WiFi First](about-openwifi/contribute.md)
* [Open WiFi Stack](about-openwifi/openwifi-stack.md)
* [About the OpenWiFi SDK](about-openwifi/about-the-sdk.md)
* [OpenWiFi Firmware](about-openwifi/firmware.md)
* [About Device Provisioning](about-openwifi/device-provisioning.md)
+ [Supported Hardware](about-openwifi/supported-hardware.md)
+ [Integrations](about-openwifi/openwifi-stack.md)
* [Ordering OpenWiFi APs](ordering-open-wi-fi-aps.md)
* [Device Partner Information](device-partner-information.md)
* [Cloud Partner Information](cloud-partner-information.md)

View File

@@ -0,0 +1,23 @@
# About TIP OpenWifi
Meta Connectivity provides solutions leveraging the Telecom Infra Project (TIP) OpenWiFi ecosystem—as part of the TIP Open Converged Wireless Project Group.
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/>
![](./media/image1.jpeg)
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.
![](./media/image2.png)
# Forward Looking
There is much that could be done with OpenWiFi and Meta Connectivity Leads are moving forward. The alignment of how to introduce advanced services for Wi-Fi or as we term it Network Slicing for Wi-Fi as a Service, could help enable a much deeper end-to-end view of subscriber, service, and quality.
Ideally the outcome is the subscribers service follows them with the network—dynamically adjusting to this request—as opposed to today's model of the subscriber following the network using fixed provisioning.

View File

@@ -0,0 +1,17 @@
# OpenWiFi SDK
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.
![](./media/image10.png)

View File

@@ -0,0 +1,28 @@
# Open Source First
TIP OpenWiFi is an Open Source project offered by the TIP Open Converged Wireless Project Group. TIP OpenWiFi ensures there are no moments of vendor lock in. Contributions to the Open Source are managed by maintainers to ensure compliance with BSD license and TIP charter, additionally the end-to-end architecture is curated to ensure an open environment.
## 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](https://cdn.brandfolder.io/D8DI15S7/as/q7rnyo-fv487k-d2tvpc/Bylaws)
- [Telecom Infra Project Organizational documents](https://telecominfraproject.com/organizational-documents/)
- [TIP Document IPR Policy](https://cdn.brandfolder.io/D8DI15S7/as/q7rnyo-fv487k-7qoext/Document_IPR_Policy_-_Telecom_Infra_Project.pdf)
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.
To contribute to the project, you must sign up to become a member 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 bi-weekly on Mondays. For meeting schedules and additional information, see the [OpenWiFi Project Confluence](https://telecominfraproject.atlassian.net/wiki/spaces/WIFI/overview>) wiki.

View File

@@ -0,0 +1,75 @@
# Device Provisioning
![](./media/image12.jpeg)
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.
![](./media/image13.png){width="6.4in" height="3.0in"}Use the SDK UI to assign a device to a venue, review device configurations, update record tags or delete a device.
![](./media/image14.png)
### 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.
![](./media/image15.jpeg)
![](./media/image16.png)
## Provisioning Templates
Use the Create Configuration window to create a configuration template for a specific venue or device.
![](./media/image17.png)
![](./media/image18.png)
![](./media/image19.png)
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.

View File

@@ -0,0 +1,7 @@
# Firmware Management
One of the highest management costs for operators is delivering firmware to the production network.
TIP OpenWiFi provides an out-of-the-box firmware management service—controlled using the Firmware dashboard or the firmware API.
![](./media/image11.jpeg)

View File

@@ -0,0 +1,87 @@
# SDK Integrations
You can extend deployment opportunities using 3^rd^ party integrations with the TIP OpenWiFi SDK. For example, using 3rd party integrations, you can create a controller of multiple services including device provisioning, firmware management, network management, service assurance, subscriber authentication, captive portal services, IoT and various 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.
![](./media/image20.png)
In service provider access, commonly non fixed subscribers are served via 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 WAG (Wireless Access Gateway) 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.
![](./media/image21.png)
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.
![](./media/image22.png)
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.
![](./media/image23.jpeg)
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.
![](./media/image24.jpeg)
### 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.
![](./media/image25.jpeg)
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.
![](./media/image26.jpeg)
![](./media/image27.jpeg)
### 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.
![](./media/image28.png)
![](./media/image29.png)
![](./media/image30.png)
### 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.
![](./media/image20.png)
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.
### Summary SDK Integrations
![](./media/image31.png)

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 134 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 183 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 146 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 162 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 65 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 84 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 61 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 278 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 204 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 214 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 154 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 204 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 215 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 557 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 245 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 350 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 435 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 275 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 214 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 348 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 348 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 249 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 675 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 265 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 211 KiB

View File

@@ -0,0 +1,29 @@
# TIP OpenWiFi Stack
The TIP OpenWiFi SDK and the AP network operating system (AP NOS) firmware serves many use cases. With TIP OpenWiFi, the entire 'stack' from the SDK to the firmware can be consumed—lowering the cost of entry and time to market of a new entrant.
![](./media/image3.png)
![](./media/image4.png)
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.
![](./media/image5.png)
## Cloud or On-prem
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.
![](./media/image6.png)
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.
![](./media/image7.png)

View File

@@ -0,0 +1,13 @@
# Hardware Platforms
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, Wallys, Lindsay, HFCL and Inventum.
![](./media/image8.png)
## Supported Hardware
The table below lists the supported hardware.
![](./media/image9.png)

5
whats-new.md Normal file
View File

@@ -0,0 +1,5 @@
# What's New in this release
TIP OpenWiFi 2.6 _description
Add a list of new features and descriptions - where necessary, include a link to a task describing how to use the new feature.