Home / Call Flows / 5G / Relay / Sidelink Security Procedure

5G Relay / Sidelink Security Procedure Call Flow

call-flow 5G | Relay Security | Sidelink Security | NAS | Specialized Features

5G Relay / Sidelink Security is the specialized security family used when relay-aware or sidelink-aware features need their own trusted continuation beyond normal subscriber access security.

It is the place where feature-specific key handling and feature-specific authentication decide whether those specialized behaviors may continue.

Introduction

This branch is different from ordinary registration and service security because it protects the specialized feature itself, not only the subscriber’s general 5G access.

That is why engineers often see normal service working while the relay or sidelink feature still fails: the failure lives inside this specialized security path.

What Is Relay / Sidelink Security Procedure in Simple Terms?

What starts the procedure: A relay or sidelink feature needs its own trusted security continuation.
What the UE and network want to achieve: Authorize and protect specialized relay-aware or sidelink-aware behavior.
What success looks like: The feature-specific key and authentication branch completes and the specialized feature continues.
What failure means: The specialized feature is denied or unstable even though ordinary service may still work.

Why this procedure matters

Relay and sidelink features create a second layer of trust beyond ordinary 5G access. This procedure is where that specialized trust is either earned or denied.

Quick Fact Sheet

Procedure name	5G Relay / Sidelink Security Procedure
Domain	5G relay-aware and sidelink-aware security handling
Main trigger	The UE is participating in relay or sidelink behavior that requires feature-specific security context beyond ordinary access security
Start state	UE already has or is obtaining general 5G trust, but feature-specific relay or sidelink protection is not yet established
End state	Relay or sidelink signaling can continue using the validated feature-specific security context
Main nodes	UE or relay participant, network security functions, relay-aware control context
Main protocols	NAS, relay-specific security messages, sidelink feature security handling
Main success outcome	The feature-specific security branch completes and relay or sidelink operation can continue safely
Main failure outcome	The UE keeps normal service trust but the relay or sidelink feature branch is denied or unstable
Most important messages	Relay Key Request, Relay Key Accept or Reject, Relay Authentication Request, Relay Authentication Response
Main specs	TS 24.501, TS 23.501, TS 23.502

5G Relay and Sidelink Security Procedure call flow

Preconditions

The UE or participant is using or requesting a relay-aware or sidelink-aware feature branch.
Ordinary 5G access trust may already exist but is not sufficient for the specialized feature.
The network supports the specialized security messages for the feature.
Transaction continuity can be maintained across the key and authentication phases.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE or relay-capable participant	Requests and applies feature-specific relay or sidelink security context.
Network relay-security handling	Evaluates relay-specific requests and decides whether the feature-specific branch may continue.
Relay or sidelink transaction context	Keeps feature-specific request, acceptance, and authentication state aligned across the exchange.

Interfaces used

Interface	Path	Role
NAS security branch	UE or relay participant <-> network	Carries relay-specific key handling and later feature-authentication signaling.
Feature-specific relay or sidelink context	Internal procedure state	Maintains the relay-aware or sidelink-aware continuity needed for later protected operation.

End-to-End Call Flow

Participant                Network
|-- Relay Key Request ----->|
|<- Relay Key Accept/Reject-|
|<- Relay Authentication ---|
|-- Relay Authentication -->|
|==== feature continues only if specialized trust succeeds ====|

Major Phases

Phase	What happens
1. Feature-specific security need appears	The relay or sidelink feature cannot continue using only ordinary 5G access trust.
2. Relay-aware key handling	The participant asks the network for the feature-specific security branch to begin.
3. Feature authentication	If the key branch is accepted, the network validates the relay-aware or sidelink-aware participant using the dedicated exchange.
4. Feature continuation or denial	The feature continues only if the specialized branch succeeds.

Step-by-Step Breakdown

Relay or sidelink feature reaches a security checkpoint

Sender -> receiver: UE or relay participant -> network feature logic

Message(s): Feature-entry security trigger

Purpose: Recognize that ordinary registration and NAS trust are not enough for this specialized branch.

State or context change: The participant may already be a valid 5G subscriber, but the feature itself is still not trusted.

Note: This is why relay or sidelink failures can coexist with otherwise healthy registration and service traces.

Participant starts feature-specific key handling

Sender -> receiver: Participant -> network

Message(s): Relay Key Request and Relay Key Accept or Relay Key Reject

Purpose: Ask the network to create or approve the security basis for the specialized relay or sidelink branch.

State or context change: The feature moves from generic trust into feature-specific security setup.

Note: If the branch is rejected here, the specialized feature stops even though ordinary 5G service may remain fine.

