RRC 5G UE -> gNB 3GPP TS 38.331

5G NR - RRCSetupComplete

Uplink NR RRC message sent by the UE on SRB1 and DCCH to confirm successful RRC connection establishment and transfer the initial NAS message.

Message Fact Sheet

Protocol	rrc	Network	5g
Spec	3GPP TS 38.331	Spec Section	5.3.3.1, 5.3.3.3, 6.2.2
Direction	UE -> gNB	Message Type	Connection Control

Full message name	5G NR - RRCSetupComplete
Protocol	RRC
Technology	5G
Direction	UE -> gNB
Interface	Uu
Signaling bearer / channel	SRB1 / UL-DCCH
Typical trigger	The UE has successfully applied RRCSetup and is ready to confirm the setup while forwarding the first dedicated NAS message.
Main purpose	Confirms successful completion of RRC connection establishment, moves the procedure into core-facing signaling, and carries the dedicated NAS message toward the network.
Procedures where used	RRC Connection Establishment, Initial Registration, Mobility Registration Update, Periodic Registration Update, Service Request from Idle
Related timers	T300
Related cause values	None highlighted
Main specification	3GPP TS 38.331, 5.3.3.1, 5.3.3.3, 6.2.2

What this message does in simple terms

Uplink NR RRC message sent by the UE on SRB1 and DCCH to confirm successful RRC connection establishment and transfer the initial NAS message.

Confirms successful completion of RRC connection establishment, moves the procedure into core-facing signaling, and carries the dedicated NAS message toward the network.

Why this message matters

RRCSetupComplete tells the gNB that the UE finished the initial radio setup and is now sending the first real NAS message, such as Registration Request.

Where this message is used

5G RRC Connection Setup

Call flow position: UE response after applying the RRC Setup configuration.

Typical state: UE has entered connected-mode handling and can now use SRB1.

Preconditions:

RRCSetup has been received and successfully applied.
SRB1 is available.
The dedicated NAS payload is ready for transfer.

Next likely message: Initial UE Message on N2 and then AMF-driven response signaling

5G Initial Registration

Call flow position: Bridge message between radio setup and core registration signaling.

Typical state: UE is ready to deliver Registration Request into the network.

Preconditions:

Initial access and RRC setup completed successfully.

Next likely message: Initial UE Message

Full Procedure Context

Previous message(s): RRCSetup

Next message(s): Initial UE Message, Security Mode Command, Downlink NAS Transport

Message Direction and Transport

Sender and receiver: UE -> gNB

Interface: Uu

Domain: Access-side radio control carrying core-bound NAS payload

Signaling bearer: SRB1

Logical channel: UL-DCCH

Transport / encapsulation: RRC over DCCH on SRB1 after the initial setup has been applied

Security context: Sent after SRB1 is established. Depending on the exact stage, the message is still before later AS security activation but already uses the dedicated control bearer rather than SRB0.

Message Structure Overview

RRCSetupComplete still uses the RRC transaction wrapper, but the operationally important payload is the dedicated NAS message plus selected PLMN and optional AMF or slice context.
Unlike RRCSetupRequest, this message is sent on SRB1 and therefore marks the move to the dedicated connected-mode control bearer.
Engineers should inspect the dedicatedNAS-Message first, then selectedPLMN-Identity and any AMF / S-NSSAI context.

ASN.1 for 5G NR - RRCSetupComplete

RRCSetupComplete ::= SEQUENCE {
  rrc-TransactionIdentifier RRC-TransactionIdentifier,
  criticalExtensions CHOICE {
    rrcSetupComplete RRCSetupComplete-IEs,
    criticalExtensionsFuture SEQUENCE {}
  }
}

RRCSetupComplete-IEs ::= SEQUENCE {
  selectedPLMN-Identity    INTEGER,
  registeredAMF            RegisteredAMF OPTIONAL,
  guami-Type               GUAMI-Type OPTIONAL,
  s-NSSAI-List             S-NSSAI-List OPTIONAL,
  dedicatedNAS-Message     DedicatedNAS-Message,
  ng-5G-S-TMSI-Value       NG-5G-S-TMSI-Value OPTIONAL,
  lateNonCriticalExtension OCTET STRING OPTIONAL,
  nonCriticalExtension     SEQUENCE {} OPTIONAL
}

