Solutions
Alepo AAA Solutions
Telco Type
Leading Telecommunications Operator
Country
Middle East
Five Years, One Platform: How a Leading Operator’s AAA Layer Evolved Without Being Replaced
A case study of how a leading Middle East telecommunications operator has run its NFV-based AAA layer in continuous production for five years, and how the platform’s configurability, not a string of forklift upgrades, has kept pace with a changing subscriber base, security posture, and operational model. Prepared for operators evaluating whether their next AAA platform choice needs to be revisited every few years.
5 years
NFV-based AAA in continuous multi-site production
2X
licensed capacity expanded in place, no re-platforming
In place
major-version database upgrade with no production disruption
Self-managed
platform operated by the customer’s own technical team
Background
The operator, a leading telecommunications provider in the Middle East, deployed an NFV-based AAA platform after a multi-year architecture and planning phase. It runs as a multi-site, high-availability estate serving a large concurrent-session base. Five years on, it is still the AAA layer of record, not because requirements stopped changing, but because the platform changed with them.
The Product Question Behind the Longevity
Most AAA platforms are chosen once and re-evaluated every few years, as requirements outgrow what was originally built. This one was designed to absorb new operational, security, and integration requirements as configuration and API-level extensions, rather than separate projects bolted onto a fixed core. The platform flexes to the operator’s evolving needs; the operator does not flex to a fixed feature set.
What This Says About the Operating Model
The operator runs the platform with its own technical team. A dedicated Alepo operations resource supported the initial ramp-up and was not renewed once the internal capability was in place, leaving standby vendor support for specific configuration and escalation needs. The platform’s design, not a services dependency, is what makes that model possible.
How the Platform Adapted, In Production, Without Downtime
New operational demands were taken on through native configuration and API extension, with no architecture replacement:
Bulk operational visibility at scale
Native bulk APIs cover session status, user identification, restored and rejected users, and disconnected sessions, supporting large operational sweeps on short monitoring cycles.
Granular, role-based administrative control
Per-role read, add, update, and delete permissions configured in the management layer, with no platform-version change.
Capacity that scales with the subscriber base, not the contract
Licensed capacity was doubled in place as a legacy access base was consolidated, with no re-platforming.
Authentication that extends to new access methods
Line-identification-based authentication added as a configuration-level extension, strengthening verification and access control.
Infrastructure hardening on the operator’s own timeline
Database nodes upgraded in place, with no disruption to the production estate.
Major-version database upgrade, in place
The clustered database beneath the platform moved across major versions in production, and the platform now takes quarterly security updates with all components still connected.
Configurability was the upgrade path: requirements absorbed as configuration and API extensions never became replacement projects.
Capacity sat on the license line, not the hardware line: in-place expansion doubled capacity with no re-platforming.
Vendor presence tapered by design: on-site support ended once the operator’s own team was fully ramped up.
What to Verify Before Committing to an AAA Platform
Checks drawn from this deployment, useful regardless of vendor:
Can your AAA absorb new operational and security requirements through configuration, or does each new need become its own project?
Is your licensed capacity tied to your hardware footprint, or can it scale in place as your subscriber base grows?
Can new authentication and access methods be added without a platform-version dependency?
Does your platform require an ongoing managed-services presence, or can your own team operate it once ramped up?
If you added up every ‘upgrade project’ your current AAA vendor has proposed, would you be replacing the platform, or extending it?
