| Protocol | nas | Network | 5g |
|---|---|---|---|
| Spec | 3GPP TS 24.501 | Spec Section | 8.2.35 |
| Direction | Network to UE | Message Type | 5GMM signaling |
| Full message name | 5G NAS - Relay Key Accept |
|---|---|
| Protocol | NAS |
| Technology | 5G |
| Direction | Network to UE |
| Interface | N1 |
| Signaling bearer / channel | NAS signaling / Dedicated NAS message, transported over the existing NAS path |
| Typical trigger | Sent after successful processing of Relay Key Request when the network can provide the requested relay key response information. |
| Main purpose | Confirms successful relay key processing and carries the relay response parameters needed for the next relay-security step. |
| Main specification | 3GPP TS 24.501, 8.2.35 |
| Release added | Release 17 |
| Procedures where used | Relay key procedure, Relay security handling, ProSe relay context |
Relay Key Accept is the NAS message the network sends when the relay key request succeeds and the relay-related key response material can be delivered to the UE.
Confirms successful relay key processing and carries the relay response parameters needed for the next relay-security step.
Relay Key Accept means the network accepted the relay key request and returned relay-related response information.
Call flow position: Positive response branch after Relay Key Request.
Typical state: The relay-aware NAS context is valid and the network has accepted the relay key request.
Preconditions:
Next likely message: Relay-procedure continuation or later relay authentication handling
Call flow position: Network response step delivering relay-key result information back to the UE.
Typical state: The relay security branch succeeded far enough to return usable relay-key response data.
Preconditions:
Next likely message: Relay-specific continuation
Previous message(s): Relay Key Request, Relay authentication context establishment
Next message(s): Relay procedure continuation, Relay Authentication Request
Security context: This message belongs to the relay-key handling branch, so it should be interpreted together with the earlier Relay Key Request, relay transaction identity, and the relay-specific response parameters.
This message is not typically analyzed as ASN.1 on the wire. It is usually read as a NAS or protocol field structure instead.
Relay Key Accept follows NAS 24.501 IE structure and is not an ASN.1 message.
Relay Key Accept
Extended Protocol Discriminator: 5G Mobility Management
Security Header Type: Integrity protected and ciphered
Message Type: Relay Key Accept
ProSe Relay Transaction Identity: 7
Relay Key Response Parameters: 0x98ab34cd...
| IE | Required | Description |
|---|---|---|
ProSe relay transaction identity | Yes | Identifies the relay-key transaction so the accept can be matched with the earlier request. |
Relay key response parameters | Yes | Carries the relay-specific response data returned by the network after successful key processing. |
ProSe relay transaction identityIdentifies the relay-key transaction so the accept can be matched with the earlier request.
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.
Relay key response parametersCarries the relay-specific response data returned by the network after successful key processing.
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.
Likely cause: The request succeeded, but the later relay-specific step may not accept or use the returned key response parameters correctly.
What to inspect: Check the relay transaction identity, response parameters, and the next relay procedure message.
Next step: Move analysis forward into the relay continuation step rather than treating the accept itself as the failure point.
Likely cause: The relay transaction identity and relay-specific context were not correlated carefully.
What to inspect: Match the transaction identity and compare request-versus-response parameters.
Next step: Rebuild the relay procedure timeline using the transaction identity as the anchor.
It tells the UE that the relay key request succeeded and carries the relay-related response information needed for the next relay-security step.
No. It belongs to a specialized relay security procedure rather than the standard registration path.
The next step is relay-specific procedure continuation, potentially including later relay authentication handling.
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.