NAS 5G SMF to UE via AMF 3GPP TS 24.501

5G NAS - PDU Session Establishment Accept

PDU Session Establishment Accept is the 5GSM success message the network sends after it creates the requested PDU session and returns the final session parameters, address, and QoS context.

Message Fact Sheet

Protocol	nas	Network	5g
Spec	3GPP TS 24.501	Spec Section	8.3.2
Direction	SMF to UE via AMF	Message Type	5GSM signaling

Full message name	5G NAS - PDU Session Establishment Accept
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 accepted the UE's PDU Session Establishment Request after evaluating subscription, DNN, slice, policy, and user-plane requirements.
Main purpose	Confirms that the requested PDU session was created and delivers the session parameters the UE needs to use the data connection correctly.
Main specification	3GPP TS 24.501, 8.3.2
Release added	Release 15
Procedures where used	5G PDU Session Establishment, VoNR Registration, PDU Session Authentication
Related timers	T3580

What is PDU Session Establishment Accept in simple terms?

PDU Session Establishment Accept is the 5GSM success message the network sends after it creates the requested PDU session and returns the final session parameters, address, and QoS context.

Confirms that the requested PDU session was created and delivers the session parameters the UE needs to use the data connection correctly.

Why this message matters

PDU Session Establishment Accept means the network created the UE's data session and is telling the UE what address, QoS, and service parameters it should use next.

Where this message appears in the call flow

5G PDU Session Establishment

Call flow position: Successful downlink response returned after the SMF accepts the UE-requested session and finishes the main session context.

Typical state: The UE is waiting for session parameters and will move from establishment pending to active once it sends the completion message.

Preconditions:

The UE is already registered and NAS security is in place.
The PDU Session Establishment Request reached the SMF path successfully.
The requested DNN, slice, and policy combination was accepted.

Next likely message: User-plane data transfer

VoNR Registration

Call flow position: Often carries the IMS PDU session context used after registration for voice service.

Typical state: The UE is registered and is bringing up the IMS data session.

Preconditions:

Registration completed successfully.
The requested IMS DNN and slice combination is allowed.

Next likely message: Voice signaling over the newly established session

Call flow position

Previous message(s): PDU Session Establishment Request, DL NAS Transport, PDU Session Authentication Complete

Next message(s): User-plane data transfer, PDU Session Modification Request, PDU Session Release Request

Message direction and transport

Sender and receiver: SMF to UE via AMF

Interface: N1

Domain: Core-side session management response with access-side NAS delivery dependency

Signaling bearer: NAS signaling

Logical channel: Usually carried inside DL NAS Transport on the access side

Transport / encapsulation: 5GSM NAS message transported end-to-end from the SMF to the UE through AMF mediation

Security context: Normally sent after NAS security is established, so the downlink NAS payload is usually integrity protected and often ciphered.

Message Structure Overview

PDU Session Establishment Accept is a 5GSM NAS success response defined by ordered information elements in TS 24.501, not by ASN.1.
The mandatory core of the message identifies the accepted transaction and the final session selection: session type, SSC mode, DNN, QoS rules, and Session AMBR.
Optional fields then add the practical engineering details: address assignment, slice context, reflective QoS timer, EPS interworking, authentication result, and protocol configuration.
Release 15 defines the baseline, while later releases add optional containers and feature-specific extensions such as Always-on, ATSSS-related, and MBS-related information where supported.

ASN.1 Message Syntax for 5G NAS - PDU Session Establishment Accept

This message is not typically analyzed as ASN.1 on the wire. It is usually read as a NAS or protocol field structure instead.

This message is a 5GSM NAS structure defined by TS 24.501 information elements, not ASN.1. Engineers normally decode the ordered IE set and optional fields rather than a tree-based ASN.1 structure.

5G NAS - PDU Session Establishment Accept - Example Dump

PDU Session Establishment Accept
  Extended Protocol Discriminator: 5G Session Management
  PDU Session ID: 10
  PTI: 1
  Message Type: PDU Session Establishment Accept
  Selected PDU Session Type: IPv4v6
  Selected SSC Mode: SSC mode 1
  DNN: ims
  Authorized QoS Rules:
    Rule 1:
      QFI: 9
      Packet filter: permit out ip from any to any
      Precedence: 255
  Session AMBR:
    Downlink: 200 Mbps
    Uplink: 100 Mbps
  PDU Address:
    IPv4: 10.145.23.14
    IPv6 interface identifier: 2001:db8:100::14
  S-NSSAI:
    SST: 1
    SD: 0x112233
  RQ Timer Value: 300 s
  Extended Protocol Configuration Options:
    DNS IPv4 address: 10.1.1.1
    DNS IPv6 address: 2001:db8::53

How to read this dump

