|
|
This tutorial shows how to control the RAN with FlexRAN base station-local
|
|
|
applications from within the controller. It assumes that a running
|
|
|
[OAI-CN](tutorials/oai-cn), [OAI-RAN](tutorials/oai-ran) and
|
|
|
[FlexRAN](tutorials/flexran) are present. Furthermore, you need the
|
|
|
`file_store` application of the [Store](tutorials/store).
|
|
|
|
|
|
The applications are showcased in Youtube videos on the
|
|
|
[pitch](https://youtu.be/E4BmLbL3sj8) and [complete
|
|
|
demo](https://youtu.be/E4BmLbL3sj8) of our [MobiCom demo "Service-oriented
|
|
|
intelligent and extensible
|
|
|
RAN"](https://dl.acm.org/doi/10.1145/3372224.3417321).
|
|
|
|
|
|
# FlexRAN Base Station applications
|
|
|
|
|
|
Base station applications are FlexRAN applications that are executed directly
|
|
|
on the base station instead of within the controller (cf. Figure below). This
|
|
|
allows to extend base station behavior and lower overhead within the
|
|
|
controller. Apart from using a sample app, we will show this through an
|
|
|
application that manages the UE-slice application using a regex, without any
|
|
|
intervention of the controller. The applications are compiled within OAI and
|
|
|
then uploaded to a "NetStore" called Store application. Then, they can be
|
|
|
deployed from the store in the base station, configured, and released, all
|
|
|
using the north-bound interface of the controller.
|
|
|
|
|
|
![FlexRAN Architecture with base station-local apps](fig/flexran-arch.png)
|
|
|
|
|
|
# Compile an application and upload it to the NetStore
|
|
|
|
|
|
## Compiling FlexRAN base station applications
|
|
|
|
|
|
Before you can use an app, you need to compile it from within the OAI build
|
|
|
directory:
|
|
|
```bash
|
|
|
$ cd cmake_targets/ran_build/build/
|
|
|
$ make flapp_all
|
|
|
```
|
|
|
This will compile all *FL*exran *APP*lications. Below we will use two
|
|
|
applications, `sample` and `imsi`, which you can compile independently like so:
|
|
|
```bash
|
|
|
$ make flapp_sample
|
|
|
$ make flapp_imsi
|
|
|
```
|
|
|
|
|
|
## Uploading applications to the NetStore
|
|
|
|
|
|
For guidance on how to run and use the NetStore, please refer to the [dedicated
|
|
|
section](tutorials/store#application-netstorefile_store_app).
|
|
|
|
|
|
Upload the two apps like so:
|
|
|
```bash
|
|
|
$ curl -XPOST localhost:8080/push/sample --data-binary @libflapp_sample.so
|
|
|
$ curl -XPOST localhost:8080/push/imsi --data-binary @libflapp_imsi.so
|
|
|
```
|
|
|
|
|
|
# Deployment of an application
|
|
|
|
|
|
*Before starting the RAN, verify that the configured directory for the FlexRAN
|
|
|
cache in the OAI configuration file (`FLEXRAN_CACHE`) exists!*
|
|
|
|
|
|
*Also note that as of tag v2.4, FlexRAN expects the NetStore app to run on
|
|
|
localhost port 8080, which does not correspond to the default configuration of
|
|
|
the NetStore application!*
|
|
|
|
|
|
Start CNs, FlexRAN, and the RAN as normal (no UE connection is required, and
|
|
|
everything works in the [L2 simulator](l2-sim)). To start an application, you
|
|
|
issue the following call, which will cause the FlexRAN-internal NetStore
|
|
|
application to look for an app with name `sample` in the NetStore, and
|
|
|
deploying it on the base station if it is available:
|
|
|
```bash
|
|
|
$ curl localhost:9999/netstore/app/sample
|
|
|
```
|
|
|
You might proceed to configure the running application afterwards.
|
|
|
|
|
|
To release an application, run
|
|
|
```bash
|
|
|
$ curl -XDELETE localhost:9999/netstore/app/sample
|
|
|
```
|
|
|
|
|
|
# Custom configuration per application
|
|
|
|
|
|
The configuration is specific to every application. Since they are deployed
|
|
|
dynamically, FlexRAN cannot expose a specific north-bound interface unless a
|
|
|
matching FlexRAN controller app is loaded, exposing specific north-bound
|
|
|
interfaces. To cater for configuration of every application, FlexRAN exposes a
|
|
|
generic [BS app configuration
|
|
|
end-point](https://mosaic5g.io/apidocs/flexran/#api-NetStore-ReconfigureApp)
|
|
|
that can be used to configure every application. The syntax always follows
|
|
|
this schema:
|
|
|
```json
|
|
|
{
|
|
|
"params" : {
|
|
|
"key1": { "str": "eins" },
|
|
|
"key2": { "integer": 1 },
|
|
|
"key3": { "floating": 1.123 },
|
|
|
"key4": { "boolean": boolean }
|
|
|
}
|
|
|
}
|
|
|
```
|
|
|
`params` is fixed, and the object it references is a key-value dictionary,
|
|
|
i.e., the keys are completely free but should be disjoint, and the values are
|
|
|
objects of either type string (`str`), `integer`, a float (`floating`), or a
|
|
|
bool (`boolean`).
|
|
|
|
|
|
## Sample
|
|
|
|
|
|
## IMSI-slice association
|
|
|
|
|
|
# Reproducing the MobiCom demo
|
|
|
|
|
|
## Auto-loading new scheduling algorithms
|
|
|
|
|
|
New scheduling algorithms might be loaded dynamically into the base station
|
|
|
user plane. Note that this only applies to the default scheduler, and the
|
|
|
fairRR scheduler is not supported.
|
|
|
|
|
|
First, compile a slice algorithm as outlined below, and upload it to the
|
|
|
NetStore. In order to load it, simply issue the [slice
|
|
|
reconfiguration call](https://mosaic5g.io/apidocs/flexran/#api-SliceConfiguration-ApplySliceConfiguration):
|
|
|
the base station won't find it locally, and ask the controller for it. It will
|
|
|
then search in the NetStore for an object with the name as for the scheduling
|
|
|
algorithm (e.g., `proportional_fair_wbcqi_dl`), and send it back if found. The
|
|
|
user plane then loads it.
|
|
|
|
|
|
The default scheduler has three different user scheduling algorithms:
|
|
|
round-robin, proportional-fair, and maximum throughput. All are compiled in by
|
|
|
default and can be changed dynamically. To demonstrate how to upload and switch
|
|
|
the scheduler from within the NetStore, apply [this patch](pf-mt.patch), then
|
|
|
compile and upload with
|
|
|
```bash
|
|
|
$ make maximum_throughput_wbcqi_dl proportional_fair_wbcqi_dl
|
|
|
$ curl -XPOST localhost:8080/push/maximum_throughput_wbcqi_dl --data-binary @libmaximum_throughput_wbcqi_dl.so
|
|
|
$ curl -XPOST localhost:8080/push/proportional_fair_wbcqi_dl --data-binary @libproportional_fair_wbcqi_dl.so
|
|
|
```
|
|
|
|
|
|
## `burst_analysis` and low-latency slice scheduling
|
|
|
|
|
|
The start-up of `burst_analysis` happens similarly to what is shown
|
|
|
above. Once active, it will monitor UEs in slice 3, and change the slice
|
|
|
algorithm to `SCN19` if it was `NVS` before, which can significantly reduce
|
|
|
round-trip-time.
|
|
|
|
|
|
At the time of writing this wiki, the code for the `burst_analysis` application
|
|
|
as well as the [NVS](https://ieeexplore.ieee.org/document/6117098) and
|
|
|
[SCN19](https://ieeexplore.ieee.org/document/9013258) slice algorithms is not
|
|
|
publicly available. We will update this page once we have merged the code. |