How to read this ASN.1

In practice, read this message as the UE confirming setup and handing the first real NAS payload into the radio-to-core pipeline. The dedicatedNAS-Message is usually the most important field.

Decoded Message Dump

UL-DCCH-Message
  message: rrcSetupComplete
    rrc-TransactionIdentifier: 1
    criticalExtensions:
      rrcSetupComplete:
        selectedPLMN-Identity: 1
        registeredAMF:
          plmn-Identity: 001-01
          amf-Identifier:
            regionID: 02
            setID: 341
            pointer: 1
        guami-Type: native
        s-NSSAI-List:
          - sst: 1
        dedicatedNAS-Message:
          Registration Request
            Extended Protocol Discriminator: 5GMM
            Security Header Type: Plain NAS
            Message Type: Registration Request
            5GS Registration Type: Initial Registration
            UE Identity: SUCI
        ng-5G-S-TMSI-Value:
          ng-5G-S-TMSI-Part2: 0x101

How to read this dump

selectedPLMN-Identity should match the PLMN selection broadcast and chosen by the UE.
The key payload is dedicatedNAS-Message because it tells the network what core procedure starts next.
If present, registeredAMF and slice information can influence how the later core handling proceeds.

Information Elements

IE	Required	Description
`rrc-TransactionIdentifier`	Yes	Transaction identifier matching the RRC setup transaction being completed.
`selectedPLMN-Identity`	Yes	Index of the PLMN or SNPN selected by the UE from the plmn-IdentityInfoList or npn-IdentityInfoList broadcast in SIB1.
`registeredAMF`	Optional	Transfers the GUAMI of the AMF where the UE is registered, as provided by upper layers.
`guami-Type`	Optional	Indicates whether the GUAMI is native or mapped.
`s-NSSAI-List`	Optional	Carries one or more S-NSSAI values provided by upper layers for slice-related access handling.
`dedicatedNAS-Message`	Yes	Mandatory NAS message container used to transfer the initial UE-specific NAS message transparently through RRC.
`ng-5G-S-TMSI-Value`	Optional	Optional NG-5G-S-TMSI value. In the normal RRCSetupRequest -> RRCSetup -> RRCSetupComplete path, the UE sets the Part2 form when upper layers provide a 5G-S-TMSI.
`lateNonCriticalExtension`	Optional	Late non-critical extension container used for release evolution and backward compatibility.
`nonCriticalExtension`	Optional	Regular extension branch used for later release additions such as idle measurement availability, mobility history, UL RRC segmentation, onboarding request, NCR indication, and mobile IAB indication.

Detailed field explanation

`rrc-TransactionIdentifier`

Transaction identifier matching the RRC setup transaction being completed.

Presence: Required

`selectedPLMN-Identity`

Index of the PLMN or SNPN selected by the UE from the plmn-IdentityInfoList or npn-IdentityInfoList broadcast in SIB1.

Presence: Required

`registeredAMF`

Transfers the GUAMI of the AMF where the UE is registered, as provided by upper layers.

Presence: Optional

`guami-Type`

Indicates whether the GUAMI is native or mapped.

Presence: Optional

`s-NSSAI-List`

Carries one or more S-NSSAI values provided by upper layers for slice-related access handling.

Presence: Optional

`dedicatedNAS-Message`

Mandatory NAS message container used to transfer the initial UE-specific NAS message transparently through RRC.

Presence: Required

`ng-5G-S-TMSI-Value`

Optional NG-5G-S-TMSI value. In the normal RRCSetupRequest -> RRCSetup -> RRCSetupComplete path, the UE sets the Part2 form when upper layers provide a 5G-S-TMSI.

Presence: Optional

`lateNonCriticalExtension`

Late non-critical extension container used for release evolution and backward compatibility.

Presence: Optional

`nonCriticalExtension`

Regular extension branch used for later release additions such as idle measurement availability, mobility history, UL RRC segmentation, onboarding request, NCR indication, and mobile IAB indication.

Presence: Optional

What to check in logs and traces

Confirm the message follows a valid RRCSetup and uses SRB1 / UL-DCCH.
Decode the embedded dedicatedNAS-Message fully and correlate it with the expected procedure.
Check selectedPLMN-Identity against SIB1 broadcast information and UE selection.
Inspect any registeredAMF or NG-5G-S-TMSI-related context for consistency with prior UE state.
Correlate the message with the subsequent Initial UE Message on N2.

