Commit c1f7678e authored by Raphael Defosseux's avatar Raphael Defosseux

Merge branch 'develop_integration_2018_w46' into 'develop'

Develop integration 2018 w46

See merge request oai/openairinterface5g!445
parents d00f80b5 18a099fa
# OAI configuration module
The configuration module provides an api that other oai components can use to get parameters at init time. It defines a parameter structure, used to describe parameters attributes (for example name and type). The same structure includes a pointer to the variable where the configuration module writes the parameter value, at run time, when calling config_get or config_getlist functions. For each parameter a function to check the value can be specified and pre-defined functions are provided for some common parameter validations (integer in a range or in a list, string in a list). The module also include a mechanism to check that no unknown options have been entered on the command line
## Documentation
* [runtime usage](config/rtusage.md)
* [developer usage](config/devusage.md)
* [module architecture](config/arch.md)
[oai Wikis home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
# config module source files
![configmodule_srcdir](/uploads/fdc3e96011fd5592440900dfa05b4701/configmodule_srcdir.png)
# config module components
![configmodule_components](/uploads/54f8a3953d5ee53717cd9a3b71f85c68/configmodule_components.png)
[Configuration module home](../config.md)
\ No newline at end of file
The configuration module objectives are
1. Allow easy parameters management in oai, helping the development of a flexible, modularized and fully configurable softmodem.
1. Use a common configuration API in all oai modules
1. Allow development of alternative configuration sources without modifying the oai code. Today the only delivered configuration source is the libconfig format configuration file.
As a developer you may need to look at these sections:
* [add parameters in an existing section](devusage/addaparam.md)
* [add a parameter set, in a new section](devusage/addparamset.md)
* [configuration module API](devusage/api.md)
* [configuration module public structures](devusage/struct.md)
Whatever your need is, configuration module usage examples can be found in oai sources:
* complex example, using all the configuration module functionalities, including parameter checking:
[NB-IoT configuration code](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair2/ENB_APP/NB_IoT_config.c) and [NB-IoT configuration include file](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair2/ENB_APP/NB_IoT_paramdef.h)
* very simple example, just reading a parameter set corresponding to a dedicated section: the telnetsrv_autoinit function in [common/utils/telnetsrv/telnetsrv.c, around line 726](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/telnetsrv/telnetsrv.c#L726)
* an example with run-time definition of parameters, in the logging sub-system: the log_getconfig function at the top of [openair2/UTIL/LOG/log.c](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair2/UTIL/LOG/log.c)
[Configuration module home](../config.md)
To add a new parameter in an existing section you insert an item in a `paramdef_t` array, which describes the parameters to be read in the existing `config_get` call. You also need to increment the numparams argument.
existing code:
```c
unsigned int varopt1;
paramdef_t someoptions[] = {
/*---------------------------------------------------------------------------------*/
/* configuration parameters for some module */
/* optname helpstr paramflags XXXptr defXXXval type numelt */
/*---------------------------------------------------------------------------------*/
{"opt1", "<help opt1>", 0, uptr:&varopt1, defuintval:0, TYPE_UINT, 0 },
};
config_get( someoptions,sizeof(someoptions)/sizeof(paramdef_t),"somesection");
```
new code:
```c
unsigned int varopt1;
/* varopt2 will be allocated by the config module and free at end_configmodule call
except if PARAMFLAG_NOFREE bit is set in paramflags field*/
char *varopt2;
paramdef_t someoptions[] = {
/*---------------------------------------------------------------------------------*/
/* configuration parameters for some module */
/* optname helpstr paramflags XXXptr defXXXval type numelt */
/*---------------------------------------------------------------------------------*/
{"opt1", "<help opt1>", 0, uptr:&varopt1, defuintval:0,TYPE_UINT, 0 },
{"opt2", "<help opt2>", 0, strptr:&varopt2,defstrval:"",TYPE_STRING,0 },
};
config_get( someoptions,sizeof(someoptions)/sizeof(paramdef_t),"somesection");
```
The corresponding configuration file may now include opt2 parameter in the somesection section:
```c
somesection =
{
opt1 = 3;
opt2 = "abcd";
};
```
In these examples the variables used to retrieve the parameters values are pointed by the `uptr` or `strptr` fields of the `paramdef_t` structure. After the `config_get` call `varopt1` and `varopt2` have been set to the value specified in the config file. It is also possible to specify a `NULL` value to the `< XXX >ptr` fields, which are then allocated by the config module and possibly free when calling `config_end()`, if the `PARAMFLAG_NOFREE` bit has not been set in the `paramflags` field.
The configuration module provides a mechanism to check the parameter value read from the configuration source. The following functions are implemented:
1. Check an integer parameter against a list of authorized values
1. Check an integer parameter against a list of authorized values and set the parameter to a new value
1. Check an integer parameter against a range
1. Check a C string parameter against a list of authorized values
1. Check a C string parameter against a list of authorized values and set the parameter to a new integer value
A `checkedparam_t` structure array provides the parameter verification procedures:
```c
/*
definition of the verification to be done on param opt1 and opt2.
opt1 is an integer option we must be set to 0,2,3,4 or 7 in the
config source.
if opt1 is set to 0 in the config file, it will be set to 1, etc
opt2 is C string option with the authorize values "zero","oneThird","twoThird","one"
*/
#define OPT1_OKVALUES {0,2,3,4,7}
#define OPT1_NEWVALUES {1,1,0,6,9}
#define OPT2_OKVALUES {"zero","oneThird","twoThird","one"}
#define OPT_CHECK_DESC { \
{ .s1a= { config_check_modify_integer, OPT1_OKVALUE, OPT1_NEWVALUES ,5 }}, \
{ .s3= { config_check_strval, OPT2_OKVALUES,4 }}, \
}
checkedparam_t checkopt[] = OPT_CHECK_DESC;
.....
/* assign the verification procedures to the parameters definitions */
for(int i=0 ; i < sizeof(someoptions)/sizeof(paramdesc_t) ; i ++) {
someoptions[i].chkPptr = &(checkopt[i]);
}
....
```
When you need a specific verification algorithm, you can provide your own verification function and use it in place of the available ones, in the `checkedparam_t` union. If no existing structure definition match your need, you can enhance the configuration module. You then have to add a new verification function in https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_userapi.c and add a new structure definition in the `checkedparam_t` type defined in https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_paramdesc.h
[Configuration module developer main page](../../config/devusage.md)
[Configuration module home](../../config.md)
The configuration module maps a configuration file section to a `paramdef_t` structure array. One `config_get` call can be used to return the values of all the parameters described in the `paramdef_t` array.
Retrieving a single occurence of a parameter set ( a group in the libconfig terminology) is just a two steps task:
1. describe the parameters in a `paramdef_t` array
1. call the `config_get` function
[config_get example](../../config/devusage/addaparam.md)
In oai some parameters set may be instantiated a variable number of occurrences. In a configuration file this is mapped to lists of group of parameters, with this syntax:
```c
NB-IoT_MACRLCs =
/* start list element 1 */
(
/* start a group of parameters */
{
num_cc = 2;
.....
remote_s_portd = 55001;
}
),
/* start list element 2 */
(
/* start a group of parameters */
{
num_cc = 1;
......
remote_s_portd = 65001;
}
);
```
The configuration module provides the `config_getlist` call to support lists of group of parameters. Below is a commented code example, using the config_getlist call.
```c
/* name of section containing the list */
#define NBIOT_MACRLCLIST_CONFIG_STRING "NB-IoT_MACRLCs"
/*
The following macro define the parameters names, as used in the
configuration file
*/
#define CONFIG_STRING_MACRLC_CC "num_cc"
.....
#define CONFIG_MACRLC_S_PORTD "remote_s_portd"
/*
now define a macro which will be used to initialize the NbIoT_MacRLC_Params
variable. NbIoT_MacRLC_Params is an array of paramdef_t structure, each item
describing a parameter. When using the config_getlist call you must let the config
module allocate the memory for the parameters values.
*/
/*------------------------------------------------------------------------------------------------------------*/
/* optname helpstr paramflags XXXptr defXXXval type numelt */
/*------------------------------------------------------------------------------------------------------------*/
#define MACRLCPARAMS_DESC { \
{CONFIG_STRING_MACRLC_CC, NULL, 0, uptr:NULL, defintval:1, TYPE_UINT, 0}, \
............. \
{CONFIG_MACRLC_S_PORTD, NULL, 0, uptr:NULL, defintval:50021, TYPE_UINT, 0}, \
}
/*
the following macros define the indexes used to access the NbIoT_MacRLC_Params array
items. They must be maintained consistent with the previous MACRLCPARAMS_DESC macro
which is used to initialize the NbIoT_MacRLC_Params variable
*/
#define MACRLC_CC_IDX 0
.........
#define MACRLC_REMOTE_S_PORTD_IDX 16
void RCconfig_NbIoTmacrlc(void) {
/*
define and initialize the array of paramdef_t structures describing the groups of
parameters we want to read. It will be passed as the second argument of the
config_getlist call, which will use it as an input only argument.
*/
paramdef_t NbIoT_MacRLC_Params[] = MACRLCPARAMS_DESC;
/*
now define and initialize a paramlist_def_t structure which will be passed
to the config_getlist call. The first field is the only one to be initialized
it contains the name of the section to be read.
that section contains the list of group of parameters.
The two other fields are output parameters used to return respectively
a pointer to a two dimensional array of paramdef_t structures pointers, and the
number of items in the list of groups (size of first dimension, the second one
being the number of parameters in each group.
*/
paramlist_def_t NbIoT_MacRLC_ParamList = {NBIOT_MACRLCLIST_CONFIG_STRING,NULL,0};
/*
the config_getlist will allocate the second field of the paramlist_def_t structure, a
two dimensional array of paramdef_t pointers. In each param_def item it will allocate
the value pointer and set the value to what it will get from the config source. The
numelt field of the paramlist_def_t structure will be set to the number of groups of
parameters in the list.
in this example the last argument of config_getlist is unused, it may contain a
character string, used as a prefix for the section name. It has to be specified when the
list to be read is under another section.
*/
config_getlist( &NbIoT_MacRLC_ParamList,NbIoT_MacRLC_Params,
sizeof(NbIoT_MacRLC_Params)/sizeof(paramdef_t),
NULL);
/*
start a loop in the nuber of groups in the list, the numelt field of the
paramlist_def_t structure has been set in the config_getlist call
*/
for (j=0 ; j<NbIoT_MacRLC_ParamList.numelt ; j++) {
..........
/* access the MACRLC_REMOTE_S_PORTD parameter in the j ieme group of the list */
RC.nb_iot_mac[j]->eth_params_s.remote_portd =
*(NbIoT_MacRLC_ParamList.paramarray[j][MACRLC_REMOTE_S_PORTD_IDX].iptr);
............
} // MacRLC_ParamList.numelt > 0
}
```
[Configuration module developer main page](../../config/devusage.md)
[Configuration module home](../../config.md)
```c
configmodule_interface_t *load_configmodule(int argc, char **argv)
```
* Parses the command line options, looking for the –O argument
* Loads the `libparams_<configsource>.so` (today `libparams_libconfig.so`) shared library
* Looks for `config_<config source>_init` symbol and calls it , passing it an array of string corresponding to the « : » separated strings used in the –O option
* Looks for `config_<config source>_get`, `config_<config source>_getlist` and `config_<config source>_end` symbols which are the three functions a configuration library should implement. Get and getlist are mandatory, end is optional.
* Stores all the necessary information in a `configmodule_interface_t structure`, which is of no use for caller as long as we only use one configuration source.
```c
void End_configmodule(void)
```
* Free memory which has been allocated by the configuration module since its initialization.
* Possibly calls the `config_<config source>_end` function
```c
int config_get(paramdef_t *params,int numparams, char *prefix)
```
* 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
* `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
```c
int config_libconfig_getlist(paramlist_def_t *ParamList, paramdef_t *params, int numparams, char *prefix)
```
* Reads multiple occurrences of a parameters array
* Calls the `config_<config source>_get` function for each list occurrence
* `params` points to an array of `paramdef_t` structures which describes the parameters in each occurrence of the list
* `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
[Configuration module developer main page](../../config/devusage.md)
[Configuration module home](../../config.md)
# `paramdef_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#L103). This structure is used by developers to describe parameters and by the configuration module to return parameters value. A pointer to a `paramdef_t` array is passed to `config_get` and `config_getlist` calls to instruct the configuration module what parameters it should read.
| Fields | Description | I/O |
|:-----------|:------------------------------------------------------------------|----:|
| `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 |
| `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 |
| `numelt` | For `TYPE_STRING` where `strptr` points to a preallocated string, this field must contain the size in bytes of the available memory. For all multiple values types, this field contains the number of values in the value field.| I/O |
| `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 |
# `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.
| Fields | Description | I/O |
|:-----------|:------------------------------------------------------------------|----:|
| `listname` | Name of the section containing the list, 63 bytes max (64 with trailing \0). It is used to prefix each paramater name when looking for its value. In the libconfig syntax, the parameter name full path build by the configuration module is: listname.[occurence index].optname. | I |
| `paramarray` | Pointer to an array of `ǹumelt` `paramdef_t` pointers. It is allocated by the configuration module and is used to return the parameters values. All input fields of each `paramdef_t` occurence are a copy of the `paramdef_t` argument passed to the `config_getlist` call. | O |
| `numelt` | Number of items in the `paramarray` field | O |
# `checkedparam_t` union
It is defined in include file [ common/config/config_paramdesc.h ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_paramdesc.h#L62).
This union of structures is used to provide a parameter checking mechanism. Each `paramdef_t` instance may include a pointer to a `checkedparam_t`structure which is then used by the configuration module to check the value it got from the config source.
Each structure in the union provides one parameter verification method, which returns `-1` when the verification fails. Currently the following structures are defined in the `checkedparam_t` union:
| structure name | Description |
|:-----------|:------------------------------------------------------------------|----:|
| `s1` | check an integer against a list of authorized values |
| `s1a` | check an integer against a list of authorized values and set the parameter value to another integer depending on the read value|
| `s2` | check an integer against an authorized range, defined by its min and max value|
| `s3` | check a string against a list of authorized values |
| `s3a` | check a string against a list of authorized values and set the parameter value to an integer depending on the read value|
| `s4` | generic structure, to be used to provide a specific, not defined in the configuration module, verification algorithm |
each of these structures provide the required fields to perform the specified parameter check. The first field is a pointer to a function, taking one argument, the `paramdef_t` structure describing the parameter to be checked. This function is called by the configuration module, in the `config_get` call , after the parameter value has been set, it then uses the other fields of the structure to perform the check.
The configuration module provides an implementation of the functions to be used to check parameters, qs described below.
## `s1` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f1` | pointer to the checking function. Initialize to `config_check_intval` to use the config module implementation |
| `okintval` | array of `CONFIG_MAX_NUMCHECKVAL` integers containing the authorized values |
| `num_okintval` | number of used values in `okintval` |
## `s1a` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f1a` | pointer to the checking function. Initialize to `config_check_modify_integer` to use the config module implementation |
| `okintval` | array of `CONFIG_MAX_NUMCHECKVAL` integers containing the authorized values |
| `setintval` | array of `CONFIG_MAX_NUMCHECKVAL` integers containing the values to be used for the parameter. The configuration module implementation set the parameter value to `setintval[i]` when the configured value is `okintval[i]` |
| `num_okintval` | number of used values in `okintval` and `setintval` |
## `s2` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f2` | pointer to the checking function. Initialize to `config_check_intrange` to use the config module implementation |
| `okintrange` | array of 2 integers containing the min and max values for the parameter |
## `s3` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f3` | pointer to the checking function. Initialize to `config_check_strval` to use the config module implementation |
| `okstrval` | array of `CONFIG_MAX_NUMCHECKVAL` C string pointers containing the authorized values |
| `num_okstrval` | number of used values in `okstrtval` |
## `s3a` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f3a` | pointer to the checking function. Initialize to `config_checkstr_assign_integer` to use the config module implementation |
| `okstrval` | array of `CONFIG_MAX_NUMCHECKVAL` C string pointers containing the authorized values |
| `setintval` | array of `CONFIG_MAX_NUMCHECKVAL` integers containing the values to be used for the parameter. The configuration module implementation set the parameter value to `setintval[i]` when the configured value is `okstrval[i]` |
| `num_okstrval` | number of used values in `okintval` and `setintval` |
## `s4` and `s5` structures
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f4` or `f5` | pointer to the checking function. they are generic structures to be used when no existing structure provides the required parameter verification. `f4` takes one argument, the `paramdef_t` structure corresponding to the parameter to be checked (`int (*f4)(paramdef_t *param)`), `f5` taxes no argument (`void (*checkfunc)(void)`) |
[Configuration module developer main page](../../config/devusage.md)
[Configuration module home](../../config.md)
-O is the only mandatory command line option to start the eNodeb softmodem (lte-softmodem executable), it is used to specify the configuration source with the associated parameters:
```bash
$ ./lte-softmodem -O <configsource>:<parameter1>:<parameter2>:...
```
The configuration module can also be used without a configuration source, ie to only parse the command line. In this case the -O switch is optional. This mode is used in the ue-softmodem executable and by the phy_simulators executables (ulsim, dlsim)
Currently the available config sources are:
- **libconfig**: libconfig file. [libconfig file format](http://www.hyperrealm.com/libconfig/libconfig_manual.html#Configuration-Files) Parameter1 is the file path and parameter 2 can be used to specify the level of console messages printed by the configuration module.
```bash
$ ./lte-softmodem -O libconfig:<config>:dbgl<debuglevel>
```
- **cmdlineonly**: command line only, the default mode for lte-uesoftmodem and the phy simiulators. In this case -O may be used to specify the config module debug level.
The debug level is a mask:
* bit 1: print parameters values
* bit 2: print memory allocation/free performed by the config module
* bit 3: print command line processing messages
* bit 4: disable execution abort when parameters checking fails
As a oai user, you may have to use bit 1 (dbgl1) , to check your configuration and get the full name of a parameter you would like to modify on the command line. Other bits are for developers usage, (dbgl7 will print all debug messages).
```bash
$ ./lte-softmodem -O libconfig:<config>:dbgl1
```
```bash
$ ./lte-uesoftmodem -O cmdlineonly:dbgl1
```
For the lte-softmodem (the eNodeB) The config source parameter defaults to libconfig, preserving the initial -O option format. In this case you cannot specify the debug level.
```bash
$ ./lte-softmodem -O <config>
```
Configuration file parameters, except for the configuration file path, can be specified in a **config** section in the configuration file:
```
config:
{
debugflags = 1;
}
```
Configuration files examples can be found in the targets/PROJECTS/GENERIC-LTE-EPC/CONF sub-directory of the oai source tree. To minimize the number of configuration file to maintain, any parameter can also be specified on the command line. For example to modify the lte bandwidth to 20 MHz where the configuration file specifies 10MHz you can enter:
```bash
$ ./lte-softmodem -O <config> --eNBs.[0].component_carriers.[0].N_RB_DL 100
```
As specified earlier, use the dbgl1 debug level to get the full name of a parameter you would like to modify on the command line.
[Configuration module home](../config.md)
\ No newline at end of file
# OAI shared library loader
Shared libraries usage is modularization mechanism which provides the following advantages:
1. Prevents including in the main executable code which is not used in a given configuration
1. Provides flexibility, several implementation of a given functionality can be chosen at run-time, without any compilation step. For example you can build several devices (USRP, BladeFR, LimeSDR) and choose which one you want to use on the command line or via the configuration.
1. Makes code evolution easier: as soon as the shared library interface is clearly defined, you can work on the functionality implemented in a shared library while regularly updating the other components of the code. You can decide to develop your own version of a functionality, decide to deliver it or not, letting the user decide wwhat version he wants to use.
The main drawback is a performance cost at init time, when loading libraries.
## Documentation
* [runtime usage](loader/rtusage.md)
* [developer usage](loader/devusage.md)
* [module architecture](loader/arch.md)
[oai Wikis home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
\ No newline at end of file
# loader source files
The oai shared library loader is implemented in two source files, located in [common/utils](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils)
1. [load_module_shlib.c](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils/load_module_shlib.c) contains the loader implementation
1. [load_module_shlib.h](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils/load_module_shlib.h) is the loader include file containing both private and public data type definitions. It also contain API prototypes.
[loader home page](../loader.md)
\ No newline at end of file
The configuration module objectives are
1. Allow easy parameters management in oai, helping the development of a flexible, modularized and fully configurable softmodem.
1. Use a common configuration API in all oai modules
1. Allow development of alternative configuration sources without modifying the oai code. Today the only delivered configuration source is the libconfig format configuration file.
As a developer you may need to look at these sections:
* [loading a shared library](devusage/loading.md)
* [loader API](devusage/api.md)
* [loader public structures](devusage/struct.md)
Loader usage examples can be found in oai sources:
* device and transport initialization code: [function `load_lib` in *targets/ARCH/COMMON/__common_lib.c__* ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/targets/ARCH/COMMON/common_lib.c#L91)
* turbo encoder and decoder initialization: [function `load_codinglib`in *openair1/PHY/CODING/__coding_load.c__*](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair1/PHY/CODING/coding_load.c#L113)
[loader home page](../loader.md)
Loader API is defined in the [common/utils/load_module_shlib.h](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/load_module_shlib.h) include file.
```c
int load_module_shlib(char *modname,loader_shlibfunc_t *farray, int numf)
```
* possibly initializes the loader, if it has not been already initialized
* Formats the full shared library path, using the `modname` argument and the loader `shlibpath` and `shlibversion`configuration parameters.
* loads the shared library, using the dlopen system call
* looks for `< modname >_autoinit` symbol, using the `dlsym` system call and possibly call the corresponding function.
* looks for `< modname >_checkbuildver` symbol, using the `dlsym` system call and possibly calls the corresponding function. If the return value of this call is `-1`, program execution is stopped. It is the responsibility of the shared library developer to implement or not a `< modname >_checkbuildver` function and to decide if a version mismatch is a fatal condition. The `< modname >_checkbuildver` function must match the `checkverfunc_t` function type. The first argument is the main executable version, as set in the `PACKAGE_VERSION` macro defined in the [oai CMakeLists](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/cmake_targets/CMakeLists.txt#L218), around line 218. The second argument points to the shared library version which should be set by the `< modname >_checkbuildver` function.
* If the farray pointer is null, looks for `< modname >_getfarray` symbol, calls the corresponding function when the symbol is found. `< modname >_getfarray` takes one argument, a pointer to a `loader_shlibfunc_t` array, and returns the number of items in this array, as defined by the `getfarrayfunc_t` type. The `loader_shlibfunc_t` array returned by the shared library must be fully filled (both `fname` and `fptr` fields).
* looks for the `numf` function symbols listed in the `farray[i].fname` arguments and set the corresponding `farray[i].fptr`function pointers
```c
void * get_shlibmodule_fptr(char *modname, char *fname)
```
Returns a pointer to the symbol `fname`, defined in module `modname`, or `NULL` if the symbol is not found.
[loader home page](../../loader.md)
[loader developer home page](../devusage.md)
\ No newline at end of file
Implementing a shared library dynamic load using the oai loader is a two steps task:
1. define the `loader_shlibfunc_t` array, describing the list of externally available functions implemented in the library. This is the interface of the module.
1. Call the `load_module_shlib` function, passing it the previously defined array and the number of items in this array. The first argument to `load_module_shlib` is the name identifying the module, which is also used to format the corresponding library name, as described [here](loader/rtusage#shared-library-names)
After a successful `load__module_shlib` call, the function pointer of each `loader_shlibfunc_t` array item has been set and can be used to call the corresponding function.
Typical loader usage looks like:
```c
/* shared library loader include file */
#include "common/utils/load_module_shlib.h"
.............
/*
define and initialize the array, describing the list of functions
implemented in "mymodule"
*/
loader_shlibfunc_t mymodule_fdesc[2];
mymodule_fdesc[0].fname="mymodule_f1";
mymodule_fdesc[1].fname="mymodule_f2";
/*
load the library, it's name must be libmymod.so. Configuration can be
used to specify a specific path to look for libmymod.so. Configuration
can also specify a version, for example "V1", in this case the loader
will look for libmymodV1.so
*/
ret=load_module_shlib("mymod",mymodule_fdesc, sizeof(mymodule_fdesc)/sizeof(loader_shlibfunc_t));
if (ret < 0) {
fprintf(stderr,"Library couldn't be loaded\n");
} else {
/*
library has been loaded, we probably want to call some functions...
*/
ret=((funcf1_t)mymodule_fdesc[0].fptr)();
..................
/*
later and/or somewhere else in the code you may want to call function "mymodule_f2"
You can use the loader get_shlibmodule_fptr(char *modname, char *fname) function
to retrieve the pointer to that function
*/
funcf2_t *f2;
int ret;
int intarg1;
char *strarg;
........................
f2 = (funcf2_t)get_shlibmodule_fptr("mymodule", "mymodule_f2")
if (f2 != NULL) {
ret = f2(intarg1,strarg);
}
...............
```
When loading a shared library the loader looks for a symbol named `< module name > _autoinit` and, if it finds it, calls it. The `autoinit` function is called without any argument and the returned value, if any, is not tested.
[loader home page](../loader.md)
[loader developer home page](../../loader/devusage.md)
\ No newline at end of file
# `loader_shlibfunc_t`structure
It is defined in include file [ common/util/load_module_shlib.h ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/load_module_shlib.h#L38). This structure is used to list the symbols that should be searched by the loader when calling the `load_module_shlib` function.
| Fields | Description | I/O |
|:-----------|:------------------------------------------------------------------|----:|
| `fname` | symbol name, is passed to the [`dlsym`](http://man7.org/linux/man-pages/man3/dlsym.3.html) system call performed by the loader to get a pointer to the symbol | I |
| `fptr` | pointer to the symbol name, set by the loader. `fptr` is defined as a `int (*fptr)(void)` function type | O |
[loader home page](../../loader.md)
[loader developer home page](../devusage.md)
\ No newline at end of file
## shared library names
Shared library full names are built by the loader using the format:
> < *path* >/lib< *module name* >< *module version* >.so
1. the < *module name* > is defined at development time, it comes from the `modname` argument of the `load_module_shlib` call.
1. the < *module version* > and < *path* > optional parameters, are defined at run-time, depending on the configuration.
## loader parameters
The loader is using the [configuration module](../../../config/DOC/config.md), and defines global and per library parameters. Global parameters must be specified under the **loader** section and library specific parameters under a **loader.<*module name*>** section. Module specific parameters override the global parameters.
### Global loader parameters
| name | type | default | description |
|:---:|:---:|:---:|:----|
| `shlibpath` | `string of char` | `""` | directory path used to look for shared libraries, may be superseded by the library specific `shlibpath`.|
| `maxshlibs` | `integer` | 10 | Maximum number of shared libraries the loader can manage. |
### library specific loader parameters
| name | type | default | description |
|:---:|:---:|:---:|:----|
| `shlibpath` | `string of char` | `""` | directory path used to look for this shared library.|
| `shlibversion` | `string of char` | `""` | version to be used to load this shared library.|
### loader configuration examples
The following configuration file example just reproduce the default loader parameters:
```c
loader :
{
shlibpath = "./";
maxshlibs = 10;
liboai_device :
{
shlibpath = "./";
shlibversion = "";
}
};
```
If you want to load a device called *liboai_device_USRP.so* without writting a specific configuration, you can start the softmodem using the following command:
> ./lte-softmodem -O libconfig:/usr/local/oai/openairinterface5g/targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.nbiot.band7.tm1.50PRB.usrpb210.conf:dbgl5 --loader.oai_device.shlibversion _USRP
With this latest example, nn the softmodem logs, you can check that the right device library has been loaded:
```bash
[LIBCONFIG] loader.oai_device.shlibpath not found in /usr/local/oai/develop-nb-iot-merge/openairinterface5g/targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.nbiot.band7.tm1.50PRB.usrpb210.conf
[LIBCONFIG] loader.oai_device.shlibversion set to default value ""
[LIBCONFIG] loader.oai_device: 1/2 parameters successfully set, (1 to default value)
[CONFIG] shlibversion set to _USRP from command line
[CONFIG] loader.oai_device 1 options set from command line
```
[loader home page](../loader.md)
\ No newline at end of file
......@@ -14,10 +14,10 @@
#define DEFAULT_IP "127.0.0.1"
#define DEFAULT_PORT 9999
#define NO_PREAMBLE -1
#define DEFAULT_LIVE_IP "127.0.0.1"
#define DEFAULT_LIVE_PORT 2021
int no_sib = 0;
int no_mib = 0;
#define NO_PREAMBLE -1
typedef struct {
int socket;
......@@ -46,6 +46,15 @@ typedef struct {
int rar_frame;
int rar_subframe;
int rar_data;
/* config */
int no_mib;
int no_sib;
int max_mib;
int max_sib;
int live;
/* runtime vars */
int cur_mib;
int cur_sib;
} ev_data;
void trace(ev_data *d, int direction, int rnti_type, int rnti,
......@@ -104,7 +113,11 @@ void dl(void *_d, event e)
{
ev_data *d = _d;
if (e.e[d->dl_rnti].i == 0xffff && no_sib) return;
if (e.e[d->dl_rnti].i == 0xffff) {
if (d->no_sib) return;
if (d->max_sib && d->cur_sib == d->max_sib) return;
d->cur_sib++;
}
trace(d, DIRECTION_DOWNLINK,
e.e[d->dl_rnti].i != 0xffff ? C_RNTI : SI_RNTI, e.e[d->dl_rnti].i,
......@@ -117,7 +130,9 @@ void mib(void *_d, event e)
{
ev_data *d = _d;
if (no_mib) return;
if (d->no_mib) return;
if (d->max_mib && d->cur_mib == d->max_mib) return;
d->cur_mib++;
trace(d, DIRECTION_DOWNLINK, NO_RNTI, 0,
e.e[d->mib_frame].i, e.e[d->mib_subframe].i,
......@@ -269,9 +284,18 @@ void usage(void)
" -ip <IP address> send packets to this IP address (default %s)\n"
" -p <port> send packets to this port (default %d)\n"
" -no-mib do not report MIB\n"
" -no-sib do not report SIBs\n",
" -no-sib do not report SIBs\n"
" -max-mib <n> report at maximum n MIB\n"
" -max-sib <n> report at maximum n SIBs\n"
" -live run live\n"
" -live-ip <IP address> tracee's IP address (default %p)\n"
" -live-port <por> tracee's port (default %d)\n"
"-i and -live are mutually exclusive options. One of them must be provided\n"
"but not both.\n",
DEFAULT_IP,
DEFAULT_PORT
DEFAULT_PORT,
DEFAULT_LIVE_IP,
DEFAULT_LIVE_PORT
);
exit(1);
}
......@@ -288,6 +312,9 @@ int main(int n, char **v)
ev_data d;
char *ip = DEFAULT_IP;
int port = DEFAULT_PORT;
char *live_ip = DEFAULT_LIVE_IP;
int live_port = DEFAULT_LIVE_PORT;
int live = 0;
memset(&d, 0, sizeof(ev_data));
......@@ -299,8 +326,17 @@ int main(int n, char **v)
{ if (i > n-2) usage(); input_filename = v[++i]; continue; }
if (!strcmp(v[i], "-ip")) { if (i > n-2) usage(); ip = v[++i]; continue; }
if (!strcmp(v[i], "-p")) {if(i>n-2)usage(); port=atoi(v[++i]); continue; }
if (!strcmp(v[i], "-no-mib")) { no_mib = 1; continue; }
if (!strcmp(v[i], "-no-sib")) { no_sib = 1; continue; }
if (!strcmp(v[i], "-no-mib")) { d.no_mib = 1; continue; }
if (!strcmp(v[i], "-no-sib")) { d.no_sib = 1; continue; }
if (!strcmp(v[i], "-max-mib"))
{ if (i > n-2) usage(); d.max_mib = atoi(v[++i]); continue; }
if (!strcmp(v[i], "-max-sib"))
{ if (i > n-2) usage(); d.max_sib = atoi(v[++i]); continue; }
if (!strcmp(v[i], "-live")) { live = 1; continue; }
if (!strcmp(v[i], "-live-ip"))
{ if (i > n-2) usage(); live_ip = v[++i]; continue; }
if (!strcmp(v[i], "-live-port"))
{ if (i > n-2) usage(); live_port = atoi(v[++i]); continue; }
usage();
}
......@@ -309,19 +345,47 @@ int main(int n, char **v)
exit(1);
}
if (input_filename == NULL) {
printf("ERROR: provide an input file (-i)\n");
if (input_filename == NULL && live == 0) {
printf("ERROR: provide an input file (-i) or run live (-live)\n");
exit(1);
}
if (input_filename != NULL && live != 0) {
printf("ERROR: cannot use both -i and -live\n");
exit(1);
}
if (live == 0) {
in = open(input_filename, O_RDONLY);
if (in == -1) { perror(input_filename); return 1; }
} else
in = connect_to(live_ip, live_port);
database = parse_database(database_filename);
load_config_file(database_filename);
h = new_handler(database);
if (live) {
char mt = 1;
int number_of_events = number_of_ids(database);
int *is_on = calloc(number_of_events, sizeof(int));
if (is_on == NULL) { printf("ERROR: out of memory\n"); exit(1); }
on_off(database, "ENB_MAC_UE_UL_PDU_WITH_DATA", is_on, 1);
on_off(database, "ENB_MAC_UE_DL_PDU_WITH_DATA", is_on, 1);
on_off(database, "ENB_PHY_MIB", is_on, 1);
on_off(database, "ENB_PHY_INITIATE_RA_PROCEDURE", is_on, 1);
on_off(database, "ENB_MAC_UE_DL_RAR_PDU_WITH_DATA", is_on, 1);
/* activate selected traces */
if (socket_send(in, &mt, 1) == -1 ||
socket_send(in, &number_of_events, sizeof(int)) == -1 ||
socket_send(in, is_on, number_of_events * sizeof(int)) == -1) {
printf("ERROR: socket_send failed\n");
exit(1);
}
free(is_on);
}
ul_id = event_id_from_name(database, "ENB_MAC_UE_UL_PDU_WITH_DATA");
dl_id = event_id_from_name(database, "ENB_MAC_UE_DL_PDU_WITH_DATA");
mib_id = event_id_from_name(database, "ENB_PHY_MIB");
......
# code example of adding a command to the telnet server
The following example is extracted from [the oai `openair1/PHY/CODING/coding_load.c` file](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair1/PHY/CODING/coding_load.c).
```c
/*
include the telnet server data structures and API definitions
*/
#include "common/utils/telnetsrv/telnetsrv.h"
/*
define the null terminated array of telnetshell_cmddef_t structures
which map each sub-command string to a function implementing it.
you may also provide a help string which will be printed when
the global help command is used. The prototype for the function
implementing sub commands must match the `cmdfunc_t` type defined
in `telnetsrv.h`
*/
static int coding_setmod_cmd(char *buff, int debug, telnet_printfunc_t prnt);
static telnetshell_cmddef_t coding_cmdarray[] = {
{"mode","[sse,avx2,stdc,none]",coding_setmod_cmd},
{"","",NULL},
};
/*
define the null terminated list of telnetshell_vardef_t structures defining the
variables that can be set and get using the pre-defined get and set command
of the telnet server
*/
telnetshell_vardef_t coding_vardef[] = {
{"maxiter",TELNET_VARTYPE_INT32,&max_turbo_iterations},
{"",0,NULL}
};
.................
/*
look for telnet server, if it is loaded, add the coding commands to it
we use the shared library loader API to check the telnet server availibility
The telnet server TELNET_ADDCMD_FNAME function takes three arguments:
1. The name of the telnet command to be added, here "coding"
1. The `coding_cmdarray` list of "coding" sub-commands we defined earlier
1. The `coding_varde f`list of variables we defined earlier
*/
add_telnetcmd_func_t addcmd = (add_telnetcmd_func_t)get_shlibmodule_fptr("telnetsrv", TELNET_ADDCMD_FNAME);
if (addcmd != NULL) {
addcmd("coding",coding_vardef,coding_cmdarray);
.......
/*
functions implementing the "coding mode" sub command, as defined in
the `coding_cmdarray` passed earlier to the TELNET_ADDCMD_FNAME function.
This function will be called by the telnet server, when the `coding_cmdarray`
command is received from the telnet client
*/
int coding_setmod_cmd(char *buff, int debug, telnet_printfunc_t prnt)
{
/*
1. buff argument is an input argument, pointer to the string received
from the telnet client, the command and sub-command parts are removed
In this case it points after "coding setmod" and is of no use as
we don't have second level sub-commands.
1. debug argument is an input argument set by the telnet server
1. prnt arguments is also an input argument, a function pointer, to be used
in place of printf to print messages on the telnet client interface. As this function
is called by the telnet server stdout points to the main executable console,
*/
if (debug > 0)
prnt( "coding_setmod_cmd received %s\n",buff);
if (strcasestr(buff,"sse") != NULL) {
decoding_setmode(MODE_DECODE_SSE);
} else if (strcasestr(buff,"avx2") != NULL) {
decoding_setmode(MODE_DECODE_AVX2);
} else if (strcasestr(buff,"stdc") != NULL) {
decoding_setmode(MODE_DECODE_C);
} else if (strcasestr(buff,"none") != NULL) {
decoding_setmode(MODE_DECODE_NONE);
} else {
prnt("%s: wrong setmod parameter...\n",buff);
}
prnt("Coding and decoding current mode: %s\n",modedesc[curmode]);
return 0;
}
..............
```
# telnet server API
```c
int add_telnetcmd(char *modulename, telnetshell_vardef_t *var, telnetshell_cmddef_t *cmd)
```
Add a command and the `cmd` list of sub-commands to the telnet server. After a successful call to `add_telnetcmd` function, the telnet server calls the function defined for each sub-commands in the null terminated `cmd` array, when the character string received from the telnet client matches the command and sub-command strings.
Also adds the list of variables described in the `var` array to the list of variable which can be set and read.
The function returns -1 if one argument is NULL.
The telnet server is dynamically loaded, to use the `add_telnetcmd` function, the shared library loader API should be used to check the availability of the telnet server and retrieve it's address, as shown in [the example at the top of this page](telnetaddcmd.md#code-example-of-adding-a-command-to-the-telnet-server).
# telnet server public data types
## `telnetshell_vardef_t`structure
This structure is used by developers to describe the variables that can be set or read using the get,set and getall sub-commands.
| Fields | type |Description |
|:-----------|:------:|:-----------------------|
| `varname` | `char[TELNET_CMD_MAXSIZE]` | variable name, as specified when using the get and set commands. |
| `vartype` | `char` | Defines the type of the variable pointed by the `varvalptr`field. Supported values: TELNET_VARTYPE_INT32 TELNET_VARTYPE_INT16 TELNET_VARTYPE_INT64 TELNET_VARTYPE_STRING TELNET_VARTYPE_DOUBLE |
| `varvalptr` | `void*` | Defines the type of the variable pointed by the `varvalptr`field |
## `telnetshell_cmddef_t`structure
This structure is used by developers to describe the first level sub-commands to be added to the telnet server.
| Fields | type |Description |
|:-----------|:------:|:-----------------------|
| `cmdname` | `char[TELNET_CMD_MAXSIZE]` | command name, as tested by the telnet server to check it should call the `cmdfunc` function |
| `helpstr` | `char[TELNET_HELPSTR_SIZE]` | character string to print when the elp`command is received from the telnet client |
| `cmdfunc` | `cmdfunc_t` | pointer to the function implementing the `cmdname` sub command. |
[oai telnet server home](telnetsrv.md)
\ No newline at end of file
# telnet server principles
The oai telnet server is implemented in a shared library to be loaded by the [oai shared library loader](loader). The implementation includes a `telnetsrv_autoinit` function which is automatically called at load time, starts the telnet server and registers a first set of commands, which are delivered with the server (telnet, softmodem, loader).
Currently the telnet server only supports one user connection. The same dedicated thread is used to wait for a user connection and process the input received from this connection.
The telnet server provides an API which can be used by any oai component to add new CLI commands to the server. A pre-defined command can be used to get or set a list of variables.
# telnet server source files
telnet server source files are located in [common/utils/telnetsrv](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils/telnetsrv)
1. [telnetsrv.c](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils/telnetsrv/telnetsrv.c) contains the telnet server implementation, including the implementation of the telnet CLI command.
1. [telnetsrv.h](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils/telnetsrv/telnetsrv.h) is the telnet server include file containing both private and public data type definitions. It also contains API prototypes for functions that are used to register a new command in the server.
1. `telnetsrv\_\<XXX\>.c`: implementation of \<XXX\> CLI command which are delivered with the telnet server.
1. `telnetsrv\_\<XXX\>.h`: include file for the implementation of XXX CLI command. Usually included only in the corresponding `.c`file
1. [telnetsrv_CMakeLists.txt](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/telnetsrv/telnetsrv_CMakeLists.txt): CMakelists file containing the cmake instructions to build the telnet server. this file is included in the [global oai CMakelists](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/cmake_targets/CMakeLists.txt).
[oai telnet server home](telnetsrv.md)
\ No newline at end of file
getall command can be used to get the list of variables that can bet set or get from the telnet shell. Knowing the names of the variables they can then be set or read. Setting a variable is not always relevant, the telnet server doesn't provide a mechanism to restrict the set command.
```bash
softmodem> telnet getall
telnet, debug = 0
telnet, prio = 0
telnet, loopc = 10
telnet, loopd = 5000
telnet, phypb = 65000
telnet, hsize = 50
telnet, hfile = "oaitelnet.history"
softmodem> telnet set loopc 100
telnet, loopc set to
100
softmodem> telnet get loopc
telnet, loopc = 100
softmodem>
```
[oai telnetserver home](telnetsrv.md)
[oai telnetserver usage home](telnetusage.md)
\ No newline at end of file
# oai telnet server global help
``` bash
alblf@at8020-a:~$ telnet 10.133.10.77 9090
Trying 10.133.10.77...
Connected to 10.133.10.77.
Escape character is '^]'.
softmodem> help
module 0 = telnet:
telnet [get set] debug <value>
telnet [get set] prio <value>
telnet [get set] loopc <value>
telnet [get set] loopd <value>
telnet [get set] phypb <value>
telnet [get set] hsize <value>
telnet [get set] hfile <value>
telnet redirlog [here,file,off]
telnet param [prio]
telnet history [list,reset]
module 1 = softmodem:
softmodem show loglvl|thread|config
softmodem log (enter help for details)
softmodem thread (enter help for details)
softmodem exit
module 2 = phy:
phy disp [phycnt,uedump,uestat UE<x>]
module 3 = loader:
loader [get set] mainversion <value>
loader [get set] defpath <value>
loader [get set] maxshlibs <value>
loader [get set] numshlibs <value>
loader show [params,modules]
module 4 = coding:
coding [get set] maxiter <value>
coding mode [sse,avx2,stdc,none]
softmodem>
```
# oai telnet server, specific commands help
``` bash
softmodem> softmodem log help
log sub commands:
show: display current log configuration
online, noonline: enable or disable console logs
enable, disable id1-id2: enable or disable logs for components index id1 to id2
level_<level> id1-id2: set log level to <level> for components index id1 to id2
level_<verbosity> id1-id2: set log verbosity to <verbosity> for components index id1 to id2
use the show command to get the values for <level>, <verbosity> and the list of component indexes that can be used for id1 and id2
softmodem>
```
[oai telnetserver home](telnetsrv.md)
[oai telnetserver usage home](telnetusage.md)
\ No newline at end of file
The telnet server implements a simple history system
```bash
softmodem> telnet history list
1: telnet history list
2: telnet history list
3: help
4: loader show modules
5: softmodem show loglvl
6: help
7: telnet history
8: help
9: telnet history list
10: help
11: loader show modules
12: softmodem show loglvl
13: softmodem log help
14: softmodem log disable 0-35
15: softmodem log show
16: help
17: telnet history list
18: loader show modules
19: softmodem thread show
20: help
21: softmodem thread help
22: softmodem log show
23: softmodem log help
24: softmodem log level_error 0-4
25: loader show modules
26: loader show config
27: help
28: loader show params
29: loader show modules
softmodem> !28
softmodem> loader show params
loader parameters:
Main executable build version: "Branch: develop-telnet-loader-fixes Abrev. Hash: e56ae69 Date: Fri Mar 9 16:47:08 2018 +0100"
Default shared lib path: ""
Max number of shared lib : 10
softmodem>
```
[oai telnetserver home](telnetsrv.md)
[oai telnetserver usage home](telnetusage.md)
\ No newline at end of file
loader command can be used to check loader configuration parameters and the list of loaded shared libraries and for each library the list of available functions.
```bash
softmodem> loader show params
loader parameters:
Main executable build version: "Branch: develop-telnet-loader-fixes Abrev. Hash: e56ae69 Date: Fri Mar 9 16:47:08 2018 +0100"
Default shared lib path: ""
Max number of shared lib : 10
softmodem> loader show modules
4 shared lib have been dynamicaly loaded by the oai loader
Module 0: telnetsrv
Shared library build version: "Branch: develop-telnet-loader-fixes Abrev. Hash: e56ae69 Date: Fri Mar 9 16:47:08 2018 +0100"
Shared library path: "libtelnetsrv.so"
1 function pointers registered:
function 0 add_telnetcmd at 0x7ff8b772a2b0
Module 1: NB_IoT
Shared library build version: ""
Shared library path: "libNB_IoT.so"
1 function pointers registered:
function 0 RCConfig_NbIoT at 0x7ff8b6b1b390
Module 2: coding
Shared library build version: "Branch: develop-telnet-loader-fixes Abrev. Hash: e56ae69 Date: Fri Mar 9 16:47:08 2018 +0100"
Shared library path: "libcoding.so"
13 function pointers registered:
function 0 init_td8 at 0x7ff8adde63a0
function 1 init_td16 at 0x7ff8adde9760
function 2 init_td16avx2 at 0x7ff8addec050
function 3 phy_threegpplte_turbo_decoder8 at 0x7ff8adde6780
function 4 phy_threegpplte_turbo_decoder16 at 0x7ff8adde9a90
function 5 phy_threegpplte_turbo_decoder_scalar at 0x7ff8addef4a0
function 6 phy_threegpplte_turbo_decoder16avx2 at 0x7ff8addec530
function 7 free_td8 at 0x7ff8adde61d0
function 8 free_td16 at 0x7ff8adde9590
function 9 free_td16avx2 at 0x7ff8addebe80
function 10 threegpplte_turbo_encoder_sse at 0x7ff8adde45b0
function 11 threegpplte_turbo_encoder at 0x7ff8adde4a30
function 12 init_encoder_sse at 0x7ff8adde49d0
Module 3: oai_device
Shared library build version: ""
Shared library path: "liboai_device_usrp.so"
1 function pointers registered:
function 0 device_init at 0x7ff8ac16a7a0
softmodem>
```
[oai telnetserver home](telnetsrv.md)
[oai telnetserver usage home](telnetusage.md)
\ No newline at end of file
The log command can be used to get the status of the log parameters and to dynamically modify these parameters. The log command has its own [help](telnethelp.md#oai-telnet-server-specific-commands-help)
```bash
softmodem> softmodem log disable 0-35
log level/verbosity comp 0 PHY set to info / medium (disabled)
log level/verbosity comp 1 MAC set to info / medium (disabled)
log level/verbosity comp 2 EMU set to info / medium (disabled)
log level/verbosity comp 3 OCG set to info / medium (disabled)
log level/verbosity comp 4 OMG set to info / medium (disabled)
log level/verbosity comp 5 OPT set to info / medium (disabled)
log level/verbosity comp 6 OTG set to info / medium (disabled)
log level/verbosity comp 7 OTG_LATENCY set to info / medium (disabled)
log level/verbosity comp 8 OTG_LATENCY_BG set to info / medium (disabled)
log level/verbosity comp 9 OTG_GP set to info / medium (disabled)
log level/verbosity comp 10 OTG_GP_BG set to info / medium (disabled)
log level/verbosity comp 11 OTG_JITTER set to info / medium (disabled)
log level/verbosity comp 12 RLC set to info / medium (disabled)
log level/verbosity comp 13 PDCP set to info / medium (disabled)
log level/verbosity comp 14 RRC set to info / medium (disabled)
log level/verbosity comp 15 NAS set to info / medium (disabled)
log level/verbosity comp 16 PERF set to info / medium (disabled)
log level/verbosity comp 17 OIP set to info / medium (disabled)
log level/verbosity comp 18 CLI set to info / medium (disabled)
log level/verbosity comp 19 MSC set to info / medium (disabled)
log level/verbosity comp 20 OCM set to info / medium (disabled)
log level/verbosity comp 21 UDP set to info / medium (disabled)
log level/verbosity comp 22 GTPV1U set to info / medium (disabled)
log level/verbosity comp 23 comp23? set to info / medium (disabled)
log level/verbosity comp 24 S1AP set to info / medium (disabled)
log level/verbosity comp 25 SCTP set to info / medium (disabled)
log level/verbosity comp 26 HW set to info / medium (disabled)
log level/verbosity comp 27 OSA set to info / medium (disabled)
log level/verbosity comp 28 eRAL set to info / medium (disabled)
log level/verbosity comp 29 mRAL set to info / medium (disabled)
log level/verbosity comp 30 ENB_APP set to info / medium (disabled)
log level/verbosity comp 31 FLEXRAN_AGENT set to info / medium (disabled)
log level/verbosity comp 32 TMR set to info / medium (disabled)
log level/verbosity comp 33 USIM set to info / medium (disabled)
log level/verbosity comp 34 LOCALIZE set to info / medium (disabled)
log level/verbosity comp 35 RRH set to info / medium (disabled)
softmodem> softmodem log show
Available log levels:
emerg alert crit error warn notice info debug file trace
Available verbosity:
none low medium high full
component verbosity level enabled
00 PHY: medium info N
01 MAC: medium info N
02 EMU: medium info N
03 OCG: medium info N
04 OMG: medium info N
05 OPT: medium info N
06 OTG: medium info N
07 OTG_LATENCY: medium info N
08 OTG_LATENCY_BG: medium info N
09 OTG_GP: medium info N
10 OTG_GP_BG: medium info N
11 OTG_JITTER: medium info N
12 RLC: medium info N
13 PDCP: medium info N
14 RRC: medium info N
15 NAS: medium info N
16 PERF: medium info N
17 OIP: medium info N
18 CLI: medium info N
19 MSC: medium info N
20 OCM: medium info N
21 UDP: medium info N
22 GTPV1U: medium info N
23 comp23?: medium info N
24 S1AP: medium info N
25 SCTP: medium info N
26 HW: medium info N
27 OSA: medium info N
28 eRAL: medium info N
29 mRAL: medium info N
30 ENB_APP: medium info N
31 FLEXRAN_AGENT: medium info N
32 TMR: medium info N
33 USIM: medium info N
34 LOCALIZE: medium info N
35 RRH: medium info N
36 comp36?: medium info Y
37 LOADER: medium alert Y
softmodem> softmodem log level_error 0-4
log level/verbosity comp 0 PHY set to error / medium (enabled)
log level/verbosity comp 1 MAC set to error / medium (enabled)
log level/verbosity comp 2 EMU set to error / medium (enabled)
log level/verbosity comp 3 OCG set to error / medium (enabled)
log level/verbosity comp 4 OMG set to error / medium (enabled)
softmodem> exit
Connection closed by foreign host.
```
[oai telnetserver home](telnetsrv.md)
[oai telnetserver usage home](telnetusage.md)
\ No newline at end of file
The telnet server includes a **_loop_** command that can be used to iterate a given command. The number of iterations and the delay, in ms between two iterations can be modified, as shown in the following example:
```bash
softmodem> telnet get loopc
telnet, loopc = 10
softmodem> telnet get loopd
telnet, loopd = 2000
softmodem> telnet set loopd 1000
telnet, loopd set to
1000
softmodem> loop softmodem show thread
2018-03-27 17:58:49.000 2/10
id name state USRmod KRNmod prio nice vsize proc pol
3946 lte-softmodem S 20005 9440 20 0 236560384 2 0 other
3946 lte-softmodem S 7 95 20 0 236560384 2 0 other
3948 telnet R 0 0 20 0 236560384 2 0 other
3949 ITTI acceptor S 2 9 20 0 236560384 2 0 other
3951 ITTI 12 S 2 2 20 0 236560384 7 0 other
3952 ITTI 11 S 0 0 20 0 236560384 0 0 other
3953 ITTI 9 S 0 0 20 0 236560384 1 0 other
3954 ITTI 7 S 0 0 20 0 236560384 7 0 other
3955 ITTI 8 S 0 0 20 0 236560384 7 0 other
3956 ITTI 4 S 35 0 20 0 236560384 2 0 other
3957 ru_thread S 15366 3072 -10 0 236560384 0 2 rt: rr
3958 ru_thread_prach S 0 0 -10 0 236560384 7 1 rt: fifo
3959 fep_thread S 1874 123 -10 0 236560384 5 1 rt: fifo
3960 feptx_thread S 1554 101 -10 0 236560384 7 1 rt: fifo
3969 ru_thread S 0 0 -10 0 236560384 0 2 rt: rr
3970 ru_thread S 1313 5522 -10 0 236560384 5 2 rt: rr
3971 ru_thread S 4 6 -10 0 236560384 1 2 rt: rr
3972 lte-softmodem S 318 9 -10 0 236560384 7 1 rt: fifo
3973 lte-softmodem S 6 13 -10 0 236560384 4 1 rt: fifo
```
A **_loop_** command can be interrupted by pressing the **_enter_** key till getting the prompt.
[oai telnetserver home](telnetsrv.md)
[oai telnetserver usage home](telnetusage.md)
\ No newline at end of file
The oai embedded telnet server is an optional monitoring and debugging tool. It provides a simple Command Line Interface to the oai softmem. New commands can easily be added by developers to the telnet server.
* [Using the telnet server](telnetusage.md)
* [Adding commands to the oai telnet server](telnetaddcmd.md)
* [telnet server architecture ](telnetarch.md)
[oai Wikis home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
\ No newline at end of file
# starting the softmodem with the telnet server
By default the embedded telnet server, which is implemented in a shared library, is not built. It can be built after compiling the softmodem executable using the `build_oai` script:
```bash
cd \<oai repository\>/openairinterface5g
source oaienv
cd cmake_targets
./build_oai --build-telnetsrv
```
This will create the `libtelnetsrv.so` file in the `targets/bin` and `cmake_targets/lte_build_oai/build` sub directories of the oai repository.
When starting the softmodem, you must specify the **_\-\-telnetsrv_** option to load and start the telnet server. The telnet server is loaded via the [oai shared library loader](loader).
# using the Command Line Interface
By default the telnet server listen on all the ip addresses configured on the system and on port 9090. This behavior can be changed using the `listenaddr` and `listenport` parameters.
The telnet server includes a basic help, listing available commands and some commands also provide a specific detailed help sub-command.
Below are examples of telnet sessions:
* [getting help](telnethelp.md)
* [using the history](telnethist.md)
* [using the get and set commands](telnetgetset.md)
* [using the loop command](telnetloop.md)
* [loader command](telnetloader.md)
* [log command](telnetlog.md)
# telnet server parameters
The telnet server is using the [oai configuration module](Config/Rtusage). Telnet parameters must be specified in the `telnetsrv` section. Some parameters can be modified via the telnet telnet server command, as specified in the last column of the following table.
| name | type | default | description | dynamic |
|:---:|:---:|:---:|:----|:----:|
| `listenaddr` | `ipV4 address, ascii format` | "0.0.0.0" | local address the server is listening on| N |
| `listenport` | `integer` | 9090 | port number the server is listening on | N |
| `loopcount` | `integer` | 10 | number of iterations for the loop command | Y |
| `loopdelay` | `integer` | 5000 | delay (in ms) between 2 loop command iterations | Y |
| `histfile` | `character string` | "oaitelnet.history" | file used for command history persistency | Y |
| `histfsize` | `integer` | 50 | maximum number of commands saved in the history | Y |
[oai telnet server home](telnetsrv.md)
\ No newline at end of file
This diff is collapsed.
......@@ -298,7 +298,10 @@ rx_sdu(const module_id_t enb_mod_idP,
case POWER_HEADROOM:
if (UE_id != -1) {
UE_list->UE_template[CC_idP][UE_id].phr_info =
(payload_ptr[0] & 0x3f) - PHR_MAPPING_OFFSET;
(payload_ptr[0] & 0x3f) - PHR_MAPPING_OFFSET + (int8_t)(hundred_times_log10_NPRB[UE_list->UE_template[CC_idP][UE_id].nb_rb_ul[harq_pid]-1]/100);
if(UE_list->UE_template[CC_idP][UE_id].phr_info > 40)
UE_list->UE_template[CC_idP][UE_id].phr_info = 40;
LOG_D(MAC,
"[eNB %d] CC_id %d MAC CE_LCID %d : Received PHR PH = %d (db)\n",
enb_mod_idP, CC_idP, rx_ces[i],
......
BladeRF documentation
=====================
As of 2018-11-06, the bladeRF support is not fully automatic and requires
some manual settings before use. This documentation is the ultimate source
of information. If something described in this file does not work or does
not correspond to the reality, then contact us so we can fix the problems
and update this documentation.
1. Install bladeRF 2.0 libraries.
As of now, it's better to install from source.
So, do not run: ./build_oai -I -w BLADERF
(That is: do not include '-w BLADERF'.)
Instead, follow the instructions at: https://github.com/Nuand/bladeRF
If you already had some bladeRF software installed using automatic
methods, first remove it by hand ('apt-get purge bladeRF' or something
similar, you can get the list of installed bladeRF packages by running
'dpkg -l|grep -i blade', remove them all).
2. Update the device.
Download the latest FX3 firmware and FPGA images from Nuand's website.
As of writing, this is:
https://github.com/Nuand/bladeRF/wiki
That points to the following pages.
For FX3:
http://www.nuand.com/fx3_images/
For FPGA:
http://www.nuand.com/fpga_images/
Install FX3 firmware:
sudo bladeRF-cli -f bladeRF_fw_latest.img
Install FPGA image (this is for BladeRF x40):
sudo bladeRF-cli -L hostedx40-latest.rbf
Retrieve calibration information:
sudo bladeRF-cli -i
info
That outputs the serial number of your device.
Go to:
https://www.nuand.com/calibration
And enter your serial number.
The website tells you to run something like:
sudo bladeRF-cli -i
flash_init_cal 40 0x9271
Actual values depend on your device and serial number.
3. Calibrate the bladeRF device.
We will work with band 7 on 2.68GHz with a bandwidth of 5 MHz (25 RBs).
Plug the bladeRF device, then run:
sudo bladeRF-cli -i
set frequency tx 2680000000
set frequency rx 2560000000
set gain rx 60
set gain tx 60
set bandwidth 5000000
set samplerate 7680000
cal lms
cal lms
cal lms
cal dc rxtx
cal dc rxtx
cal dc rxtx
4. Tune the RX gain using the enb tracer.
Run the softmodem and the 'enb' tracer. For instructions, see:
https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/T/basic
In the enb window, check the 'input signal'. You should see some blue
signal as seen at:
https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/T/enb
(the 'Time signal power' plot).
The level should be around 30.
If it's not around 30 then edit your configuration file and modify
the value 'max_rxgain' in the section 'RUs'.
The configuration file to use is:
configuration/bladeRF/enb-band7-5mhz.conf
In the configuration file, you also need to set the correct values for:
- tracking_area_code
- plmn_list: mcc, mnc, mnc_length
- mme_ip_address: this is the IP address used by the computer running
the softmodem to connect to the EPC
- NETWORK_INTERFACES: all the ENB*ADDRESS* variables have to point
to the IP address of the EPC machine
5. You're good to go.
You can now connect a UE and pass some traffic. If everything is well
configured you can expect more than 16 Mb/s of throughput in the downlink
using iperf and more than 8 Mb/s in the uplink. Looking at the logs, you
should find lines containing 'PHR 40' and 'CQI 15'. If your values are
lower then your setup may need some adjustments.
6. In case of problems.
If the performance of the softmodem is very bad, you can stop it and
run the calibration again, without setting the parameters (frequencies,
gains, etc.). Just run:
sudo bladeRF-cli -i
cal lms
cal dc rxtx
That may help.
Be sure to use proper radio equipment (duplexer, antennas, clean
environment without interferences).
......@@ -116,15 +116,6 @@ int trx_brf_start(openair0_device *device) {
abort();
}
if ((status=bladerf_calibrate_dc(brf->dev, BLADERF_MODULE_TX)) != 0) {
fprintf(stderr,"Failed to calibrate TX DC: %s\n", bladerf_strerror(status));
abort();
}
if ((status=bladerf_calibrate_dc(brf->dev, BLADERF_MODULE_RX)) != 0) {
fprintf(stderr,"Failed to calibrate RX DC: %s\n", bladerf_strerror(status));
abort();
}
return 0;
}
......@@ -235,8 +226,6 @@ static int trx_brf_read(openair0_device *device, openair0_timestamp *ptimestamp,
* \param device the hardware to use
*/
void trx_brf_end(openair0_device *device) {
abort();
int status;
brf_state_t *brf = (brf_state_t*)device->priv;
// Disable RX module, shutting down our underlying RX stream
......@@ -247,6 +236,7 @@ abort();
fprintf(stderr, "Failed to disable TX module: %s\n", bladerf_strerror(status));
}
bladerf_close(brf->dev);
exit(1);
}
/*! \brief print the BladeRF statistics
......@@ -362,6 +352,8 @@ void set_rx_gain_offset(openair0_config_t *openair0_cfg, int chain_index) {
*/
void calibrate_rf(openair0_device *device) {
/* TODO: this function does not seem to work. Disabled until fixed. */
return;
brf_state_t *brf = (brf_state_t *)device->priv;
openair0_timestamp ptimestamp;
......@@ -1005,6 +997,12 @@ int device_init(openair0_device *device, openair0_config_t *openair0_cfg) {
// RX
// Example of CLI output: RX Frequency: 2539999999Hz
if ((status=bladerf_set_gain_mode(brf->dev, BLADERF_MODULE_RX, BLADERF_GAIN_MGC))) {
fprintf(stderr, "[BRF] Failed to disable AGC\n");
brf_error(status);
}
if ((status=bladerf_set_frequency(brf->dev, BLADERF_MODULE_RX, (unsigned int) openair0_cfg->rx_freq[0])) != 0){
fprintf(stderr,"Failed to set RX frequency: %s\n",bladerf_strerror(status));
brf_error(status);
......@@ -1096,17 +1094,14 @@ int device_init(openair0_device *device, openair0_config_t *openair0_cfg) {
// calibrate
if ((status=bladerf_calibrate_dc(brf->dev, BLADERF_MODULE_TX)) != 0) {
fprintf(stderr,"Failed to calibrate TX DC: %s\n", bladerf_strerror(status));
if ((status=bladerf_calibrate_dc(brf->dev, BLADERF_DC_CAL_LPF_TUNING)) != 0 ||
(status=bladerf_calibrate_dc(brf->dev, BLADERF_DC_CAL_TX_LPF)) != 0 ||
(status=bladerf_calibrate_dc(brf->dev, BLADERF_DC_CAL_RX_LPF)) != 0 ||
(status=bladerf_calibrate_dc(brf->dev, BLADERF_DC_CAL_RXVGA2)) != 0) {
fprintf(stderr, "[BRF] error calibrating\n");
brf_error(status);
} else
printf("[BRF] TX module calibrated DC \n");
if ((status=bladerf_calibrate_dc(brf->dev, BLADERF_MODULE_RX)) != 0) {
fprintf(stderr,"Failed to calibrate RX DC: %s\n", bladerf_strerror(status));
brf_error(status);
}else
printf("[BRF] RX module calibrated DC \n");
printf("[BRF] calibration OK\n");
bladerf_log_set_verbosity(get_brf_log_level(openair0_cfg->log_level));
......@@ -1146,8 +1141,8 @@ int device_init(openair0_device *device, openair0_config_t *openair0_cfg) {
* \returns 0 on success
*/
int brf_error(int status) {
//exit(-1);
fprintf(stderr, "[BRF] brf_error: %s\n", bladerf_strerror(status));
exit(-1);
return status; // or status error code
}
......@@ -1190,7 +1185,7 @@ struct bladerf * open_bladerf_from_serial(const char *serial) {
int get_brf_log_level(int log_level){
int level=BLADERF_LOG_LEVEL_INFO;
return BLADERF_LOG_LEVEL_DEBUG; // BLADERF_LOG_LEVEL_VERBOSE;// BLADERF_LOG_LEVEL_DEBUG; //
return BLADERF_LOG_LEVEL_INFO;
switch(log_level) {
case LOG_DEBUG:
level=BLADERF_LOG_LEVEL_DEBUG;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment