5G/NR - RAN Architecture

 

 

 

NR RAN - F1 Interface

A gNB does not have to run all its protocol layers in one place. But once we separate the CU and DU, they still have to serve the same UE. How does an RRC message reach the UE, and how does a user packet find the correct radio bearer? F1 provides the connection needed for both.

The useful starting point is the protocol split. The CU handles the higher layers, while the DU handles RLC, MAC and PHY. F1-C coordinates their operation, and F1-U carries user data between them. This note follows ordinary NR UE access and bearer operation, using the Release 19 specification versions listed in Reference. It does not cover every optional F1 feature.

Executive Summary

Use this table to connect an F1 trace to the function it represents.

Question

What to remember

Where is the split?

CU: RRC, SDAP and PDCP. DU: RLC, MAC and PHY. With a split CU, control and user plane functions reside in CU-CP and CU-UP.

F1-C

F1AP over SCTP/IP. Interface management, UE context management and RRC message transfer.

F1-U

GTP-U over UDP/IP. User data and NR user plane protocol information for bearer flow control.

First interface procedure

DU initiates F1 Setup after the transport association is operational.

First UE message

INITIAL UL RRC MESSAGE TRANSFER carries the initial RRC message and the DU's UE identifier.

Tunnel direction

CU-UP allocates the receiving endpoint for UL. DU allocates the receiving endpoint for DL.

Where does F1 sit in the gNB?

Before looking at F1AP messages, we need to know which functions are on each side. Otherwise, it is easy to confuse F1 with the core network interface or a radio fronthaul connection.

A gNB can contain a gNB-CU and one or more gNB-DUs. The CU hosts RRC, SDAP and PDCP, while the DU hosts RLC, MAC and PHY. F1 connects these two logical parts. The DU therefore handles MAC scheduling and the radio-facing lower layers. It does not ask the CU to make each individual MAC scheduling decision over F1.

The CU can be further separated into CU-CP and CU-UP. CU-CP hosts RRC and control plane PDCP. CU-UP hosts SDAP and user plane PDCP. In this arrangement, F1-C terminates at CU-CP, F1-U terminates at CU-UP, and E1 connects the two CU parts.

Figure 1 shows these logical endpoints. The two F1 connections reach the same DU, but they serve different protocol functions. The drawing shows one CU-UP and one DU for clarity.

CU-CP and CU-UP connect through F1-C and F1-U to a DU gNB-CU-CPRRC / control plane PDCP gNB-CU-UPSDAP / user plane PDCP gNB-DURLCMACPHY E1 F1-C: F1AP / SCTP F1-U: GTP-U / UDP

Figure 1. F1 separates the CU's higher layer functions from the DU's radio lower layers.

  • F1-C connects CU-CP and DU when the CU is split.
  • F1-U connects CU-UP and DU; E1 coordinates the CU parts.

These are logical boundaries. Separate boxes in Figure 1 do not require separate buildings or physical servers. Likewise, a point-to-point F1 relationship does not require a direct cable between the CU and DU. The transport network can contain intermediate equipment.

NG connects the gNB to the 5G Core, and Xn connects NG-RAN nodes. F1 stays inside the split gNB architecture. A separate DU-to-radio-unit connection is also outside the F1 boundary shown here. Keeping these endpoints clear is more useful than identifying an interface only from its cable or IP network.

What travels over F1-C and F1-U?

Once the functions are separated, two different exchanges are needed. The CU and DU must agree on resources and UE contexts, and they must move user data through those resources.

F1-C carries F1AP messages over SCTP/IP. F1AP manages the interface, establishes and changes UE contexts, and transfers RRC messages between CU and DU. SCTP supplies reliable transport for those signalling messages. An SCTP acknowledgement confirms transport reception; it does not confirm that the requested F1AP operation succeeded.

Layer or function

F1-C

F1-U

Information

F1AP procedures and RRC containers

User plane PDCP PDUs and NR user plane protocol information

Transport stack

F1AP / SCTP / IP

GTP-U / UDP / IP

Context to inspect

Procedure, CU/DU UE F1AP IDs and relevant IEs

Receiving IP address, TEID, direction and DRB mapping

F1-U carries user plane traffic between the PDCP side and the RLC side. The CU's SDAP function maps QoS flows to DRBs. So an F1-U bearer is understood at DRB level; it is not simply one tunnel for an entire PDU session. Features such as duplication can involve multiple tunnels for a DRB.

There is also feedback on F1-U. The NR user plane protocol defined in TS 38.425 carries information in the NR RAN Container GTP-U extension header. For example, DL DATA DELIVERY STATUS helps the CU understand delivery progress and the DU's buffering needs. This is separate from an F1AP UE context response.

Also distinguish an NR-U sequence number from a PDCP sequence number. They serve different protocol functions and cannot be substituted when correlating packets. A packet arriving at the DU is not, by itself, evidence that the UE received its contents.

  • F1-C configures and coordinates the CU/DU operation.
  • F1-U carries data and bearer feedback; successful F1-C signalling alone does not prove this path works.

How does F1 become operational?

A reachable DU IP address is only the beginning. The CU still needs the DU's application configuration, and the DU needs the CU's response before the new F1 interface can be used.

The DU first establishes the SCTP association toward the CU. For a new F1 interface instance, the DU then sends F1 SETUP REQUEST. The CU answers with F1 SETUP RESPONSE when setup succeeds, or F1 SETUP FAILURE when it fails. This is a non-UE-associated procedure: it establishes the interface relationship, not an individual subscriber's resources.

The request identifies the DU and provides relevant configuration, including served-cell information when present. The response identifies the CU and can include cells to activate. Pay attention to that distinction. Receiving a successful response does not mean that every advertised cell has necessarily been activated.

F1 Setup exchanges the initial application-level configuration. Later changes use procedures such as gNB-DU Configuration Update and gNB-CU Configuration Update. Repeating F1 Setup as a periodic health check would be wrong. A new setup can reinitialise application state and affect existing UE-related contexts.

The transport model also deserves care. A CU/DU pair must support a single SCTP association, but the specifications support additional transport associations. Establishing another association for an existing F1 interface does not generally require another F1 Setup. Therefore, counting SCTP associations is not a reliable way to count logical F1 interfaces.

When checking startup, follow the state in order: transport connection, F1 Setup result, then the applicable cell configuration and activation. A failure at one stage changes what the next stage can do. None of these steps establishes a DRB for a UE.

  • SCTP establishment makes signalling transport available.
  • F1 Setup establishes the initial CU/DU application relationship.

How does the first RRC message cross F1?

RRC terminates at the CU, but the UE's radio transmission reaches the DU first. The DU therefore needs a way to forward the first RRC message before the CU has assigned its UE identifier.

Before this UE exchange, the DU establishes an SCTP association with the CU (CU-CP when the CU is split). Once the association is operational, the DU sends F1 SETUP REQUEST over F1-C. The CU returns F1 SETUP RESPONSE on successful setup. SCTP provides the signalling transport, while F1 Setup exchanges the application configuration needed for CU/DU operation.

These are interface-level prerequisites. They are performed for the new F1-C interface instance, not repeated for every UE that accesses an already operational interface. The UE's RRC exchange below assumes that setup has succeeded and the serving cell is available.

For ordinary initial access, the DU receives RRCSetupRequest and sends INITIAL UL RRC MESSAGE TRANSFER to the CU. This message carries the initial RRC message, the gNB-DU UE F1AP ID and information such as the C-RNTI. It can also provide the DU-to-CU RRC container with lower layer configuration when the DU can serve the UE.

The CU allocates its gNB-CU UE F1AP ID and generates RRCSetup. It sends the RRC content toward the DU using DL RRC MESSAGE TRANSFER. The DU transmits RRCSetup to the UE. When the UE returns RRCSetupComplete, the DU forwards it through UL RRC MESSAGE TRANSFER.

Figure 2 starts with SCTP establishment and F1 Setup, then shows the initial RRC exchange for one UE. The SCTP handshake is grouped into one step. Random access details, core network signalling, security activation and later bearer setup are omitted.

SCTP establishment and F1 Setup precede the initial UE RRC exchange UEgNB-DUgNB-CU / CU-CP Interface startup (not repeated for each UE) SCTP association establishment (DU initiates) F1 SETUP REQUEST F1 SETUP RESPONSE UE initial access (F1 operational; serving cell available) RRCSetupRequest (SRB0) INITIAL UL RRC MESSAGE TRANSFER DL RRC MESSAGE TRANSFER (RRCSetup) RRCSetup (SRB0) RRCSetupComplete (SRB1) UL RRC MESSAGE TRANSFER

Figure 2. SCTP and F1 Setup establish the interface before the DU forwards the UE's initial RRC signalling.

  • SCTP establishment and F1 Setup prepare the CU/DU interface; they are not per-UE procedures.
  • INITIAL UL RRC MESSAGE TRANSFER starts the F1AP UE relationship using the DU-assigned identifier.
  • DL/UL RRC MESSAGE TRANSFER carries subsequent RRC signalling for the UE.

There is an easily missed classification here. INITIAL UL RRC MESSAGE TRANSFER is non-UE-associated signalling in F1AP, even though its contents concern a UE. The procedure initiates the UE-associated logical connection. The later DL and UL RRC transfer procedures are UE-associated.

The RRC container also depends on the signalling bearer. SRB0 has no PDCP layer, while SRB1 signalling passes through control plane PDCP. So an F1 trace does not always expose a plain, directly decodable RRC message. Security state and the bearer being carried matter when interpreting that container.

Which UE and bearer does a message belong to?

A trace contains several identifiers for the same UE, but each belongs to a different protocol context. Before correlating messages, check who allocated an identifier and where that identifier is meaningful.

The DU assigns the gNB-DU UE F1AP ID. The CU assigns the gNB-CU UE F1AP ID. Once both sides have established the association, UE-associated F1AP messages use the identifiers required by that procedure to select the corresponding context. The two values do not have to be equal.

