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

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

• Interface

• VLAN-Id

• SSID

• Encryption Mode

• Device Name

• Device Model

• Device Location

• Access Point MAC Address

• Access Point MAC in Hex

• Client MAC Address

• Client MAC Address in Hex

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

• VLAN-Id

• SSID

• AP-MAC

• AP-MAC-Hex

• Client MAC

• Client MAC Hex

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

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

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

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

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

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

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

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

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

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

OpenWiFi supports Zero Touch Provisioning in a number of ways.

• Zero Touch Mesh

• Zero Touch WDS

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

Onboarding

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

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

Onboarding Steps

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

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

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

   • Any radio(s) may be used

3. Firstboot devices with no WAN wired port detected will

   • Enable all radios

   • Scan for SSID "OpenWifi-onboarding"

   • Associate and when challenged use TIP certificate as identity

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

   • Connect to SDK, obtain provisioning from OpenWiFi Gateway service

   • Reload configuration

Zero Touch Mesh

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

In a Zero Touch Mesh deployment, the Gateway Access Point, sometimes termed the Root node, advertises mesh participating interfaces when "bss-mode": "mesh" is applied to an SSID. Please see Mesh for further details on initial setup.

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

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

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

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

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

Zero Touch WDS

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

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

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

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

With management network access, reachability for the WDS Client Access Point to the OpenWiFi Gateway should be possible, device provisioning stage will initiate with the production configuration being loaded to the client device. For more information on WDS configuration please consult WDS.

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

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

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

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

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            }
        },
        {
            "name": "GRE",
            "role": "upstream",
            "vlan": {
                "id": 20
            },
            "tunnel": {
                "proto": "gre",
                "peer-address": "far end IP address",
            },
            "ssids": [
                {
                    "name": "Tunneled SSID via GRE from VLAN 20 Interface",
                    "wifi-bands": [
                        "2G", "5G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "none",
                        "ieee80211w": "optional"
                    },
                    "rate-limit": {
                        "ingress-rate": 100,
                        "egress-rate": 100
                    },                    
                    "roaming": {
                        "message-exchange": "ds",
                        "generate-psk": true
                    }
                }
            ]
        },

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

Metrics

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

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

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

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

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

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

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

SSH

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

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

Associate Service to Interface

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

Operator Key Management

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

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

NTP

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

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

Associate to an Interface

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

LLDP

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

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

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

MDNS

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

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

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

Syslog

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

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

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

IGMP

When enabled the OpenWiFi device will process IGMP Proxy.

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

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

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

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

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

        {
            "name": "LAN",
            "role": "downstream",
            "services": [ "ssh" ],
            "ethernet": [
                {
                    "select-ports": [
                        "LAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "static",
                "subnet": "192.168.1.1/24",
                "dhcp": {
                    "lease-first": 10,
                    "lease-count": 100,
                    "lease-time": "6h"
                }
            }
        },
        {
            "name": "L2TP",
            "role": "downstream",
            "tunnel": {
                "proto": "l2tp",
                "server": " far end IP address ",
                "user-name": "secret-l2tp-username",
                "password": "secrectPassword"
            },
            "ipv4": {
                "addressing": "static",
                "subnet": "192.168.10.1/24",
                "dhcp": {
                    "lease-first": 10,
                    "lease-count": 100,
                    "lease-time": "6h"
                }
            },
            "ssids": [
                {
                    "name": "Tunneled SSID",
                    "wifi-bands": [
                        "5G", "2G"
                    ],
                    "bss-mode": "ap"
                }
            ]
        }
    ],

Wireless Distribution System (WDS) supports an Access Point, Station and Repeater mode of operation. OpenWiFi 2.0 supports all three.

In the below example, the LAN side of the Access Point at the top of the topology will be wirelessly bridged to the LAN side of the Access Point Station at the bottom of the topology.

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "services": [ "lldp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            }
        },
        {
            "name": "LAN",
            "role": "downstream",
            "services": [ "ssh", "lldp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "LAN*"
                    ]
                }
            ],
            "ssids": [
                {
                    "name": "OpenWifi_WDS_AP",
                    "wifi-bands": [
                        "5G"
                    ],
                    "bss-mode": "wds-ap",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    },
                    "roaming": {
                        "message-exchange": "ds",
                        "generate-psk": true
                    }
                }
            ],            
            "ipv4": {
                "addressing": "static",
                "subnet": "192.168.10.1/24",
                "dhcp": {
                    "lease-first": 10,
                    "lease-count": 100,
                    "lease-time": "6h"
                }
            }
        }
    ],

    "interfaces": [
        {
            "name": "WAN",
            "role": "upstream",
            "services": [ "lldp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            }
        },
        {
            "name": "LAN",
            "role": "downstream",
            "services": [ "ssh", "lldp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "LAN*"
                    ]
                }
            ],
            "ssids": [
                {
                    "name": "OpenWifi_WDS_AP",
                    "wifi-bands": [
                        "5G"
                    ],
                    "bss-mode": "wds-sta",
                    "encryption": {
                        "proto": "psk2",
                        "key": "OpenWifi",
                        "ieee80211w": "optional"
                    },
                    "roaming": {
                        "message-exchange": "ds",
                        "generate-psk": true
                    }
                }
            ],
    }

