Initial UL RRC Message Transfer is the F1AP message the gNB-DU sends to the gNB-CU to forward the first uplink RRC message received from a UE, including early cell and radio identifiers needed for CU-side access handling.
Message Fact Sheet
Protocol
f1ap
Network
5g
Spec
3GPP TS 38.473
Spec Section
Sections 8.4.1 and 9.2.3.1
Direction
gNB-DU -> gNB-CU initiatingMessage
Message Type
Initial RRC message transfer from DU to CU
Full message name
Initial UL RRC Message Transfer
Protocol
F1AP
Technology
5G
Direction
gNB-DU -> gNB-CU initiatingMessage
Interface
F1-C
Signaling bearer / channel
Non-UE-associated F1AP signaling that initiates the UE-associated logical F1 connection / SCTP carried F1AP initiatingMessage
Typical trigger
The gNB-DU receives an initial uplink RRC message from a UE on SRB0 over the radio interface and needs to forward that transparent RRC payload to the gNB-CU.
Main purpose
Forwards initial UE-originated RRC signaling, allows CU-centralized RRC processing, transports transparent UL-CCCH or UL-CCCH1 payloads from DU to CU, supports initial access, resume, re-establishment, RedCap, SDT, and relay-aware access workflows, and links radio access at the DU with CU-side control-plane decisions.
What is Initial UL RRC Message Transfer in simple terms?
Initial UL RRC Message Transfer is the F1AP message the gNB-DU sends to the gNB-CU to forward the first uplink RRC message received from a UE, including early cell and radio identifiers needed for CU-side access handling.
Forwards initial UE-originated RRC signaling, allows CU-centralized RRC processing, transports transparent UL-CCCH or UL-CCCH1 payloads from DU to CU, supports initial access, resume, re-establishment, RedCap, SDT, and relay-aware access workflows, and links radio access at the DU with CU-side control-plane decisions.
Why this message matters
Initial UL RRC Message Transfer is the DU's way to hand the first UE RRC message to the CU. Validate DU UE ID, NR CGI, C-RNTI, Transaction ID, and the RRC Container, then follow the CU's next procedure.
Where this message appears in the call flow
Initial UE access transfer
Access branch: the DU receives the first uplink RRC payload and forwards it to the CU over F1-C.
Call flow position: The DU has received the first uplink RRC payload and sends Initial UL RRC Message Transfer to the CU before normal UE-associated F1 signaling is fully established.
Typical state: The UE-associated logical F1 connection is initiated as part of this procedure.
Preconditions:
The F1 interface is operational.
The DU has allocated a gNB-DU UE F1AP ID.
The DU knows the serving NR CGI and C-RNTI.
Next likely message: DL RRC Message Transfer or UE Context Setup Request
Identity and payload validation
Decode branch: validate DU UE ID, NR CGI, C-RNTI, Transaction ID, and then decode the transparent RRC payload.
Call flow position: The CU uses gNB-DU UE F1AP ID, NR CGI, C-RNTI, Transaction ID, and the RRC Container to decide how to continue access handling.
Typical state: The initial RRC payload is still transparent to F1AP; RRC decoding happens at the CU/RRC layer.
Preconditions:
RRC Container is present and contains an UL-CCCH or UL-CCCH1 message.
Transaction ID is present for procedure correlation.
Next likely message: CU-side RRC setup, resume, or re-establishment handling
Initial UL versus later UL and NGAP
Scope branch: separate early F1 RRC transport from later F1 UL RRC transfer and N2 NGAP signaling.
Call flow position: Initial UL RRC Message Transfer is the early F1 step. Later UL RRC Message Transfer is used after a UE-associated F1 context exists; NGAP Initial UE Message is generated on N2 toward the AMF.
Typical state: Trace analysis should separate F1 RRC transport from NGAP access signaling.
Preconditions:
The first uplink RRC message has just reached the DU.
Next likely message: DL RRC Message Transfer, UE Context Setup, or NGAP Initial UE handling
Call flow position
Previous message(s): UE sends initial uplink RRC signaling over NR radio, DU receives UL-CCCH or UL-CCCH1 payload
Next message(s):UE Context Setup Request, Downlink RRC response over F1-C, Initial UE handling toward the AMF, Later uplink RRC transfer after UE context exists
Message direction and transport
Sender and receiver: gNB-DU -> gNB-CU initiatingMessage
Interface: F1-C
Domain: Initial uplink RRC access and CU-side RRC processing
Signaling bearer: Non-UE-associated F1AP signaling that initiates the UE-associated logical F1 connection
Transport / encapsulation: F1AP over SCTP/IP between gNB-CU and gNB-DU
Security context: Initial UL RRC Message Transfer does not establish NAS security. It forwards an initial RRC payload and early radio identifiers so the CU can decide the next RRC, UE context, or NGAP action.
Message Structure Overview
Initial UL RRC Message Transfer is sent by the gNB-DU to the gNB-CU after the first uplink RRC message is received over the radio interface.
The procedure uses non-UE-associated F1AP signaling, and the UE-associated logical F1 connection is initiated as part of the procedure.
The mandatory core is Message Type, gNB-DU UE F1AP ID, NR CGI, C-RNTI, RRC-Container, and Transaction ID.
RRC-Container carries the transparent initial RRC UL-CCCH or UL-CCCH1 message. F1AP transports it; RRC semantics are decoded by the CU RRC layer.
DU to CU RRC Container is optional but important because TS 38.473 expects the DU to include it, or sidelink relay configuration, when the DU can serve the UE.
This message is different from UL RRC Message Transfer, which is used after a UE-associated logical F1 connection already exists.
This page follows the Release 18 message table in TS 38.473: Transaction ID is mandatory, and the procedure is non-UE-associated even though it creates the early UE-associated logical F1 connection.
Treat this as a teaching example based on the expected message structure, not as a captured network trace.
Start with gNB-DU UE F1AP ID, NR CGI, and C-RNTI to identify the early radio-side UE context.
Decode RRC-Container as the transparent RRC payload; do not expect F1AP itself to interpret the RRC message semantics.
Check Transaction ID because it is mandatory in Release 18.
If DU to CU RRC Container is absent, check whether sidelink relay configuration is present and whether the CU rejects the access.
Important Information Elements
IE
Presence
Description
Message Type
Mandatory
Identifies the F1AP PDU as INITIAL UL RRC MESSAGE TRANSFER.
gNB-DU UE F1AP ID
Mandatory
Mandatory DU-side UE identifier allocated by the gNB-DU for this early UE signaling association.
NR CGI
Mandatory
Mandatory NR Cell Global Identifier for the serving cell where the initial uplink RRC message was received.
C-RNTI
Mandatory
Mandatory UE radio identifier allocated at the gNB-DU for the serving cell.
RRC-Container
Mandatory
Mandatory transparent container carrying the initial uplink RRC UL-CCCH or UL-CCCH1 message.
Transaction ID
Mandatory
Mandatory correlation identifier for the Initial UL RRC Message Transfer procedure in Release 18.
DU to CU RRC Container
Optional
Optional container carrying DU-provided CellGroupConfig information, at least SRB1 configuration when the DU can serve the UE.
SUL Access Indication
Optional
Optional indication that the UE performed access on a supplementary uplink carrier.
RAN UE ID
Optional
Optional 8-octet RAN UE identifier that the CU may store when supported.
RRC-Container-RRCSetupComplete
Optional
Optional container carrying an UL-DCCH message including RRCSetupComplete in applicable early data or context retrieval cases.
NR RedCap UE Indication / NR eRedCap UE Indication
Optional
Optional indicators that the accessing UE is RedCap or eRedCap.
SDT Information
Optional
Optional small-data-transmission context information used by the CU when supported.
Sidelink Relay Configuration
Optional
Optional information for NR ProSe Layer-2 U2N remote UE access through a relay UE.
Detailed field explanation
Message Type
Identifies the F1AP PDU as INITIAL UL RRC MESSAGE TRANSFER.
Presence: Mandatory
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.
gNB-DU UE F1AP ID
Mandatory DU-side UE identifier allocated by the gNB-DU for this early UE signaling association.
Presence: Mandatory
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.
NR CGI
Mandatory NR Cell Global Identifier for the serving cell where the initial uplink RRC message was received.
Presence: Mandatory
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.
C-RNTI
Mandatory UE radio identifier allocated at the gNB-DU for the serving cell.
Presence: Mandatory
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.
RRC-Container
Mandatory transparent container carrying the initial uplink RRC UL-CCCH or UL-CCCH1 message.
Presence: Mandatory
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.
Transaction ID
Mandatory correlation identifier for the Initial UL RRC Message Transfer procedure in Release 18.
Presence: Mandatory
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.
DU to CU RRC Container
Optional container carrying DU-provided CellGroupConfig information, at least SRB1 configuration when the DU can serve the UE.
Presence: Optional
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.
SUL Access Indication
Optional indication that the UE performed access on a supplementary uplink carrier.
Presence: Optional
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.
RAN UE ID
Optional 8-octet RAN UE identifier that the CU may store when supported.
Presence: Optional
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.
RRC-Container-RRCSetupComplete
Optional container carrying an UL-DCCH message including RRCSetupComplete in applicable early data or context retrieval cases.
Presence: Optional
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.
NR RedCap UE Indication / NR eRedCap UE Indication
Optional indicators that the accessing UE is RedCap or eRedCap.
Presence: Optional
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.
SDT Information
Optional small-data-transmission context information used by the CU when supported.
Presence: Optional
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.
Sidelink Relay Configuration
Optional information for NR ProSe Layer-2 U2N remote UE access through a relay UE.
Presence: Optional
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.
What to check in logs and traces
Confirm message direction is gNB-DU to gNB-CU.
Verify gNB-DU UE F1AP ID is present and later procedures correlate to it.
Validate NR CGI and C-RNTI against the serving cell and radio trace.
Confirm RRC-Container is present and decodable as UL-CCCH or UL-CCCH1.
Check Transaction ID is present.
Decode DU to CU RRC Container, SUL Access Indication, RAN UE ID, RedCap/eRedCap, SDT, or relay fields when present.
Look for DL RRC Message Transfer, UE Context Setup Request, or NGAP Initial UE Message as the follow-up branch.
Common Issues and Troubleshooting
No follow-up UE Context Setup or DL RRC message appears.
Likely cause: The CU may reject the access because required DU-to-CU configuration is absent, the RRC payload cannot be decoded, or the serving cell identity is not accepted.
What to inspect: Check RRC-Container decode, DU to CU RRC Container, NR CGI, C-RNTI, Transaction ID, and CU admission logs.
Next step: Fix the radio/cell mapping or DU-to-CU configuration and confirm the CU generates the expected follow-up.
The RRC payload fails to decode.
Likely cause: The container may not contain the expected UL-CCCH or UL-CCCH1 message, or the trace tool may be applying the wrong RRC version or channel type.
What to inspect: Verify RRC-Container bytes, RRC release version, and whether the payload is RRCSetupRequest, RRCResumeRequest, or RRCReestablishmentRequest.
Next step: Decode the payload as RRC, not as F1AP, and align the decoder version with TS 38.331.
The UE is confused with another early access attempt.
Likely cause: C-RNTI reuse, wrong NR CGI mapping, or missing correlation between gNB-DU UE F1AP ID and later CU-side IDs.
What to inspect: Compare NR CGI, C-RNTI, gNB-DU UE F1AP ID, timing, and later UE Context Setup Request or DL RRC Message Transfer.
Next step: Anchor troubleshooting on the DU UE ID plus cell identity before following later CU and NGAP messages.
LTE / 5G / Variant Comparison
Compared with DL RRC Message Transfer
Initial UL RRC Message Transfer carries the first uplink RRC message from DU to CU. DL RRC Message Transfer carries CU-originated downlink RRC content toward the UE through the DU.
Compared with UL RRC Message Transfer
Initial UL is used before or during establishment of the early UE-associated logical F1 connection. UL RRC Message Transfer is used after that UE-associated connection already exists.
Compared with NGAP Initial UE Message
Initial UL RRC Message Transfer is F1-C DU-to-CU RRC transport. NGAP Initial UE Message is N2 signaling from the gNB/CU toward the AMF, often generated after the CU processes the initial RRC and NAS content.
FAQ
What is Initial UL RRC Message Transfer in F1AP?
It is the F1AP message the gNB-DU sends to the gNB-CU to transfer the first uplink RRC message received from a UE.
Who sends this message?
The gNB-DU sends Initial UL RRC Message Transfer to the gNB-CU over F1-C.
What RRC messages can it carry?
It commonly carries initial UL-CCCH or UL-CCCH1 messages such as RRCSetupRequest, RRCResumeRequest, or RRCReestablishmentRequest.
What is the purpose of the RRC Container?
RRC Container carries the transparent uplink RRC payload from the UE. F1AP transports it, while the CU RRC layer interprets it.
What is the difference from UL RRC Message Transfer?
Initial UL RRC Message Transfer is used for the first uplink RRC message before the normal UE-associated F1 context exists. UL RRC Message Transfer is used later after that context exists.
How is this different from NGAP Initial UE Message?
Initial UL RRC Message Transfer runs on F1-C between DU and CU. NGAP Initial UE Message runs on N2 between the gNB/CU and AMF.
What is C-RNTI used for?
C-RNTI identifies the UE radio context in the serving cell where the DU received the initial uplink RRC message.
How do you troubleshoot Initial UL RRC Message Transfer failures?
Check direction, gNB-DU UE F1AP ID, NR CGI, C-RNTI, Transaction ID, RRC Container decode, DU to CU RRC Container when present, and the expected CU follow-up procedure.
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.