Common Issues and Troubleshooting

RRCSetupComplete is missing after RRCSetup.

Likely cause: The UE may have failed while applying RRC Setup or failed before assembling the dedicated NAS payload.

What to inspect: Check RRCSetup content, SRB1 bring-up, and whether the UE can build the NAS message.

Next step: Troubleshoot the transition from RRCSetup to SRB1-based uplink signaling.

RRCSetupComplete is present but the core procedure fails immediately.

Likely cause: The embedded NAS message or identity context may be wrong even though the radio procedure succeeded.

What to inspect: Decode dedicatedNAS-Message, selected PLMN, and AMF-related fields, then compare with Initial UE Message.

Next step: Shift troubleshooting from pure RRC to the NAS / NGAP handoff path.

Unexpected PLMN or AMF context is used.

Likely cause: selectedPLMN-Identity or registeredAMF-related fields may not match the scenario.

What to inspect: Check SIB1 selection context, GUAMI usage, and any temporary identity values.

Next step: Validate PLMN selection and UE context assumptions.

Detailed explanation

5G RRCSetupComplete Message Explained

The RRCSetupComplete message is the uplink NR RRC message that the UE sends after successfully receiving and applying RRCSetup. This message is one of the most important checkpoints in the entire RRC connection establishment procedure because it does two things at once:

confirms that the UE successfully completed the radio-side setup, and
carries the first dedicated NAS message from the UE toward the network.

In a real 5G call trace, RRCSetupComplete is often the message that bridges the radio access procedure and the core-network procedure. It is the point where radio setup becomes registration signaling, service request signaling, or another UE-triggered NAS procedure.

Why RRCSetupComplete matters

This message is much more than a simple acknowledgment.

It matters because it:

confirms successful completion of RRC connection establishment
is the first uplink RRC message sent on SRB1
carries the UE’s initial NAS dedicated information/message
tells the network which PLMN or SNPN the UE selected
can optionally transfer the registered AMF identity, slice information, and NG-5G-S-TMSI value
leads directly into NGAP and NAS processing toward the AMF

If RRCSetupComplete is missing or malformed, the network may have radio connectivity but still cannot continue the UE’s core signaling procedure.

Where RRCSetupComplete appears in the call flow

A successful NR connection establishment flow is:

RRCSetupRequest from UE to gNB
RRCSetup from gNB to UE
RRCSetupComplete from UE to gNB

This is the successful branch shown in the RRC connection establishment procedure.

From a system perspective, that sequence means:

the UE requested the connection
the gNB admitted the UE and configured SRB1
the UE confirmed setup and transferred the first NAS message

After that, the gNB typically packages the NAS message into an Initial UE Message on NGAP and forwards it toward the AMF.

Transport characteristics

RRCSetupComplete is carried differently from RRCSetupRequest.

Direction: UE to network
Signaling radio bearer: SRB1
RLC mode: AM
Logical channel: DCCH
Message class: UL-DCCH

This is a critical detail in trace analysis. If you still see only SRB0 / CCCH behavior, you are not yet at the RRCSetupComplete stage.

What RRCSetupComplete means operationally

When the UE sends this message, it is telling the network:

the RRCSetup message was received and successfully applied
the UE has moved into RRC_CONNECTED
SRB1 is active and usable
the UE is now ready to deliver the initial NAS message

So RRCSetupComplete is effectively the handover point from pure radio setup to access-plus-core signaling.

ASN.1 structure of RRCSetupComplete

A simplified ASN.1-style view is:

RRCSetupComplete ::= SEQUENCE {
  rrc-TransactionIdentifier RRC-TransactionIdentifier,
  criticalExtensions CHOICE {
    rrcSetupComplete RRCSetupComplete-IEs,
    criticalExtensionsFuture SEQUENCE {}
  }
}