Identifier

What it identifies

Useful caution

gNB-CU UE F1AP ID

UE-associated F1 context at the CU

Keep the CU and interface context when correlating logs.

gNB-DU UE F1AP ID

UE-associated F1 context at the DU

Do not equate it with the CU's value.

C-RNTI

UE radio identity within its cell context

It is not a global subscriber identity.

SRB ID / DRB ID

A signalling or data radio bearer for the UE

The bearer number alone does not identify a UE.

GTP-U TEID

A tunnel endpoint at the receiving side

Keep the destination address and packet direction with it.

For example, suppose one context uses CU UE F1AP ID 123 and DU UE F1AP ID 45. Its DRB 1 is not identified on F1-U by either of those F1AP values. The control plane establishes a mapping from that DRB to the relevant GTP-U tunnel endpoints. User plane packets then carry the TEID for their receiving endpoint.

This also explains why a packet-only capture can be incomplete. An F1-U capture may show traffic without showing which F1AP procedure created its mapping. A capture starting after context setup needs earlier signalling or CU/DU context logs to recover that relationship.

Identifiers can change as contexts are released and created again. Record the time interval as well as the value, especially across restarts or mobility. Matching the same number in two distant log entries does not establish continuity of the UE context.

  • F1AP IDs select the UE signalling context. DRB IDs and TEIDs identify different parts of its bearer configuration.

How does a DRB get its F1-U tunnels?

RRC signalling can work while the user data path is still missing. A DRB needs DU resources and receiving tunnel endpoints, and the sending nodes must learn those endpoints before forwarding data.

With a split CU, CU-CP coordinates this work through E1 and F1-C. CU-UP allocates the F1-U uplink receiving address and TEID. CU-CP obtains that information through bearer context setup on E1 and supplies it to the DU through F1AP bearer configuration.

For downlink, the DU allocates its receiving address and TEID. The DU returns its accepted bearer configuration and tunnel information to CU-CP. CU-CP then supplies the downlink endpoint to CU-UP through E1 bearer context modification. TS 38.401 clause 8.9 describes this coordination.

Figure 3 uses invented values for one DRB with one tunnel endpoint per direction. The addresses and TEIDs are teaching examples, not a captured network trace. Notice that the receiver allocates the TEID used by the sender.

UL and DL packets use the TEID allocated by their respective receiver gNB-CU-UP192.0.2.10Allocates UL receive TEID0x1001 gNB-DU192.0.2.20Allocates DL receive TEID0x2001 UL: destination 192.0.2.10 / TEID 0x1001 DL: destination 192.0.2.20 / TEID 0x2001 Example: DRB 1; endpoint information exchanged through CU-CP

Figure 3. UL and DL use different receiving endpoints for the same example DRB.

  • UL packets leave the DU for CU-UP using TEID 0x1001.
  • DL packets leave CU-UP for the DU using TEID 0x2001.

The direction is relative to the UE's user traffic. An uplink tunnel therefore terminates on the CU side, even though its packets originate on the DU side of F1. That detail is easy to reverse when reading a field called UL UP TNL Information.

UE CONTEXT SETUP REQUEST asks the DU to establish the applicable context and bearer resources. A response must be read at bearer level: inspect accepted resources and any reported failures. The existence of a UE context alone does not prove every requested DRB was established.

After setup, data movement still depends on transport reachability, the installed mapping and radio-side operation. Downlink delivery status helps distinguish DU buffering from subsequent delivery progress. For RLC AM, delivered status has a different meaning from merely having transmitted data toward lower layers. It should not be treated as an application acknowledgement from the UE.

What changes after UE context setup?

A UE context is not fixed for the lifetime of the connection. Bearers can be added or changed, radio resources can change, and the CU and DU must eventually release their related state.

UE context management provides procedures for these changes. The CU can request a modification, and the DU can initiate the appropriate modification-required procedure when its side needs a change. These are different signalling procedures, so identify the initiating node before interpreting a request or its response.

A successful F1AP modification concerns the CU/DU resource exchange. When the change also requires UE configuration, the relevant RRC procedure must take place. Do not treat the F1AP response as a substitute for RRCReconfigurationComplete. The DU accepting its resources and the UE applying its configuration are separate events.

Release has a similar distinction. The CU can initiate UE context release directly, or it can act after a DU release request. The release procedure removes the applicable UE-related resources at the DU. A request from the DU should therefore be followed through to the CU's action and the completion, rather than being read as proof that cleanup has finished.

Mobility can require resources at another DU and changes to the user plane path. Even when the CU remains the same, the target DU needs its own context and tunnel information. Correlate the source and target procedures through the CU's logs, and check the lifetime of each mapping before interpreting later packets.

Interface recovery is broader than one UE release. Reset is used to recover from failure and reinitialise affected contexts, while F1 removal concerns the interface relationship. Their scope matters when many UEs fail together. A single missing bearer and a DU-wide loss of contexts lead to different investigations.

  • Track the complete procedure, including accepted resources, responses and any required RRC completion.
  • Keep context lifetime visible when comparing identifiers and tunnels before and after a change.

What should be checked when F1 fails?

The most useful first question is where progress stops. An SCTP connection problem, a rejected UE context and a missing downlink tunnel can all interrupt service, but they leave different evidence.

Start with one failing attempt and keep its timeline. Record the DU, cell, CU/DU UE F1AP IDs and requested DRBs. Then add the receiving tunnel addresses and TEIDs when bearer setup reaches that stage. This gives each packet or message a specific context.

Observed symptom

Next evidence to inspect

No F1AP exchange

SCTP establishment, configured peer addresses, routing and transport filtering. IP reachability alone is insufficient.

SCTP works, but F1 is unavailable

F1 SETUP REQUEST and its response or failure. Compare DU identity, served-cell information and the reported cause.

UE access stops early

Follow Figure 2 in order. Determine whether the DU received the radio message and whether the corresponding F1AP transfer reached the CU.

RRC works, but a DRB fails

UE context setup or modification results, accepted bearer lists and the complete endpoint exchange through CU-CP.

Only one user data direction works

Compare that direction's destination address and TEID with the receiving node's installed mapping. Check both ends of the transport path.

DL packets reach DU, but service stalls

NR user plane delivery status, DU buffering and radio-side RLC/MAC evidence. F1-U reception alone does not establish UE delivery.

Capture F1-C and F1-U together when possible. In Wireshark, protocol filters such as f1ap, sctp and gtp help separate the exchanges. A capture must also be decoded correctly; an empty F1AP view does not prove that no packets were sent.

When comparing captures from CU and DU, account for clock alignment. A packet visible at the sender but absent at the receiver suggests a transport or capture-location issue. A received packet with an unknown TEID instead points toward context mapping or context lifetime. These observations narrow the investigation; neither identifies the root cause by itself.

Finally, distinguish transport acknowledgement, F1AP procedure success, radio delivery and application success. They describe different stages. The useful evidence is the first stage that fails after the preceding stage has been verified.

  • Follow one UE and one DRB first. Expand the investigation when the evidence shows a shared DU or transport problem.

F1AP

Which F1AP message should appear next in a trace? The answer depends on the procedure being performed. F1 Setup, UE context management and RRC transfer use different messages, even though they share the same F1-C signalling transport.

F1AP is the F1 Application Protocol between the gNB-CU and gNB-DU. When the CU is split, CU-CP terminates this signalling. F1AP messages travel over SCTP; they are separate from the GTP-U user data carried on F1-U.

The table lists all 162 message types in TS 38.473 v19.3.0 (Release 19), grouped in the order of clause 9.2. Message names were cross-checked against both procedure tables in clause 8.1. Each row gives the direction, a short purpose and the clause defining its contents. CU and DU abbreviate gNB-CU and gNB-DU; "Either direction" means that either endpoint can send the message.

Class 1 procedures have a response, which may be a successful or unsuccessful outcome. Class 2 procedures have no response within that elementary procedure. A message named REQUEST therefore does not always have a matching RESPONSE with the same name. For example, UE CONTEXT RELEASE REQUEST asks the CU to initiate a separate release procedure.

Not every deployment uses every row. Positioning, IAB, MBS and other optional functions introduce their own messages. The list is complete for the stated version, but it does not mean that every CU or DU implements every feature. Use the purpose column to identify the exchange, then check the referenced clause for its IEs and the procedure in clause 8 for its conditions.

Message

Direction

Purpose

TS 38.473 clause

Interface management, resource coordination and status

RESET

Either direction

Request reset of all or part of the F1 interface.

9.2.1.1

RESET ACKNOWLEDGE

Either direction

Acknowledge the requested reset.

9.2.1.2

ERROR INDICATION

Either direction

Report a detected protocol error.

9.2.1.3

F1 SETUP REQUEST

DU → CU

Provide the DU configuration for initial F1 Setup.

9.2.1.4

F1 SETUP RESPONSE

CU → DU

Accept F1 Setup and provide the CU configuration.

9.2.1.5

F1 SETUP FAILURE

CU → DU

Reject F1 Setup and report the cause.

9.2.1.6

GNB-DU CONFIGURATION UPDATE

DU → CU

Provide changed DU configuration for the F1-C interface.

9.2.1.7

GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE

CU → DU

Acknowledge the DU configuration update.

9.2.1.8

GNB-DU CONFIGURATION UPDATE FAILURE

CU → DU

Report failure of the DU configuration update.

9.2.1.9

GNB-CU CONFIGURATION UPDATE

CU → DU

Provide changed CU configuration for the F1-C interface.

9.2.1.10

GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE

DU → CU

Acknowledge the CU configuration update.

9.2.1.11

GNB-CU CONFIGURATION UPDATE FAILURE

DU → CU

Report failure of the CU configuration update.

9.2.1.12

GNB-DU RESOURCE COORDINATION REQUEST

CU → DU

Coordinate desired, offered or agreed radio resource allocation with the DU.

9.2.1.13

GNB-DU RESOURCE COORDINATION RESPONSE

DU → CU

