OpenWiFi
4.0.0
4.0.0
  • OpenWiFi Release 4.0.0
  • ABOUT
    • About OpenWiFi
    • Supported Hardware
    • Device Partner Information
    • Cloud Partner Information
    • Ordering OpenWiFi APs
    • Example Partner Integrations
    • Contributing
  • OPENWIFI STACK
    • Overview
    • SDK
    • Access Points
      • Local Device Settings
    • Cloud Discovery
      • Discovery without Cloud
    • Code Repositories
    • Artifacts
  • SDK
    • Getting Started
    • Architecture
    • Provisioning for Integrators
      • Data Model Introduction
      • Creating a Configuration
    • User Interface for Admins
      • Provisioning
        • Creating Entities
          • Configurations
            • Metrics Settings Example
        • Creating Venues
          • Configurations
            • WAN
            • VAP - SSID
      • Inventory Association
      • Gateway
      • Devices
        • Commands
        • Statistics
        • Command History
      • Firmware
    • Monitoring
      • ELK Integration
  • RELEASE
    • What's New
    • Features
    • Security Updates
    • Resolved Issues
    • Outstanding Items
    • Testing Results
  • SDK Installation
    • Overview
    • Deploy using Docker Compose
    • Deploy using Helm
  • Device Feature Configuration Examples
    • Basic Device Provisioning
      • Bridge Mode SSID
      • NAT Gateway Mode SSID
      • Multi-VLAN SSID
    • Advanced Device Feature Configuration Examples
      • Zero Touch Provisioning
      • DHCP Relay
      • Services
      • Metrics
      • GRE
      • L2TP
      • VxLAN
      • WDS
      • Mesh
      • QoS
      • Dynamic Air Time Fairness
      • Advanced Captive Portal
        • External Captive Portal
      • Roaming RRM and SON
      • RADIUS Authenticated SSID
        • Dynamic VLANs with RADIUS
        • WISPr Subscriber Bandwidth
        • Dynamic Multi PSK
        • RADIUS MAC-Auth
      • Multi-PSK (MDU Shared Key)
      • Wireguard
      • Dynamic Air-Time Policy
      • Opportunistic Wireless Encryption (OWE)
      • Passpoint®
        • Configuration Introduction
        • Advertising Services
        • Passpoint® Configuration
      • Restricted Unit Support
  • DEVELOPER RESOURCES
    • SDK API
      • OpenAPI Definitions
      • Security Service
      • Gateway Service
      • Firmware Management Service
      • Provisioning Service
      • Analytics Service
      • Radio Resource Management Service
      • Postman Collection
    • SDK KAFKA
      • Connection
      • Device Event Queue
      • Device Telemetry
      • Healthcheck
      • Provisioning Change
      • Service Events
      • State
      • WiFi Scan
Powered by GitBook
On this page
  1. SDK
  2. User Interface for Admins

Provisioning

PreviousUser Interface for AdminsNextCreating Entities

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

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

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

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

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

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

Entities

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

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