RRCSetupComplete-IEs ::= SEQUENCE {
  selectedPLMN-Identity INTEGER (1..maxPLMN),
  registeredAMF RegisteredAMF OPTIONAL,
  guami-Type ENUMERATED {native, mapped} OPTIONAL,
  s-NSSAI-List SEQUENCE (SIZE (1..maxNrofS-NSSAI)) OF S-NSSAI OPTIONAL,
  dedicatedNAS-Message DedicatedNAS-Message,
  ng-5G-S-TMSI-Value CHOICE {
    ng-5G-S-TMSI NG-5G-S-TMSI,
    ng-5G-S-TMSI-Part2 BIT STRING (SIZE (9))
  } OPTIONAL,
  lateNonCriticalExtension OPTIONAL,
  nonCriticalExtension OPTIONAL
}

Compared with RRCSetupRequest, this is a much richer message because the UE now has an established signaling bearer and can provide more access and core-related context.

Important information elements in RRCSetupComplete

1. rrc-TransactionIdentifier

This field ties the UE response to the transaction initiated by RRCSetup.

Why it matters

It allows the receiving side to correlate the completion message with the correct RRC procedure instance.

Troubleshooting value

If the transaction identifier does not line up with the corresponding RRCSetup, decoders and protocol stacks may treat the procedure as invalid or unmatched.

2. selectedPLMN-Identity

This is a mandatory field and one of the most important IEs in the entire message.

It identifies the index of the PLMN or SNPN selected by the UE from the broadcast information in SIB1.

Why it matters

The network needs to know exactly which broadcast identity context the UE selected when it accessed the cell.

How the UE sets it

The UE sets the value as follows:

if upper layers selected an SNPN or a PLMN and, in the PLMN case, the UE is allowed or instructed to access that PLMN via a cell broadcasting at least one CAG ID, then the UE sets selectedPLMN-Identity from npn-IdentityInfoList
otherwise, the UE sets selectedPLMN-Identity to the PLMN selected by upper layers from plmn-IdentityInfoList

Troubleshooting value

If the selected PLMN index does not match the SIB1 broadcast lists, the network can interpret the access under the wrong PLMN or NPN context.

3. registeredAMF

This optional field transfers the GUAMI of the AMF where the UE is registered, when upper layers provide it.

The RegisteredAMF structure contains:

plmn-Identity optional
amf-Identifier

Why it matters

This helps the access network and core procedures understand the UE’s prior registered AMF context.

UE setting logic

If upper layers provide a Registered AMF, the UE includes it. If the PLMN identity of that Registered AMF is different from the currently selected PLMN, the UE includes the AMF PLMN identity explicitly.

Troubleshooting value

This field is highly useful in mobility, AMF selection, AMF relocation, and access debugging, especially when the UE is not performing a brand-new registration from scratch.

4. guami-Type

This optional IE indicates whether the GUAMI is native or mapped.

Why it matters

This gives context for how the AMF identity should be interpreted.

Troubleshooting value

It can help explain differences between identity handling in interworking or mapped-identity scenarios.

5. s-NSSAI-List

This optional field carries one or more S-NSSAI values provided by upper layers.

Why it matters

It gives the network slice-related information that may be relevant at the time of access and initial NAS transfer.

Troubleshooting value

For slicing-related access issues, this field can explain why the network selected a particular behavior, policy, or routing path.

6. dedicatedNAS-Message

This is the most operationally important IE in RRCSetupComplete. It is mandatory.

The DedicatedNAS-Message IE is defined as an OCTET STRING, and the RRC layer is transparent for this information.

Why it matters

This field is the actual NAS message the UE wants to send into the core network.

Typical examples include:

Registration Request
Service Request
other UE-specific NAS messages depending on the procedure

Troubleshooting value

If a registration flow stalls right after RRC connection establishment, this is one of the first places to inspect. The radio procedure may be perfectly fine, while the embedded NAS message may be malformed, unexpected, or rejected later by the core.

7. ng-5G-S-TMSI-Value

This optional IE carries the NG-5G-S-TMSI value.

It has two forms:

ng-5G-S-TMSI
ng-5G-S-TMSI-Part2

Important standards behavior

If upper layers provide a 5G-S-TMSI and the RRCSetup was received in response to an RRCSetupRequest, the UE sets this field to ng-5G-S-TMSI-Part2.

Otherwise, the UE sets it to the full ng-5G-S-TMSI form.

Why it matters

This field is part of the identity chain that helps the network associate the newly established RRC connection with an existing UE context.

Practical interpretation

A common engineering pattern is:

Part1 of the 5G-S-TMSI appears earlier in RRCSetupRequest
Part2 can appear here in RRCSetupComplete

