Universal
Access Platform.

Three commitments, one platform

Universal means the hardware constrains nothing — not the architecture, not the software vendor, not the console

One solution does not fit all

Wireless complexity does not grow with the number of access points. It grows with what has to move between them.

A single-site office needs a controller in the same box as its firewall. A multi-site retailer needs policy that follows the branch. A campus or a carrier network needs client mobility across thousands of APs and VLANs, with authentication and forwarding that never centralize into a bottleneck. These are not three sizes of the same requirement — they are three different architectures.

The industry's usual answer is three different product lines, three firmware trees and three operations teams. Ours is one access point that speaks to all of them.

Universal AP

Every access point connects to every control plane — automatically or by choice

An IDL access point discovers and attaches to whichever control plane it finds, and an administrator can redeploy it to a different one at any time. No separate firmware image, no re-flash to a different product line, no change to the code running on the box. The AP you bought for a branch office can be redeployed into a campus fabric on Monday and into a carrier network on Friday.

What that buys an operator

• Inventory that does not fragment — one part number covers every architecture you sell into, so stock, spares and RMA pools stay pooled instead of splitting per segment
• Architecture decided after the sale — quote the hardware before the customer has settled on centralized or cloud management, and let the site's requirements pick the control plane later
• One qualification, one certification cycle — regulatory approval, interop testing and internal acceptance are done once per model, not once per deployment model
• Growth without replacement — a site that outgrows its integrated gateway moves to a dedicated controller by re-pointing the APs, not by replacing them

Under the hood

A chipset abstraction layer is why a single build can span three silicon vendors

This is also what makes the second software line cheap to carry: the same separation that lets one firmware span three silicon vendors is what lets an IDL access point ship a TIP OpenWiFi image as an alternative to our own — see OpenWiFi · Dual-Image AP.

NMP

The other half of the story — one cloud console across every product and every scenario

A universal access point solves the device side. It does not, on its own, stop an operator from running four consoles: one for the carrier network, one for the campus estate, one for the branches and one for whatever the home team deployed. NMP is the single management plane over all of it — the access points, the switches, the gateways, the controllers and the home routers, in every scenario they are deployed into.

Four things it does

What makes it different from a vendor cloud

• You choose where it runs — public cloud, your private cloud, or plain x86 servers in your own data centre. A managed network should not require handing your operational data to a vendor's SaaS as a condition of managing your own equipment
• Multi-tenant and domain-scoped by design — multi-user, multi-role, hierarchical administration, so a service provider can run many customers, and a customer can delegate a site without handing over the estate
• Open API rather than an export button — statistics, service configuration and raw data APIs, with application registration, API scoping and data-range control, so your own BSS/OSS drives the network instead of your staff re-typing into it
• Built to hold the volume — Docker on Linux, distributed storage across NoSQL, SQL and Redis, and a Spark processing engine, because carrier-scale telemetry is a data problem before it is a networking one

The full NMP feature list is in the software capabilities section below, and the product entry is on the products page.

Which control plane, at which scale

The same access point, positioned differently

Indicative sizing. Density, roaming behaviour and authentication method move these boundaries more than raw client count does — talk to us with a floor plan rather than a headcount.

Software capabilities

Four layers, one architecture — from the radio to the cloud API

What follows is the shipping feature set at each layer. Items marked roadmap are in development and are called out rather than blended in — if a capability decides your tender, ask us for its current status in writing.

Two axes of choice, not one

The control plane is yours to pick. So is the software stack.

Most vendors ask a customer to settle both questions at procurement, then charge them in hardware when the answer changes. We would rather sell the hardware once and let the answers keep moving.