Start with PDU Session ID and PTI because they tie the accept to the correct request transaction.
Check the selected PDU session type and SSC mode first because they define the actual session behavior the network accepted.
PDU Address is the fastest indicator of whether the UE received usable addressing for the requested session type.
Authorized QoS Rules and Session AMBR usually explain performance complaints sooner than packet capture timing does.
DNN and S-NSSAI should be compared with the original request and registration-time context whenever the session behaves unexpectedly.
If a 5GSM cause is present in the accept, inspect whether the network normalized the requested session type instead of rejecting it.

Important Information Elements

IE	Required	Description
`Selected PDU session type`	Yes	Shows the final session type the network accepted. This can differ from the requested type, so it is one of the first fields to verify.
`Selected SSC mode`	Yes	Shows the continuity mode the network actually accepted for the session and helps explain later mobility or anchor behavior.
`DNN`	Yes	Identifies the data network for the session and is critical for IMS, enterprise, and internet access troubleshooting.
`Authorized QoS rules`	Yes	Defines the accepted QoS behavior and packet-filter to QFI mapping that the UE should use for this session.
`Session AMBR`	Yes	Defines the aggregate uplink and downlink bit-rate cap for the session and is often the first sign of an intentionally restricted service.
`5GSM cause`	Optional	Included when the selected PDU session type differs from the requested one. In practice, this can reveal a network normalization decision rather than a hard failure.
`PDU address`	Optional	Carries the IPv4 address, IPv6 interface identifier, or dual-stack context that the UE should use for user-plane traffic.
`RQ timer value`	Optional	Used when reflective QoS is supported and the network wants to tell the UE how long to apply it.
`S-NSSAI`	Optional	Confirms the slice context used by the session and is especially important in roaming or slice-dependent service setups.
`Mapped EPS bearer contexts`	Optional	Present when interworking to EPS is supported for the session and the network maps QoS flows to EPS bearers.
`EAP message`	Optional	Carries a successful EAP result when the external DN performed authentication and authorization.
`Extended protocol configuration options`	Optional	Carries optional network configuration such as DNS or other protocol parameters that often explain later service behavior.
`Always-on PDU session indication`	Optional	Relevant in later releases and feature sets where the network explicitly indicates always-on behavior for the session.

Detailed field explanation

`Selected PDU session type`

Shows the final session type the network accepted. This can differ from the requested type, so it is one of the first fields to verify.

Presence: Required

In practice: In practice, this field tells you what connectivity model the network finally accepted, so it is one of the first places to look when the UE requested IPv4v6 but the session came back narrower than expected.

`Selected SSC mode`

Shows the continuity mode the network actually accepted for the session and helps explain later mobility or anchor behavior.

Presence: Required

In practice: This matters for mobility and service continuity. If the accepted SSC mode is different from what the UE or service expected, later handover or anchor behavior can look inconsistent even though the session itself was accepted.

`DNN`

Identifies the data network for the session and is critical for IMS, enterprise, and internet access troubleshooting.

Presence: Required

In practice: The DNN is the service anchor for the session. In traces, compare it directly with the requested DNN and with the subscription or IMS profile to confirm the session was built toward the right data network.

`Authorized QoS rules`

Defines the accepted QoS behavior and packet-filter to QFI mapping that the UE should use for this session.

Presence: Required

In practice: QoS rules are the real service profile of the session. Inspect the QFI mapping, packet filters, and precedence because those values explain how user traffic will actually be classified and forwarded.

`Session AMBR`

Defines the aggregate uplink and downlink bit-rate cap for the session and is often the first sign of an intentionally restricted service.

Presence: Required

In practice: Session AMBR is often where throughput limits show up first. If user data is slower than expected immediately after setup, this is one of the highest-value fields to compare against policy and subscription limits.

`5GSM cause`

Included when the selected PDU session type differs from the requested one. In practice, this can reveal a network normalization decision rather than a hard failure.

Presence: Optional

In practice: When this appears in an accept, it often means the network normalized a requested value rather than failing the session outright. Check it together with the selected session type, not in isolation.

`PDU address`

Carries the IPv4 address, IPv6 interface identifier, or dual-stack context that the UE should use for user-plane traffic.

Presence: Optional

In practice: This field determines whether the UE received usable addressing for the session type. For IPv4v6 or IMS-type sessions, it is worth checking the address format and any returned IPv6 interface identifier carefully.

`RQ timer value`

Used when reflective QoS is supported and the network wants to tell the UE how long to apply it.

Presence: Optional

In practice: Reflective QoS timing only matters when the feature is actually in use. If the session uses reflective QoS, this timer helps explain how long the UE should keep applying the reflected behavior.

`S-NSSAI`

Confirms the slice context used by the session and is especially important in roaming or slice-dependent service setups.

Presence: Optional

In practice: This is the slice context that ties the session to the network selection outcome. In roaming or slice-specific cases, it is one of the strongest indicators of whether the session landed on the expected slice.

`Mapped EPS bearer contexts`

Present when interworking to EPS is supported for the session and the network maps QoS flows to EPS bearers.

