Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Root Certificate Trust
TIP OpenWiFi program ensures unique identity of all devices, encryption of traffic to and from the management cloud, discovery of management cloud, and ability to change device to cloud service discovery. TIP model ensures worldwide Zero Touch Provisioning, unique identity of all device and cloud conversation with no vendor lock in.
TIP device and cloud partners in OpenWiFi are uniquely managed members within a division of the Telecom Infra Project CA within DigiCert.
TIP ODM partners have the ability to generate signed certificates from the TIP Root Certificate Authority. This is done during manufacture for any TIP SKU product using signed certificates.
Each ODM partner will use the Manufacturer name, device MAC address, and optionally a value for Redirector and Model of device when requesting a new certificate.
The Redirector value is what determines cloud discovery and may be empty for example if the devices being manufactured do not yet have a cloud service provider assigned, for example a retail distribution model. Alternatively the value of the Redirector may be set at the same time as the certificate generation occurs.
TIP provides an automated script to perform the device certificate request.
TIP Cloud partners have the ability to generate signed certificates for the cloud SDK.
Similar to device onboarding, TIP provides a script to automate this process. For the cloud components the Operator name and a Fully Qualified Domain Name of the cloud are sent with each cloud key request. In addition, local configuration files are set in the request script to generate certificates matched to the operating name of certain services such as the opensync-controller and the mqtt-broker.
Each device on initial startup or when factory reset will connect to the Certificate Authority using its unique device credentials requesting its current 'cloud' value. This functions both as cloud discovery as well as redirector in the event the device owner wishes to change the cloud or cloud service provider relationship with their device.
In certain situations, a connection to the cloud or the root authority may not be possible. When this occurs, each TIP OpenWiFi Access Point device on factory boot presents an initial configuration Wi-Fi Management SSID called 'Maverick'. Connecting to Maverick presents a web page where updating WAN interface settings and the fully qualified domain name of the cloud may be entered.
When the device is a PoE Ethernet switch, a local management interface exists where the same configuration of cloud and WAN are possible.
There are two ways to get started with TIP OpenWiFi. For those interested in 'rolling their own' feel free to continue through the Cloud SDK Installation and related information to configure and consume the open source stack. Note you will need to join the TIP Open Converged Wireless PG for this.
Interested in getting started with a partner? Obtaining a TIP AP directly or via a partner is simple and these partners will help setup cloud trial environment with you.
Consuming Open Source Stack
Consuming the stack is exciting, and up to you how to integrate into a complete solution. Accessing the source code is free: Github
Understanding how to consume the project needs membership with the Telecom Infra Project Open Converged Wireless group: Join OCW Group
There is no fee to join, once you are approved, access to Confluence, JIRA, Slack will all be included in addition to the ability to check in and contribute code to the project.
Deploying the TIP OpenWiFi solution into a lab or into production is simple to do. Some basic pre-requisites should be satisfied before beginning.
Ensure the following are known before beginning installation:
Fully Qualified Domain Name (FQDN) is available and configurable
Internet Protocol (IP) subnet with Dynamic Host Configuration Protocol (DHCP) for access points is available
Internet Protocol (IP) subnet with static addressing is available for Cloud SDK
If using VLAN features of the access points, an IEEE 802.1q compliant Ethernet switch and VLAN topology are supported in your network
Network traffic is permitted for the following ports from Access Points to Cloud SDK:
80
443
1883
6640
6643
All TIP Open Wi-Fi devices implement discovery of the cloud SDK through a Zero Touch Provisioning design based on the unique signed certificate present on each device.
Each device contacts the Certificate Authority (CA) using its certificate credentials to lookup the current value of the cloud SDK.
Once the configured cloud is returned from CA to the device, a connection is created to the cloud SDK where provisioning of the device will occur.
For more information on cloud discovery, devices and obtaining keys please proceed to the next section.
For questions on how to obtain keys or support related to certificates please contact: licensekeys@telecominfraproject.com
Telecom Infra Project Open WiFi
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. OpenWiFi offers premium managed Wi-Fi features, local break-out design, cloud native open source controller, and an open source AP firmware operating system tested nightly.
TIP OpenWiFi is the industry's first CI/CD open source Wi-Fi eco-system. Built nightly with a strong community of Wi-Fi leaders, new features are unit tested in automated RF chambers and checked from cloud to ground for Wi-Fi performance and conformance.
Zero Touch Provisioning
Firmware Management
Integration Northbound Interface (NBI) RESTful
Data model driven API
Template based device provisioning with RADIUS profile management
Advanced RF control with RRM
Multiple topologies including Bridging, Virtual LAN, NAT Gateway, Local Breakout, Overlay
Multiple authentications WPA2, WPA3, Enterprise Radius models
Passpoint® Release 2 and above
Zero Touch Provisioning
Captive Portal
OpenWiFi AP Detail List:
Wi-Fi 4 (n) Wi-Fi 5 (ac) Wi-Fi 6 (ax)
Dual Bank Bootloader
Multi-SSID per Radio
SSID Authentications: WPA/WPA2/WPA3 - Mixed, Personal, Enterprise
Un-Authorized Device Control
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
Embedded Captive Portal (Local Splash non-auth)
Link Layer Discovery Protocol (LLDP)
Airtime Fairness
Wireline & Wireless Tracing (PCAP Cloud Remote Troubleshooting)
Synthetic Client (Cloud Remote Troubleshooting)
Flight Recorder (Stack Remote Collection)
Local Provisioning over SSID (when Cloud or WAN down)
Multimedia Heuristics (Detection of Unified Communication Sessions)
SSID Rate Limiting
Inter-AP Communication (Client - Session Signalling)
Client / AP / Network Metric Telemetry (MQTT)
Cloud SDK additional features
Provisioning
Device Identity (Model, MAC, Serial Number)
AP Software Upgrade
Profile Provisioning Templates
Multiple SSID Configuration
Bandwidth Rate Control per SSID
Multi-Radio 2.4/5GHz control
AP Network Mode Control (Bridge/NAT mode)
Basic Captive Portal (Local Splash Page admin from Controller)
Security (WPA2/WPA3 Personal/Enterprise Mixed)
VLAN per SSID
NTP Enable/Disable
RTLS (Location Services) Enable/Disable
RF Control
Wi-Fi Agile Multiband
(k) Client Radio Resource Management - Directed Steering
(v) Network Assisted Roaming
(r) Fast BSS Transition
RRM Location AP Channel Table Provisioning
RRM Location AP Cell Size Table Provisioning
RRM Location Client Steering Threshold Table Provisioning
Remote Troubleshooting and Service Assurance
Syslog
Synthetic Client
Remote DHCP, RADIUS, UE Network Analysis
Remote Shell
Remote Packet Capture Analysis
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.
OpenWiFi Cloud SDK may be deployed to both public and private cloud environments.
Helm charts support automated deployment of the Cloud SDK PODs and containers into AWS and MicroK8s Kubernetes platforms.
The following pages provide step-by-step instructions to deploy in public cloud (AWS) or private on-premises (MicroK8s) cloud.
TIP Controller Local Deployment
MicroK8s deployment is available as part of Release 1.0 candidate. API services, database, message bus and ability to adjust Kubernetes POD performance parameters are all possible with this system which may be useful to the Community for local on premises installations.
A snap capable operating system is required for MicroK8s installation. TIP Controller has been installed on an Ubuntu 20 system with 32Gb memory, 500Gb disk and Gigabit Ethernet network interface with a user account tip created.
The system should have a fully qualified domain name and the deployment of TIP controller will require additional DNS records to be created.
Local /etc/hosts should contain the following DNS entires for your controller assigned to the IP address your machine is using to connect to the network. This same IP will be used when configuring metallb address in a subsequent step.
When accessing the UI from a workstation or when AP is connecting to the local controller the local DNS server will need to provide authoritative response for these A records in the wlan.local domain. In a future release of TIP Controller instructions will be provided to modify the FQDN of all Controller services.
DNS default entries for /etc/hosts
Install microk8s
The above specifies latest stable release will be installed
Set user permissions
source or re-login to shell for environment to be applied to current user ($USER)
Setup MicroK8s
metlalb will request an IP address range. Specify the IP of Gigabit Ethernet interface. If your interface address is 10.1.1.10 then provide metallb with: 10.1.1.1-10.1.1.10
TIP Controller may be deployed with self-signed certificates for a local lab environment. The following steps will guide the reader through that process.
Install Keytool and Zip Packages
Enable Firewall to permit Controller traffic from Container Network Interface
Change to a directory for configuring certificates and running controller. This can be within the tip home directory.
This step only applies when using locally built AP images. All devices purchased via ODM partners from factory will ship with TIP Signed keys. Updating Redirector value for the device is the recommended way to connect to a local Cloud SDK
From the current directory, two sub-directories now exist for wlan-pki-certs and wlan-cloud-helm.
Enter the PKI directory and the configs sub-directory cd /wlan-pki-cert-scripts/configs
Modify all certificate configuration files for the value of your organizationalUnitName_default value set to your organizational name or other string value used in each of the PKI certificate files. Optionally this may be left unchanged.
Within the following files, ensure the FQDN (Fully Qualified Domain Name) based on local setup for DNS aligns accordingly. The following files are updated per:
mqtt-server.cnf
commonName_default = opensync-mqtt-broker.FQDN
openssl-server.cnf
DNS.1 = opensync-redirector.FQDN
DNS.2 = opensync-controller.FQDN
Once complete generate the service certificates and copy these to the controller.
Note within the wlan-pki-cert-scripts folder, a subfolder /generated is present after key creation.
The AP.zip archive in the generated folder contains the Access Point certificates for loading onto APs in the AP /usr/opensync/certs device folder
TIP controller defaults to a domain of wlan.local. It is possible to operate a lab DNS service permitting local resolution of this domain for the TIP controller services. Certificate instructions for a self-signed private domain will follow in a subsequent release of service and documentation.
Helm will deploy the Controller containers within a TIP namespace to microk8s on the machine.
To check status of the PODs, Services, and Persistent Volume Claims (storage) use the following commands. Please note, depending on your server, all PODs may take several minutes to fully initialize.
Get svc will return the network Services of each container port maps as well as list of containers mapped to external IP address defined during the metallb config stage earlier.
Get pvc will return the Persistent Volume Claims of the containers to the microk8s storage service
Get pods will return the current state of all containers. The controller will require two to four minutes for all pods to reach 'Running' state.
Examples of all three commands:
In the earlier stage when self-signed keys were created for the controller, keys were also created to support Access Point connections over SSL to the newly deployed controller.
To obtain these keys, return to the /wlan-pki-cert-scripts/generated folder and copy AP.zip containing the Access Point keys.
Extract this archive and using sing secure copy (SCP) transfer keys to the /usr/opensync/certs folder on the AP.
The above assumes the microk8s system has IP connectivity to the Access Point If this is not possible, copy the AP.zip file to a machine that will have SCP access to the AP, extract the files and copy to the AP folder per above.
In the current release of a TIP Controller using self-signed certificates, Access Points communicate to the TIP Controller using OpenSync. Access Points are directed to the controller at this time using local configuration.
The default TIP Open AP username and login are 'root' and 'openwifi'
The IP address (or FQDN) are the same as the metallb exposed External IP as shown in earlier steps
TIP Controller Deployment Instructions
The following must be available to start this installation:
AWS Account
AWS Route 53 Hosted Zone
The steps outlined in this guide will create a local installation of the Terraform automation environment that will also depend on the AWS command line interface, Helm and Kubectl local command line packages.
Each of these applications provide detailed instructions for installation on multiple client operating systems.
Install Kubectl https://kubernetes.io/docs/tasks/tools/install-kubectl/
Install Helm https://helm.sh/docs/intro/install/
If the instructions for Terraform were followed, a Docker container was locally created, nginx was run with a default localhost:80 nginx returned web page displayed. After which 'terraform destroy' was run to remove the local test of Terraform.
If the instructions for AWS CLI were followed, AWS CLI version 2 has been installed. This may be verified using the command which aws and aws --version. If these succeed installation of AWS CLI has completed.
If the instructions for Helm were followed, Helm has now been locally installed. This may be verified using the command which helm and helm version. If these succeed installation of Helm has completed.
If the instructions for Kubectl were followed, Kubectl has not been locally installed. This may be verified using the command which kubectl and kubectl version --client. If these succeed installation of Kubectl has completed.
If any of the above have not completed, please refer back to the specific install instructions from the package provider listed in the Prerequisite links accordingly before continuing.
Access to AWS should have been satisfied with an AWS account as noted in Prerequisites. This account is entitled with Administrator level permissions. For information on this process please refer to: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html
Create a workspace on your local system and clone in the TIP Controller project.
Create a Terraform file in the aws-cloudsdk directory named aws.tfadding the following to that new file:
If a specific authentication method previously exists depending on your local machine environment when connecting to AWS, adjustments may be required. Please consult Terraform instructions accordingly: https://registry.terraform.io/providers/hashicorp/aws/latest/docs#authentication
Terraform will use the initial configuration of your environment variables from the previous step when communicating with AWS. Prior to initializing Terraform, ensure authentication is successful.
Within the /wlan-cloud-helm/terraform/aws-cloudsdk directory, copy the terraform.tfvars.sample file to terraform.tfvars and edit the content of the new terraform.tfvars replacing parameter values for cidr and route53_zone_name accordingly:
Once these steps have been completed, it is now possible to deploy the TIP Controller to AWS.
If Terraform is able to connect and authenticate to AWS, a prompt to accept the creation of the deployment is presented. Answer yes to proceed. Terraform will execute for 10-15 minutes during which time the following are being configured:
EKS cluster with three nodes where CloudSDK will run on
VPC for the EKS cluster
ACM that will sign the certificate for the public HTTPS services exposed by CloudSDK
Route53 record to let ACM know that you own the domain
external-dns that will take care of creating DNS entries for all CloudSDK components
aws-load-balancer-controller which will take care of exposing CloudSDK components to the public
Required IAM roles for all components
When Terraform completes the following should have emitted:
Apply complete! Resources: 57 added, 0 changed, 0 destroyed.
Outputs:
acm_arn = "arn:aws:acm:ca-central-1:1xxxxxxx68:certificate/7e3xxxx7-74xx-4xxx-8bef-d6xxxxxx5a3"
TIP Controller services use SSL certificates to ensure inter-service security. These certificates must be generated. To generate TIP Controller certificates, navigate out of the tip-wlan-cloud directory to a directory where cloning the TIP PKI repository may occur:
Enter the PKI directory and the configs sub-directory cd /wlan-pki-cert-scripts/configs
Modify all certificate configuration files for the value of your organizationalUnitName_default value set to your organizational name or other string value used in each of the PKI certificate files. Optionally this may be left unchanged.
Within the following files, ensure the FQDN (Fully Qualified Domain Name) based on the Terraform setup for Route53 hosted-zone aligns accordingly. If the defaults were not changed Terraform will have created a sub-domain cloudsdk within the supplied Route53 hosted-zone. The following files are updated per:
mqtt-server.cnf
commonName_default = opensync-mqtt-broker.cloudsdk.route53hosted-zone_name
openssl-server.cnf
DNS.1 = opensync-redirector.cloudsdk.route53hosted-zone_name
DNS.2 = opensync-controller.cloudsdk.route53hosted-zone_name
To generate keys, ensure necessary Java resources are installed for your operating system:
openjdk-11-jre-headless
default-jdk
From within the wlan-pki-cert-scripts folder execute ./generate_all.sh script.
Copy the generated keys assuming the wlan-cloud-helm folder is at the same level as the wlan-pki-certs folder per: ./copy-certs-to-helm.sh ~/wlan-cloud-helm/
Note within the wlan-pki-cert-scripts folder, a subfolder /generated is present after key creation.
The AP.zip archive in the generated folder contains the Access Point certificates for loading onto APs in the AP /usr/opensync/certs device folder
Certain TIP Charts have upstream dependencies, form the wlan-cloud-helm folder execute:
Various Bitnami charts will be brought into the deployment such as Kafka, PostGres, Cassandra.
Localizing the Helm charts for AWS is a critical step. Editing the following file
Key variables to replace in this file are:
alb.ingress.kubernetes.io/certificate-arn: "Enter the ARN supplied during terraform output"
All locations with a URL or FQDN align to your AWS environment such as:
external-dns.alpha.kubernetes.io/hostname: wlan-filestore.cloudsdk.route53hosted-zone
ovsdb: opensync-controller.cloudsdk.route53hostedzone
mqtt: opensync-mqtt-broker.cloudsdk.route53hostedzone
All occurrences of a URL or FQDN within this file replacing route53hostedzone with your deployed Route53 hosted zone name
Local Kubeconfig is associated to the AWS service to enable Helm control of EKS resources by entering the following:
With all dependencies met, certificates created and in place, using Helm and the authenticated session to AWS, execute the following:
If a connection error occurs, AWS CLI may need to re-authenticate. This can be done with aws configure.
If Helm has a successful connection to AWS the following returns:
Release "cloudsdk" does not exist. Installing it now.
NAME: cloudsdk
LAST DEPLOYED: Sun Feb 7 14:00:28 2021
NAMESPACE: tip
STATUS: deployed
REVISION: 1
TEST SUITE: None
To check on status of PODs now launching in AWS enter kubectl get pods -n tip to return results from the operational EKS Kubernetes CloudSDK cluster:
After 5 to 8 minutes elapse, all POD services should be operational for example:
Navigate to https://wlan-ui.cloudsdk.yourdomainname
Default username support@example.com and password support
TIP Cloud SDK
TIP open source SDK offers a web based user interface supporting many common configurations. The web based interface uses the SDK north bound API.
It is possible to further extend functionality of the SDK user interface or to create other interfaces using the SDK API.
Default user account is support@example.com with password support.
If using the self-signed certificates provided in the open source distribution, it will be necessary to add an exception to the web browser for the following URLs:
Further instructions available here.
TIP OpenWiFi devices are available from many hardware partners. All TIP OpenWiFi devices have the same standard image of open source software.
TIP OpenWiFi 1.0 devices run OpenWrt operating system with OpenSync as a management stack. The use of OpenWrt is largely upstream based on OpenWrt 19.07 in Open WiFi 1.0.
When a TIP firmware image is created, the system will merge TIP specific patches, kernel specific patches, and build this with the target OpenWrt 19.07 operating system as one complete firmware image. From this process a TIP OpenWiFi standard firmware results with the following settings.
If the OpenWiFi device has been unable to reach the internet or the assigned controller, the 'Maverick' SSID will appear. Joining this Wi-Fi network will join the local management interface to help onboard the device to the internet and controller.
After joining Maverick SSID, opening a web browser to the address 192.168.1.1 where the following login displays. Enter root login and password.
Common setup to enable internet access is available. WAN interface defaults to DHCP, if the WAN requires static configuration select the drop down to continue:
Changing the Local Area Network is also possible from Maverick mode. There may be cases where an IP overlap has occurred in certain double NAT internal networks. For this reason it may be necessary to change this value, else no change is required here:
It is possible to apply a firmware update from the Maverick interface. This operation is normally performed by the controller however in the event it is desired, have the sysupgrade image downloaded locally before continuing:
Manually setting the cloud location may be done using its Fully Qualified Domain Name (FQDN) in the Redirector field. Device certificates are unique per TIP Open WiFi access point or switch. It should not be required to change these values at any time. Please exercise caution if replacing certificates manually.
Cloud SDK Default Landing Page
TIP Cloud SDK is organized into main components presented along the top of the screen.
Dashboard is the default landing page for the user interface. Network enables management of Access Points and display of Client Devices status. Profiles enables template based management of all provisioning parameters. System enables Manufacturer OUI Updates, Firmware Updates, Auto-Provisioning and Client Block List. Users enables configuration of local user accounts of the Cloud SDK. Alarm indicates an error condition has occurred with one or multiple Access Points. Gear icon to Log Out.
Component | Description |
Access Point | Total Provisioned Access Points In Service Access Points ( Actively Reporting ) With Clients ( Actively Reporting and with Associated Wi-Fi Devices ) |
Client Devices | Total Associated as a numeric total of associated Wi-Fi clients 5GHz as a numeric total of associated Wi-Fi clients over 5GHz 2GHz as a numeric total of associated Wi-Fi clients over 2GHz |
Usage Information | 24 Hour Report of total bandwidth Upstream and Downstream across all Access Points |
Inservice APs | 24 Hour line graph of Actively Reporting Access Points |
Client Devices | 24 Hour line graph of Associated Wi-Fi Client Devices |
Traffic | 24 Hour line graph of Total Traffic Upstream and Downstream |
AP Vendors | Pie Chart graph of AP Vendors by Organizational Unique Identifier |
Client Vendors | Pie Chart graph of Client device Vendors by Organizational Unique Identifier |
Defaults
Values
Login: root
Password: openwifi
Default LAN
192.168.1.1/24
Default WAN
DHCP
TIP OpenWiFi
With the Cloud SDK now installed into either a public cloud or on premises, logging in with default username support@example.com and password support are now possible.
Once successfully logged in, please refer to User Interface documentation for further details of specific configuration.
Current TIP Cloud SDK deploys using self-signed certificates. This requires accepting the self-signed certificate in the UI for the following URLs: https://wlan-ui.wlan.local https://wlan-ui-graphql.wlan.local Navigate to both URLs and accept the certificate exception. Once the client browser has these certificate exceptions loaded login will succeed.
Cloud SDK Accounts
Cloud SDK local accounts support user interface and API connections. Adding and removing accounts from the web user interface may be completed from the Users navigation tab.
Select 'Add User' to create a new Cloud SDK user, assign a Role and password.
Manage Devices and Monitor Clients
From the Network page it is possible to create organizational regions to group devices within, view all devices, retrieve individual device records and view all associated and disassociated client devices.
In a future release it will be possible to assign devices to new locations to help in building an administrative hierarchy supporting convenient organization of device to service location. This functionality is exposed in the API and may be further refined in subsequent open source UI releases.
For each access point that has contacted Cloud SDK, a row will populate within Access Points. Specific information for each device including Device name, alarm state, model and IP address are shown.
Along the right side of each Access Point row are Profile, Channel, Occupancy, Noise Floor and Devices. Channel indicates the current provisioned RF Channel for each radio in the device. Occupancy indicates available RF bandwidth for Wi-Fi clients as a value over 100. Noise Floor represents the reported RF noise condition being measured by the device within the operating channel and reported to the Cloud SDK. Devices indicated the total associated clients for each radio in the access point.
Each access point managed by Cloud SDK inherits provisioning information from Profiles in addition to supporting device specific configurations and reporting device specific operating conditions.
General information includes device name, model, MAC address and country of operation. Status presents operating conditions for each frequency band of operation in addition to Alarms. Location permits the assignment of the device to a location in Cloud SDK hierarchy tree.
Operating System Stats are sent to Cloud SDK from each device using the MQTT interface. These statistics are regularly received as part of the overall telemetry stream.
The Cloud SDK may initiate an on demand firmware upgrade for any associated device. The Active Version of firmware is reported to the Cloud SDK. If the reported version from the device is not part of the System known firmware, the status will be 'UNDEFINED'.
Several TIP devices implement a secondary boot loader bank which Cloud SDK supports the method to command a device to 'Switch to Inactive Bank and Reboot' .
To initiate a firmware upgrade, select a version from the drop down within Upgrade, select the 'Download, Flash, Reboot' button.
Within the Firmware sub-tab, Reboot AP button. Selecting this will cause Cloud SDK to send a warm reboot command to the Access Point.
General Settings
Cloud SDK System configuration permits uploading OUI data file to assist with device fingerprinting as shown on the initial dashboard landing page dials.
Obtain the OUI file locally and upload to Cloud SDK via Device Manufacturer
Firmware image upgrades may be triggered from the Cloud SDK. It is necessary to populate Cloud SDK with Model Target information. If your model is not displayed select Add Model Target Version then proceed to defined a firmware version for use.
Note a local web service should be reachable by deployed AP devices from the Fully Qualified Domain Name and file path configured in this step
Adding firmware version:
When returning to the Network and selecting an Access Point, available Firmware will be presented for actions on a per device basis.
Locations defined within the Cloud SDK may be auto-provisioned by default or subject to pre-provisioning logic in the Cloud SDK. When a device associates to the Cloud SDK, a Model : Profile match will be attempted in Auto-Provisioning mode.
If any client should be denied access to any Wi-Fi service visible to Cloud SDK management it may be added through the global Client Blocked List.
Type | Role |
RF | Radio Frequency configuration parameters |
SSID | Service Set Identifier |
RADIUS | Authentication Authorization Accounting Configuration per SSID |
Equipment AP | 1:1 or 1:Many Device Association to RF Profile and SSID |
Captive Portal | Access Point Captive Portal configuration parameters |
Passpoint | R1 & R2 Compliant IEEE 802.11u configuration parameters |
Passpoint ID Provider | R2 Compliant Offload, Venue, NAI and OpenRoaming configuration parameters |
TIP OpenWiFi project is a data-model driven design, meaning the features in the solution are designed as interfaces to be consumed either by micro-services, network devices, or other applications integrating with the solution.
The most useful way to learn the TIP OpenWiFi API is to consume the Swagger interface that fully describes all implemented REST methods.
TIP OpenWiFi controller uses OAuth for authentication. A bearer token must first be obtained for subsequent API calls to succeed.
Use the value from access_token for subsequent API calls into the controller
Cloud SDK Profile Use
Cloud SDK processes Profiles by aggregating certain profile types as child profiles inherited during device configuration.
Association of devices to Access Point and SSID is possible as one-to-one (1:1) or one-to-many (1:M). The decision on using 1:1 or 1:M is entirely based on the desired deployment.
Creating a 1:1 Access Point Profile could be useful in certain lab or specific network locations. If a specific RF Profile was desired on a select device, using an Access Point Profile with reference to the specific RF Profile would accomplish this provisioning logic.
Creating an RF Profile specifically for IEEE802.11ac Wi-Fi 5 Access Points to inherit may be a common approach with another RF Profile for all IEEE802.11ax Wi-Fi 6 Access Points. Another reason to create a unique RF Profile may configured outdoor RF configuration that is unique from other indoor based Access Points.
Creating RF Profile with specific Client Steering, Channel Hop, or general radio operation other than default settings are useful when defining behavior of Access Points individually or as a large group of managed devices.
Example Wi-Fi 5 IEEE802.11AC RF Profile:
Example Wi-Fi 6 IEEE802.11AX RF Profile
Profile
Provisioning Role
RF
Radio Operations
Access Point
LAN & GRE Configuration
Association to RF Profile
Association to SSID Profile
SSID
Service Set Identifier Wireless Network Operations
Device Profiles
TIP SDK will process a 1:1 (one to one) or 1:Many (one to many ) association of Access Point Profile offering a number of possible configuration approaches.
When configuring in a 1:1 approach, it is advised to name the Access Point Profile in a manner meaningful to the deployment, for example Profile Name including significant OUI information.
When configuring in a 1:M approach, it is advised to name the Access Point Profile in a manner meaningful to the shared service, RF parameters or grouped function all Access Points of this Profile will inherit.
Within the Access Point Profile, RF configuration all device members will share is specified.
One or many SSID Profiles may be associated to the Access Point Profile.
Relationship of RF Profile and Access Point Profile is visible in the Network, Access Point device record.
Example inherited Profiles to an Access Point device:
L2 Wi-Fi to WAN/LAN
When bridging an SSID this has the affect of moving the SSID virtual interface from the 'LAN' side of an Access Point to the 'WAN' side of an Access Point.
Bridging SSID is configured within Profiles, SSID Profile:
Create a Profile of type SSID
Assign a Profile Name
Create the SSID
Assign SSID Name
Set related optional SSID parameters
Network Connectivity
Ensure Mode is set to Bridge
Security and Encryption
Set a Mode and related security for the SSID
IEEE 802.1Q VLAN over IEEE 802.11 SSID
When assigning an SSID to a VLAN, this has the affect of adding the Virtual LAN inner tag to the header of Ethernet frames once Wi-Fi client traffic reaches the Access Point for forwarding onward over Ethernet.
The 'WAN' side of the Access Point will present an Ethernet sub-interface with the Virtual LAN identifier equivalent to VLAN set duing SSID creation.
802.1Q VLAN SSID is configured within Profiles, SSID Profile:
Create a Profile of type SSID
Assign a Profile Name
Create the SSID
Assign SSID Name
Set related optional SSID parameters
Network Connectivity
Mode is set as Bridge
Security and Encryption
VLAN is set to 'Use Custom VLAN'
Enter desired value from 2 - 4,095
Once the SSID Profile configured for a unique VLAN is associated to an Access Point, clients will receive DHCP, Routing, DNS from the Virtual LAN of the upstream network provider
Online and Local Open API Access
TIP Open Wi-Fi controller implements an Open API compliant NorthBound Interface (NBI) to assist with integration and related back office features.
Cloud SDK north bound API is a key function for most open source community members or vendors seeking to consume the SDK for integration or for value added software development above the SDK layer.
Swagger is a useful tool to explore and learn any system API. Both online and local options are available to help development teams consume the Cloud SDK.
Running a local Swagger instance requires a current version of NodeJS installed.
Current SDK open API is available at the following URL: CloudSDK Open API
When running a local instance of Swagger, first obtain the most current Cloud SDK open API from source control:
With Swagger running, open the Open API data model file and begin to use locally on port 9091 or add your own TIP Open Wi-Fi controller to the Swagger definitions. Remember to obtain an OAuth bearer token to 'Authorize' your session.
Configuring AP as a Gateway
When defining an SSID in NAT mode, this has the affect of isolating all SSID virtual interface traffic in Layer 2 and Layer 3 behind a NAT function inside the Access Point.
The Access Point will use its 'WAN' interface as the public facing IP address for clients behind the SSID associated to NAT mode operation.
NAT mode SSID will have a local DHCP service enabled by default with an address range of 192.168.1.0/24 where the first address is used by the Access Point as the SSID NAT LAN interface serving as default gateway address to all associated UE clients.
NAT SSID is configured within Profiles, SSID Profile:
Create a Profile of type SSID
Assign a Profile Name
Create the SSID
Assign SSID Name
Set related optional SSID parameters
Network Connectivity
Ensure Mode is set to NAT
Once the SSID Profile is associated to an Access Point, clients will receive DHCP, Routing, DNS from the Access Point 'LAN' side
SSID Profile for RADIUS
A common deployment model is to use a RADIUS system for authentication of client devices. Cloud SDK supports this using a RADIUS type Profile.
Defining a RADIUS Profile requires a Name, RADIUS server IP, shared secret and port. Default port for Authentication and Authorization is 1812 and Accounting is 1813. Cloud SDK does not assume these defaults, they must be entered as each deployment may choose to change these values.
It is possible to configure independent authentication from accounting as these services may be unique for some operators.
The RADIUS Profile is associated with a Security and Encryption Mode of an SSID Profile. For example, any Enterprise mode for WPA & WPA2 will depend on RADIUS. Select the desired RADIUS Profile from drop down and set the desired accounting interval in seconds.
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
Passpoint®
TIP OpenWiFi devices implement support for both the air interface and systems interfaces necessary to support Passpoint® Release 2 and above. Once also termed Hotspot 2.0, IEEE 802.11u specified added air interface fields exposing Access Network Query Protocol interactions for clients to discovery Access Point capabilities.
Wi-Fi Alliance expanded ANQP to include Online Signup (OSU) concepts to leverage seamless onboarding and client security for Passpoint® networks. Following on from these efforts, Wireless Broadband Alliance has provided the necessary system interfaces for identity, security, mobile offload within a common federated operator solution known as OpenRoaming.
TIP OpenWiFi enables operators to deploy the full range of Passpoint® and OpenRoaming solutions.
Term
Description
Operator
Wi-Fi Infrastructure Operator
Access Network Provider (ANP) as defined by OpenRoaming
Venue
Deployed location of Wi-Fi service
Identity Provider
Subscriber authenticating service provider
Home Service Provider (HSP) as defined by OpenRoaming
Roaming Exchange
Operator and Identity Provider Authentication, Authorization, Accounting
ANQP
Access Network Query Protocol contains:
Domain
Venue Name
Venue Info
Operator Friendly Name
IP Type
WAN Metric
Connection Capability
Operating Class
Authentication Type
Service Providers List
GAS
Generic Advertisement Layer 2 Service for client query
Client query returns:
Organization Identifier / Service Provider Identity
Domain
Authentication
Roaming Consortium List
Network Access Identifier Realm (NAI)
3GPP Network Data
OSU
Online Signup - Advertised over ANQP contains:
OSU SSID
OSU URI
OSU Method
OSU Available Icons
OSU ESS (OSEN) SSID
OSU Description
OSEN
OSU Server Authenticated Layer 2 Encryption Network
Passpoint® Setup
In earlier sections of OpenWiFi documentation, the association of Access Point Equipment and SSID Profiles were described.
For Passpoint® configuration, each Equipment Profile may reference multiple SSID Profiles. Within the SSID Profile, an association to RADIUS and Passpoint® Profile is made.
From the Passpoint® Profile, an Operator, Venue and multiple Identity Providers are defined.
Passpoint®
Passpoint® requires ANQP to supply three information elements from the Access Point.
Public Land Mobile Network Id is defined by 3GPP and comprised of two, three digit numbers to uniquely identify the Mobile Network Operator (MNO).
A Fully Qualified Domain Name (FQDN) is a realm representing the service provider of the Wi-Fi service. Non MNO operators are an example of 'realm-based' service advertisements. Examples include Cable MSOs, Enterprises or other on MNO providers. Authentication methods used with realm-based configuration are EAP-TLS and EAP-TTLS.
Organization Id or as defined by Wireless Broadband Alliance, Roaming Consortium Organization Id indicate the federated identity capable of authentication. Examples would be OpenRoaming, Eduroam and follow the Passpoint® EAP authentication methods.
Passpoint® Configuration
Cloud SDK user interface enables all Passpoint® configuration needed for live service.
Passpoint® services will combine multiple Cloud SDK Profiles.
RADIUS
Passpoint
Passpoint ID Provider
Passpoint Operator
Passpoint Venue
Add a RADIUS Profile, specify the IP address and shared secret and port required for reachability and authentication and accounting with the defined server(s).
Each Operator of Wi-Fi services or Venue must be defined.
Network Access Identifier (NAI) Realm implements all possible EAP methods for authentications. When adding EAP method, select the appropriate configuration to the deployment.
Passpoint profile aggregates the other Operator / Venue, Identity Provider together, once joined to an SSID will be combined with RADIUS in terms of the Access Point processing logic for UE association and authentication.
Add Passpoint Profile
Associate to the SSIDs of network service:
Advertise type of IP Connectivity
Advanced settings support ANQP Domain ID, GAS Behaviors and DGAF operation
Passpoint® via API
Cloud SDK accepts all Passpoint® configuration via API if desired. Please refer to API for additional instructions on use of Cloud SDK OpenAPI.
For reference: Postman collection for Passpoint to assist the reader is available.
Open WiFi 1.0 SSIDs are mapped to a single RADIUS profile. All Authentication and Accounting will be forwarded to the RADIUS services defined in the Profile. Sub-release 1.1 supports realm-based forwarding and RADSec operations (RADIUS over TLS)
In the above example, an MNO with PLMN identifiers is configured. The result of this configuration will be a UE mobile handset learns its home network operator is available over Wi-Fi network and attempts authentication seamlessly. The MNO logo will display in the UE home screen top bar.
In the above example, a settled roaming provider part of the OpenRoaming federated RCOI has been defined. The UE device will automatically discover this network, for many devices with existing OpenRoaming credentials will seamlessly associate to the advertised service from this Wi-Fi network.
The above example demonstrates a realm-based identity provider configured for authentication using EAP-TTLS.
With all other profile configuration in place, the logical association of these profiles occurs within the Passpoint Profile.
RADIUS Profile and Passpoint Profile are both Child Profiles of the Access Point Equipment
