QoS Rules, IP Addressing, and Session Context in 5G NAS
In 5G NAS, the 5GSM sublayer defines how a PDU session receives IP addressing, QoS treatment, and other session-level parameters that the UE must store and apply. This includes the address-related, QoS-related, and session-level context first created in PDU Session Establishment Accept and later updated in PDU Session Modification Command if the network changes the session.
Use this page to understand the reusable session context of a PDU session: selected PDU session type, SSC mode, PDU address, Authorized QoS rules, Authorized QoS flow descriptions, Session-AMBR, Extended protocol configuration options, slice and DNN context, and related feature-specific parameters. It stays focused on what these parameters mean and how they are created or updated, rather than retelling the full establishment and modification procedure sequences.
Quick facts
| Technology | 5G |
|---|---|
| Area / Protocol | 5GSM session context in NAS |
| Main scope | PDU session IP addressing, QoS rules, QoS flow descriptions, Session-AMBR, and other reusable session parameters |
| Main create point | PDU Session Establishment Accept |
| Main update point | PDU Session Modification Command |
| Related topics | PDU Session ID and PTI, session establishment, session modification, PDU Session Establishment Accept, PDU Session Modification Command, QoS flow establishment, 5GSM states |
Contents
- What this page covers
- PDU session type and addressing basis
- IP address allocation
- QoS rules and QoS flow context
- Session context created at establishment
- Session context updates during modification
- Session context special cases
- Related procedure pages
- Related 5GSM messages
- Specification map
- FAQ
- References
- Related pages
What This Page Covers
| Area | Main focus | Why it belongs here |
|---|---|---|
| IP address allocation | How the session receives IPv4, IPv6, or IPv4v6-related context. | This is the base of the session-side addressing model. |
| Quality of service | How QoS rules, QoS flow descriptions, Session-AMBR, and related behavior are defined. | This is the reusable QoS model carried into the session context. |
| PDU Session Establishment Accept | The main message that creates baseline session context in the UE. | This is where selected session parameters are first delivered together. |
| PDU Session Modification Command | The main message that updates parts of an existing session context. | This explains the lifecycle of session parameters after first setup. |
PDU Session Type and Addressing Basis
The selected PDU session type is one of the first parameters that shapes the whole session context. It tells the UE what kind of addressing and service model the session is expected to support and therefore changes what later address-related and QoS-related parameters should mean.
| PDU session type | Main meaning | Why it matters for session context |
|---|---|---|
| IPv4 | IPv4 address allocation applies to the IPv4 PDU session type and may be delivered through NAS or DHCPv4-related handling. | The selected session type determines whether the session context needs only IPv4-related parameters. |
| IPv6 | IPv6 allocation includes IPv6-related addressing context and may involve link-local behavior, SLAAC, DHCPv6 parameters, or prefix delegation. | The session context must carry the right IPv6-related parameters for later UE behavior. |
| IPv4v6 | IPv4v6 combines IPv4 address information with IPv6-related context in one PDU session. | The UE must keep both address families inside the same session-side context. |
| Ethernet | Ethernet is part of the wider PDU session type model and is specifically called out in QoS behavior. | QoS matching and session behavior differ from simple IP-only reading. |
| Unstructured | Unstructured PDU session handling is treated separately in the QoS model. | All uplink packets are associated with the same QoS flow in this case. |
The selected session type becomes visible in the accepted session context, not only in the original request. A compact read might look like this in PDU Session Establishment Accept:
PDU SESSION ESTABLISHMENT ACCEPT
Extended protocol discriminator: 5GSM
PDU Session ID: 10
PTI: 0x01
Message type: PDU SESSION ESTABLISHMENT ACCEPT
Selected PDU session type: IPv4v6
Selected SSC mode: SSC mode 1
Authorized QoS rules: present
Session-AMBR: present
PDU address: IPv4 + IPv6 information
DNN: internet
S-NSSAI: presentIn this example, Selected PDU session type: IPv4v6 tells the reader that the later address-related context and QoS-side session context must be read as part of one combined dual-stack session rather than a simple IPv4-only or IPv6-only case.
IP Address Allocation
The session-side address model answers how the UE receives the addressing information it needs for the chosen PDU session type. In practical reading, this means understanding whether the session carries IPv4, IPv6, or both, and whether the session context is being delivered directly through NAS or with other supporting mechanisms.
| Allocation area | Main meaning | Reference reading note |
|---|---|---|
| General IP address allocation model | The session-side network selects addressing behavior according to the chosen PDU session type and operator policy. | This is the baseline for deciding whether the session carries IPv4, IPv6, or combined addressing context. |
| IP address allocation via NAS signaling | Addressing information can be delivered directly through session-side NAS signaling. | This is the most direct way the UE learns the address-related session context from establishment accept or later update behavior. |
| IPv6 prefix delegation via DHCPv6 | IPv6-related session behavior may involve DHCPv6 prefix delegation rather than only simple address delivery. | This matters when the session context needs to support delegated IPv6 behavior rather than only one host-side address view. |
| Additional RG-related requirements | Some session-context handling changes when residential-gateway-related behavior applies. | This is not the default case for every UE, but it changes what the addressing context must support. |
| Additional ProSe relay requirements | UE-to-network relay behavior adds its own address-allocation expectations. | This is a special deployment case that changes what should be stored and applied as session context. |
Start by checking the selected PDU session type, then confirm whether the session context needs IPv4-only, IPv6-only, or combined IPv4v6 behavior before deciding what the PDU address and later configuration mean.
A compact address-related read in PDU Session Establishment Accept might look like this:
PDU SESSION ESTABLISHMENT ACCEPT
Selected PDU session type: IPv6
PDU address: 2001:db8:100:1::/64
Extended protocol configuration options: present
DNN: internetIn this example, the address-related context is primarily IPv6-oriented. The reader should expect the session to keep IPv6 parameters rather than a simple IPv4-only address view.
QoS Rules and QoS Flow Context
QoS-related session context is one of the most reusable parts of a PDU session. It tells the UE how uplink packets should be matched, what QoS flow behavior is authorized, what the session aggregate bit-rate looks like, and whether reflective or MA-PDU-session-specific behavior should also be considered.
| QoS concept | Main meaning | Reference reading note |
|---|---|---|
| QoS rules | QoS rules define how uplink user data packets are matched and associated with QoS treatment inside a session. | This is one of the core reusable parts of session context because later traffic behavior depends on it. |
| Signalled QoS rules | The network can provide QoS rules during establishment or modification. | These are the rules the UE is explicitly told to apply. |
| Derived QoS rules | Some QoS behavior can be derived rather than fully signalled as an independent rule set. | This matters when the full traffic treatment is not only a direct copy of one signalled rule block. |
| QoS flow descriptions | QoS flow descriptions identify how the authorized QoS flow side of the session should be understood. | These are separate from QoS rules, even though the two are read together in session context. |
| Session-AMBR | Session-AMBR defines the aggregate maximum bit-rate context for the session. | It is part of the baseline session context from establishment and can later be updated. |
| UL user data packet matching | The UE uses the rule set to decide how uplink packets should be matched to the right QoS treatment. | This is one of the most practical reasons the rules must be read clearly. |
| Reflective QoS | Reflective QoS is treated as its own part of the 5GSM QoS model. | It should be read separately because it changes how QoS context can be applied or inferred later. |
| QoS in MA PDU session | MA PDU session behavior can require one or two QoS-related sets depending on access and interworking conditions. | This is one of the most important special cases because it changes how much session context the UE maintains. |
5G QoS Flow Establishment
Use the QoS-focused flow when the next question is how the authorized session QoS becomes live service behavior.
5G NAS Messages
Open the NAS message library when you need message-level reading of establishment accept or modification command QoS fields.
A compact QoS-focused read in PDU Session Establishment Accept might look like this:
PDU SESSION ESTABLISHMENT ACCEPT
Authorized QoS rules: present
Rule 1: default rule, QFI 9, precedence 255
Authorized QoS flow descriptions: present
QFI 9: 5QI and allocation details present
Session-AMBR: DL 200 Mbps / UL 100 MbpsIn this example, the reader can separate three different QoS objects: the Authorized QoS rules used for packet matching, the Authorized QoS flow descriptions used for flow-level authorization, and the Session-AMBR that limits the aggregate session rate.
Session Context Created at PDU Session Establishment
Establishment creates the baseline session context in the UE. This is where the session becomes more than a request: it now has selected type, selected mode, QoS-side authorization, address-related parameters, and any other feature-specific items the UE must store for later use. Use PDU Session Establishment for the full sequence and PDU Session Establishment Accept for the exact message that delivers the baseline session context.
| Context group | Session parameters |
|---|---|
| Mandatory establishment context | Selected PDU session type, Selected SSC mode, Authorized QoS rules, Session-AMBR |
| Address and routing context | PDU address, Extended protocol configuration options |
| QoS and traffic context | Authorized QoS flow descriptions, RQ timer value |
| Slice and DNN context | S-NSSAI, DNN |
| Feature and optimization context | 5GSM network feature support, Serving PLMN rate control, ATSSS container, Control plane only indication, IP header compression configuration, Ethernet header compression configuration |
| Special interworking and service context | Mapped EPS bearer contexts, EAP message, Service-level-AA container, Received MBS container, N3QAI, Protocol description |
A baseline establishment-context read in PDU Session Establishment Accept might look like this:
PDU SESSION ESTABLISHMENT ACCEPT
Selected PDU session type: IPv4v6
Selected SSC mode: SSC mode 1
Authorized QoS rules: present
Session-AMBR: present
PDU address: present
Authorized QoS flow descriptions: present
S-NSSAI: present
DNN: internet
5GSM network feature support: presentThis is the baseline session context view: it combines session type, mode, QoS, address-related fields, and slice or DNN context in one accepted session branch.
Session Context Updates During Modification
Modification does not recreate the whole session from zero. It changes selected parts of an already-existing session context. That is why this section is best read as a lifecycle view: establishment creates the baseline, and modification changes the parts that need to evolve later. Use PDU Session Modification for the flow view and PDU Session Modification Command for the exact network message that updates the stored session context.
| Update area | Main meaning |
|---|---|
| Session-AMBR updates | The aggregate session bit-rate context can be changed after establishment. |
| Authorized QoS rule updates | The network can replace, add, or otherwise update the QoS-rule view of the session. |
| Authorized QoS flow description updates | The QoS-flow side of the session context can also be updated without recreating the full session. |
| Always-on and RQ timer updates | Timers and always-on behavior may be updated as part of modification handling. |
| EPC interworking updates | Mapped EPS bearer context can be updated where interworking behavior applies. |
| ATSSS and optimization updates | ATSSS and header-compression-related optimization context can change later in the session lifecycle. |
| Slice and rate-control updates | Alternative slice context, serving-PLMN rate control, N3QAI, and protocol-description-related context may also be updated. |
A later update read in PDU Session Modification Command might look like this:
PDU SESSION MODIFICATION COMMAND
Session-AMBR: updated
Authorized QoS rules: updated
Authorized QoS flow descriptions: updated
RQ timer value: present
Serving PLMN rate control: presentIn this example, the session itself already exists. The reader should interpret the message as a change to stored context, not as a brand-new session creation branch.
Session Context Special Cases
Not every PDU session uses the simplest session-context shape. Some deployments add special behavior that changes what the UE must keep and how later updates should be interpreted.
| Special case | Main meaning |
|---|---|
| MA PDU session context | MA PDU sessions can change how many QoS-rule and Session-AMBR sets the UE keeps. This is one of the most important cases where session context is not just one simple rule block. |
| Mapped EPS bearer context | Interworking-related mapping can become part of the session context and must be read alongside the normal 5GSM parameters. |
| Always-on PDU session context | Always-on behavior changes what the UE should expect about ongoing session continuity and lifecycle handling. |
| CIoT control-plane-only context | Control-plane-only behavior changes what parts of the session are expected to exist and how the UE should interpret them. |
| Service-level authentication context | Some sessions include additional service-level authentication or authorization context that is not part of the simplest normal case. |
A special-case session-context read in PDU Session Establishment Accept might look like this:
PDU SESSION ESTABLISHMENT ACCEPT
Selected PDU session type: IPv4v6
Always-on PDU session indication: present
ATSSS container: present
Mapped EPS bearer contexts: present
Service-level-AA container: presentIn this example, the reader should not treat the accepted session as a simple default case. The presence of Always-on, ATSSS, Mapped EPS bearer contexts, and Service-level-AA shows that the stored session context includes special lifecycle, interworking, and service-control behavior beyond the normal baseline set.
Specification Map
| Area | What it covers |
|---|---|
| IP address allocation | Address allocation model, NAS-delivered address context, IPv6 delegation-related behavior, and special requirements. |
| Quality of service | QoS rules, QoS flow descriptions, Session-AMBR, uplink packet matching, reflective QoS, and MA PDU session QoS behavior. |
| PDU Session Establishment Accept | The baseline set of session parameters first delivered to the UE. |
| PDU Session Modification Command | The update path for selected session parameters after establishment. |
| Related 5GSM information elements | The formal IE-level definition area for session parameters such as PDU address, Session-AMBR, QoS rules, and related fields. |
FAQ
What is included in 5G NAS session context for a PDU session?
It includes items such as selected PDU session type, selected SSC mode, authorized QoS rules, Session-AMBR, PDU address, authorized QoS flow descriptions, slice and DNN context, and feature-specific parameters that the UE must keep for the session.
How does 5G NAS allocate IPv4, IPv6, and IPv4v6 addresses?
The address-related session context depends on the selected PDU session type. IPv4, IPv6, and IPv4v6 each create different address behavior and stored session parameters in the UE.
What is the difference between Authorized QoS rules and Authorized QoS flow descriptions?
Authorized QoS rules describe packet-matching and rule behavior, while Authorized QoS flow descriptions describe the authorized QoS-flow side of the session context.
What is Session-AMBR in 5G NAS?
Session-AMBR is the aggregate maximum bit-rate context for the PDU session and is one of the reusable session parameters carried in establishment and modification handling.
Which session parameters are created at establishment and which are updated during modification?
Establishment creates the baseline session context. Modification updates selected parts such as Session-AMBR, QoS rules, QoS flow descriptions, timers, feature support, and other changeable session parameters.
What changes in session context for an MA PDU session?
MA PDU session handling can change how many QoS-related sets the UE maintains, which makes the session context more complex than the simplest single-set case.
References
- 3GPP TS 24.501, Non-Access-Stratum (NAS) protocol for the 5G System
- 3GPP TS 23.502, Procedures for the 5G System