Return resource allocation information for the coordination request.

9.2.1.14

GNB-DU STATUS INDICATION

DU → CU

Report the DU's overload status.

9.2.1.15

F1 REMOVAL REQUEST

Either direction

Request removal of the F1 interface instance and its resources.

9.2.1.16

F1 REMOVAL RESPONSE

Either direction

Accept the F1 removal request.

9.2.1.17

F1 REMOVAL FAILURE

Either direction

Reject the F1 removal request.

9.2.1.18

NETWORK ACCESS RATE REDUCTION

CU → DU

Ask the DU to reduce the rate of UE network access.

9.2.1.19

RESOURCE STATUS REQUEST

CU → DU

Control the requested resource-status measurements.

9.2.1.20

RESOURCE STATUS RESPONSE

DU → CU

Confirm initiation of the requested measurements.

9.2.1.21

RESOURCE STATUS FAILURE

DU → CU

Report inability to initiate the requested measurements.

9.2.1.22

RESOURCE STATUS UPDATE

DU → CU

Report resource-status measurement results.

9.2.1.23

DU-CU TA INFORMATION TRANSFER

DU → CU

Provide timing advance information to the CU.

9.2.1.24

CU-DU TA INFORMATION TRANSFER

CU → DU

Provide timing advance information to the DU.

9.2.1.25

RACH INDICATION

DU → CU

Report one or more random access procedures performed at the DU.

9.2.1.26

UE context management and mobility

UE CONTEXT SETUP REQUEST

CU → DU

Request establishment of a UE context and its resources.

9.2.2.1

UE CONTEXT SETUP RESPONSE

DU → CU

Confirm UE context setup and report its results.

9.2.2.2

UE CONTEXT SETUP FAILURE

DU → CU

Report unsuccessful UE context setup.

9.2.2.3

UE CONTEXT RELEASE REQUEST

DU → CU

Ask the CU to release the UE-associated connection or applicable candidate-cell resources.

9.2.2.4

UE CONTEXT RELEASE COMMAND

CU → DU

Instruct the DU to release the UE-associated connection or applicable candidate-cell resources.

9.2.2.5

UE CONTEXT RELEASE COMPLETE

DU → CU

Confirm completion of the requested release.

9.2.2.6

UE CONTEXT MODIFICATION REQUEST

CU → DU

Request changes to the UE context at the DU.

9.2.2.7

UE CONTEXT MODIFICATION RESPONSE

DU → CU

Confirm the UE context modification and report its results.

9.2.2.8

UE CONTEXT MODIFICATION FAILURE

DU → CU

Report failure of the CU-requested context modification.

9.2.2.9

UE CONTEXT MODIFICATION REQUIRED

DU → CU

Ask the CU to modify the UE context.

9.2.2.10

UE CONTEXT MODIFICATION CONFIRM

CU → DU

Confirm the DU-requested context modification.

9.2.2.11

UE CONTEXT MODIFICATION REFUSE

CU → DU

Reject the DU-requested context modification.

9.2.2.11A

UE INACTIVITY NOTIFICATION

DU → CU

Report UE activity information.

9.2.2.12

NOTIFY

DU → CU

Report whether QoS is no longer met, or is met again, for DRBs under notification control.

9.2.2.13

ACCESS SUCCESS

DU → CU

Identify the cell successfully accessed in the applicable mobility procedure.

9.2.2.14

DU-CU CELL SWITCH NOTIFICATION

DU → CU

Notify the CU of cell-switch command initiation toward the UE.

9.2.2.15

CU-DU CELL SWITCH NOTIFICATION

CU → DU

Notify the DU of cell-switch command initiation toward the UE.

9.2.2.16

CU-DU MOBILITY INITIATION REQUEST

CU → DU

Trigger a UE cell-switch command and/or early synchronization.

9.2.2.17

DU-CU CSI-RS COORDINATION REQUEST

DU → CU

Request CSI-RS coordination, such as SP CSI-RS activation/deactivation at specific cells.

9.2.2.18

DU-CU CSI-RS COORDINATION RESPONSE

CU → DU

Return the result of DU-initiated CSI-RS coordination.

9.2.2.19

CU-DU CSI-RS COORDINATION REQUEST

CU → DU

Request DU-side CSI-RS coordination, such as SP CSI-RS activation/deactivation.

9.2.2.20

CU-DU CSI-RS COORDINATION RESPONSE

DU → CU

Return the result of CU-initiated CSI-RS coordination.

9.2.2.21

RRC message transfer

INITIAL UL RRC MESSAGE TRANSFER

DU → CU

Forward the UE's initial RRC message to the CU.

9.2.3.1

DL RRC MESSAGE TRANSFER

CU → DU

Carry downlink RRC signalling from the CU toward the UE.

9.2.3.2

UL RRC MESSAGE TRANSFER

DU → CU

Forward uplink RRC signalling from the DU to the CU.

9.2.3.3

RRC DELIVERY REPORT

DU → CU

Report delivery status of downlink RRC signalling.

9.2.3.4

Public Warning System (PWS)

WRITE-REPLACE WARNING REQUEST

CU → DU

Request the start or replacement of a warning broadcast.

9.2.4.1

WRITE-REPLACE WARNING RESPONSE

DU → CU

Acknowledge the warning broadcast request.

9.2.4.2

PWS CANCEL REQUEST

CU → DU

Request cancellation of an ongoing warning broadcast.

9.2.4.3

PWS CANCEL RESPONSE

DU → CU

Report the warning areas where cancellation succeeded or failed.

9.2.4.4

PWS RESTART INDICATION

DU → CU

Indicate availability of PWS information for some or all DU cells.

9.2.4.5

PWS FAILURE INDICATION

DU → CU

Report failure of ongoing PWS operation in one or more cells.

9.2.4.6

System information delivery

SYSTEM INFORMATION DELIVERY COMMAND

CU → DU

Request broadcasting of the specified SystemInformation messages, including Other SI.

9.2.5.1

Paging

PAGING

CU → DU

Request paging of UEs through the DU.

9.2.6.1

Trace

TRACE START

CU → DU

Start a UE trace session.

9.2.7.1

DEACTIVATE TRACE

CU → DU

Stop a trace session.

9.2.7.2

CELL TRAFFIC TRACE

DU → CU

Provide trace-specific information to the CU.

9.2.7.3

Radio information transfer

DU-CU RADIO INFORMATION TRANSFER

DU → CU

Transfer radio-related information from DU to CU.

9.2.8.1

CU-DU RADIO INFORMATION TRANSFER

CU → DU

Transfer radio-related information from CU to DU.

9.2.8.2

Integrated Access and Backhaul (IAB)

BAP MAPPING CONFIGURATION

CU → DU

Configure backhaul routing and/or traffic mapping at the DU.

9.2.9.1

BAP MAPPING CONFIGURATION ACKNOWLEDGE

DU → CU

Acknowledge BAP mapping configuration.

9.2.9.2

BAP MAPPING CONFIGURATION FAILURE

DU → CU

Report failure of BAP mapping configuration.

9.2.9.2A

GNB-DU RESOURCE CONFIGURATION

CU → DU

Provide IAB-related DU resource configuration.

9.2.9.3

GNB-DU RESOURCE CONFIGURATION ACKNOWLEDGE

DU → CU

Acknowledge DU resource configuration.

9.2.9.4

GNB-DU RESOURCE CONFIGURATION FAILURE

DU → CU

Report failure of DU resource configuration.

9.2.9.4A

IAB TNL ADDRESS REQUEST

CU → DU

Request allocation of IP addresses for IAB nodes.

9.2.9.5

IAB TNL ADDRESS RESPONSE

DU → CU

Return the allocated IAB transport addresses.

9.2.9.6

IAB TNL ADDRESS FAILURE

DU → CU

Report failure of IAB address allocation.

9.2.9.6A

IAB UP CONFIGURATION UPDATE REQUEST

CU → DU

Provide updated uplink backhaul or user plane transport information.

9.2.9.7

IAB UP CONFIGURATION UPDATE RESPONSE

DU → CU

Return updated downlink F1-U tunnel transport addresses.

9.2.9.8

IAB UP CONFIGURATION UPDATE FAILURE

DU → CU

Report failure of the IAB user plane configuration update.

9.2.9.9

MIAB F1 SETUP TRIGGERING

CU → DU

Trigger F1 setup from the co-located target logical DU to the target IAB-donor-CU.

9.2.9.10

MIAB F1 SETUP OUTCOME NOTIFICATION

DU → CU

Report the outcome of that target logical DU's F1 setup.

9.2.9.11

Access and mobility information

ACCESS AND MOBILITY INDICATION

CU → DU

Provide access and mobility information to the DU.

9.2.10.1

DU-CU ACCESS AND MOBILITY INDICATION

DU → CU

Provide access and mobility information to the CU.

9.2.10.2

Reference time information

REFERENCE TIME INFORMATION REPORTING CONTROL

CU → DU

Control the DU's delivery of accurate reference time information.

9.2.11.1

REFERENCE TIME INFORMATION REPORT

DU → CU

Report accurate reference time information to the CU.

9.2.11.2

Positioning

POSITIONING ASSISTANCE INFORMATION CONTROL

CU → DU

Provide positioning assistance information to the DU.

9.2.12.1

POSITIONING ASSISTANCE INFORMATION FEEDBACK

DU → CU

Return feedback on broadcasting positioning assistance information.

9.2.12.2

POSITIONING MEASUREMENT REQUEST

CU → DU

Request configuration of positioning measurements at the DU.

9.2.12.3

POSITIONING MEASUREMENT RESPONSE

DU → CU

Return positioning measurement results for the request.

9.2.12.4

POSITIONING MEASUREMENT FAILURE

DU → CU

Report failure of the positioning measurement request.

9.2.12.5

POSITIONING MEASUREMENT REPORT

DU → CU

Report positioning measurements for the target UE.

9.2.12.6

POSITIONING MEASUREMENT ABORT

CU → DU