In this configuration, LAN clients of the WDS Station AP receive IP addresses from the WDS Access Point AP from its LAN side DHCP service, via WDS link at 5GHz.

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

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

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

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

                    }
            ]
        },

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

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

Quality of service for Wi-Fi involves multiple functions.

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

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

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

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

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

• Matches by port, range, and or DNS FQDN

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

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

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

How it works

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

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

OpenWiFi WMM Supports the following class selector profiles:

• Enterprise

• RFC8325 - default

• 3GPP

Example QoS Definition

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

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

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

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

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

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

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

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

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

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

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

Configure VxLAN

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

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

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

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

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

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

OpenWiFi WMM Supports the following class selector profiles:

• Enterprise

• RFC8325 - default

• 3GPP

Air Time Fairness Example:

"services": {
                "airtime-fairness": {
                        "voice-weight": 4,
                        "packet-threshold": 100,
                        "bulk-threshold": 50,
                        "priority-threshold": 30,
                        "weight-normal": 256,
                        "weight-priority": 384,
                        "weight-bulk": 128
                }
        }

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

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

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

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

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

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

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

RADIUS Subscriber WISPr Speed Definition:

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

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

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

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

RADIUS Access-Accept

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

• Tunnel-Type = 13

• Tunnel-Medium-Type = 6

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

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

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

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

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

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

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

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

OpenWiFi support two types of captive portal:

• Internal/Local Captive Portal

• External Captive Portal

Local Captive Portal

The internal captive portal supports the following modes of authentication.

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

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

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

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

Click-to-continue configuration

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

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

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

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

User credentials

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

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

Radius based credentials

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

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

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

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

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

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

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

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

Steering

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

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

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

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

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

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

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

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

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

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

RRM 802.11k

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

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

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

Automatic Channel Balancing

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

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

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

Multiple Pre Shared Key is a popular configuration option in Multi Dwelling Unit, dormitory or similar environment where it is costly to implement complex 802.1x security however that same level of per-client security is highly desired.

A SSID when configured for multi-psk can have multiple PSK/VID mappings. Each one of them can be bound to a specific MAC or be a wildcard.

            "ssids": [
                {
                    "name": "MDU Wi-Fi",
                    "wifi-bands": [
                        "5G",
                        "2G"
                    ],
                    "bss-mode": "ap",
                    "encryption": {
                        "proto": "psk2",
                        "ieee80211w": "optional",
                        "key": "OpenWifi"
                    },
                    "multi-psk": [
                        {
                            "key": "akey",
                            "vlan-id": 100
                        },
                        {
                            "key": "bkey"
                            "vlan-id": 200
                        }
                    ],
                    "roaming": {
                        "message-exchange": "ds",
                        "generate-psk": true
                    }
                }
            ]

Wireguard is an overlay technology supporting both Layer 2 and Layer 3 operations. In TIP OpenWiFi this is designed as a configured service that is associated to any logical interface.

As a fully encrypted overlay, key negotiation and exchange of peers is required. This peer endpoint exchange conversation is known as PEX.

A PEX service is deployed with public network visibility and defined in the wireguard-overlay root-node configuration section of the client.

Endpoints to be key negotiated with are defined as hosts.

When this wireguard-overlay is then associated as a service to a layer 3 interface either upstream (WAN) or downstream (LAN) then a layer 3 path is available between the define host endpoints.

When the wireguard-overlay is associated as a service with vxlan configured, the host adjacencies become layer 2 paths.