Network performs feature-specific authentication

Sender -> receiver: Network -> participant and participant -> network

Message(s): Relay Authentication Request and Relay Authentication Response

Purpose: Validate that the participant is allowed to continue with relay or sidelink behavior.

State or context change: The specialized branch now moves from key setup into trust validation.

Note: This phase is where transaction continuity and feature-specific identity handling become critical.

Feature either continues securely or is denied

Sender -> receiver: Network feature decision

Message(s): Feature continuation or termination behavior

Purpose: Decide whether relay or sidelink signaling may proceed using the specialized security context.

State or context change: The UE either gains protected feature access or remains limited to ordinary service behavior.

Note: If the feature fails while ordinary 5G access remains healthy, this is often the decisive branch to inspect.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Relay Key Request	NAS	Participant -> network	Starts specialized relay-aware security handling.	Inspect transaction identity and feature context alignment.
Relay Key Accept or Relay Key Reject	NAS	Network -> participant	Shows whether the specialized branch may continue.	Inspect whether rejection is due to policy, context, or malformed request state.
Relay Authentication Request	NAS	Network -> participant	Challenges the participant for feature-specific trust validation.	Inspect continuity from the earlier key-handling branch.
Relay Authentication Response	NAS	Participant -> network	Returns the feature-specific proof needed for continuation.	Inspect whether the response reaches the network and completes the same transaction context.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Feature-specific transaction identity	The identifier tying the relay or sidelink security exchange together.	Relay-specific NAS messages	Critical for proving continuity across key and authentication branches.	If it changes unexpectedly, the branch often fails even with valid payloads.
Feature authorization context	Whether the participant is actually allowed to use the specialized feature.	Request and accept or reject handling	Explains why a valid subscriber can still lose the feature branch.	Authorization mismatch is easy to confuse with generic NAS failure.
Key-branch outcome	Whether the specialized key handling succeeded before authentication started.	Relay Key Accept or Reject	Defines whether later feature authentication should even be attempted.	If ignored, engineers may troubleshoot the wrong phase.
Feature-authentication continuity	Whether the later authentication exchange follows the same feature transaction and context.	Relay Authentication Request and Response	Separates real proof failure from transaction drift.	Transaction drift can look like bad authentication.
Ordinary-service versus feature-specific success	Whether normal 5G service still works while the specialized feature fails.	Whole-trace comparison	Helps isolate the problem to relay or sidelink security rather than general subscriber state.	Without this comparison, feature failures get overgeneralized.

Success Criteria

The specialized feature request is authorized and accepted.
Transaction continuity holds across the key and authentication phases.
The participant completes the feature-specific authentication exchange.
The relay or sidelink feature actually continues afterward.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Relay or sidelink feature fails while ordinary service still works	The feature-specific security branch failed even though general subscriber trust is healthy.	Feature authorization and transaction continuity.	Relay Key and Relay Authentication messages	NAS specialized branch	This is the most common and most important isolation clue.
Relay Key is rejected immediately	The specialized feature request is not acceptable in the current context.	Request parameters, policy, and authorization state.	Relay Key Request, Relay Key Reject	NAS specialized branch	Do not treat this like ordinary registration rejection.
Key handling succeeds but authentication later fails	The branch moved forward, but the participant could not complete specialized trust validation.	Transaction continuity and later feature authentication data.	Relay Authentication Request and Response	NAS specialized branch	The root cause is often later in the branch than engineers first assume.
Authentication response never arrives	The participant did not process the challenge or the specialized branch lost continuity on the way back.	Uplink continuity and transaction identity.	Relay Authentication Response	NAS specialized branch	This is often a feature-path delivery problem, not just a security-calculation problem.

What to Check in Logs and Traces

Compare ordinary service health with feature-specific branch health first.
Inspect the Relay Key transaction identity across all specialized messages.
Separate authorization failure from feature-authentication failure.
If the response is missing, inspect the specialized uplink path and transaction continuity.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is the 5G Relay / Sidelink Security Procedure?

It is the specialized security branch used when relay-aware or sidelink-aware features need their own trusted continuation beyond normal access security.

Why is this separate from normal authentication?

Because a UE can be a valid 5G subscriber and still need extra feature-specific security handling for relay or sidelink behavior.

What should I inspect first when the feature fails?

Start by comparing ordinary service success with feature-specific branch failure, then inspect Relay Key transaction continuity.

Is Relay Key Procedure part of this family?

Yes. It is one of the main specialized security branches inside relay-aware feature handling.

Why can the feature fail even when registration and service look normal?

Because the relay or sidelink branch has its own security authorization and transaction continuity requirements.