Abort the requested positioning measurement.

9.2.12.7

POSITIONING MEASUREMENT FAILURE INDICATION

DU → CU

Indicate that previously requested positioning measurements can no longer be reported.

9.2.12.8

POSITIONING MEASUREMENT UPDATE

CU → DU

Change a previously configured positioning measurement.

9.2.12.9

TRP INFORMATION REQUEST

CU → DU

Request information about TRPs hosted by the DU.

9.2.12.10

TRP INFORMATION RESPONSE

DU → CU

Return the requested TRP information.

9.2.12.11

TRP INFORMATION FAILURE

DU → CU

Indicate that the requested TRP information cannot be provided.

9.2.12.12

POSITIONING INFORMATION REQUEST

CU → DU

Request UE uplink-positioning SRS configuration and retrieve its details.

9.2.12.13

POSITIONING INFORMATION RESPONSE

DU → CU

Return the configured SRS information.

9.2.12.14

POSITIONING INFORMATION FAILURE

DU → CU

Indicate that the required uplink-positioning SRS transmissions could not be configured.

9.2.12.15

POSITIONING ACTIVATION REQUEST

CU → DU

Request activation or triggering of UE uplink SRS transmission.

9.2.12.16

POSITIONING ACTIVATION RESPONSE

DU → CU

Confirm successful uplink SRS activation.

9.2.12.17

POSITIONING ACTIVATION FAILURE

DU → CU

Report failure to activate uplink SRS transmission.

9.2.12.18

POSITIONING DEACTIVATION

CU → DU

Deactivate or release the UE's uplink SRS transmissions.

9.2.12.19

E-CID MEASUREMENT INITIATION REQUEST

CU → DU

Request initiation of E-CID measurements.

9.2.12.20

E-CID MEASUREMENT INITIATION RESPONSE

DU → CU

Confirm initiation of E-CID measurements.

9.2.12.21

E-CID MEASUREMENT INITIATION FAILURE

DU → CU

Reject initiation of E-CID measurements.

9.2.12.22

E-CID MEASUREMENT FAILURE INDICATION

DU → CU

Indicate that an ongoing E-CID measurement can no longer be reported.

9.2.12.23

E-CID MEASUREMENT REPORT

DU → CU

Report E-CID measurement results.

9.2.12.24

E-CID MEASUREMENT TERMINATION COMMAND

CU → DU

Terminate the requested E-CID measurement.

9.2.12.25

POSITIONING INFORMATION UPDATE

DU → CU

Notify the CU that the SRS configuration has changed.

9.2.12.26

PRS CONFIGURATION REQUEST

CU → DU

Request configuration or update of PRS transmissions.

9.2.12.27

PRS CONFIGURATION RESPONSE

DU → CU

Acknowledge PRS configuration or update.

9.2.12.28

PRS CONFIGURATION FAILURE

DU → CU

Indicate that no requested PRS transmission could be configured.

9.2.12.29

MEASUREMENT PRECONFIGURATION REQUIRED

CU → DU

Provide multi-TRP PRS configuration and request a UE measurement gap or PRS processing window.

9.2.12.30

MEASUREMENT PRECONFIGURATION CONFIRM

DU → CU

Confirm configuration of the requested gap or processing window.

9.2.12.31

MEASUREMENT PRECONFIGURATION REFUSE

DU → CU

Reject configuration of the requested gap or processing window.

9.2.12.32

MEASUREMENT ACTIVATION

CU → DU

Activate or deactivate a preconfigured measurement gap or PRS processing window.

9.2.12.33

POSITIONING SYSTEM INFORMATION DELIVERY COMMAND

CU → DU

Request broadcast of the indicated positioning system information.

9.2.12.34

SRS INFORMATION RESERVATION NOTIFICATION

CU → DU

Request reservation or release of SRS resources within a Validity Area.

9.2.12.35

Broadcast MBS

BROADCAST CONTEXT SETUP REQUEST

CU → DU

Request a broadcast MBS session context and its MBS-associated F1 connection.

9.2.13.1

BROADCAST CONTEXT SETUP RESPONSE

DU → CU

Confirm broadcast context setup.

9.2.13.2

BROADCAST CONTEXT SETUP FAILURE

DU → CU

Report failure of broadcast context setup.

9.2.13.3

BROADCAST CONTEXT RELEASE COMMAND

CU → DU

Command release of the broadcast context.

9.2.13.4

BROADCAST CONTEXT RELEASE COMPLETE

DU → CU

Confirm broadcast context release.

9.2.13.5

BROADCAST CONTEXT RELEASE REQUEST

DU → CU

Ask the CU to initiate broadcast context release.

9.2.13.5a

BROADCAST CONTEXT MODIFICATION REQUEST

CU → DU

Request changes to the broadcast context.

9.2.13.6

BROADCAST CONTEXT MODIFICATION RESPONSE

DU → CU

Confirm broadcast context modification.

9.2.13.7

BROADCAST CONTEXT MODIFICATION FAILURE

DU → CU

Report failure of broadcast context modification.

9.2.13.8

BROADCAST TRANSPORT RESOURCE REQUEST

DU → CU

Ask the CU to establish broadcast-session F1-U resources.

9.2.13.9

Multicast MBS

MULTICAST GROUP PAGING

CU → DU

Request multicast group paging of UEs.

9.2.14.1

MULTICAST CONTEXT SETUP REQUEST

CU → DU

Request a multicast MBS session context and its MBS-associated F1 connection.

9.2.14.2

MULTICAST CONTEXT SETUP RESPONSE

DU → CU

Confirm multicast context setup.

9.2.14.3

MULTICAST CONTEXT SETUP FAILURE

DU → CU

Report failure of multicast context setup.

9.2.14.4

MULTICAST CONTEXT RELEASE COMMAND

CU → DU

Command release of the multicast context.

9.2.14.5

MULTICAST CONTEXT RELEASE COMPLETE

DU → CU

Confirm multicast context release.

9.2.14.6

MULTICAST CONTEXT RELEASE REQUEST

DU → CU

Ask the CU to initiate multicast context release.

9.2.14.6a

MULTICAST CONTEXT MODIFICATION REQUEST

CU → DU

Request changes to the multicast context.

9.2.14.7

MULTICAST CONTEXT MODIFICATION RESPONSE

DU → CU

Confirm multicast context modification.

9.2.14.8

MULTICAST CONTEXT MODIFICATION FAILURE

DU → CU

Report failure of multicast context modification.

9.2.14.9

MULTICAST DISTRIBUTION SETUP REQUEST

DU → CU

Request establishment of a Multicast F1-U Context.

9.2.14.10

MULTICAST DISTRIBUTION SETUP RESPONSE

CU → DU

Confirm establishment of the Multicast F1-U Context.

9.2.14.11

MULTICAST DISTRIBUTION SETUP FAILURE

CU → DU

Report failure to establish the Multicast F1-U Context.

9.2.14.12

MULTICAST DISTRIBUTION RELEASE COMMAND

DU → CU

Command release of the Multicast F1-U Context.

9.2.14.13

MULTICAST DISTRIBUTION RELEASE COMPLETE

CU → DU

Confirm release of the Multicast F1-U Context.

9.2.14.14

MULTICAST CONTEXT NOTIFICATION INDICATION

DU → CU

Notify the CU of multicast context changes requiring action.

9.2.14.15

MULTICAST CONTEXT NOTIFICATION CONFIRM

CU → DU

Confirm execution of the functions requested by the notification.

9.2.14.16

MULTICAST CONTEXT NOTIFICATION REFUSE

CU → DU

Report unsuccessful execution of the functions requested by the notification.

9.2.14.17

MULTICAST COMMON CONFIGURATION REQUEST

CU → DU

Request configuration of common multicast items at the DU.

9.2.14.18

MULTICAST COMMON CONFIGURATION RESPONSE

DU → CU

Confirm the requested common multicast configuration.

9.2.14.19

MULTICAST COMMON CONFIGURATION REFUSE

DU → CU

Reject the requested common multicast configuration.

9.2.14.20

Propagation Delay Compensation (PDC)

PDC MEASUREMENT INITIATION REQUEST

CU → DU

Request initiation of propagation delay compensation measurements.

9.2.15.1

PDC MEASUREMENT INITIATION RESPONSE

DU → CU

Confirm initiation of PDC measurements.

9.2.15.2

PDC MEASUREMENT INITIATION FAILURE

DU → CU

Reject initiation of PDC measurements.

9.2.15.3

PDC MEASUREMENT REPORT

DU → CU

Report PDC measurement results.

9.2.15.4

PDC MEASUREMENT TERMINATION COMMAND

CU → DU

Terminate an ongoing periodic PDC measurement.

9.2.15.5

PDC MEASUREMENT FAILURE INDICATION

DU → CU

Indicate that previously requested PDC measurements can no longer be reported.

9.2.15.6

Quality of Experience (QoE)

QOE INFORMATION TRANSFER

CU → DU

Provide RAN-visible QoE information to the DU.

9.2.16.1

QOE INFORMATION TRANSFER CONTROL

DU → CU

Control transfer of QoE information from the CU.

9.2.16.2

Timing synchronisation status

TIMING SYNCHRONISATION STATUS REQUEST

CU → DU

Request the start or stop of RAN timing synchronisation status reporting.

9.2.17.1

TIMING SYNCHRONISATION STATUS RESPONSE

DU → CU

Confirm the reporting-control request.

9.2.17.2

TIMING SYNCHRONISATION STATUS FAILURE

DU → CU

Indicate that timing synchronisation status reporting cannot be initiated.

9.2.17.3

TIMING SYNCHRONISATION STATUS REPORT

DU → CU

Report RAN timing synchronisation status.

9.2.17.4

Cross-Link Interference (CLI)

CLI INDICATION

Either direction

Report CLI measurement results or request SRS resource configuration information.

9.2.18.1

F1AP ASN for 5G Initial Registration

