Intelligent AAA Proxy for APN Selection

Explore seven additional case studies by downloading the full Why Intellegent AAA is the Swiss Army Knife of Telecom paper below. You can also go here to learn more about the Enea AAA Server.

Once the APN Selection process is complete, the Enea AAA Server performs one of two actions based on the subscriber profile:

• Proxy Authentication: Forwards the request to an external Home AAA Server (HAAA).
• Local Authentication: Validates the session directly against the Enea AAA internal account database.

To ensure consistent billing and session tracking, all RADIUS Accounting-Requests received from the PGW are transparently proxied to the designated external HAAA. In some cases, the Accounting-Request is also copied to another AAA server.

To optimize performance and management, the architecture is divided into two functionally identical AAA proxy systems, each dedicated to a specific subscriber segment:

1. Consumer: The AAA system described in more detail in this case study.
2. Corporate: A dedicated Enea AAA environment tailored for enterprise-grade IoT and data services, not covered in further detail here.

Overcoming Inflexible APN Selection

CSP B’s existing core systems lacked the necessary flexibility to manage complex APN Selection requirements. The operator required a highly programmable solution capable of executing sophisticated business logic on incoming RADIUS Access-Requests to drive precise APN assignments.

Key requirements for the new solution included:

• Dynamic Authentication Logic: The operator required the ability to determine the appropriate handling for each subscriber based on predefined policies. Specifically, the system needed to decide whether a request should be “Always Accepted,” proxied to the correct HAAA for external authentication, or authenticated against the solution’s local database.
• Multi-Destination Routing: The flexibility to proxy accounting messages to one or more HAAA nodes as well ass DPI and billing systems, based on predefined policy rules.

CSP B sought to implement an intelligent mediation layer to bridge the gap between their legacy core routing and the dynamic business logic needed to handle modern APN selection and proxying requirements.

Enea AAA Server as AAA Proxy for APN Selection

To achieve the necessary flexibility and performance, CSP B selected the Enea AAA Server to serve as an intelligent AAA proxy for APN Selection. While many AAA platforms can deliver high transactions per second (TPS) for standard RADIUS signaling, executing advanced business logic for APN selection at scale requires a more sophisticated engine.

Performance and Scalability Requirements

To support the mass-market consumer segment, CSP B defined several high-performance benchmarks:

• Subscriber Scale: Support for 20 million monthly unique users and 12 million concurrent sessions.
• Throughput: Processing 36,000 TPS while simultaneously executing advanced business logic.

Virtualized Deployment Architecture

To meet these rigorous requirements, the Enea AAA Server is deployed as a Virtual Network Function (VNF). The “Consumer” system comprises 36 VNF nodes organized into six clusters of six nodes each. An additional, functionally identical system with 18 nodes was deployed to support the “Corporate” service. For validation and testing, CSP B also maintains a 12-node Pre-production/Lab system.

Each cluster operates independently. Because the system is designed to be stateless for this use case, geo-redundancy is achieved without the need for complex inter-site synchronization, simplifying the overall architecture.

Cluster Configuration and Node Roles

There are six Enea AAA Server clusters. Within each six-node cluster, functional roles are distributed to maximize performance and ensure continuous service availability:

• Four Payload (PL) Nodes: These nodes are dedicated to business logic execution, RADIUS signaling, LDAP queries, and the account database. The architecture is engineered for horizontal scaling, allowing for the addition of payload nodes as traffic volume increases. To optimize resource utilization, the fourth node in this group operates as a combo node, handling both standard payload processing and Usage Data (UD) functions.
• Two Management (Mgmt) Nodes: The primary management node is responsible for centralized system configuration, business logic updates, and daily administration. The secondary node serves as an active redundant management node, providing high availability (HA) across the cluster. To maximize operational efficiency, this secondary node remains fully accessible for daily tasks, such as log analysis, database queries, metric monitoring, and subscriber tracing.

APN Selection

The APN Selection process is driven by the Enea AAA Server’s business logic engine, utilizing a combination of database lookups and advanced ruleset configurations. When the Enea AAA receives a RADIUS Access-Request from the Packet Gateway (PGW), the engine executes the logic to determine the correct Home AAA (HAAA) destination. Ultimately, the system assigns a specific APN, which is returned as an Attribute-Value Pair (AVP) in the Access-Accept message forwarded to the PGW.

Specialized Handling for Accounts and Devices

The Enea AAA provides granular control over specific account types and device models through its internal database (provisioned via GUI or CSV import). This allows the system to perform specialized handling for:

• PLMN and Roaming Data: Logic-based routing according to the origin network.
• Restricted and Test Devices: Denylisted devices, test IMSIs, and specific IMEIs.
• Device Models and Firmware: Utilizing a combination of the Type Allocation Code (TAC) and minimum Software Version (SV) to identify specific hardware and software revisions.

The business logic is designed to perform lookups against these tables in the Enea AAA internal database and take immediate action based on the results. This often leads to “Local Authentication,” where the Enea AAA issues an Access-Accept or Access-Reject directly to the Packet Gateway without involving the Home AAA. This allows the system to resolve authentication for these special cases independently.