Example:

“wireguard-overlay”: {
                        “private-key”: “####AAAABBBBCCCDDDDEEEFFFFFGGGG“,
                        “root-node”: {
                                “key”: “ZZZZWWWWQQQEEERRRTTYYYY“,
                                “endpoint”: “148.251.188.218",
                                “ipaddr”: [ “192.168.3.1" ]
                        },
                        “hosts”: [
                                {
                                        “name”: “ap1”,
                                        “key”: “CCCCDDDDEEEEFFFFGGGHHHHIIII“,
                                        “ipaddr”: [ “192.168.4.1" ]
                                }, {
                                        “name”: “ap2",
                                        “key”: “JJJKKKLLLAAABBBBBNCCCC####“,
                                        “ipaddr”: [ “192.168.5.1" ]
                                }
                        ],
                        “vxlan”: {
                                “isolate”: false
                        }
                }

Peer Endpoint eXchange Service (PEX)

Currently TIP OpenWiFi wireguard services are an early preview feature. The PEX network discovery daemon service is intended to be containerized and likely re-written as a core service of the TIP OpenWiFi SDK cloud.

For development members in the Community who wish to begin with this feature, the following repo should be consulted for functional information on a base Linux deployment of PEX via: https://github.com/nbd168/unetd/blob/master/PEX.md

Please connect with the Community maintainers via Slack if working on this early access feature.

APNOS now support OWE mode of authentication. In addition OWE Transition mode is support for clients that are not able to support OWE mode. In transition mode, there should be two SSIDs, one is Open SSID and other one is OWE SSID. The open SSID should broadcast and the OWE SSID should be hidden.

The following encryption block is added to interfaces->ssids block:

"encryption": {
    "proto": "owe",
    "ieee80211w": "required"
}

Configuration with owe transition mode block is done by using the following encryption block:

"encryption": {
    "proto": "owe-transition",
    "ieee80211w": "required"
}

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

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

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

Possible Uses

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

For example:

Any number of services may interest the administrator for airtime-policies. Simply determine the FQDN or wildcard FQDN applicable and update the OpenWiFi device configuration.

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

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

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

When deploying headless devices such as IoT services, MAC based authentication dedicated to a unique SSID may be required. TIP OpenWiFi supports MAC-Auth for any SSID when configured with RADIUS parameters set to "mac-filter" true.

Example

Passpoint® requires ANQP to supply three information elements from the Access Point.

PLMN-Id

Public Land Mobile Network Id is defined by 3GPP and comprised of two, three digit numbers to uniquely identify the Mobile Network Operator (MNO).

Realm

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.

OI / RCOI

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.

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.

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

Starting release v2.8.0, APNOS allows the ability for community members to provide regulatory domain restrictions as their end product use cases. APNOS and the SDK provides generic building blocks for restricting various aspects of the unit.

The initial requirements for this feature are captured here.

By default APNOS is open and not considered restricted. To enable restriction the unit must have restrictions.json file in the /certificate directory at the time of factory. The restrictions.json file has the following format:

{
    "commands": true,
    "country": [
      "US",
      "CA"
    ],
    "dfs": true,
    "key_info": {
      "algo": "static",
      "vendor": "dummy"
    },
    "rtty": true,
    "sysupgrade": true,
    "tty": true
}

Here are description of the keys above: country: commands: dfs: key_info: rtty: sysupdate: tty:

It is possible to configure all Passpoint attributes required for production deployment.

Capabilities for Hotspot 2.0 / Passpoint® include:

• venue-name

• venue-group

• venue-type

• venue-url

• auth-type

• domain-name

• nai-realm

• osen

• anqp-domain

• anqp-3gpp-cell-net

• firendly-name

• icons

Example Passpoint Configuration

    	"interfaces": [{
			
			"ssids": [{
				"name": "Mobile Offload",
				"wifi-bands": [
					"5G"
				],
				"bss-mode": "ap",
				"encryption": {
					"proto": "wpa-mixed",
					"ieee80211w": "optional"
				},
                "services": [
                    "radius-proxy"
                ],
				"radius": {
					"nas-identifier": "NAS-Lab",
					"chargeable-user-id": true,
					"authentication": {
						"host": "127.0.0.1",
						"port": 1812,
						"secret": "secret",
						"request-attribute": [{
							"id": 126,
							"value": "s:TIP"
						}]
					},
					"accounting": {
						"host": "127.0.0.1",
						"port": 1813,
						"secret": "secret",
						"request-attribute": [{
							"id": 126,
							"value": "s:TIP"
						}],
						"interval": 600
					}
				},
				"pass-point": {
					"venue-name": [
						"eng:Example passpoint_venue",
						"fra:Exemple de lieu"
					],
					"domain-name": [
                        "operator.com"
                    ],
					"asra": false,
					"internet": true,
					"esr": false,
					"uesa": false,
					"access-network-type": 0,
					"hessid":"11:22:33:44:55:66",
					"venue-group": 2,
					"venue-type": 8,
					"connection-capability":[
						"1:0:2",
						"6:22:1",
						"17:5060:0"
					],
					"roaming-consortium": [
                        			"A4F5E8F5F4",
						"BAA2D00100",
						"CAA2D00000",
						"DA03BA0000"
					],
					"disable-dgaf": true,
					"anqp-domain": 8888,
					"ipaddr-type-available": 14,
					"nai-realm": [
						"0,ooperator.com,21[5:7][2:4],13[5:-1]",
                        "0,boingo.com,21[5:7][2:4],13[5:-1]"
					],
					"osen": false,
					"anqp-3gpp-cell-net": [
						"310,410"
					],
					"friendly-name": [
						"eng:Operator Labs",
						"fra:Operator Labs"
					],
					"venue-url": [
						"http://www.example.com/info-fra",
						"http://www.example.com/info-eng"
					],
					"auth-type": {
						"type": "terms-and-conditions"
					}
				}
			}]
		},
		
"services": {

        "radius-proxy":{
            "realms":[
                {
                    "protocol": "radsec",
                    "realm": ["*.mobile.operator.com"],
                    "host": "ipv4 address",
                    "port": 2083,
                    "auto-discover": false,
                    "secret": "radsec",
                    "use-local-certificates": false,
                    "ca-certificate": "AAAAABBBBBCCCCDDDEEEEEEFFFFNPZ0F3SUJBZ0lKQUxIQmJFWmU3QTBzTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdvTVFzd0NRWUQKVlFRR0V3SlZVekVUTUJFR0ExVUVDQXdLUTJGc2FXWnZjbTVwWVRFUk1BOEdBMVVFQnd3SVUyRnVJRXB2YzJVeApIREFhQmdOVkJBb01FME5wYzJOdklGTjVjM1JsYlhNc0lFbHVZeTR4RkRBU0JnTlZCQXNNQzA5d1pXNXliMkZ0CmFXNW5NUmd3RmdZRFZRUUREQTl2Y0dWdWNtOWhiV2x1Wnk1dmNtY3hJekFoQmdrcWhraUc5dzBCQ1FFV0ZHVnUKWWkxa1pYWnZjSE5BWTJselkyOHVZMjl0TUI0WERURTVNRGt4TmpFeU1EYzFPVm9YRFRNNU1Ea3hNVEV5TURjMQpPVm93Z2FneEN6QUpCZ05WQkFZVEFsVlRNUk13RVFZRFZRUUlEQXBEWVd4cFptOXlibWxoTVJFd0R3WURWUVFICkRBaFRZVzRnU205elpURWNNQm9HQTFVRUNnd1RRMmx6WTI4Z1UzbHpkR1Z0Y3l3Z1NXNWpMakVVTUJJR0ExVUUKQ3d3TFQzQmxibkp2WVcxcGJtY3hHREFXQmdOVkJBTU1EMjl3Wlc1eWIyRnRhVzVuTG05eVp6RWpNQ0VHQ1NxRwpTSWIzRFFFSkFSWVVaVzVpTFdSbGRtOXdjMEJqYVhOamJ5NWpiMjB3Z2dJaU1BMEdDU3FHU0liM0RRRUJBUVVBCkE0SUNEd0F3Z2dJS0FvSUNBUUMwSmM0V3d2QlJJa3BsU0pmdVdZaWo1TTZ2WkRtYVpRNk82YjhGRjBNRVdhZ3UKRFZpVkpRM0JVZ1oyUUtET25JcktNZUlmS3ZWUzRNRWJMM3U0OHgveUtqb09IRkQ0aUhRRTdBUFBvd1BvZkVTcwp4emZveGkwYnozQ3FvK3pXRzVESVJ5V3krNFNDRGlsc2xBN25XU1l5TTdGeUZGWUxvWHdEZVY1N1MzNnJqN3hGClpXdjJ3NjI3dkNPUjJKM2RiYkRLR0ZneEZSVHhMK3I0SWlIWGN5Mm8zaUlwK3R3bDBablJydzBEME5aUmxwNzkKZ2VCS2E5VHZ1MUQxMDcxVWRDQjlaK3VZMFBrNEVaN1dlWVNjWjJhdkxtQjl3cVpkU1F0U2pTQ0xqNVlTOTZzTwpodmlOTWxDb1pNbDBkUE14T2RCb3JZOE52L1VodWk3WDBseUpjKytYaVVuVCs2c05KTXJUeWQ1bCt5OTBmZ0RrCmVqUTNhcWZsTDdRTy9SWjRGejhpL3dCQTRmTWR5TDkvYThqUzBiYWZlc01PZFFDUEd4TThNYXF3QUhZOUN0Z1cKWFFuWi9CT3l3bTArY1gxMkwyd3R3SGFjZ1F6bUROZ2R3NU5PdUdIVEdFcTBpUFVITFBrUXZWc1VTRTBpSUxmZgpXWkhpN2RhOHlsZi9WVktDVjN3U3pKdjc4NXB1c0Z6QVNxbHpLZnErYUs5T1A4bVhyS1dibFZCWHR0aE5mSWJ1CmcvaXNoWW4rYXIrcnlEdmRvL05vL202QjhCemNqVzRWWlIxQkszZUd1R3k2MkhxbTdHMkdZS1FpbkhzdElTYWsKeFFMK3IxOW1HcEhkbzdXcWgyd3ZVZmd6MXN4QjZxOVRhaWZoS21nbEJiSnV1dHpQRFViRHRqWHVlbGcvS1FJRApBUUFCbzJZd1pEQWRCZ05WSFE0RUZnUVVER1Z5QWU4THpNSjR0NVRuRVplVUpXeGVGcE13SHdZRFZSMGpCQmd3CkZvQVVER1Z5QWU4THpNSjR0NVRuRVplVUpXeGVGcE13RWdZRFZSMFRBUUgvQkFnd0JnRUIvd0lCQXpBT0JnTlYKSFE4QkFmOEVCQU1DQVlZd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dJQkFGcnlOZldoU2J4RitYS3Nhd29MT2l0bgpDd2ZkTUNrQUJvMWlvWFhyclB1M0xzYm9keXBEdUIwQ2NHdEI1WlZiQ1pSWXBTVFNWMjcramdhRVZlMG1zSk9vCjRoNVBYdnM0QklseTJ6RE1yaE9rTmIxSXN0Y1kyNFdtbGJRYUlBTGcwUW4zQXJTWStITUtUMjhoWjR6bVM3N3QKKzg3d0FYNmlBaGF5QktLWHhJQnQ4VEVTL0hXU0RWczl1RFY4ZjRNTzI0TGozQXBhQkpaV2dFcFpXYi9LdkRmSQp4ckJUK1loL2xTSWpvWGNvZHdNT2dMeTcrLzJrQjZQcXJtWktMcnFWZ3Byd3VXNDJVYVh4YkpYQnFvdmVURkxiCnhXaHA5T1kzbWxnTy9IbWthdS8rUnNLelJzYnJJWGZqRzRDT1ViOHh1ajV1WmZkQ2FYRVlWNnZwdnUwN0NTVEgKZk51VnlZYlMxampLZHRoWE9JQ2YvN3N4YTdiVlpOTkNOQWFwK21FcldPNXQxTEhXdi9ZL0ZYYk5TTVdadlozVApPM0RYc0p5K3grU1piZ283OWhzUktxeDFDSjQybktBaGM2WFZZUkRTOGs0SHZVSzBxbnpTaExvMm5MYTFCVUVMCkkzVnkybDVVMkMxMUYvTDRhNE1Pb2R0Z3h4L0Q5VjI0cWZnTVRPY3Q4bS9QRFB6b1ovL2NoTUpQUU5pWHV5SUEKWmlOUWRxRngrYWI2N1ErM3kwcGxKRDVjVk81Z01MN0F5dXZuMDJlalRhWFYrUkQxVmpoSkRCM0l1Y0FHUnIxLwpVTVVNbmlTZSt4S2FaVHA5SGtza0x2K051ZjV1Slc2VXVHZ0RIbUFCYUFEWUdTMGhKTFU2MjMxMTE3OWh4Q3NmCmVMNXJQdlVtMitRZWhDWURBUjR1Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=",
                    "certificate":"AAAAABBBBBCCCCDDDEEEEEEFFFFS0tCk1JSUNHVENDQWNDZ0F3SUJBZ0lVUjEwVFR5NThxNVF2d1VlVEVsWnZRNE1tYzYwd0NnWUlLb1pJemowRUF3SXcKUVRFTE1Ba0dBMVVFQmhNQ1ZWTXhFekFSQmdOVkJBb1RDa0oxZEhSdmJuZHZiMlF4SFRBYkJnTlZCQU1URkVKMQpkSFJ2Ym5kdmIyUWdVbUZrYzJWaklFTkJNQjRYRFRJeE1EY3hNVEUyTXpNeE5Wb1hEVEl6TURjeE1URTJNek14Ck5Wb3dZakVMTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFvVENrSjFkSFJ2Ym5kdmIyUXhJekFoQmdOVkJBTVQKR21aaFkyVmliMjlyTG05eWFXOXVMbUZ5WldFeE1qQXVZMjl0TVJrd0Z3WUtDWkltaVpQeUxHUUJBUk1KUjI5dgpaMnhsT2xWVE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRTAvdXpKQ1FZVU1uTXpjMHFzaXBYClZreXkzdkdIM0hOZWxJQnkzTzFGaVMrdVVBa1NUS0VUSHduK1Nza3N1WjIzZnV0bWJzcEQ4bXZQUkI3bXlwZ24KZDZOMU1ITXdEZ1lEVlIwUEFRSC9CQVFEQWdlQU1CTUdBMVVkSlFRTU1Bb0dDQ3NHQVFVRkJ3TUNNQXdHQTFVZApFd0VCL3dRQ01BQXdKUVlEVlIwUkJCNHdISUlhWm1GalpXSnZiMnN1YjNKcGIyNHVZWEpsWVRFeU1DNWpiMjB3CkZ3WURWUjBnQkJBd0RqQU1CZ29yQmdFRUFlNHFBUUVGTUFvR0NDcUdTTTQ5QkFNQ0EwY0FNRVFDSUVKZ00yenoKUXJiR3NZMWticmNOZ1p2QTdBbE02WTllS3d6VWZHSzNGN2d3QWlBbDFmNlVBSGMxVlFmNUgwUVlRbjh4QW1WWAp6azJIQmI3MHMxQjEwN2NKY3c9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0t",
                    "private-key":"AAAAABBBBBCCCCDDDEEEEEEFFFF0tLS0tCk1IY0NBUUVFSUg0cXVHblBndUIxckk1TnlXejc3ejBvOXRUOGhxN1dBbXVrcFRXa3J2cHdvQW9HQ0NxR1NNNDkKQXdFSG9VUURRZ0FFMC91ekpDUVlVTW5NemMwcXNpcFhWa3l5M3ZHSDNITmVsSUJ5M08xRmlTK3VVQWtTVEtFVApId24rU3Nrc3VaMjNmdXRtYnNwRDhtdlBSQjdteXBnbmR3PT0KLS0tLS1FTkQgRUMgUFJJVkFURSBLRVktLS0tLQ=="
                },
                {
                    "protocol": "radius",
                    "realm": ["*.3gppnetwork.org"],
                    "auth-server": "ipv4 address",
                    "auth-port": 11812,
                    "auth-secret": "secret",
                    "acct-server": "ipv4 address",
                    "acct-port": 11813,
                    "acct-secret": "secret"
                },
                {
                    "protocol": "radius",
                    "realm": ["operator.com"],
                    "auth-server": "ipv4 address",
                    "auth-port": 1812,
                    "auth-secret": "secret",
                    "acct-server": "ipv4 address",
                    "acct-port": 1813,
                    "acct-secret": "secret"
                },
                {
                    "protocol": "block",
                    "realm": ["*"],
                    "message": "realm-not-allowed"
                }
            ]
        }
	}

The above configuration example mobile offload has been configured for two realms that will both have radius traffic sent as radius-proxy via the OpenWiFi Gateway to enable cloud native AAA support for any customer premises topology services are operating from.