NAS 5G UE to AMF 3GPP TS 24.501

5G NAS - Service Request

Service Request is the NAS message the UE uses to request service resumption when it already has a valid registration context but needs active signaling again.

Message Fact Sheet

Protocol	nas	Network	5g
Spec	3GPP TS 24.501	Spec Section	8.2.15
Direction	UE to AMF	Message Type	5GMM signaling

Full message name	5G NAS - Service Request
Protocol	NAS
Technology	5G
Direction	UE to AMF
Interface	N1
Signaling bearer / channel	NAS signaling / Dedicated NAS message carried after access or resume-related signaling
Typical trigger	UE has uplink or downlink service need while already registered but not in active connected service state.
Main purpose	Lets the UE request service handling without performing a full fresh registration, typically to resume data or signaling activity using existing context.
Main specification	3GPP TS 24.501, 8.2.15
Release added	Release 15
Procedures where used	Service Request, Idle / Inactive Service Resume
Related timers	T3517, T3525
Related cause values	Service type

What is Service Request in simple terms?

Service Request is the NAS message the UE uses to request service resumption when it already has a valid registration context but needs active signaling again.

Lets the UE request service handling without performing a full fresh registration, typically to resume data or signaling activity using existing context.

Why this message matters

Service Request is the UE asking the network to restart active service using its existing registration context.

Where this message appears in the call flow

Service Request

Call flow position: Used when the UE already has registration context and wants active service restored.

Typical state: UE is registered but needs active service handling.

Preconditions:

The UE has valid 5GMM context.
The UE has completed the needed access-side step such as resume or setup if applicable.

Next likely message: Service Accept or Service Reject

Call flow position

Previous message(s): Paging, RRC Resume, Stored registration context

Next message(s): Service Accept, Service Reject

Message direction and transport

Sender and receiver: UE to AMF

Interface: N1

Domain: Core-side mobility management signaling with strong dependency on access-side resume or setup behavior

Signaling bearer: NAS signaling

Logical channel: Dedicated NAS message carried after access or resume-related signaling

Transport / encapsulation: NAS 5GS message carried end-to-end between UE and AMF

Security context: Normally protected because Service Request usually relies on an existing NAS security context.

Message Structure Overview

Service Request is not a fresh registration message.
Its main value is in reconnecting active service using already existing registration state.

Structure Syntax

This message is not typically analyzed as ASN.1 on the wire. Engineers usually inspect it as a NAS or protocol field decode rather than an ASN.1 tree.

Service Request is a NAS 24.501 message, not ASN.1.

Decoded Message Dump

Service Request
  Extended Protocol Discriminator: 5G Mobility Management
  Security Header Type: Integrity protected and ciphered
  Message Type: Service Request
  Service Type: Mobile originating data

How to read this dump

The service type is one of the first things engineers inspect because it explains why the UE is asking for service.

Important Information Elements

IE	Required	Description
`Service type`	Yes	Explains what kind of service handling the UE is requesting.
`TMSI-based identity context`	Yes	Lets the network correlate the request with the UE's existing registered context.

Detailed field explanation

`Service type`

Explains what kind of service handling the UE is requesting.

Presence: Required

`TMSI-based identity context`

Lets the network correlate the request with the UE's existing registered context.

Presence: Required

What to check in logs and traces

Confirm the UE already had valid registered context.
Correlate the message with paging, resume, or other access-side triggers.
Check whether the next NAS message is Service Accept or Service Reject.

Common Issues and Troubleshooting

UE reaches resume or access but service still does not continue.

Likely cause: The issue may be in NAS service handling rather than the earlier paging or radio path.

What to inspect: Check Service Request fields, security state, and the resulting Service Accept or Reject.

Next step: Correlate with AMF decision and session state.

Detailed explanation

5G NAS - Service Request Explained

Service Request is the NAS message used when the UE is already registered and just needs active service handling again. It is not a fresh registration and not a reject path. It is the UE’s way of saying: I already have context, now I need service resumed.

What is Service Request in simple terms?

The UE already has valid 5G registration. It now wants to send or receive data or signaling again, so it asks the network to restore active service.

Why this message matters

This message sits between reachability and real service continuation. If it fails, users often experience the symptom as “paging worked” or “resume worked” but traffic still did not continue.

Where this message appears in the call flow

UE                              gNB / AMF
|<-- Paging ---------------------|
|--- Resume / access ----------->|
|--- Service Request ----------->|
|<-- Service Accept / Reject ----|

Transport characteristics

sender: UE
receiver: AMF
interface: N1
common context: follows paging, setup, or resume depending on the scenario

What Service Request means operationally

Operationally, Service Request means the UE is not trying to register from scratch. It already has valid 5GMM context and now wants the network to restore active service handling.

That makes it a bridge between:

reachability, paging, or resume on the access side
and actual service continuation on the core side

If traces show successful paging or resume but no real service continuity, this message is often where the useful NAS analysis starts.

Important Information Elements

IE	Why it matters
`Service type`	Tells you what kind of service handling the UE is asking for.
`Identity context`	Correlates the request with existing registration state.

Example message dump

Service Request
  Extended Protocol Discriminator: 5G Mobility Management
  Security Header Type: Integrity protected and ciphered
  Message Type: Service Request
  Service Type: Mobile originating data

How to read this dump

Confirm the UE really had valid registration context before the message.
Read Service Type first because it explains why active service is being requested.
Then correlate the message with the following Service Accept or Service Reject.

What to check in logs

verify that the message follows paging, resume, or another legitimate service trigger
confirm the NAS security state matches an existing registered context
inspect the service type and identity correlation fields
look immediately at the AMF response because Service Accept versus Service Reject changes the rest of the analysis

FAQ

What does Service Request do in 5G?

It asks the network to restore active service when the UE is already registered.

Summary

Service Request is the NAS message the UE uses to request service resumption when it already has a valid registration context but needs active signaling again.

Advanced Engineer Notes

This message is often best analyzed together with paging, RRC resume, and AMF service-state transitions.

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.