F1 Setup Request is the first F1AP procedure a gNB-DU sends after the F1-C transport association becomes operational so the gNB-CU can learn DU identity, served-cell configuration, DU-owned system information, and transport details before the F1 interface starts carrying normal traffic.
Message Fact Sheet
Protocol
f1ap
Network
5g
Spec
3GPP TS 38.473
Spec Section
Section 8.2.3 and sections 9.2.1.4 to 9.2.1.6 (Release 18 baseline)
Non-UE-associated F1AP signaling / SCTP carried F1AP initiatingMessage followed by successfulOutcome or unsuccessfulOutcome
Typical trigger
A new F1-C interface instance becomes transport-operational and the gNB-DU must advertise its identity, cell inventory, and DU-owned system information to the gNB-CU before any other F1AP procedure can run.
Main purpose
Bootstraps an F1-C interface instance by transferring the gNB-DU identity, served-cell inventory, RRC version, and related configuration so the gNB-CU and gNB-DU can interoperate correctly on the F1 interface.
Main specification
3GPP TS 38.473, Section 8.2.3 and sections 9.2.1.4 to 9.2.1.6 (Release 18 baseline)
Release added
Release 15
Procedures where used
Initial F1 interface bring-up, DU to CU onboarding, Served-cell advertisement, CU-DU configuration resynchronization, IAB-related CU-DU bootstrap
What is F1 Setup Request in simple terms?
F1 Setup Request is the first F1AP procedure a gNB-DU sends after the F1-C transport association becomes operational so the gNB-CU can learn DU identity, served-cell configuration, DU-owned system information, and transport details before the F1 interface starts carrying normal traffic.
Bootstraps an F1-C interface instance by transferring the gNB-DU identity, served-cell inventory, RRC version, and related configuration so the gNB-CU and gNB-DU can interoperate correctly on the F1 interface.
Why this message matters
F1 Setup Request is the DU-to-CU onboarding message that makes a new F1 interface usable by telling the CU who the DU is, which cells it serves, and what basic configuration it exposes.
Where this message appears in the call flow
Initial DU onboarding to the CU
Base branch: the DU advertises its identity and served cells, the CU returns F1 Setup Response, and the F1 interface becomes operational.
Call flow position: The gNB-DU has transport connectivity to the gNB-CU and now advertises its identity, served cells, and DU-owned system information so the F1 interface can become operational.
Typical state: This is the first F1AP procedure for the F1-C interface instance after the TNL association becomes operational.
Preconditions:
The F1-C transport association is operational.
The gNB-DU knows which cell configuration and DU-owned system information it wants to expose.
The gNB-CU is ready to decide whether to accept or reject the interface setup.
Next likely message: F1 Setup Response
Shared transport association serving multiple F1-C interface instances
Activation branch: after accepting setup, the CU can request which DU cells should be activated and can provide updated NR PCI values.
Call flow position: The same TNL association is reused for several F1-C interface instances, and one F1 Setup Request is issued per interface instance after transport is up.
Typical state: Transport is already established, but each logical F1-C interface still needs its own application-level setup exchange.
Preconditions:
The TNL association is shared by more than one F1-C interface instance.
This specific logical interface instance has not yet completed F1 Setup.
Next likely message: F1 Setup Response or F1 Setup Failure for that interface instance
Setup rejected by the gNB-CU
Rejection branch: the CU cannot accept setup, returns failure with backoff guidance, and the DU retries later.
Call flow position: The gNB-CU cannot accept the interface setup and returns F1 Setup Failure instead of making the F1 interface operational.
Typical state: The gNB-DU must back off and retry later if Time To Wait is present.
Preconditions:
The gNB-CU found the request unacceptable or unsupported.
A Cause can be generated for the failure outcome.
Next likely message: Later F1 Setup Request retry after the Time To Wait window if one was returned
Call flow position
Previous message(s): Operational SCTP or TNL association establishment, gNB-DU startup or restart, F1 interface recovery
Logical channel: SCTP carried F1AP initiatingMessage followed by successfulOutcome or unsuccessfulOutcome
Transport / encapsulation: F1AP over SCTP/IP between gNB-DU and gNB-CU
Security context: F1 Setup Request does not create a UE security context. It is a node-level bootstrap procedure. The procedure replaces previously stored application-level configuration and re-initializes F1AP UE-related contexts the same way a reset would.
Message Structure Overview
F1 Setup Request is the first F1AP procedure on a new F1-C interface instance once the transport association is operational.
The procedure uses non-UE-associated signaling, but it has UE-context impact because successful or repeated setup replaces stored application-level configuration and re-initializes F1AP UE-related contexts.
The request is gNB-DU centric: identity, served cells, DU-owned system information, RRC version, and optional transport or IAB details flow from DU to CU.
The response can return gNB-CU naming, gNB-CU system information, Cells to be Activated, available PLMN or SNPN restrictions, and optional transport or IAB data.
If the gNB-CU rejects setup, F1 Setup Failure carries mandatory Cause and optional Time To Wait for controlled retry.
The request combines node identity with a potentially large served-cell inventory. In practice the heavy IE is Served Cell Information because that is where PLMN, slice, NR mode, timing, and feature exposure sit. The response side decides whether the interface becomes operational immediately or fails with backoff guidance.
On the request side, the main payload is usually the served-cells list rather than the DU name or DU ID.
When a trace includes Cells to be Activated List in the response, the interface is already accepted and the CU is now steering DU-side activation state.
If setup fails, carry the same Transaction ID forward when matching the failure to the request before reading Cause or Time To Wait.
Important Information Elements
IE
Required
Description
Transaction ID
Yes
Mandatory transaction correlate used by the gNB-CU to match the request with the corresponding response or failure.
gNB-DU ID
Yes
Mandatory DU identifier that uniquely identifies the gNB-DU at least within a gNB-CU and is independent of cell identifiers.
gNB-DU Name
Optional
Optional printable DU name. If Extended gNB-DU Name is also present, the CU may ignore this IE for human-readable naming.
gNB-DU Served Cells List
Optional
Optional list of cells configured in the gNB-DU. Each item carries Served Cell Information and optionally DU-owned system information for that cell.
Served Cell Information
Yes
Per-cell configuration block including NR CGI, PCI, PLMN and slice advertisement, mode-specific frequency and bandwidth information, measurement timing configuration, and optional extras such as cell direction, TDD intent, PRACH, RedCap, XR, or TAC-related data.
gNB-DU System Information
Optional
Optional DU-owned RRC container associated with a served cell. For NG-RAN use, this IE and the TAI Slice Support List are part of the DU’s service advertisement during setup.
gNB-DU RRC version
Yes
Mandatory DU RRC version information. The latest enhanced RRC version is required in both setup request and response.
Transport Layer Address Info
Optional
Optional transport-layer address information that the gNB-CU may use, if supported, for IPSec tunnel establishment considerations.
BAP Address
Optional
Optional IAB-related BAP address. It can help the gNB-CU discover IAB node co-location or return a BAP address in the response when donor-DU behavior applies.
Extended gNB-DU Name
Optional
Extended human-readable DU name using visible or UTF-8 strings. If present, the gNB-CU may use it and ignore gNB-DU Name for human-readable labeling.
RRC Terminating IAB-Donor gNB-ID
Optional
Optional global gNB ID used for mobile IAB cases where the RRC-terminating donor differs from the receiving gNB-CU.
Mobile IAB-MT User Location Information
Optional
Optional mobile IAB location information that the receiving gNB-CU may use when reporting UE location information to the AMF for UEs served by the mobile IAB node.
Detailed field explanation
Transaction ID
Mandatory transaction correlate used by the gNB-CU to match the request with the corresponding response or failure.
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.
gNB-DU ID
Mandatory DU identifier that uniquely identifies the gNB-DU at least within a gNB-CU and is independent of cell identifiers.
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.
gNB-DU Name
Optional printable DU name. If Extended gNB-DU Name is also present, the CU may ignore this IE for human-readable naming.
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.
gNB-DU Served Cells List
Optional list of cells configured in the gNB-DU. Each item carries Served Cell Information and optionally DU-owned system information for that cell.
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.
Served Cell Information
Per-cell configuration block including NR CGI, PCI, PLMN and slice advertisement, mode-specific frequency and bandwidth information, measurement timing configuration, and optional extras such as cell direction, TDD intent, PRACH, RedCap, XR, or TAC-related data.
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.
gNB-DU System Information
Optional DU-owned RRC container associated with a served cell. For NG-RAN use, this IE and the TAI Slice Support List are part of the DU’s service advertisement during setup.
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.
gNB-DU RRC version
Mandatory DU RRC version information. The latest enhanced RRC version is required in both setup request and response.
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.
Transport Layer Address Info
Optional transport-layer address information that the gNB-CU may use, if supported, for IPSec tunnel establishment considerations.
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.
BAP Address
Optional IAB-related BAP address. It can help the gNB-CU discover IAB node co-location or return a BAP address in the response when donor-DU behavior applies.
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.
Extended gNB-DU Name
Extended human-readable DU name using visible or UTF-8 strings. If present, the gNB-CU may use it and ignore gNB-DU Name for human-readable labeling.
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 Terminating IAB-Donor gNB-ID
Optional global gNB ID used for mobile IAB cases where the RRC-terminating donor differs from the receiving gNB-CU.
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.
Mobile IAB-MT User Location Information
Optional mobile IAB location information that the receiving gNB-CU may use when reporting UE location information to the AMF for UEs served by the mobile IAB node.
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 F1 Setup is the first F1AP procedure after the F1-C transport association became operational.
Match Transaction ID across request, response, or failure before comparing any detailed IEs.
Read the served-cells list as a DU inventory advertisement and verify each NR CGI, PCI, PLMN set, and slice-support block.
If Extended gNB-DU Name is present, prefer it over gNB-DU Name for human-readable correlation.
Check whether the response restricted available PLMNs or SNPN IDs compared with what the DU advertised, because that changes what the DU should broadcast afterward.
Common Issues and Troubleshooting
The F1 transport is up, but no UE-context procedures start afterward.
Likely cause: F1 Setup may have failed or never completed, so the F1 interface never became operational for normal traffic.
What to inspect: Look for F1 Setup Response or F1 Setup Failure with the same Transaction ID immediately after the request.
Next step: If failure is present, honor Time To Wait before retry. If nothing came back, debug the transport or CU-side acceptance logic before looking at later F1AP procedures.
Cells advertised by the DU do not become active the way the DU expected.
Likely cause: The gNB-CU may have returned a Cells to be Activated List that selectively activates cells or requests NR PCI changes during the successful outcome.
What to inspect: Compare the served-cells list in the request with the response-side Cells to be Activated List and any NR PCI values carried there.
Next step: Treat activation as a CU-controlled post-setup decision instead of assuming all advertised DU cells automatically enter service.
The interface comes back, but old UE-related assumptions break after setup.
Likely cause: F1 Setup re-initializes F1AP UE-related contexts and erases related signaling connections like a Reset procedure would do.
What to inspect: Correlate the setup event with any preceding recovery or restart event on the DU or CU.
Next step: Model the post-setup state as a fresh interface bootstrap rather than a continuation of earlier UE-level F1 state.
LTE / 5G / Variant Comparison
Compared with NG Setup Request
NG Setup Request boots the N2 interface between NG-RAN and AMF. F1 Setup Request boots the internal CU-DU control plane and carries radio-cell inventory rather than AMF selection data.
Served cell advertisement versus later DU Configuration Update
F1 Setup Request is the first full interface bootstrap and can wipe old F1 application state. Later gNB-DU Configuration Update messages adjust an already operational interface instead of creating it.
Success versus failure outcome
Success makes the F1 interface operational and may activate selected cells. Failure keeps the interface non-operational and can instruct the DU to wait before retrying toward the same CU.
FAQ
What is F1 Setup Request in 5G F1AP?
It is the first non-UE-associated F1AP message the gNB-DU sends to the gNB-CU after F1-C transport becomes operational so the two nodes can exchange the application-level data needed to use the F1 interface.
Does F1 Setup Request affect existing UE contexts?
Yes. The specification says the F1 Setup procedure erases existing application-level configuration data and re-initializes F1AP UE-related contexts like a Reset procedure would do.
What is carried in the request?
At minimum the request carries Transaction ID, gNB-DU ID, and gNB-DU RRC version. It can also carry DU naming, served-cell inventory, DU-owned system information, transport-layer address information, and IAB-related identifiers.
What does the response add?
F1 Setup Response can include gNB-CU naming, gNB-CU system information, Cells to be Activated List, available PLMN or SNPN restrictions, optional transport-layer information, and some IAB-specific data.
When does the DU retry after failure?
If F1 Setup Failure includes Time To Wait, the gNB-DU shall wait at least that long before reinitiating F1 Setup toward the same gNB-CU.
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.
