* Reads as many parameters as described in params, they must all be in the same configuration file section
* Calls the `config_<config source>_get` function
* Calls the `config_process_cmdline` function
*`params` points to an array of `paramdef_t` structures which describes the parameters to be read, possibly including a pointer to a checking function. The following bits can possibly be set in the `paramflags` mask before calling
-`PARAMFLAG_MANDATORY`: -1 is returned if the parameter is not explicitly defined in the config source.
-`PARAMFLAG_DISABLECMDLINE`: parameter cannot be modified via the command line
-`PARAMFLAG_DONOTREAD`: ignore the parameter, can be used at run-time, to alter a pre-defined `paramdef_t` array which is used in several `config_get` or/and `config_getlist` calls.
-`PARAMFLAG_NOFREE`: do not free the memory possibly allocated by the config module to store the value of the parameter. Default behavior is for the config module to free the memory it has allocated when the `config_end` function is called.
-`PARAMFLAG_BOOL`: Only relevant for integer types. tell the config module that when processing the command line, the corresponding option can be specified without any arggument and that in this case it must set the value to 1.
*`params` is also used as an output parameter, `< XXX >ptr >` field is used by the config module to store the value it has read. The following bits can possibly be set in the `paramflags` mask after the call:
-`PARAMFLAG_MALLOCINCONFIG`: memory has been allocated for the ` < XXX >ptr > ` field
-`PARAMFLAG_PARAMSET`: parameter has been found in the config source, it is not set to default value.
-`PARAMFLAG_PARAMSET`: parameter has been set to its default value
*`params` points to an array of `paramdef_t` structures which describes the parameters to be read, possibly including a pointer to a checking function.The `paramflags` bit mask can be used to modify how a specific parameter is processed and the same mask is also used by the configuration module to return information about how the parameter has been processed. Bits definitions are described in the [`paramdef_t` structure description](./struct.md)
*`numparams` is the number of entries in the params array
*`prefix` is a character string to be appended to the parameters name, it defines the parameters position in the configuration file hierarchy (the section name in libconfig terminology).
* The returned value is the number of parameters which have been assigned a value or -1 if a severe error occured
...
...
@@ -44,6 +40,9 @@ int config_libconfig_getlist(paramlist_def_t *ParamList, paramdef_t *params, int
*`ParamList` points to a structure, where `paramarray` field points to an array of `paramdef_t` structure, allocated by the function. It is used to return the values of the parameters.
* The returned value is the number of occurrences in the list or -1 in case of severe error
## utility functions and macros
The configuration module also defines APIs to access the `paramdef_t` and `configmodule_interface_t` fields. They are listed in the configuration module [include file `common/config/config_userapi.h`](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_userapi.h)
[Configuration module developer main page](../../config/devusage.md)
| `optname` | parameter name, as used when looking for it in the config source, 63 bytes max (64 with trailing \0) | I |
| `helstr` | pointer to a C string printed when using --help on the command line | I |
| `paramflags` | bit mask, used to modify how the parameter is processed, or to return to the API caller how the parameter has been set, see list in the next table | IO |
| `strptr``strlistptr``u8ptr``i8ptr``u16ptr``i16ptr``uptr``iptr``u64ptr``i64ptr``dblptr``voidptr` | a pointer to a variable where the parameter value(s) will be returned. This field is an anonymous union, the supported pointer types have been built to avoid type mismatch warnings at compile time. | O |
| `defstrval``defstrlistval``defuintval``defintval``defint64val``defintarrayval``defdblval` | this field is an anonymous union, it can be used to define the default value for the parameter. It is ignored if `PARAMFLAG_MANDATORY` is set in the `paramflags` field.| I |
| `type` | Supported parameter types are defined as integer macros. Supported simple types are `TYPE_STRING`, parameter value is returned in `strptr` field, `TYPE_INT8``TYPE_UINT8``TYPE_INT16``TYPE_UINT16``TYPE_INT32``TYPE_UINT32``TYPE_INT64``TYPE_UINT64`, parameter value is returned in the corresponding uXptr or iXptr, `TYPE_MASK`, value is returned in `u32ptr`, `TYPE_DOUBLE` value is returned in `dblptr`, `TYPE_IPV4ADDR` value is returned in binary, network bytes order in `u32ptr` field. `TYPE_STRINGLIST`, `TYPE_INTARRAY` and `TYPE_UINTARRAY` are multiple values types. Multiple values are returned in respectively, `strlistptr`, `iptr` and `uptr` fields which then point to arrays. The `numelt` field gives the number of item in the array. | I |
...
...
@@ -12,6 +13,22 @@ It is defined in include file [ common/config/config_paramdesc.h ](https://gitla
| `chkPptr` | possible pointer to the structure containing the info used to check parameter values | I |
| `processedvalue` | When `chkPptr` is not `ǸULL`, is used to return a value, computed from the original parameter, as read from the configuration source. | O |
| `PARAMFLAG_MANDATORY` | parameter is mandatory, comfiguration module will stop the process if it is not specified. Default value is ignored | I |
| `PARAMFLAG_DISABLECMDLINE` | parameter cannot be specified on the command line | I |
| `PARAMFLAG_DONOTREAD` | ignore the parameter, usefull when a parameter group is used in different context | I |
| `PARAMFLAG_NOFREE` | The end_configmodule API won't free the memory which has been possibly allocated to store the value of the parameter.| I |
| `PARAMFLAG_BOOL` | Parameter is a boolean, it can be specified without a value to set it to true | I |
| `PARAMFLAG_CMDLINE_NOPREFIXENABLED` | parameter can be specified without the prefix on the command line. Must be used with care, carefuly checking unicity, especially for short parameter names | I |
| `PARAMFLAG_MALLOCINCONFIG` | Memory for the parameter value has been allocated by the configuration module |O |
| `PARAMFLAG_PARAMSET` | Parameter value has been explicitely set, as the parameter was specified either on the command line or the config source | O |
| `PARAMFLAG_PARAMSETDEF` | Parameter value has been set to it's default | O |
# `paramlist_def_t`structure
It is defined in include file [ common/config/config_paramdesc.h ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_paramdesc.h#L160).
It is used as an argument to `config_getlist` calls, to get values of multiple occurrences of group of parameters.
- The `-I` option is to install pre-requisites, you only need it the first time you build the softmodem or when some oai dependencies have changed.
- The `-w` option is to select the radio head support you want to include in your build. Radio head support is provided via a shared library, which is called the "oai device" The build script creates a soft link from `liboai_device.so` to the true device which will be used at run-time (here the USRP one,`liboai_usrpdevif.so` . USRP is the only hardware tested today in the Continuous Integration process.
- The `-w` option is to select the radio head support you want to include in your build. Radio head support is provided via a shared library, which is called the "oai device" The build script creates a soft link from `liboai_device.so` to the true device which will be used at run-time (here the USRP one,`liboai_usrpdevif.so` . USRP is the only hardware tested today in the Continuous Integration process. The RF simulator[RF simulator](../targets/ARCH/rfsimulator/README.md) is implemented as a specific device replacing RF hardware, it can be build using `-w SIMU` option.
-`--eNB` is to build the `lte-softmodem` executable and all required shared libraries
-`--UE` is to build the `lte-uesoftmodem` executable and all required shared libraries
cancel_ra_proc(enb_mod_idP,CC_idP,frameP,current_rnti);// TODO: Currently we don't support retransmission of Msg3 ( If in error Cancel RA procedure and reattach)
This is an RF simulator that allows to test OAI without an RF board.
#General
This is an RF simulator that allows to test OAI without an RF board. It replaces an actual RF board driver.
It replaces an actual RF board driver.
As much as possible, it works like an RF board, but not in real-time: It can run faster than real-time if there is enough CPU, or slower (it is CPU-bound instead of real-time RF sampling-bound).
As much as possible, it works like an RF board, but not in realtime: It can run faster than realtime if there is enough CPU or slower (it is CPU bound instead of real time RF sampling bound)
# build
#build
## From [build_oai](../../../doc/BUILD.md) script
The RF simulator is implemented as an OAI device and always built when you build the OAI eNB or the OAI UE.
## From build_oai
You can build it the same way, and together with actual RF driver
Using the `-w SIMU` option it is possible to just re-build the RF simulator device.
Example:
```bash
./build_oai --ue-nas-use-tun--UE--eNB-w SIMU
./build_oai --UE--eNB
Will compile UE
Will compile eNB
CMAKE_CMD=cmake ..
No local radio head and no transport protocol selected
No radio head has been selected (HW set to None)
No transport protocol has been selected (TP set to None)
RF HW set to None
Flags for Deadline scheduler: False
......................
......................
Compiling rfsimulator
Log file for compilation has been written to: /usr/local/oai/rfsimu_config/openairinterface5g/cmake_targets/log/rfsimulator.Rel15.txt
rfsimulator compiled
......................
......................
```
It is also possible to build actual RF and use choose on each run:
Will build both the eNB (lte-softmodem) and the UE (lte-uesoftmodem)
We recommend using the option --ue-nas-use-tun that is much simpler to use than the OAI kernel driver.
## Add the rfsimulator after initial build
After any regular build, you can compile the driver
After any regular build you can compile the device from the build directory:
```bash
cd <the_compilation_dir_from_build_oai_script>/build
cd <path to oai sources>/openairinterface5g/cmake_targets/ran_build/build
make rfsimulator
```
Then, you can use it freely
This is equivalent to using `-w SIMU` when running the `build_oai` script.
# Usage
Setting the env variable RFSIMULATOR enables the RF board simulator. It should be set to "server" in the eNB or gNB.
To use the RF simulator add the `--rfsim` option to the command line. By default the RF simulator device will try to connect to host 127.0.0.1, port 4043, which is usually the behavior for the UE.
The RF simulator is using the configuration module, and its parameters are defined in a specific section called "rfsimulator".
| serveraddr | ip address to connect to, or "enb" to behave as a tcp server | 127.0.0.1 |
| serverport | port number to connect to or to listen on (eNB, which behaves as a tcp server) | 4043 |
| options | list of comma separated run-time options, two are supported: `chanmod` to enable channel modeling and `saviq` to write transmitted iqs to a file | all options disabled |
| modelname | Name of the channel model to apply on received iqs when the `chanmod` option is enabled | AWGN |
| IQfile | Path to the file to be used to store iqs, when the `saviq` option is enabled | /tmp/rfsimulator.iqs |
Setting the env variable RFSIMULATOR can be used instead of using the serveraddr parameter; it is to preserve compatibility with previous version.
## 4G case
For the UE, it should be set to the IP address of the eNB
example:
For the UE, it should be set to the IP address of the eNB. For example:
Of course, set the gNB machine IP address if the UE and the gNB are not on the same machine.
In UE, you can add "-d" to get the softscope
In the UE, you can add `-d` option to get the softscope.
### Store and replay
You can store emitted I/Q samples:
If you set the environment variable: saveIQfile to a file name
The simulator will write all IQ samples into this file
You can store emitted I/Q samples. If you set the option `saviq`, the simulator will write all the I/Q samples into this file. Then, you can replay with the executable `replay_node`.
Then, you can replay with the executable "replay_node"
First compile it, as the other binaries
```
First compile it like other binaries:
```bash
make replay_node
```
You can use this binary as I/Q data source to feed whatever UE or NB with recorded I/Q samples.
You can use this binary as I/Q data source to feed whatever UE or gNB with recorded I/Q samples.
The file format is successive blocks of a header followed by the I/Q array.
If you have existing stored I/Q, you can adpat the tool "replay_node" to convert your format to the rfsimulator format.
The file format is successive blocks of a header followed by the I/Q array. If you have existing stored I/Q, you can adapt the tool `replay_node` to convert your format to the rfsimulator format.
The format intend to be compatible with the OAI store/replay feature on USRP
The format intends to be compatible with the OAI store/replay feature on USRP.
### Channel simulation
The RF channel simulator is called.
In current version all channel paramters are hard coded in the call to:
When the `chanmod` option is enabled, the RF channel simulator is called.
In the current version all channel parameters are set depending on the model name via a call to:
```bash
new_channel_desc_scm(bridge->tx_num_channels,
bridge->rx_num_channels,
AWGN,
<model name>,
bridge->sample_rate,
bridge->tx_bw,
0.0, // forgetting_factor
0, // maybe used for TA
0); // path_loss in dB
0, // maybe used for TA
0);// path_loss in dB
```
Only the input noise can be changed on command line with the `-s` parameter.
Only the input noise can be changed on command line with -s parameter.
With path loss = 0 set "-s 5" to see a little noise.
With path loss = 0 set `-s 5` to see a little noise. `-s` is a shortcut to `channelmod.s`. It is expected to enhance the channel modelization flexibility by the addition of more parameters in the channelmod section.
## Caveats
Still issues in power control: txgain, rxgain are not used
# Caveats
Still issues in power control: txgain, rxgain are not used.
#define CONFIG_HLP_MSLOTS "Skip the missed slots/subframes \n"
#define CONFIG_HLP_ULMCS "Set the maximum uplink MCS\n"
#define CONFIG_HLP_TDD "Set hardware to TDD mode (default: FDD). Used only with -U (otherwise set in config file).\n"
#define CONFIG_HLP_SNR "Set average SNR in dB (for --siml1 option)\n"
#define CONFIG_HLP_UE "Set the lte softmodem as a UE\n"
#define CONFIG_HLP_TQFS "Apply three-quarter of sampling frequency, 23.04 Msps to reduce the data rate on USB/PCIe transfers (only valid for 20 MHz)\n"