That split helps the overall access procedure carry UE identity information efficiently across the early connection-establishment phase.

8. lateNonCriticalExtension and nonCriticalExtension

These extension containers are important for release evolution.

Later releases add fields such as:

iab-NodeIndication-r16
idleMeasAvailable-r16
ue-MeasurementsAvailable-r16
mobilityHistoryAvail-r16
mobilityState-r16
ul-RRC-Segmentation-r16
onboardingRequest-r17
ncr-NodeIndication-r18
mobileIAB-NodeIndication-r18
reselectionMeasAvailable-r18
other release-specific indicators

Why they matter

In many commercial deployments, these fields are absent. But for advanced features, relay scenarios, mobility analytics, RedCap-like evolution paths, IAB, and onboarding-related implementations, they can become highly relevant.

Troubleshooting value

If your decoder ignores extension branches, you may miss fields that explain real network behavior.

How the UE builds RRCSetupComplete

After receiving and applying RRCSetup, the UE enters connected mode and then constructs RRCSetupComplete.

The standards-based behavior includes:

setting selectedPLMN-Identity
optionally including registeredAMF
optionally including guami-Type
optionally including s-NSSAI-List
setting the mandatory dedicatedNAS-Message
optionally including ng-5G-S-TMSI-Value
including later-release extension flags when applicable

That means RRCSetupComplete is the message where several upper-layer access decisions become visible to the radio/control-plane trace.

RRCSetupComplete vs RRCSetupRequest

RRCSetupRequest starts the connection establishment attempt.
RRCSetupComplete confirms success and carries the first NAS message.

RRCSetupComplete vs RRCSetup

RRCSetup is the network’s acceptance and SRB1 configuration.
RRCSetupComplete is the UE’s confirmation that setup succeeded.

RRCSetupComplete vs Initial UE Message

RRCSetupComplete is an RRC message on the radio side.
Initial UE Message is an NGAP message on the N2 interface.

In practice, the dedicatedNAS-Message inside RRCSetupComplete is later forwarded by the gNB toward the AMF using Initial UE Message.

What to verify in a live trace

When analyzing RRCSetupComplete, check the following.

1. Was RRCSetup successfully received first?

The message should come only after a valid RRCSetup. If not, the procedure sequence is broken.

2. Is the message on SRB1 / DCCH?

If the bearer and channel mapping do not match, your trace classification or protocol processing may be wrong.

3. Does selectedPLMN-Identity match SIB1?

Verify that the selected PLMN or SNPN index lines up with the broadcast information in SIB1.

4. Is the dedicatedNAS-Message correct for the scenario?

Examples:

Registration Request for initial registration
Service Request for UE-triggered service restoration

A mismatch here can explain why the radio side looks correct but the core-side procedure fails.

5. Is ng-5G-S-TMSI-Value present when expected?

Check whether the UE had a 5G-S-TMSI from upper layers and whether the field appears in the correct form.

6. Are registeredAMF and guami-Type consistent?

If present, they should align with the UE’s prior registration context and the selected access identity.

7. Are extension fields present?

For advanced deployments, extension flags can explain unexpected behavior related to mobility history, measurement availability, onboarding, NCR, or mobile IAB.

Common troubleshooting scenarios

RRCSetupComplete missing after RRCSetup

This usually means the UE failed to apply the received RRCSetup, failed to build SRB1/DCCH signaling, or encountered another problem before it could complete the procedure.

RRC connection succeeds but registration does not

This often means the radio side is healthy, but the dedicatedNAS-Message is rejected or mishandled later in NAS or NGAP.

Wrong PLMN or NPN context

If the network interprets the access under the wrong PLMN, one of the first fields to inspect is selectedPLMN-Identity.

If the UE appears to be associated with the wrong AMF context, inspect registeredAMF, guami-Type, and the later NGAP forwarding behavior.

Summary

If you are searching for 5G RRCSetupComplete, NR RRC Setup Complete decode, RRCSetupComplete dedicated NAS message, or 3GPP TS 38.331 RRCSetupComplete, the key point is this:

RRCSetupComplete is the uplink NR RRC message sent on SRB1 and DCCH to confirm successful RRC connection establishment and transfer the initial UE-specific NAS message toward the network.

FAQ

