Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
NAS5GSMF to UE via AMF3GPP TS 24.501
5G NAS - Service-level Authentication Command
Service-level Authentication Command is the 5GSM message the SMF sends to deliver service-level authentication and authorization payload to the UE.
Message Fact Sheet
Protocol
nas
Network
5g
Spec
3GPP TS 24.501
Spec Section
8.3.17
Direction
SMF to UE via AMF
Message Type
5GSM service-level authentication
Full message name
5G NAS - Service-level Authentication Command
Protocol
NAS
Technology
5G
Direction
SMF to UE via AMF
Interface
N1
Signaling bearer / channel
NAS signaling / Usually carried inside DL NAS Transport on the access side
Typical trigger
The SMF receives service-level authentication and authorization payload from the DN and needs to pass it to the UE.
Main purpose
Carries the Service-level-AA container so the UE can pass service-level authentication data to upper layers and continue the service-level authentication and authorization procedure.
Main specification
3GPP TS 24.501, 8.3.17
Release added
Release 17
Procedures where used
Service-level authentication and authorization procedure, DN-driven service authorization, Enterprise or application-specific service onboarding
Related timers
T3xyz
What is Service-level Authentication Command in simple terms?
Service-level Authentication Command is the 5GSM message the SMF sends to deliver service-level authentication and authorization payload to the UE.
Carries the Service-level-AA container so the UE can pass service-level authentication data to upper layers and continue the service-level authentication and authorization procedure.
Why this message matters
Service-level Authentication Command carries service-specific authentication or authorization data to the UE through the 5GSM layer.
Where this message appears in the call flow
Service-level authentication and authorization procedure
Call flow position: Network-issued service-level payload delivery step that passes the DN-driven authentication data to the UE.
Typical state: The UE already has an active PDU session or service context and is waiting for the service-level AA payload.
Preconditions:
The SMF received service-level-AA payload from the DN or associated authorization function.
The UE has a PDU session context that can carry the service-level procedure.
Next likely message: Service-level Authentication Complete
5G PDU Session Modification
Call flow position: May appear when a service-authenticated session needs additional network-to-UE service-level payload handling.
Typical state: The UE is already in a live session and the network is refining service authorization.
Preconditions:
The session is active.
Service-level AA data has been produced by the service backend or DN path.
Next likely message: Service-level Authentication Complete
Start with PDU Session ID so you know which service-level exchange is associated with the session.
Check PTI to correlate the command with the correct service-level authentication transaction.
The Service-level AA container is the real payload carrier, so the command should be read primarily through that container.
The payload is typically opaque at the 5GSM layer and must be interpreted by the upper-layer service logic.
Important Information Elements
IE
Required
Description
PDU Session ID
Yes
Identifies the PDU session associated with the service-level authentication exchange.
PTI
Yes
Correlates the command with the transaction that is carrying the service-level AA exchange.
Service-level AA container
Yes
Carries the service-level device ID, payload type, payload, or response needed for service-level authentication and authorization.
Detailed field explanation
PDU Session ID
Identifies the PDU session associated with the service-level authentication exchange.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
PTI
Correlates the command with the transaction that is carrying the service-level AA exchange.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Service-level AA container
Carries the service-level device ID, payload type, payload, or response needed for service-level authentication and authorization.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Confirm the message appears after the SMF receives service-level AA data from the DN or related authorization path.
Verify `PDU Session ID` and `PTI` first so the service-level exchange is correlated correctly.
Inspect the `Service-level AA container` fields, especially device ID, payload type, and payload.
Correlate the command with the UE's service-level authentication complete response.
Check whether the upper-layer service logic can actually interpret the payload that the SMF forwarded.
Validate `T3xyz` handling on the network side if the procedure stalls.
Common Issues and Troubleshooting
The UE receives the command but service-level auth does not progress.
Likely cause: The Service-level-AA payload may be malformed, unsupported, or not understood by the upper-layer service logic.
What to inspect: Check the container fields, payload type, and the DN or backend service that produced the payload.
Next step: Validate the payload with the service backend and the UE implementation.
The command is missing even though the backend produced service-level AA data.
Likely cause: The service-level payload may not have been delivered to the SMF, or the downlink NAS path may have failed.
What to inspect: Check SMF logs, NEF or UAS-NF path visibility, and DL NAS Transport.
Next step: Trace the payload from the backend to the SMF before assuming the UE skipped the procedure.
The session seems correct but the service still fails after the command.
Likely cause: The service-level AA payload may be valid at NAS level but rejected or misused by the upper-layer service application.
What to inspect: Check the service-level device ID and payload interpretation at the service layer.
Next step: Correlate NAS with the service platform logs, not just with the PDU session state.
FAQ
What does Service-level Authentication Command do?
It delivers service-level authentication and authorization data to the UE using the 5GSM NAS layer.
Who sends Service-level Authentication Command?
The SMF sends it to the UE via the AMF.
When is Service-level Authentication Command sent?
It is sent when the SMF has service-level AA payload that needs to be passed to the UE.
What are the important IEs in Service-level Authentication Command?
Start with PDU Session ID and PTI, then inspect the Service-level AA container.
Is this the same as PDU Session Authentication Command?
No. It is a separate service-level authentication and authorization message introduced in later 5GSM releases.
What happens after Service-level Authentication Command?
The UE processes the service-level AA container and sends Service-level Authentication Complete.
Is ASN.1 used for Service-level Authentication Command?
No. It is a 5GSM NAS message defined by structured information elements in 3GPP TS 24.501.
What timer is related to this message?
The spec uses T3xyz as the placeholder timer for this procedure.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.