Overview
5G Standalone readiness for authentication and policy means assessing four dimensions against your current infrastructure: authentication protocol support for the 5G core, policy control granularity, network slicing readiness, and subscriber data architecture. 5G SA runs on its own core network rather than anchoring on 4G, as Non-Standalone does, so each dimension carries requirements a 4G-era platform may not meet. This article gives you a table to score yourself against.
Most operators launched 5G the fast way. Non-Standalone (NSA) put 5G radio under the existing 4G core, kept the Home Subscriber Server (HSS), kept the Policy and Charging Rules Function (PCRF), and got a 5G badge on the phone in months. The trade was deferred rather than avoided. Everything the 4G core was quietly doing for authentication and policy now has to be done by a 5G core that speaks a different language. The systems that were fine under NSA are the ones nobody re-evaluated.
This is not another explainer of what 5G Standalone is. It is a working gap analysis: four dimensions, a table to score, and an order for the remediation. It is written for the network architects and the policy and authentication teams who will be asked, probably soon, whether the estate is ready.
5G Standalone vs. Non-Standalone: what actually changes
Under NSA the 5G radio is a fast lane attached to the 4G core. Under SA the 5G core takes over the control plane entirely, and authentication, session policy, and subscriber data all move to new network functions with new interfaces.
NSA (the Option 3 family in 3GPP terms) uses dual connectivity. The 5G New Radio (NR) cell is a secondary carrier and the device is still registered on the Evolved Packet Core (EPC). The Mobility Management Entity (MME) authenticates the subscriber against the HSS over S6a, the Packet Gateway (PGW) takes its policy rules from the PCRF over Gx, and the subscriber profile lives where it always has. From the core’s point of view, an NSA subscriber is an LTE subscriber with an unusually good data rate. Our 5G SA vs 5G NSA comparison covers the use-case side of that distinction.
SA replaces the EPC with the 5G Core defined in 3GPP TS 23.501 and TS 23.502. The control plane is service-based: the Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Unified Data Management (UDM), Unified Data Repository (UDR), Policy Control Function (PCF), and Charging Function (CHF) expose HTTP/2 APIs to one another instead of the EPC’s Diameter point-to-point interfaces. Primary authentication moves from MME-and-HSS to AMF, AUSF, and UDM, using 5G-AKA or EAP-AKA’ as specified in TS 33.501. Session policy moves from PCRF-over-Gx to PCF-over-N7. The permanent identity is no longer sent in the clear at registration; it is concealed as a Subscription Concealed Identifier (SUCI) and de-concealed inside the UDM.
Those four sentences are the reason a readiness assessment is worth doing. Each names a function or an interface your current platform may or may not provide. The four dimensions below are those changes, examined one at a time.
Dimension 1: Authentication protocol support
A common mistake is to assume that because AUSF and UDM own primary authentication in 5G SA, the Authentication, Authorization, and Accounting (AAA) server retires. It does not. 3GPP wrote the AAA server into the SA architecture in several places. An operator whose AAA speaks only 4G-era Diameter and RADIUS (Remote Authentication Dial-In User Service) will find the gaps during the SA launch rather than before it. Our AAA server vs AUSF explainer sets out the division of labor.
Start with what the core itself needs: an AUSF and a UDM that implement 5G-AKA and EAP-AKA’, handle SUCI de-concealment, and expose Nausf and Nudm services. If your HSS vendor has no UDM path, or offers one only as a separate product with a separate database, that is a gap in the first row of the table. Everything else waits on it.
Then look at where the AAA server is still named. Network Slice-Specific Authentication and Authorization (NSSAA), introduced in Release 16, lets a slice require its own Extensible Authentication Protocol (EAP) round after primary authentication, terminated by an AAA server reached through the NSSAA Function (NSSAAF). Secondary authentication lets the SMF run EAP against an external data network AAA (DN-AAA) server before granting a session to a data network, which is how enterprise APN-style services carry into 5G. Non-3GPP access moves to the N3IWF and TNGF, so the question for Wi-Fi becomes which function authenticates those identities once the ePDG and TWAG retire. And EPC interworking over SWx, S6b, and SWm during coexistence keeps RADIUS and Diameter AAA in the path for years. The cloud-native AAA for 5G core article walks through each call flow.
The practical test is a written answer from your AAA and HSS vendors on six items. 5G-AKA and EAP-AKA’. SUCI handling. NSSAA termination. DN-AAA secondary authentication over RADIUS and Diameter. The non-3GPP access plan for the N3IWF and TNGF. Continued SWx, S6b, and SWm support for the interworking period. Any “on the roadmap” answer is a gap with a date attached.
Dimension 2: Policy control granularity
Here is the scenario that catches operators most often. The PCRF has served the LTE network for a decade: fair-use policies, time-of-day plans, Voice over LTE (VoLTE) dynamic policy over Rx, spending limits over Sy. The SA program assumes it will carry on. Then SMF integration testing starts, and the SMF is looking for an Npcf_SMPolicyControl service over N7, which the PCRF has never heard of.
5G SA policy is delivered by the PCF, whose job is broader than the PCRF’s. Session management policy over N7 (TS 29.512) is the closest equivalent to Gx. Access and mobility policy over N15 (TS 29.507) is new: the PCF tells the AMF which radio access technology and frequency selection priority applies and which service areas are restricted. Policy authorization over N5 (TS 29.514) replaces Rx for application functions. Spending-limit control runs against the CHF over N28 rather than the Online Charging System (OCS) over Sy, and policy subscription data is read from the UDR over Nudr. UE route selection policy, delivered to the device through the AMF, is a fifth surface with no direct 4G equivalent.
Granularity matters as much as the interfaces. 5G quality of service (QoS) works on QoS flows inside a protocol data unit (PDU) session. Each flow carries a QoS Flow Identifier (QFI) and a 5QI value that sets its characteristics, with guaranteed and maximum bit rates for GBR flows. The PCF is expected to author rules at that level. A policy engine built around access point name (APN) or bearer-level decisions will struggle to express what the SMF is asking for, even if a protocol adapter gets the messages through.
There is a second-order trap. Operators who solve N7 by standing up a separate PCF beside the PCRF end up with two authoring environments and two rule sets that drift apart. The same subscriber is then treated differently depending on whether the device registered on 4G or 5G. A converged policy plane avoids that split. That is how Alepo Converged Policy Control was built: PCF for 5G SA and PCRF for 4G EPC and 5G NSA on one 3GPP Release 16 platform, so plans already authored carry across access generations.
Dimension 3: Network slicing readiness
Slicing is where the first two dimensions intersect. It is also where an assessment most often turns from “we are fine” into “we have work to do.” A slice is identified by a Single Network Slice Selection Assistance Information value (S-NSSAI): a Slice/Service Type such as eMBB, URLLC, or MIoT, plus an optional Slice Differentiator. Everything downstream has to be slice-aware, from which slices a subscriber may use to which policy applies inside each one.
Three questions expose the gaps. Can subscriber data carry subscribed S-NSSAIs and per-slice profile templates, so the AMF can compute the Allowed NSSAI at registration? Can the policy layer apply different QoS, usage limits, and charging rules to the same subscriber on different slices? Can accounting records carry the slice identity, so revenue can be attributed per slice? And can the AAA layer terminate NSSAA for slices sold to enterprise customers who insist on authenticating their own users, often against an AAA server in the enterprise’s own domain?
The third question decides whether slicing is a product or a slide. An enterprise buying a private slice for a factory will expect to control who joins it. The network slicing authentication article covers the DN-AAA and NSSAA mechanics; for a gap analysis, the indicator is simple. If nothing in the estate can act as the EAP server for a slice-specific authentication, the slice cannot be sold with that guarantee.
Slicing does not always require a new AAA platform. It requires the platform to support slice-aware policy attributes and modern EAP at core-network scale, and it requires policy and subscriber data that can be templated per slice. Some 4G-era platforms can be extended to do this. Many were never designed to, and the vendor’s answers to the three questions will tell you which you have.
Dimension 4: Subscriber data architecture
The quietest dimension, and the one with the longest lead time, is where subscriber data lives. In the EPC the HSS holds the subscription profile, the authentication vectors, and the serving-node registration. In the 5G core that role splits: the UDM handles subscription management and credential processing, the UDR stores subscription and policy data, and the AUSF fronts the authentication exchange. Subscriber data management and AAA have always been a pair; SA makes the pairing explicit.
Two 4G-era assumptions tend not to hold. The first is that authentication data and policy data are separate systems with separate provisioning. In SA the PCF reads policy subscription data from the same UDR the UDM uses. A slice template that exists in one but not the other produces registrations that succeed and sessions that fail. The second is that 4G and 5G subscribers can be managed as separate populations. N26 interworking between the MME and AMF, which most operators need so a session survives a move from 5G coverage to 4G, assumes a combined HSS-and-UDM view of the subscriber. Two vendors, two databases, and a synchronization job in between is a gap with an outage inside it. Alepo SDM, for example, runs the UDM and the HSS as a single node on one subscriber database, so the 4G and 5G views cannot drift.
The gap indicator here is a provisioning question. Ask what happens when a new plan with a new slice is created: how many systems are updated, in what order, and what happens if one update lands and another does not. If the honest answer involves a spreadsheet, the data architecture is not ready.
Running your own gap analysis
The table below is the framework in one place. Score each row as ready, partial, or gap, and attach the evidence: a vendor statement, a test result, or a configuration you have seen running. “The vendor says it is supported” without a test is partial at best.
| Readiness dimension | NSA / legacy state | 5G SA requirement | Gap indicator |
| Authentication protocol support | MME and HSS over S6a; EPS-AKA; AAA on SWx, S6b, SWm for non-3GPP and interworking | AUSF and UDM with 5G-AKA and EAP-AKA’, SUCI de-concealment; AAA for NSSAA and DN-AAA secondary authentication; a defined non-3GPP path through N3IWF and TNGF | No UDM path from the current HSS; AAA cannot terminate NSSAA or secondary EAP; “roadmap” answers on any 5G interface |
| Policy control granularity | PCRF over Gx, Rx, Sy, Sd, S9; APN- and bearer-level rules | PCF over N7, N15, N5, N28, Nudr; per-flow 5QI rules; access and mobility policy; UE route selection policy | PCRF has no Npcf services; separate PCF and PCRF with divergent rule sets; no per-flow authoring |
| Network slicing readiness | Single network, APN-based service separation | Subscribed S-NSSAIs and per-slice templates; slice-aware policy, charging, and accounting; NSSAA for enterprise slices | No S-NSSAI in subscriber data; policy cannot differentiate by slice; nothing in the estate can act as the EAP server for a slice |
| Subscriber data architecture | HSS holds profile and vectors; policy data provisioned separately | UDM, UDR, AUSF; shared UDR for subscription and policy data; combined HSS-and-UDM view for N26 interworking | Separate authentication and policy stores; two subscriber databases with a sync job; manual multi-system provisioning per new plan |
A worked example
Take an illustrative operator, deliberately generic: a mid-sized mobile operator running 5G NSA over an EPC from one vendor, a PCRF from a second, and an AAA server installed for Wi-Fi calling years ago. SA launch is planned for next financial year, with an enterprise private-slice offer as the business case.
Scoring the table, Dimension 1 comes out partial: the core vendor has a UDM, but the AAA server has no NSSAA capability. Dimension 2 is a gap, because the PCRF vendor’s PCF is a separate product with its own authoring tool. Dimension 3 is a gap, driven by both of the above. Dimension 4 is partial, since the UDM and the PCRF’s data store are different systems and plan provisioning already touches four consoles. The operator now knows the private-slice offer depends on the AAA and policy layers rather than on the radio, and can sequence the work accordingly. That is the value of doing this before the program plan is signed.
What to do about gaps you find
Order matters, because the four dimensions are not independent.
Fix subscriber data first, because everything else reads from it. A converged UDM, UDR, and HSS with slice templates is the clean answer; a single provisioning path into whichever systems you keep is the minimum. Either removes the failure mode where registration and session disagree about what a subscriber is entitled to.
Fix policy second, and prefer convergence over addition. A PCF beside the PCRF is quicker than replacing both, but the two-rule-set problem arrives within a year. If one platform can run PCF and PCRF from a single authoring environment, migrating plans becomes configuration rather than a rewrite.
Fix authentication third, in parallel rather than by cutover. A modern AAA platform can shadow live traffic before taking it, which is how you find the undocumented vendor-specific attributes without an outage.
Then treat slicing as the integration test for the other three. A private slice that authenticates against an enterprise AAA, applies slice-specific QoS, and produces slice-tagged accounting exercises every row of the table at once.
5G Standalone readiness: preparing your authentication and policy layer
The four dimensions are the assessment, and an architecture team can score all of them in an afternoon with the right vendor answers in hand. The finding that matters is rarely a single missing interface. It is a platform designed for one access generation being asked to serve two, and the remediation is a platform designed to serve both.
That is the design point of the Alepo AAA Server. It terminates RADIUS, Diameter, and TACACS+ on one stack, with the full EAP family including EAP-AKA’. It ships as a containerized network function for Kubernetes, and also runs on VMs, bare metal, or as a managed service. The platform carries 3GPP Release 15, 16, and 17 compliance and is engineered for 99.999% availability, with N+1 or N+N redundancy and real-time database replication. It is rated at 36,000+ transactions per second (AAA Server datasheet). Beside it, Alepo Converged Policy Control runs PCF and PCRF from one authoring environment on a 3GPP Release 16 platform. Alepo SDM provides AUSF, UDM, UDR, and HSS, with S-NSSAI slice templates on a converged subscriber database. Alepo’s AAA, policy, and subscriber-data deployments span Tier-1 and Tier-2 fixed and mobile operators across the Middle East, Europe, Africa, Asia-Pacific, and Latin America. Much of that work has been migration off platforms built for the previous generation.
If your gap analysis has come back with more partials than you expected, bring the table to us. Book a demo we will score it with you against a live 5G SA AAA and policy deployment. Or start with the Converged Policy Control datasheet and check the N5, N7, and N15 integration points against your own estate.
Frequently asked questions
Q1. How do I assess my authentication infrastructure’s readiness for 5G Standalone?
Run a gap analysis across four dimensions: authentication protocol support for the 5G core (AUSF, UDM, and AAA roles), policy control granularity (PCF services and per-flow rules), network slicing readiness (S-NSSAI-aware data, policy, and NSSAA), and subscriber data architecture (UDM, UDR, and combined HSS-and-UDM). Score each as ready, partial, or gap, with evidence.
Q2. What’s the difference between 5G Standalone and Non-Standalone authentication requirements?
Under NSA the device registers on the 4G core, so authentication is EPS-AKA between MME and HSS over S6a. Under SA the 5G core authenticates natively: AMF, AUSF, and UDM run 5G-AKA or EAP-AKA’ with SUCI concealment of the permanent identity. The AAA server remains in SA for slice authentication, secondary authentication, and EPC interworking.
Q3. What policy control gaps commonly block a 5G SA transition?
The most common is a PCRF with no Npcf services, so the SMF has nothing to talk to over N7. Close behind are the lack of per-flow 5QI rule authoring, no access and mobility policy over N15, and a separate PCF whose rules drift from the PCRF’s.
Q4. What authentication changes does 5G Standalone require versus 4G?
New functions (AUSF and UDM in place of MME-and-HSS authentication), new methods (5G-AKA and EAP-AKA’), identity concealment (SUCI), and new AAA roles (NSSAA through the NSSAAF, DN-AAA secondary authentication from the SMF). Non-3GPP access moves to the N3IWF and TNGF. Interworking interfaces such as SWx and S6b stay in use while 4G and 5G coexist.
Q5. What should be on a 5G Standalone readiness checklist?
All four dimensions of the table in this article: authentication protocol support, policy control granularity, network slicing readiness, and subscriber data architecture. For each, record the current state, the SA requirement, and the evidence that the requirement is met. Treat vendor roadmap statements as partial, and anything you have not seen tested as unverified.
Q6. What AAA infrastructure requirements does 5G core introduce?
NSSAA termination, secondary authentication over RADIUS and Diameter from the SMF, EAP-AKA’ at core-network rate, a defined path for non-3GPP identities once the N3IWF and TNGF replace the ePDG and TWAG, and continued SWx, S6b, and SWm support during interworking. Operationally, the AAA layer is expected to run cloud-native beside a service-based core.
Q7. How does network slicing affect authentication and policy requirements?
Subscriber data must carry subscribed S-NSSAIs, policy must differentiate QoS and charging per slice, accounting must carry the slice identity, and an AAA server must be able to run the EAP exchange for slices that require their own authentication. Platforms built around APN-level separation typically cannot do all four.
Q8. What’s the risk of an incomplete authentication readiness assessment for 5G SA?
Discovering the gaps during SMF integration testing or, worse, at launch. Remediating a policy or subscriber data gap mid-program means re-planning provisioning, retesting the core, and delaying the services the business case depends on.
Q9. How long does closing a 5G SA authentication gap typically take?
It depends on the dimension. A missing AAA interface can be closed in weeks if the platform supports it. Replacing a policy plane or converging subscriber data is a multi-month project that has to be sequenced with the SA launch, which is why the assessment belongs at the planning stage.
Q10. Does network slicing require a completely new AAA platform?
Not necessarily. It requires slice-aware policy attributes, modern EAP methods at scale, and the NSSAA or DN-AAA roles. Some existing platforms can be extended to that; many 4G-era platforms cannot, and the vendor’s written answer will tell you which you have.