What is RRCSetupComplete in 5G NR?

It is the uplink RRC message that confirms successful RRC connection establishment and carries the UE's initial NAS message toward the network.

What NAS message is usually inside RRCSetupComplete?

Common examples are Registration Request and Service Request, depending on why the UE initiated the connection.

Does RRCSetupComplete use SRB0 or SRB1?

RRCSetupComplete is sent on SRB1 using DCCH and RLC AM, unlike RRCSetupRequest which is sent on SRB0 and CCCH.

What comes after RRCSetupComplete?

The network typically forwards the NAS message toward the AMF and continues with procedures such as Initial UE Message, Downlink NAS Transport, and Security Mode Command.

Summary

Uplink NR RRC message sent by the UE on SRB1 and DCCH to confirm successful RRC connection establishment and transfer the initial NAS message.

Advanced Engineer Notes

This message is the bridge between radio access control and core-network signaling, so cross-layer correlation is essential.
If you can decode RRCSetupComplete but not the subsequent Initial UE Message correctly, the issue may lie in the RAN-to-core transport rather than UE radio setup.
selectedPLMN-Identity and dedicatedNAS-Message are often more important for troubleshooting than the outer transaction wrapper.

LTE / 5G / Variant Comparison

Compared with RRCSetupRequest

RRCSetupRequest asks for access on SRB0 and contains no NAS payload. RRCSetupComplete confirms setup on SRB1 and carries the dedicated NAS message that launches the core procedure.

Related Messages

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.

5G NR - RRCSetupComplete

Message Fact Sheet

What this message does in simple terms

Why this message matters

Where this message is used

5G RRC Connection Setup

5G Initial Registration

Full Procedure Context

Message Direction and Transport

Message Structure Overview

ASN.1 for 5G NR - RRCSetupComplete

How to read this ASN.1

Decoded Message Dump

How to read this dump

Information Elements

Detailed field explanation

rrc-TransactionIdentifier

selectedPLMN-Identity

registeredAMF

guami-Type

s-NSSAI-List

dedicatedNAS-Message

ng-5G-S-TMSI-Value

lateNonCriticalExtension

nonCriticalExtension

What to check in logs and traces

Common Issues and Troubleshooting

RRCSetupComplete is missing after RRCSetup.

RRCSetupComplete is present but the core procedure fails immediately.

Unexpected PLMN or AMF context is used.

Detailed explanation

5G RRCSetupComplete Message Explained

Why RRCSetupComplete matters

Where RRCSetupComplete appears in the call flow

Transport characteristics

What RRCSetupComplete means operationally

ASN.1 structure of RRCSetupComplete

Important information elements in RRCSetupComplete

1. rrc-TransactionIdentifier

Why it matters

Troubleshooting value

2. selectedPLMN-Identity

Why it matters

How the UE sets it

Troubleshooting value

3. registeredAMF

Why it matters

UE setting logic

Troubleshooting value

4. guami-Type

Why it matters

Troubleshooting value

5. s-NSSAI-List

Why it matters

Troubleshooting value

6. dedicatedNAS-Message

Why it matters

Troubleshooting value

7. ng-5G-S-TMSI-Value

Important standards behavior

Why it matters

Practical interpretation

8. lateNonCriticalExtension and nonCriticalExtension

Why they matter

Troubleshooting value

How the UE builds RRCSetupComplete

RRCSetupComplete vs related messages

RRCSetupComplete vs RRCSetupRequest

RRCSetupComplete vs RRCSetup

RRCSetupComplete vs Initial UE Message

What to verify in a live trace

1. Was RRCSetup successfully received first?

2. Is the message on SRB1 / DCCH?

3. Does selectedPLMN-Identity match SIB1?

4. Is the dedicatedNAS-Message correct for the scenario?

5. Is ng-5G-S-TMSI-Value present when expected?

6. Are registeredAMF and guami-Type consistent?

7. Are extension fields present?

Common troubleshooting scenarios

RRCSetupComplete missing after RRCSetup

`rrc-TransactionIdentifier`

`selectedPLMN-Identity`

`registeredAMF`

`guami-Type`

`s-NSSAI-List`

`dedicatedNAS-Message`

`ng-5G-S-TMSI-Value`

`lateNonCriticalExtension`

`nonCriticalExtension`