When following initial registration, an F1 trace shows several different message structures around the same UE. Which fields belong to F1AP, and where is the actual NAS Registration Request? The distinction matters because F1AP transports the radio signalling without defining the NAS message inside it.

This example follows successful initial registration of an ordinary standalone NR UE through a split gNB. SCTP establishment and F1 Setup are prerequisites, as shown in Figure 2. They are not repeated for each registration. Authentication, security and context-management timing depend on the applicable procedure and existing state; the table identifies the F1AP carriers rather than prescribing one universal trace.

The ASN.1 below comes from TS 38.473 v19.4.0, the latest published version resolved for this addition. The preceding full message catalogue remains explicitly based on v19.3.0. Each tile shows selected definitions with their complete displayed IE sets, including optional entries and extension markers. Referenced types and extension sets are not all expanded, so these excerpts are not a standalone ASN.1 module.

Stage

F1AP message and direction

What it carries or establishes

Interface prerequisite

F1 SETUP REQUEST: DU → CU
F1 SETUP RESPONSE: CU → DU

CU/DU configuration after SCTP establishment. No UE Registration Request is carried here.

First UE RRC message

INITIAL UL RRC MESSAGE TRANSFER: DU → CU

RRCSetupRequest, the DU UE identifier, NRCGI and C-RNTI. RRCSetupRequest itself contains no NAS Registration Request.

RRC connection setup

DL RRC MESSAGE TRANSFER: CU → DU

RRCSetup on SRB0.

Initial NAS delivery

UL RRC MESSAGE TRANSFER: DU → CU

SRB1 signalling containing RRCSetupComplete. Its dedicatedNAS-Message carries the NAS Registration Request in this example.

Further NAS exchanges

DL / UL RRC MESSAGE TRANSFER

DLInformationTransfer / ULInformationTransfer can carry NAS authentication and NAS security messages when those procedures are performed.

DU UE context establishment

UE CONTEXT SETUP REQUEST: CU → DU
UE CONTEXT SETUP RESPONSE: DU → CU

Radio context and requested resources. This is separate from NGAP INITIAL CONTEXT SETUP between AMF and CU.

Access-stratum security and configuration

DL / UL RRC MESSAGE TRANSFER; applicable UE context procedures

RRC SecurityModeCommand / SecurityModeComplete and other required RRC exchanges. An RRCContainer may also accompany UE CONTEXT SETUP REQUEST.

NAS registration completion

DL / UL RRC MESSAGE TRANSFER

NAS Registration Accept and Registration Complete can pass through the corresponding RRC information-transfer messages. Their NAS names are not separate F1AP message types.

How the F1AP message is selected

Start with the outer F1AP-PDU before reading individual IEs. It selects an initiating message, successful outcome or unsuccessful outcome, and the procedureCode determines which message type is allowed inside value.

For example, F1SetupRequest uses initiatingMessage and F1SetupResponse uses successfulOutcome for the same procedure. UL and DL RRC message transfers are each initiatingMessage values. A DL RRC transfer is not the ASN.1 successfulOutcome of an earlier UL transfer.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

F1AP-PDU ::= CHOICE {
	initiatingMessage	InitiatingMessage,
	successfulOutcome	SuccessfulOutcome,
	unsuccessfulOutcome	UnsuccessfulOutcome,
	choice-extension	ProtocolIE-SingleContainer { { F1AP-PDU-ExtIEs} }
}

F1AP-PDU-ExtIEs F1AP-PROTOCOL-IES ::= { -- this extension is not used
	...
}

InitiatingMessage ::= SEQUENCE {
	procedureCode	F1AP-ELEMENTARY-PROCEDURE.&procedureCode		({F1AP-ELEMENTARY-PROCEDURES}),
	criticality		F1AP-ELEMENTARY-PROCEDURE.&criticality			({F1AP-ELEMENTARY-PROCEDURES}{@procedureCode}),
	value			F1AP-ELEMENTARY-PROCEDURE.&InitiatingMessage	({F1AP-ELEMENTARY-PROCEDURES}{@procedureCode})
}

SuccessfulOutcome ::= SEQUENCE {
	procedureCode	F1AP-ELEMENTARY-PROCEDURE.&procedureCode		({F1AP-ELEMENTARY-PROCEDURES}),
	criticality		F1AP-ELEMENTARY-PROCEDURE.&criticality			({F1AP-ELEMENTARY-PROCEDURES}{@procedureCode}),
	value			F1AP-ELEMENTARY-PROCEDURE.&SuccessfulOutcome	({F1AP-ELEMENTARY-PROCEDURES}{@procedureCode})
}

UnsuccessfulOutcome ::= SEQUENCE {
	procedureCode	F1AP-ELEMENTARY-PROCEDURE.&procedureCode		({F1AP-ELEMENTARY-PROCEDURES}),
	criticality		F1AP-ELEMENTARY-PROCEDURE.&criticality			({F1AP-ELEMENTARY-PROCEDURES}{@procedureCode}),
	value			F1AP-ELEMENTARY-PROCEDURE.&UnsuccessfulOutcome	({F1AP-ELEMENTARY-PROCEDURES}{@procedureCode})
}

The procedure definitions make the relationship explicit. The constants below identify F1 Setup, UE Context Setup and the three RRC transfer procedures. These procedure codes are different from UE identifiers and individual IE identifiers.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

f1Setup F1AP-ELEMENTARY-PROCEDURE ::= {
	INITIATING MESSAGE		F1SetupRequest
	SUCCESSFUL OUTCOME		F1SetupResponse
	UNSUCCESSFUL OUTCOME	F1SetupFailure
	PROCEDURE CODE			id-F1Setup
	CRITICALITY				reject
}

uEContextSetup F1AP-ELEMENTARY-PROCEDURE ::= {
	INITIATING MESSAGE		UEContextSetupRequest
	SUCCESSFUL OUTCOME		UEContextSetupResponse
	UNSUCCESSFUL OUTCOME	UEContextSetupFailure
	PROCEDURE CODE			id-UEContextSetup
	CRITICALITY				reject
}

initialULRRCMessageTransfer F1AP-ELEMENTARY-PROCEDURE ::= {
	INITIATING MESSAGE		InitialULRRCMessageTransfer
	PROCEDURE CODE			id-InitialULRRCMessageTransfer
	CRITICALITY				ignore
}

dLRRCMessageTransfer F1AP-ELEMENTARY-PROCEDURE ::= {
	INITIATING MESSAGE		DLRRCMessageTransfer
	PROCEDURE CODE			id-DLRRCMessageTransfer
	CRITICALITY				ignore
}

uLRRCMessageTransfer F1AP-ELEMENTARY-PROCEDURE ::= {
	INITIATING MESSAGE		ULRRCMessageTransfer
	PROCEDURE CODE			id-ULRRCMessageTransfer
	CRITICALITY				ignore
}

id-F1Setup									ProcedureCode ::= 1

id-UEContextSetup							ProcedureCode ::= 5

id-InitialULRRCMessageTransfer				ProcedureCode ::= 11

id-DLRRCMessageTransfer						ProcedureCode ::= 12

id-ULRRCMessageTransfer						ProcedureCode ::= 13

Each message then contains protocolIEs. An entry has its own id, criticality and value. The message-specific IE set defines the allowed type and presence requirement for each entry. PRESENCE optional describes the message definition; procedure conditions still determine when a particular optional IE is needed.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

ProtocolIE-Container {F1AP-PROTOCOL-IES : IEsSetParam} ::=
	SEQUENCE (SIZE (0..maxProtocolIEs)) OF
	ProtocolIE-Field {{IEsSetParam}}

ProtocolIE-Field {F1AP-PROTOCOL-IES : IEsSetParam} ::= SEQUENCE {
	id				F1AP-PROTOCOL-IES.&id				({IEsSetParam}),
	criticality		F1AP-PROTOCOL-IES.&criticality		({IEsSetParam}{@id}),
	value			F1AP-PROTOCOL-IES.&Value			({IEsSetParam}{@id})
}

F1 Setup before the UE registers

The DU and CU first need an operational F1 interface. These two messages establish that application-level relationship after SCTP becomes available, so their structures describe the nodes and cells rather than a particular UE.

F1SetupRequest includes TransactionID, GNB-DU-ID and the DU RRC version as mandatory IEs. The served-cell list is optional in the ASN.1 set; its use follows the procedure conditions. F1SetupResponse returns the CU RRC version and can identify cells to activate. Neither message contains a CU/DU UE F1AP ID pair.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

F1SetupRequest ::= SEQUENCE {
	protocolIEs			ProtocolIE-Container       { {F1SetupRequestIEs} },
	...
}

F1SetupRequestIEs F1AP-PROTOCOL-IES ::= {
	{ ID id-TransactionID					CRITICALITY reject	TYPE TransactionID						PRESENCE mandatory	}|
	{ ID id-gNB-DU-ID						CRITICALITY reject	TYPE GNB-DU-ID							PRESENCE mandatory	}|
	{ ID id-gNB-DU-Name						CRITICALITY ignore	TYPE GNB-DU-Name						PRESENCE optional	}|
	{ ID id-gNB-DU-Served-Cells-List		CRITICALITY reject	TYPE GNB-DU-Served-Cells-List			PRESENCE optional	}|
	{ ID id-GNB-DU-RRC-Version				CRITICALITY reject	TYPE RRC-Version						PRESENCE mandatory	}|
	{ ID id-Transport-Layer-Address-Info	CRITICALITY ignore	TYPE Transport-Layer-Address-Info		PRESENCE optional	}|
	{ ID id-BAPAddress						CRITICALITY ignore	TYPE BAPAddress							PRESENCE optional	}|
	{ ID id-Extended-GNB-DU-Name			CRITICALITY ignore	TYPE Extended-GNB-DU-Name				PRESENCE optional	}|
	{ ID id-RRC-Terminating-IAB-Donor-gNB-ID	CRITICALITY reject	TYPE GlobalGNB-ID					PRESENCE optional }|
	{ ID id-Mobile-IAB-MTUserLocationInformation	CRITICALITY ignore	TYPE Mobile-IAB-MTUserLocationInformation		PRESENCE optional	},
	...
}