Presence: Optional

In practice: When EPS interworking is enabled, this field explains how QoS flows map back to EPS bearers. It matters most when the same service has to behave consistently across 5G and LTE anchor handling.

`EAP message`

Carries a successful EAP result when the external DN performed authentication and authorization.

Presence: Optional

In practice: If present, it reflects the external DN authentication result. It is worth checking when the session succeeds on NAS but service access still depends on an external authentication flow.

`Extended protocol configuration options`

Carries optional network configuration such as DNS or other protocol parameters that often explain later service behavior.

Presence: Optional

In practice: This is where DNS and other operational configuration can hide. When the session is accepted but applications still fail, EPCO is often one of the first optional fields worth validating.

`Always-on PDU session indication`

Relevant in later releases and feature sets where the network explicitly indicates always-on behavior for the session.

Presence: Optional

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 accept matches the correct request using PDU Session ID and PTI.
Verify the selected PDU session type, SSC mode, DNN, and S-NSSAI are what the UE and service expect.
Inspect the PDU address carefully, especially for IMS, dual-stack, roaming, or enterprise scenarios.
Check the authorized QoS rules and Session AMBR before starting throughput or policy troubleshooting.
Compare any 5GSM cause in the accept against the requested session type and the final accepted type.
Correlate the message with SMF, UPF, and application behavior instead of stopping analysis at the NAS layer.
If the accept was delivered through DL NAS Transport, correlate the access-side NAS wrapper with the N1 session-management payload.

Common Issues and Troubleshooting

No PDU Session Establishment Accept appears after the request.

Likely cause: The SMF may not have accepted the request, the message may be stuck in transport, or the procedure may have branched into authentication or reject handling.

What to inspect: Check PDU Session Establishment Request, DL NAS Transport, PTI correlation, T3580 behavior, and core-side SMF traces.

Next step: Determine whether the path ended in Reject, Authentication, or a transport failure before assuming the session was accepted.

The session is accepted but the UE still cannot use data.

Likely cause: The session may be established with incomplete address, wrong DNN, unexpected slice context, or user-plane configuration issues.

What to inspect: Check PDU Address, DNN, S-NSSAI, Extended Protocol Configuration Options, and the related N2/N4 setup.

Next step: Correlate the NAS accept with user-plane tunnel activation and application-layer connectivity.

The accepted session type is different from the one requested.

Likely cause: The SMF normalized the session type to an allowed value, often because subscription or DNN policy only permits a narrower option.

What to inspect: Check the selected PDU session type, the optional 5GSM cause, and the original request type.

Next step: Verify whether the UE and application can live with the accepted type, especially in IPv4v6 downgrade cases.

Throughput is lower than expected from the start.

Likely cause: The returned Session AMBR, QoS rules, or slice policy may be more restrictive than expected.

What to inspect: Check Session AMBR, authorized QoS rules, QFI mapping, and policy context.

Next step: Use the accept as the baseline and compare it with the subscriber policy.

IMS or enterprise service fails after a successful accept.

Likely cause: The data session may be up, but the DNN, DNS, EAP result, or other protocol configuration is not aligned with the intended service.

What to inspect: Check DNN, PDU Address, EPCO, and any EAP message presence or absence.

Next step: Move to IMS or application troubleshooting once the session context is verified.

The message looks malformed or is decoded inconsistently across tools.

Likely cause: The trace may use a newer release feature, a vendor-specific parser may be stale, or the optional IE order may be handled poorly.

What to inspect: Check the release context, the exact optional IEs present, and whether the decoder understands later feature extensions.

Next step: Validate the decode with another tool or correlate against the raw NAS payload.

FAQ

What does PDU Session Establishment Accept do?

It confirms that the requested 5G PDU session was created and returns the final context the UE should use.

Who sends PDU Session Establishment Accept?

The SMF sends it to the UE via the AMF on the N1 path.

When is PDU Session Establishment Accept sent?

It is sent after the network accepts the PDU Session Establishment Request and completes the main policy and session-selection steps.

Which call flow includes PDU Session Establishment Accept?

It appears in the 5G PDU Session Establishment procedure and often in VoNR and enterprise session bring-up flows.

What are the important IEs in PDU Session Establishment Accept?

Start with Selected PDU Session Type, Selected SSC Mode, DNN, Authorized QoS Rules, Session AMBR, and then inspect PDU Address and S-NSSAI.

How do I read PDU Session Establishment Accept in logs?

Correlate it with the request using PDU Session ID and PTI, then verify the returned type, address, QoS, and slice context.

Is there ASN.1 for PDU Session Establishment Accept?

No. It is defined as a 5GSM NAS message with ordered IEs in TS 24.501.

What happens if PDU Session Establishment Accept looks wrong?

Check for session-type normalization, unexpected AMBR or QoS values, or a DNN and slice mismatch between request and response.

Related message pages

Related Procedures

Related Tools

Use This Reference in Practice

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.