Programmable Rulesets and Pattern Matching

CSP B maintains full administrative control over the match tables and rulesets. While match tables handle basic use cases, the system leverages rulesets with pattern matching for complex, high-precision APN Selection.

Example Ruleset Execution

In this APN ruleset example, the Enea AAA Server first evaluates whether the Called-Station-Id matches “blackberry.net.” If no match is found, the APN remains unchanged. If it does match, the system then applies the pattern nnnnnn[34]79* to verify the IMSI. If the IMSI matches this expression, the system returns the APN “mvnoblackberry.net”; otherwise, it returns “cspb.blackberry.net” within the modified Called-Station-Id attribute.

Note: Fort confidentiality we have anonymized APN names and replaced the first 6 digits in the IMSI with “n”.

The regular expression nnnnnn[34]79* perform matching according to this:

• Exact matching of the first 6 digits (nnnnnn) to match the MCC (country) and MNC (MNO Id) of CSP B.
• The 7th digit [34] matches either 3 or 4.
• The 8th digit matches exactly 7.
• 9* means zero or more 9 characters.

Extensible Hook Points

Beyond standard selection logic, the highly customizable rulesets allow CSP B to inject custom policy code at critical points in the signaling flow:

• RADIUS Pre-Authentication: Code execution prior to processing an authentication request.
• RADIUS Post-Authentication: Logic applied after the authentication decision is made.
• RADIUS Pre-Accounting: Logic applied before forwarding RADIUS Accounting messages.
• RADIUS Pre-Accounting-Copy: Custom logic executed before forwarding an accounting copy to an external AAA, analytics or billing server.

AAA Proxy Realms Configuration

The AAA Proxy Realms configuration, a core component of the Enea AAA Proxy package, manages the steering and handling of RADIUS Access and Accounting-Requests. This flexible configuration determines whether a request should be proxied to an external Home AAA (HAAA), or if it should be immediately accepted or rejected at the proxy layer.

Destination Mapping

The system utilizes pattern matching within the Realms configuration to identify the appropriate destination for each request. These destinations are organized into External Node Groups, which provide a layer of abstraction for managing multiple backend HAAA servers.

In addition to standard RADIUS Attribute-Value Pairs (AVPs), the Enea AAA can perform matching based on system-level attributes such as:

• The message type (e.g., Access-Request or Accounting-Request).
• The originating IP of the signaling packet.
• The configured name of the RADIUS client.

The system evaluates these filters in a top-to-bottom order, executing the first match found.

Accounting Management and Broadcasts

The Enea AAA provides granular control over accounting data to ensure billing integrity:

• Accounting Broadcast: Configurable within the Realm options, this setting can override the default proxy destination to ensure Accounting-Requests are distributed to multiple endpoints simultaneously.
• Accounting Copy: The system can be configured to send a duplicate stream of all accounting messages received from the PGWs to one or more external Node Groups. This is typically used for external analytics, auditing, or secondary billing systems without impacting the primary authentication flow.

RADIUS proxy with TPS Throttling

In high-scale deployments, network stability is often dictated by the capacity of the backend infrastructure. The Enea AAA Server’s high-performance throughput usually exceeds the processing capabilities of legacy Home AAA (HAAA) systems. To prevent downstream service degradation, the Enea AAA includes TPS Throttling functionality. This allows the operator to set granular limits on outgoing RADIUS traffic, ensuring that the HAAA nodes are not overwhelmed during peak signaling bursts.

Advanced Operational and Integration Features

Several additional capabilities were implemented to enhance the management and extensibility of CSP B’s
environment:

• Custom Counters: Administrators can define custom counters within the rulesets to track specific signaling trends, such as the number of requests processed for a particular APN. These counters can then be analyzed via the internal metrics explorer or an external NMS such as Prometheus.
• Batch Importing: The configuration supports a custom batch-import utility. This enables the high-volume ingestion of subscriber accounts and match-table entries via CSV files, streamlining large-scale updates.
• Comprehensive Unit Testing: To ensure logic accuracy before deployment, the system includes a robust unit testing framework. This allows for the evaluation of APN Selection rulesets against test data. CSP B can perform batch unit tests via CSV uploads or integrate these tests into automated programmatic validation using the REST API.
• Dynamic External Lookups: The Enea AAA Server’s programmable rulesets can be configured to perform real-time LDAP and SQL lookups, allowing authentication and selection decisions to be enriched by external subscriber data repositories.

System Interfaces

In this deployment, the Enea AAA Server acts as a high-performance hub, supporting the following interface protocols:

Inbound Interfaces:

• RADIUS: Processing Access and Accounting messages from the Packet Gateways (PGW).

Outbound Interfaces:

• RADIUS: Delivering Access-Accept/Reject responses to the PGWs and proxying signaling to
  the Home AAAs.
• LDAP/SQL: Facilitating external database queries via custom rulesets.
• Usage Data: Pushing Call Detail Records (CDRs) to remote SFTP servers for billing and auditing.