F1SetupResponse ::= SEQUENCE {
	protocolIEs			ProtocolIE-Container       { {F1SetupResponseIEs} },
	...
}

F1SetupResponseIEs F1AP-PROTOCOL-IES ::= {
	{ ID id-TransactionID					CRITICALITY reject	TYPE TransactionID						PRESENCE mandatory	}|
	{ ID id-gNB-CU-Name						CRITICALITY ignore	TYPE GNB-CU-Name						PRESENCE optional	}|
	{ ID id-Cells-to-be-Activated-List		CRITICALITY reject	TYPE Cells-to-be-Activated-List			PRESENCE optional	}|
	{ ID id-GNB-CU-RRC-Version				CRITICALITY reject	TYPE RRC-Version						PRESENCE mandatory	}|
	{ ID id-Transport-Layer-Address-Info	CRITICALITY ignore	TYPE Transport-Layer-Address-Info		PRESENCE optional	}|
	{ ID id-UL-BH-Non-UP-Traffic-Mapping	CRITICALITY reject	TYPE UL-BH-Non-UP-Traffic-Mapping		PRESENCE optional	}|
	{ ID id-BAPAddress						CRITICALITY ignore	TYPE BAPAddress							PRESENCE optional	}|
	{ ID id-Extended-GNB-CU-Name			CRITICALITY ignore	TYPE Extended-GNB-CU-Name				PRESENCE optional	}|
	{ ID id-NCGI-to-be-Updated-List			CRITICALITY reject	TYPE NCGI-to-be-Updated-List			PRESENCE optional	},
	...
}

INITIAL UL RRC MESSAGE TRANSFER

The DU has received the UE's first RRC message, but the CU has not yet assigned its UE F1AP identifier. The initial transfer therefore identifies the UE using the DU-side context and radio information.

For the RRC setup path, RRCContainer carries RRCSetupRequest. NRCGI identifies the cell and C-RNTI identifies the UE in its radio context. DUtoCURRCContainer is separate: it provides DU-generated RRC configuration information to the CU. The optional RRCContainer-RRCSetupComplete entry supports other applicable cases; its presence in the schema does not move RRCSetupComplete into the ordinary RRCSetupRequest exchange shown in Figure 2.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

InitialULRRCMessageTransfer ::= SEQUENCE {
	protocolIEs			ProtocolIE-Container       {{ InitialULRRCMessageTransferIEs}},
	...
}

InitialULRRCMessageTransferIEs F1AP-PROTOCOL-IES ::= {
	{ ID id-gNB-DU-UE-F1AP-ID					CRITICALITY reject	TYPE GNB-DU-UE-F1AP-ID						PRESENCE mandatory	}|
	{ ID id-NRCGI								CRITICALITY reject	TYPE NRCGI									PRESENCE mandatory	}|
	{ ID id-C-RNTI								CRITICALITY reject	TYPE C-RNTI									PRESENCE mandatory	}|
	{ ID id-RRCContainer						CRITICALITY reject	TYPE RRCContainer							PRESENCE mandatory	}|
	{ ID id-DUtoCURRCContainer					CRITICALITY reject	TYPE DUtoCURRCContainer						PRESENCE optional	}|
	{ ID id-SULAccessIndication					CRITICALITY ignore	TYPE SULAccessIndication					PRESENCE optional	}|
	{ ID id-TransactionID						CRITICALITY ignore	TYPE TransactionID							PRESENCE mandatory	}|
	{ ID id-RANUEID								CRITICALITY ignore	TYPE RANUEID								PRESENCE optional	}|
	{ ID id-RRCContainer-RRCSetupComplete		CRITICALITY ignore	TYPE RRCContainer-RRCSetupComplete 			PRESENCE optional	}|
	{ ID id-NRRedCapUEIndication				CRITICALITY ignore	TYPE NRRedCapUEIndication  					PRESENCE optional	}|
	{ ID id-SDTInformation						CRITICALITY ignore	TYPE SDTInformation							PRESENCE optional	}|
	{ ID id-SidelinkRelayConfiguration			CRITICALITY ignore	TYPE SidelinkRelayConfiguration			PRESENCE optional	}|
{ ID id-NReRedCapUEIndication					CRITICALITY ignore	TYPE NReRedCapUEIndication  				PRESENCE optional	},
	...
}

The optional entries also cover access variants such as RedCap, eRedCap, SDT and sidelink relay operation. They remain visible in the definition, but an ordinary initial registration does not automatically include all of them.

DL RRC MESSAGE TRANSFER

The CU now needs to deliver RRC signalling through the DU. This message identifies both UE contexts and the signalling bearer, so the DU can forward the container through the appropriate radio resources.

For RRCSetup, SRBID identifies SRB0. Later downlink signalling uses the applicable configured SRB. The same F1AP structure can carry RRC SecurityModeCommand or DLInformationTransfer containing a NAS message. RRC security and NAS security are different procedures, even though both can involve this F1AP transport.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

DLRRCMessageTransfer ::= SEQUENCE {
	protocolIEs			ProtocolIE-Container       {{ DLRRCMessageTransferIEs}},
	...
}

DLRRCMessageTransferIEs F1AP-PROTOCOL-IES ::= {
	{ ID id-gNB-CU-UE-F1AP-ID							CRITICALITY reject	TYPE GNB-CU-UE-F1AP-ID							PRESENCE mandatory	}|
	{ ID id-gNB-DU-UE-F1AP-ID							CRITICALITY reject	TYPE GNB-DU-UE-F1AP-ID							PRESENCE mandatory	}|
	{ ID id-oldgNB-DU-UE-F1AP-ID						CRITICALITY reject	TYPE GNB-DU-UE-F1AP-ID							PRESENCE optional	}|
	{ ID id-SRBID										CRITICALITY reject	TYPE SRBID											PRESENCE mandatory	}|
	{ ID id-ExecuteDuplication							CRITICALITY ignore	TYPE ExecuteDuplication							PRESENCE optional}|
	{ ID id-RRCContainer								CRITICALITY reject	TYPE RRCContainer									PRESENCE mandatory	}|
	{ ID id-RAT-FrequencyPriorityInformation			CRITICALITY reject	TYPE RAT-FrequencyPriorityInformation		PRESENCE optional	}|
	{ ID id-RRCDeliveryStatusRequest					CRITICALITY ignore	TYPE RRCDeliveryStatusRequest					PRESENCE optional }|
	{ ID id-UEContextNotRetrievable						CRITICALITY reject	TYPE UEContextNotRetrievable					PRESENCE optional }|
	{ ID id-RedirectedRRCmessage						CRITICALITY reject	TYPE OCTET STRING									PRESENCE optional }|
	{ ID id-PLMNAssistanceInfoForNetShar				CRITICALITY ignore	TYPE PLMN-Identity									PRESENCE optional }|
	{ ID id-new-gNB-CU-UE-F1AP-ID						CRITICALITY reject	TYPE GNB-CU-UE-F1AP-ID							PRESENCE optional }|
	{ ID id-AdditionalRRMPriorityIndex					CRITICALITY ignore	TYPE AdditionalRRMPriorityIndex				PRESENCE optional }|
	{ ID id-SRBMappingInfo								CRITICALITY ignore	TYPE UuRLCChannelID					 				PRESENCE optional }|
	{ ID id-PLMNIndexNRAssistanceInfoForNetShar					CRITICALITY ignore	TYPE PLMNIndexNR											PRESENCE optional }|
	{ ID id-AreaSpecificSemiPersistentSRSPosInfo		CRITICALITY ignore	TYPE AreaSpecificSemiPersistentSRSPosInfo 	PRESENCE optional },
	...
}

RRCContainer is mandatory here, together with both UE IDs and SRBID. RRCDeliveryStatusRequest can request delivery feedback. Other optional fields support cases such as context recovery, redirection and positioning; they are not additional mandatory registration steps.

UL RRC MESSAGE TRANSFER

After the initial transfer, the CU and DU can identify the UE using their established F1AP context. Subsequent uplink RRC signalling therefore uses this structure, including the response completing RRC connection setup.

For initial registration, the important payload is RRCSetupComplete with its dedicatedNAS-Message. The CU obtains the NAS Registration Request from that RRC message and forwards it toward the AMF through NGAP. Later ULInformationTransfer messages can carry further NAS responses, including Registration Complete when required.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

ULRRCMessageTransfer ::= SEQUENCE {
	protocolIEs			ProtocolIE-Container       {{ ULRRCMessageTransferIEs}},
	...
}

ULRRCMessageTransferIEs F1AP-PROTOCOL-IES ::= {
	{ ID id-gNB-CU-UE-F1AP-ID				CRITICALITY reject	TYPE GNB-CU-UE-F1AP-ID				PRESENCE mandatory	}|
	{ ID id-gNB-DU-UE-F1AP-ID				CRITICALITY reject	TYPE GNB-DU-UE-F1AP-ID				PRESENCE mandatory	}|
	{ ID id-SRBID							CRITICALITY reject	TYPE SRBID							PRESENCE mandatory	}|
	{ ID id-RRCContainer					CRITICALITY reject	TYPE RRCContainer					PRESENCE mandatory	}|
	{ ID id-SelectedPLMNID					CRITICALITY reject	TYPE PLMN-Identity					PRESENCE optional		}|
	{ ID id-new-gNB-DU-UE-F1AP-ID			CRITICALITY reject	TYPE GNB-DU-UE-F1AP-ID				PRESENCE optional		},
	...
}

Both UE IDs, SRBID and RRCContainer are mandatory. The container definitions below show why a decoder must continue into another protocol layer: F1AP treats these RRC containers as octet strings. On SRB1, the F1 RRC transfer container carries the control-plane PDCP PDU, so decoding also depends on PDCP and security state. It should not be interpreted directly as a NAS packet.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

