|
|
# The F1 interface
|
|
|
|
|
|
The F1 interface is the functional split of 3GPP between the CU (centralized
|
|
|
unit: PDCP, RRC, SDAP) and the DU (distributed unit: RLC, MAC, PHY). It is
|
|
|
standardized in TS 38.470 - 38.473 for 5G NR. Note that though there will be
|
|
|
the V1 interface destined for LTE, OAI implements the F1 interface in the LTE
|
|
|
modem.
|
|
|
|
|
|
The code can be found in branch `feature-127-protocol-split`.
|
|
|
|
|
|
# Control plane status
|
|
|
|
|
|
The current implementation is still based on R15.2. Please note that there are
|
|
|
also limitationsIt is possible to connect
|
|
|
and disconnect UEs, i.e. especially the disconnect works reliably after a
|
|
|
detach request. As in the current develop branch, a UE is not correctly freed
|
|
|
if synchronization is lost.
|
|
|
|
|
|
The following messages are currently implemented:
|
|
|
|
|
|
* F1 Setup Request and F1 Setup Response (for a successful outcome)
|
|
|
* Initial UL RRC Message Transfer
|
|
|
* UL/DL RRC Message Transfer
|
|
|
* F1 UE Context Release Request/Command/Complete
|
|
|
|
|
|
All other messages can be assumed to *not* be implemented:
|
|
|
|
|
|
* F1 UE Context Setup Request is *not* implemented. Instead, it is somewhat
|
|
|
transparently handled through UL/DL RRC message transfers which set up the
|
|
|
RLC etc.
|
|
|
* All System Information messages
|
|
|
* All Paging messages
|
|
|
* All Warning Message transmissions
|
|
|
|
|
|
There are the following notes:
|
|
|
|
|
|
* Tested up to four UEs
|
|
|
* The CU can continue run once the DU stops and does not need to be restarted
|
|
|
(e.g. CN connections can remain intact)
|
|
|
|
|
|
# Data plane status
|
|
|
|
|
|
Currently, we don't implement F1-U as specified by 3GPP, i.e. using GTP-U (the
|
|
|
reason being that work started before 3GPP specified the first revision).
|
|
|
|
|
|
The current implementation uses Google Protocol Buffers to encapsulate RLC SDUs
|
|
|
and transports them over a configurable UDP tunnel. It is powerful enough to
|
|
|
sustain at least a steady 70Mbps user data rate which is enough for a single
|
|
|
CU-DU link and a single UE saturating the wireless link over 100RB in SISO
|
|
|
(measured with OAI). Protocol Buffers are already used for FlexRAN, so no
|
|
|
changes are necessary here in the build script.
|
|
|
|
|
|
Currently, multiple DUs are not supported in the data plane (as in the control
|
|
|
plane). It is planned to replace this implementation with the
|
|
|
standard-compliant GTP-U implementation which.
|
|
|
|
|
|
# Usage
|
|
|
|
|
|
Check out the branch `feature-127-protocol-split` and compile using the
|
|
|
`build_oai` script as normal. Support for F1AP will be installed. Then, the
|
|
|
same lte-softmodem executable is used to start CU and DU, subject to
|
|
|
configuratio parameters. A sample configuration to run everything on the same
|
|
|
PC is [cu.lte.conf](f1-sample-conf/cu.lte.conf) and
|
|
|
[du.lte.band7.conf](f1-sample-conf/du.lte.band7.conf) and only the EPC need to
|
|
|
be changed. The basic structure for both files is unchanged; notable differences
|
|
|
to a monolithic deployment are the following:
|
|
|
|
|
|
* CU: `tr_s_preference` in the eNodeB configuration is set to `f1`, and there
|
|
|
is configuration for local and remote addresses which I believe are only used
|
|
|
for data plane.
|
|
|
* CU: PHY parameters can be left out.
|
|
|
* DU: in the `MACRLCs`, `tr_n_preference` is set to `f1`; address and ports are
|
|
|
used to find the CU on control and data plane level.
|
|
|
* DU: RRC and EPC parameters can be left out (the current DU implementation
|
|
|
uses RRC but gets it passed through the CU in the setup procedure), but SCTP
|
|
|
is used so leave it in there.
|
|
|
* both: there is a `nr_cellid` which needs to be set.
|
|
|
|
|
|
# Wireshark version to dissect F1 messages
|
|
|
|
|
|
The current version should have F1 support (not verified, so I also don't know
|
|
|
whether the F1AP dissector needs to be enabled etc.). However, since we
|
|
|
currently use R15.2 for the F1 messages and the current version of master
|
|
|
already has R15.4 which is incompatible to R15.2, also build an older version
|
|
|
like this:
|
|
|
|
|
|
```bash
|
|
|
$ git clone https://github.com/wireshark/wireshark
|
|
|
$ cd wireshark
|
|
|
$ git checkout a1ae40f # tested, should work for F1 R15.2 but is somewhat arbitray
|
|
|
$ mkdir build
|
|
|
$ cd build/
|
|
|
$ cmake ..
|
|
|
$ build -j$(nproc) # and go get coffee...
|
|
|
$ cd run/
|
|
|
$ sudo ./wireshark # or sudo ~/wireshark/build/run/wireshark
|
|
|
```
|
|
|
|
|
|
Capture with capture filter `port 36412 || port 30923` (i.e. when choosing the
|
|
|
device) to capture only for S1AP and F1AP traffic on the CU machine.
|
|
|
|
|
|
# FlexRAN support
|
|
|
|
|
|
Since information about the base station stemming from different layers is
|
|
|
spread on two entities (DU and CU), these two entities also need to connect to
|
|
|
a common FlexRAN controller. Support for this is included and a recent FlexRAN
|
|
|
controller version (FlexRAN tag v2.1) supports it out of the box. FlexRAN will
|
|
|
expose CU and DU as a single base station. |