RRCContainer ::= OCTET STRING

DUtoCURRCContainer ::= OCTET STRING

UE CONTEXT SETUP REQUEST and RESPONSE

Delivering the first RRC messages does not establish every DU resource needed for the connection. The CU uses UE Context Setup to request the applicable radio context, and the DU returns the configuration and resource results.

In UEContextSetupRequest, GNB-CU-UE-F1AP-ID, SpCell-ID, ServCellIndex and CUtoDURRCInformation are mandatory. GNB-DU-UE-F1AP-ID is optional in the generic definition because this procedure also covers cases where the DU context has not yet been created. During the ordinary initial-access path, the earlier RRC transfer supplies the association needed to identify the existing DU context.

SRBs-ToBeSetup-List and DRBs-ToBeSetup-List are optional in the schema. NAS registration does not by itself require a user-data DRB or an established PDU session. If DRBs are requested, the conditional GNB-DU-UE-AMBR-UL entry must be interpreted with the comment retained in the listing.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

UEContextSetupRequest ::= SEQUENCE {
	protocolIEs			ProtocolIE-Container       { { UEContextSetupRequestIEs} },
	...
}

UEContextSetupRequestIEs F1AP-PROTOCOL-IES ::= {
	{ ID id-gNB-CU-UE-F1AP-ID						CRITICALITY reject	TYPE GNB-CU-UE-F1AP-ID									PRESENCE mandatory	}|
	{ ID id-gNB-DU-UE-F1AP-ID						CRITICALITY ignore	TYPE GNB-DU-UE-F1AP-ID									PRESENCE optional 	}|
	{ ID id-SpCell-ID								CRITICALITY reject	TYPE NRCGI												PRESENCE mandatory	}|
	{ ID id-ServCellIndex							CRITICALITY reject	TYPE ServCellIndex										PRESENCE mandatory	}|
	{ ID id-SpCellULConfigured						CRITICALITY ignore	TYPE CellULConfigured									PRESENCE optional	}|
	{ ID id-CUtoDURRCInformation					CRITICALITY reject	TYPE CUtoDURRCInformation								PRESENCE mandatory}|
	{ ID id-Candidate-SpCell-List					CRITICALITY ignore	TYPE Candidate-SpCell-List							PRESENCE optional	}|
	{ ID id-DRXCycle								CRITICALITY ignore	TYPE DRXCycle											PRESENCE optional	}|
	{ ID id-ResourceCoordinationTransferContainer	CRITICALITY ignore	TYPE ResourceCoordinationTransferContainer		PRESENCE optional	}|
	{ ID id-SCell-ToBeSetup-List					CRITICALITY ignore	TYPE SCell-ToBeSetup-List								PRESENCE optional	}|
	{ ID id-SRBs-ToBeSetup-List						CRITICALITY reject	TYPE SRBs-ToBeSetup-List								PRESENCE optional	}|
	{ ID id-DRBs-ToBeSetup-List						CRITICALITY reject	TYPE DRBs-ToBeSetup-List								PRESENCE optional	}|
	{ ID id-InactivityMonitoringRequest				CRITICALITY reject	TYPE InactivityMonitoringRequest					PRESENCE optional	}|
	{ ID id-RAT-FrequencyPriorityInformation		CRITICALITY reject	TYPE RAT-FrequencyPriorityInformation				PRESENCE optional	}|
	{ ID id-RRCContainer							CRITICALITY ignore	TYPE RRCContainer										PRESENCE optional	}|
	{ ID id-MaskedIMEISV							CRITICALITY ignore	TYPE MaskedIMEISV										PRESENCE optional	}|
	{ ID id-ServingPLMN								CRITICALITY ignore	TYPE PLMN-Identity										PRESENCE optional	}|
	{ ID id-GNB-DU-UE-AMBR-UL						CRITICALITY ignore	TYPE BitRate											PRESENCE conditional }|
	-- The above IE shall be present only if the DRB to Be Setup List IE is present.
	{ ID id-RRCDeliveryStatusRequest				CRITICALITY ignore	TYPE RRCDeliveryStatusRequest						PRESENCE optional }|
	{ ID id-ResourceCoordinationTransferInformation	CRITICALITY ignore	TYPE ResourceCoordinationTransferInformation	PRESENCE optional	}|
	{ ID id-ServingCellMO							CRITICALITY ignore	TYPE ServingCellMO										PRESENCE optional	}|
	{ ID id-new-gNB-CU-UE-F1AP-ID					CRITICALITY reject	TYPE GNB-DU-UE-F1AP-ID									PRESENCE optional }|
	{ ID id-RANUEID									CRITICALITY ignore	TYPE RANUEID											PRESENCE optional	}|
	{ ID id-TraceActivation							CRITICALITY ignore	TYPE TraceActivation									PRESENCE optional	}|
	{ ID id-AdditionalRRMPriorityIndex				CRITICALITY ignore	TYPE AdditionalRRMPriorityIndex						PRESENCE optional }|
	{ ID id-BHChannels-ToBeSetup-List				CRITICALITY reject	TYPE BHChannels-ToBeSetup-List						PRESENCE optional	}|
	{ ID id-ConfiguredBAPAddress					CRITICALITY reject	TYPE BAPAddress											PRESENCE optional	}|
	{ ID id-NRV2XServicesAuthorized					CRITICALITY ignore	TYPE NRV2XServicesAuthorized							PRESENCE optional }|
	{ ID id-LTEV2XServicesAuthorized				CRITICALITY ignore	TYPE LTEV2XServicesAuthorized						PRESENCE optional }|
	{ ID id-NRUESidelinkAggregateMaximumBitrate		CRITICALITY ignore	TYPE NRUESidelinkAggregateMaximumBitrate			PRESENCE optional }|
	{ ID id-LTEUESidelinkAggregateMaximumBitrate	CRITICALITY ignore	TYPE LTEUESidelinkAggregateMaximumBitrate		PRESENCE optional }|
	{ ID id-PC5LinkAMBR								CRITICALITY ignore	TYPE BitRate											PRESENCE optional}|
	{ ID id-SLDRBs-ToBeSetup-List					CRITICALITY reject	TYPE SLDRBs-ToBeSetup-List							PRESENCE optional	}|
	{ ID id-ConditionalInterDUMobilityInformation	CRITICALITY reject	TYPE ConditionalInterDUMobilityInformation		PRESENCE optional}|
	{ ID id-ManagementBasedMDTPLMNList				CRITICALITY ignore	TYPE 		MDTPLMNList									PRESENCE optional }|
	{ ID id-ServingNID								CRITICALITY reject	TYPE NID												PRESENCE optional }|
	{ ID id-F1CTransferPath							CRITICALITY reject	TYPE F1CTransferPath									PRESENCE optional }|
	{ ID id-F1CTransferPathNRDC						CRITICALITY reject	TYPE F1CTransferPathNRDC								PRESENCE optional }|
	{ ID id-MDTPollutedMeasurementIndicator			CRITICALITY ignore	TYPE MDTPollutedMeasurementIndicator				PRESENCE optional }|
	{ ID id-SCGActivationRequest					CRITICALITY ignore	TYPE SCGActivationRequest								PRESENCE optional }|
	{ ID id-CG-SDTSessionInfoOld					CRITICALITY ignore	TYPE CG-SDTSessionInfo									PRESENCE optional }|
	{ ID id-FiveG-ProSeAuthorized					CRITICALITY ignore	TYPE FiveG-ProSeAuthorized							PRESENCE optional }|
	{ ID id-FiveG-ProSeUEPC5AggregateMaximumBitrate	CRITICALITY ignore	TYPE NRUESidelinkAggregateMaximumBitrate			PRESENCE optional }|
	{ ID id-FiveG-ProSePC5LinkAMBR					CRITICALITY ignore	TYPE BitRate											PRESENCE optional}|
	{ ID id-UuRLCChannelToBeSetupList				CRITICALITY reject	TYPE UuRLCChannelToBeSetupList						PRESENCE optional}|
	{ ID id-PC5RLCChannelToBeSetupList				CRITICALITY reject	TYPE PC5RLCChannelToBeSetupList						PRESENCE optional}|
	{ ID id-PathSwitchConfiguration					CRITICALITY ignore	TYPE PathSwitchConfiguration				 			PRESENCE optional	}|
	{ ID id-GNBDUUESliceMaximumBitRateList			CRITICALITY ignore  TYPE GNBDUUESliceMaximumBitRateList 				PRESENCE optional }|
	{ ID id-MulticastMBSSessionSetupList			CRITICALITY reject	TYPE MulticastMBSSessionList							PRESENCE optional }|
	{ ID id-UE-MulticastMRBs-ToBeSetup-List			CRITICALITY reject	TYPE UE-MulticastMRBs-ToBeSetup-List				PRESENCE optional	}|
	{ ID id-ServingCellMO-List						CRITICALITY ignore	TYPE ServingCellMO-List									PRESENCE optional	}|
	{ ID id-NetworkControlledRepeaterAuthorized		CRITICALITY ignore	TYPE NetworkControlledRepeaterAuthorized			PRESENCE optional	}|
	{ ID id-SDT-Volume-Threshold						CRITICALITY ignore	TYPE SDT-Volume-Threshold								PRESENCE optional  }|
	{ ID id-LTMInformation-Setup					CRITICALITY reject	TYPE LTMInformation-Setup								PRESENCE optional	}|
	{ ID id-LTMConfigurationIDMappingList			CRITICALITY reject	TYPE LTMConfigurationIDMappingList					PRESENCE optional	}|
	{ ID id-EarlySyncInformation-Request			CRITICALITY ignore	TYPE EarlySyncInformation-Request					PRESENCE optional	}|
	{ ID id-PathAdditionInformation				CRITICALITY reject	TYPE PathAdditionInformation							PRESENCE optional}|
	{ ID id-NRA2XServicesAuthorized					CRITICALITY ignore	TYPE NRA2XServicesAuthorized							PRESENCE optional }|
	{ ID id-LTEA2XServicesAuthorized				CRITICALITY ignore	TYPE LTEA2XServicesAuthorized								PRESENCE optional }|
	{ ID id-NRUESidelinkAggregateMaximumBitrateForA2X		CRITICALITY ignore	TYPE NRUESidelinkAggregateMaximumBitrate		PRESENCE optional }|
	{ ID id-LTEUESidelinkAggregateMaximumBitrateForA2X	CRITICALITY ignore	TYPE LTEUESidelinkAggregateMaximumBitrate		PRESENCE optional }|
	{ ID id-DLLBTFailureInformationRequest				CRITICALITY ignore	TYPE DLLBTFailureInformationRequest				PRESENCE optional }|
	{ ID id-SLPositioning-Ranging-Service-Info		CRITICALITY ignore	TYPE SLPositioning-Ranging-Service-Info						PRESENCE optional	}|
	{ ID id-NonIntegerDRXCycle						CRITICALITY ignore	TYPE NonIntegerDRXCycle									PRESENCE optional	}|
	{ ID id-LTMInformationSCGAdd					CRITICALITY reject	TYPE LTMInformationSCGAdd								PRESENCE optional	},
	...
}

UEContextSetupResponse carries both UE identifiers and DUtoCURRCInformation. Read the setup and failed-to-be-setup lists as well as the message name: a successful procedure response can report that particular requested resources failed. UEContextSetupFailure is the unsuccessful outcome when the procedure itself fails; its definition is outside this successful-path excerpt.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

UEContextSetupResponse ::= SEQUENCE {
	protocolIEs			ProtocolIE-Container       { { UEContextSetupResponseIEs} },
	...
}

UEContextSetupResponseIEs F1AP-PROTOCOL-IES ::= {
	{ ID id-gNB-CU-UE-F1AP-ID						CRITICALITY reject	TYPE GNB-CU-UE-F1AP-ID								PRESENCE mandatory	}|
	{ ID id-gNB-DU-UE-F1AP-ID						CRITICALITY reject	TYPE GNB-DU-UE-F1AP-ID								PRESENCE mandatory	}|
	{ ID id-DUtoCURRCInformation					CRITICALITY reject	TYPE DUtoCURRCInformation							PRESENCE mandatory }|
	{ ID id-C-RNTI									CRITICALITY ignore	TYPE C-RNTI											PRESENCE optional	}|
	{ ID id-ResourceCoordinationTransferContainer	CRITICALITY ignore	TYPE ResourceCoordinationTransferContainer	PRESENCE optional	}|
	{ ID id-FullConfiguration						CRITICALITY reject	TYPE FullConfiguration								PRESENCE optional	}|
	{ ID id-DRBs-Setup-List							CRITICALITY ignore	TYPE DRBs-Setup-List								PRESENCE optional	}|
	{ ID id-SRBs-FailedToBeSetup-List				CRITICALITY ignore	TYPE SRBs-FailedToBeSetup-List					PRESENCE optional	}|
	{ ID id-DRBs-FailedToBeSetup-List				CRITICALITY ignore	TYPE DRBs-FailedToBeSetup-List					PRESENCE optional	}|
	{ ID id-SCell-FailedtoSetup-List				CRITICALITY ignore	TYPE SCell-FailedtoSetup-List					PRESENCE optional	}|
	{ ID id-InactivityMonitoringResponse			CRITICALITY reject	TYPE InactivityMonitoringResponse				PRESENCE optional	}|
	{ ID id-CriticalityDiagnostics					CRITICALITY ignore	TYPE CriticalityDiagnostics						PRESENCE optional	}|
	{ ID id-SRBs-Setup-List							CRITICALITY ignore	TYPE SRBs-Setup-List								PRESENCE optional	}|
	{ ID id-BHChannels-Setup-List					CRITICALITY ignore	TYPE BHChannels-Setup-List						PRESENCE optional	}|
	{ ID id-BHChannels-FailedToBeSetup-List			CRITICALITY ignore	TYPE BHChannels-FailedToBeSetup-List			PRESENCE optional	}|
	{ ID id-SLDRBs-Setup-List						CRITICALITY ignore	TYPE SLDRBs-Setup-List								PRESENCE optional	}|
	{ ID id-SLDRBs-FailedToBeSetup-List				CRITICALITY ignore	TYPE SLDRBs-FailedToBeSetup-List				PRESENCE optional	}|
	{ ID id-requestedTargetCellGlobalID				CRITICALITY reject	TYPE NRCGI											PRESENCE optional}|
	{ ID id-SCGActivationStatus						CRITICALITY ignore	TYPE SCGActivationStatus							PRESENCE optional }|
	{ ID id-UuRLCChannelSetupList					CRITICALITY ignore	TYPE UuRLCChannelSetupList						PRESENCE optional}|
	{ ID id-UuRLCChannelFailedToBeSetupList			CRITICALITY ignore	TYPE UuRLCChannelFailedToBeSetupList			PRESENCE optional}|
	{ ID id-PC5RLCChannelSetupList					CRITICALITY ignore	TYPE PC5RLCChannelSetupList						PRESENCE optional}|
	{ ID id-PC5RLCChannelFailedToBeSetupList		CRITICALITY ignore	TYPE PC5RLCChannelFailedToBeSetupList			PRESENCE optional}|
	{ ID id-ServingCellMO-encoded-in-CGC-List		CRITICALITY ignore	TYPE ServingCellMO-encoded-in-CGC-List			PRESENCE optional}|
	{ ID id-UE-MulticastMRBs-Setupnew-List			CRITICALITY reject	TYPE UE-MulticastMRBs-Setupnew-List				PRESENCE optional}|
	{ ID id-DedicatedSIDeliveryIndication			CRITICALITY ignore	TYPE DedicatedSIDeliveryIndication				PRESENCE optional}|
	{ ID id-Configured-BWP-List						CRITICALITY ignore	TYPE Configured-BWP-List								PRESENCE optional}|
	{ ID id-EarlySyncInformation					CRITICALITY ignore	TYPE EarlySyncInformation							PRESENCE optional	}|
	{ ID id-LTMConfiguration						CRITICALITY ignore	TYPE LTMConfiguration								PRESENCE optional	}|
	{ ID id-S-CPAC-Configuration					CRITICALITY ignore	TYPE S-CPAC-Configuration							PRESENCE optional	},
	...
}

The two RRC-information structures below show the configuration exchange between CU and DU. They differ from RRCContainer, which carries signalling toward or from the UE. DUtoCURRCInformation includes cellGroupConfig, allowing the CU to use the DU's lower-layer configuration in the applicable RRC procedure.

Following is based on 38.473 v19.4.0 (Release 19), clause 9.4

CUtoDURRCInformation ::= SEQUENCE {
	cG-ConfigInfo						CG-ConfigInfo						OPTIONAL,
	uE-CapabilityRAT-ContainerList		UE-CapabilityRAT-ContainerList		OPTIONAL,
	measConfig							MeasConfig							OPTIONAL,
	iE-Extensions				ProtocolExtensionContainer { { CUtoDURRCInformation-ExtIEs} } OPTIONAL,
	...
}

DUtoCURRCInformation ::= SEQUENCE {
	cellGroupConfig		CellGroupConfig,
	measGapConfig			MeasGapConfig	OPTIONAL,
	requestedP-MaxFR1				OCTET STRING				OPTIONAL,
	iE-Extensions				ProtocolExtensionContainer { { DUtoCURRCInformation-ExtIEs} } OPTIONAL,
	...
}

Later bearer establishment or configuration changes can require UE Context Modification. That procedure is conditional on the resources being changed, so it is not shown as a mandatory registration step here. Likewise, successful F1AP context setup does not confirm that the AMF has accepted NAS registration.

  • Follow the nesting: F1AP selects a message, its IE set carries an RRC container, and the decoded RRC message may contain NAS.
  • Keep the endpoints separate: F1AP operates between CU and DU, RRC between CU and UE, and NAS between AMF and UE.

Reference :

Seven specifications were downloaded, including two versions of TS 38.473, and the relevant clauses listed here were read individually. The coverage is selective, not a full-document review. These versions provide the Release 19 baseline used for the basic procedures on this page.

  • 3GPP TS 38.401 v19.2.0: NG-RAN; Architecture description. Clauses 6.1, 8.1 and 8.9.1: CU/DU architecture, initial access and E1/F1 coordination.
  • 3GPP TS 38.470 v19.0.0: NG-RAN; F1 general aspects and principles. Clauses 4 and 5.2.1-5.2.3: interface principles, management and UE context functions.
  • 3GPP TS 38.472 v19.0.0: NG-RAN; F1 signalling transport. Clauses 4-7: SCTP/IP stack, associations and signalling transport.
  • 3GPP TS 38.473 v19.3.0: NG-RAN; F1 Application Protocol (F1AP). Clauses 8.1, 8.2.3, 8.3.1 and 8.4.1-8.4.4: procedure lists, F1 Setup, UE Context Setup and RRC message transfer. Clause 9.2: all 162 message names, introductory purpose statements and direction fields were read; the complete IE tables were not reviewed. Also consulted: 3GPP TS 38.473 v19.4.0, clause 9.4: selected ASN.1 PDU, procedure, message, IE-set and container definitions reproduced in the initial-registration section.
  • 3GPP TS 38.331 v19.4.0: NR; Radio Resource Control (RRC); Protocol specification. Selected RRCSetupComplete-IEs, DLInformationTransfer-IEs and ULInformationTransfer-IEs definitions were read to verify their dedicatedNAS-Message fields; the full specification was not reviewed.
  • 3GPP TS 38.474 v19.0.0: NG-RAN; F1 data transport. Clauses 4-5: GTP-U/UDP/IP and user data transport.
  • 3GPP TS 38.425 v19.0.0: NG-RAN; NR user plane protocol. Clauses 1, 4 and 5.1-5.4.1: scope, protocol operation, DL user data and delivery status.