HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include <stdbool.h>
|
2017-12-07 00:55:58 +00:00
|
|
|
#include <string.h>
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
|
|
|
|
struct vty;
|
|
|
|
|
|
|
|
/* handover_cfg is an opaque struct to manage several levels of configuration. There is an overall handover
|
|
|
|
* config on 'network' level and a per-'bts' specific handover config. If the 'bts' level sets no values,
|
|
|
|
* the defaults from 'network' level are used implicitly, and changes take effect immediately. */
|
|
|
|
struct handover_cfg;
|
|
|
|
|
2017-12-07 02:54:01 +00:00
|
|
|
#define HO_CFG_CONGESTION_CHECK_DEFAULT 10
|
|
|
|
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
struct handover_cfg *ho_cfg_init(void *ctx, struct handover_cfg *higher_level_cfg);
|
|
|
|
|
2018-02-14 18:56:23 +00:00
|
|
|
#define HO_CFG_STR_HANDOVER1 "Handover options for handover decision algorithm 1\n"
|
|
|
|
#define HO_CFG_STR_HANDOVER2 "Handover options for handover decision algorithm 2\n"
|
|
|
|
#define HO_CFG_STR_WIN "Measurement averaging settings\n"
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
#define HO_CFG_STR_WIN_RXLEV HO_CFG_STR_WIN "Received-Level averaging\n"
|
|
|
|
#define HO_CFG_STR_WIN_RXQUAL HO_CFG_STR_WIN "Received-Quality averaging\n"
|
2018-02-14 18:56:23 +00:00
|
|
|
#define HO_CFG_STR_POWER_BUDGET "Neighbor cell power triggering\n" "Neighbor cell power triggering\n"
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
#define HO_CFG_STR_AVG_COUNT "Number of values to average over\n"
|
2018-11-05 01:49:57 +00:00
|
|
|
#define HO_CFG_STR_MIN "Minimum Level/Quality thresholds before triggering HO\n"
|
|
|
|
#define HO_CFG_STR_AFS_BIAS "Configure bias to prefer AFS (AMR on TCH/F) over other codecs\n"
|
|
|
|
#define HO_CFG_STR_MIN_TCH "Minimum free TCH timeslots before cell is considered congested\n"
|
|
|
|
#define HO_CFG_STR_PENALTY_TIME "Set penalty times to wait between repeated handovers\n"
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
|
|
|
|
#define as_is(x) (x)
|
|
|
|
|
|
|
|
static inline bool a2bool(const char *arg)
|
|
|
|
{
|
|
|
|
return (bool)(atoi(arg));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int bool2i(bool arg)
|
|
|
|
{
|
|
|
|
return arg? 1 : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The HO_CFG_ONE_MEMBER macro gets redefined, depending on whether to define struct members,
|
|
|
|
* function declarations or definitions... It is of the format
|
|
|
|
* HO_CFG_ONE_MEMBER(TYPE, NAME, DEFAULT_VAL,
|
2021-06-15 10:39:51 +00:00
|
|
|
* VTY_CMD_PREFIX, VTY_CMD, VTY_CMD_ARG, VTY_ARG_EVAL,
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
* VTY_WRITE_FMT, VTY_WRITE_CONV,
|
|
|
|
* VTY_DOC)
|
|
|
|
* Then using HO_CFG_ALL_MEMBERS can save a lot of code dup in defining API declaration, API
|
|
|
|
* definitions, VTY commands and VTY write code. Of course this doesn't prevent us from adding manual
|
|
|
|
* members as well, in case future additions don't fit in this scheme.
|
|
|
|
*
|
|
|
|
* TYPE: a type name like int.
|
|
|
|
* NAME: a variable name suitable for a struct member.
|
|
|
|
* DEFAULT_VAL: default value, as passed to the VTY, e.g. '0' or 'foo', without quotes.
|
2018-02-15 02:59:17 +00:00
|
|
|
* VTY_CMD_PREFIX: "handover1 ", "handover2 ", ... or just "" for the common general items.
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
* VTY_CMD: a command string for VTY without any arguments.
|
|
|
|
* VTY_CMD_ARG: VTY value range like '<0-23>' or 'foo|bar', will become '(VTY_CMD_ARG|default)'.
|
|
|
|
* VTY_ARG_EVAL: function name for parsing the VTY arg[0], e.g. 'atoi'.
|
|
|
|
* VTY_WRITE_FMT: printf-like string format for vty_out().
|
|
|
|
* VTY_WRITE_CONV: function name to convert struct value to VTY_WRITE_FMT, e.g. 'as_is'.
|
|
|
|
* VTY_DOC: VTY documentation strings to match VTY_CMD and VTY_CMD_ARGs.
|
|
|
|
*/
|
2018-02-14 18:56:23 +00:00
|
|
|
#define HO_GENERAL_CFG_ALL_MEMBERS \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
\
|
|
|
|
HO_CFG_ONE_MEMBER(bool, ho_active, 0, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"", "handover", "0|1", a2bool, "%d", bool2i, \
|
2018-02-14 18:56:23 +00:00
|
|
|
"Handover general config\n" \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
"Disable in-call handover\n" \
|
|
|
|
"Enable in-call handover\n" \
|
|
|
|
"Enable/disable handover: ") \
|
|
|
|
\
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, algorithm, 1, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"", "handover algorithm", "1|2", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
"Handover general config\n" \
|
2017-12-07 00:55:58 +00:00
|
|
|
"Choose algorithm for handover decision\n" \
|
|
|
|
"Algorithm 1: trigger handover based on comparing current cell and neighbor RxLev and RxQual," \
|
|
|
|
" only.\n" \
|
|
|
|
"Algorithm 2: trigger handover on RxLev/RxQual, and also to balance the load across several" \
|
|
|
|
" cells. Consider available codecs. Prevent repeated handover by penalty timers.\n") \
|
2018-02-14 18:56:23 +00:00
|
|
|
|
|
|
|
|
|
|
|
#define HODEC1_CFG_ALL_MEMBERS \
|
2017-12-07 00:55:58 +00:00
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec1_rxlev_avg_win, 10, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover1 ", "window rxlev averaging", "<1-10>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER1 \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
HO_CFG_STR_WIN_RXLEV \
|
2019-06-24 11:43:06 +00:00
|
|
|
"How many RxLev measurements to use for averaging\n" \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
"RxLev averaging: " HO_CFG_STR_AVG_COUNT) \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec1_rxqual_avg_win, 1, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover1 ", "window rxqual averaging", "<1-10>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER1 \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
HO_CFG_STR_WIN_RXQUAL \
|
2019-06-24 11:43:06 +00:00
|
|
|
"How many RxQual measurements to use for averaging\n" \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
"RxQual averaging: " HO_CFG_STR_AVG_COUNT) \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec1_rxlev_neigh_avg_win, 10, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover1 ", "window rxlev neighbor averaging", "<1-10>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER1 \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
HO_CFG_STR_WIN_RXLEV \
|
2019-06-24 11:43:06 +00:00
|
|
|
"How many Neighbor RxLev measurements to use for averaging\n" \
|
|
|
|
"How many Neighbor RxLev measurements to use for averaging\n" \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
"Neighbor RxLev averaging: " HO_CFG_STR_AVG_COUNT) \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec1_pwr_interval, 6, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover1 ", "power budget interval", "<1-99>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER1 \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
HO_CFG_STR_POWER_BUDGET \
|
|
|
|
"How often to check for a better cell (SACCH frames)\n" \
|
|
|
|
"Check for stronger neighbor every N number of SACCH frames\n") \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec1_pwr_hysteresis, 3, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover1 ", "power budget hysteresis", "<0-999>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER1 \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
HO_CFG_STR_POWER_BUDGET \
|
2018-07-19 14:50:14 +00:00
|
|
|
"How many dB stronger must a neighbor be to become a HO candidate\n" \
|
|
|
|
"Neighbor's strength difference in dB\n") \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec1_max_distance, 9999, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover1 ", "maximum distance" , "<0-9999>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER1 \
|
|
|
|
"Maximum Timing-Advance value (i.e. MS distance) before triggering HO\n" \
|
|
|
|
"Maximum Timing-Advance value (i.e. MS distance) before triggering HO\n" \
|
|
|
|
"Maximum Timing-Advance value (i.e. MS distance) before triggering HO\n") \
|
|
|
|
|
|
|
|
|
|
|
|
#define HODEC2_CFG_ALL_MEMBERS \
|
|
|
|
\
|
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec2_rxlev_avg_win, 10, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "window rxlev averaging", "<1-10>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
|
|
|
HO_CFG_STR_WIN_RXLEV \
|
2019-06-24 11:43:06 +00:00
|
|
|
"How many RxLev measurements to use for averaging\n" \
|
2018-02-14 18:56:23 +00:00
|
|
|
"RxLev averaging: " HO_CFG_STR_AVG_COUNT) \
|
|
|
|
\
|
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec2_rxqual_avg_win, 1, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "window rxqual averaging", "<1-10>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
|
|
|
HO_CFG_STR_WIN_RXQUAL \
|
2019-06-24 11:43:06 +00:00
|
|
|
"How many RxQual measurements to use for averaging\n" \
|
2018-02-14 18:56:23 +00:00
|
|
|
"RxQual averaging: " HO_CFG_STR_AVG_COUNT) \
|
|
|
|
\
|
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec2_rxlev_neigh_avg_win, 10, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "window rxlev neighbor averaging", "<1-10>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
|
|
|
HO_CFG_STR_WIN_RXLEV \
|
2019-06-24 11:43:06 +00:00
|
|
|
"How many Neighbor RxLev measurements to use for averaging\n" \
|
|
|
|
"How many Neighbor RxLev measurements to use for averaging\n" \
|
2018-02-14 18:56:23 +00:00
|
|
|
"Neighbor RxLev averaging: " HO_CFG_STR_AVG_COUNT) \
|
|
|
|
\
|
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec2_pwr_interval, 6, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "power budget interval", "<1-99>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
|
|
|
HO_CFG_STR_POWER_BUDGET \
|
|
|
|
"How often to check for a better cell (SACCH frames)\n" \
|
|
|
|
"Check for stronger neighbor every N number of SACCH frames\n") \
|
|
|
|
\
|
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec2_pwr_hysteresis, 3, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "power budget hysteresis", "<0-999>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
|
|
|
HO_CFG_STR_POWER_BUDGET \
|
2018-07-19 14:50:14 +00:00
|
|
|
"How many dB stronger must a neighbor be to become a HO candidate\n" \
|
|
|
|
"Neighbor's strength difference in dB\n") \
|
2018-02-14 18:56:23 +00:00
|
|
|
\
|
|
|
|
HO_CFG_ONE_MEMBER(unsigned int, hodec2_max_distance, 9999, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "maximum distance" , "<0-9999>", atoi, "%u", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
"Maximum Timing-Advance value (i.e. MS distance) before triggering HO\n" \
|
|
|
|
"Maximum Timing-Advance value (i.e. MS distance) before triggering HO\n" \
|
|
|
|
"Maximum Timing-Advance value (i.e. MS distance) before triggering HO\n") \
|
2017-12-07 00:55:58 +00:00
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(bool, hodec2_as_active, 0, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "assignment", "0|1", a2bool, "%d", bool2i, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2019-06-24 11:43:06 +00:00
|
|
|
"Enable or disable in-call channel re-assignment within the same cell\n" \
|
2017-12-07 00:55:58 +00:00
|
|
|
"Disable in-call assignment\n" \
|
|
|
|
"Enable in-call assignment\n") \
|
|
|
|
\
|
2021-07-05 15:38:28 +00:00
|
|
|
HO_CFG_ONE_MEMBER(enum tdma_meas_set, hodec2_tdma_meas_set, subset, \
|
|
|
|
"handover2 ", "tdma-measurement", "auto|full|subset", \
|
|
|
|
tdma_meas_set_from_str, "%s", tdma_meas_set_name, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2018-11-05 01:49:57 +00:00
|
|
|
"Define measurement set of TDMA frames\n" \
|
2021-07-05 15:38:28 +00:00
|
|
|
"Use full set when DTX is not in use, use subset when DTX is in use," \
|
|
|
|
" as indicated by each Measurement Report\n" \
|
2017-12-07 00:55:58 +00:00
|
|
|
"Full set of 102/104 TDMA frames\n" \
|
|
|
|
"Sub set of 4 TDMA frames (SACCH)\n") \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_min_rxlev, -100, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "min rxlev", "<-110--50>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_MIN \
|
|
|
|
"How weak may RxLev of an MS become before triggering HO\n" \
|
2019-06-24 11:43:06 +00:00
|
|
|
"minimum RxLev (dBm; note: negative values)\n") \
|
2017-12-07 00:55:58 +00:00
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_min_rxqual, 5, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "min rxqual", "<0-7>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_MIN \
|
2020-11-11 18:57:51 +00:00
|
|
|
"How bad may RxQual of an MS become before triggering HO," \
|
|
|
|
" where 0 is the best quality (bit error rate < 0.2%) and" \
|
|
|
|
" 7 is the worst quality (bit error rate > 12.8%)," \
|
|
|
|
" see 3GPP TS 45.008 8.2.4.\n" \
|
|
|
|
"worst acceptable RxQual\n") \
|
2017-12-07 00:55:58 +00:00
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_afs_bias_rxlev, 0, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "afs-bias rxlev", "<0-20>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_AFS_BIAS \
|
|
|
|
"RxLev improvement bias for AFS over other codecs\n" \
|
2018-07-19 14:50:14 +00:00
|
|
|
"Virtual RxLev improvement (dB)\n") \
|
2017-12-07 00:55:58 +00:00
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_afs_bias_rxqual, 0, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "afs-bias rxqual", "<0-7>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_AFS_BIAS \
|
|
|
|
"RxQual improvement bias for AFS over other codecs\n" \
|
2018-07-19 14:50:14 +00:00
|
|
|
"Virtual RxQual improvement\n") \
|
2017-12-07 00:55:58 +00:00
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_tchf_min_slots, 0, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "min-free-slots tch/f", "<0-9999>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_MIN_TCH \
|
|
|
|
"Minimum free TCH/F timeslots before cell is considered congested\n" \
|
|
|
|
"Number of TCH/F slots\n") \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_tchh_min_slots, 0, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "min-free-slots tch/h", "<0-9999>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_MIN_TCH \
|
|
|
|
"Minimum free TCH/H timeslots before cell is considered congested\n" \
|
|
|
|
"Number of TCH/H slots\n") \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_ho_max, 9999, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "max-handovers", "<1-9999>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2018-11-05 01:49:57 +00:00
|
|
|
"Maximum number of concurrent handovers allowed per cell\n" \
|
2017-12-07 00:55:58 +00:00
|
|
|
"Number\n") \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_penalty_max_dist, 300, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "penalty-time max-distance", "<0-99999>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_PENALTY_TIME \
|
2019-06-24 11:43:06 +00:00
|
|
|
"Time to suspend handover for a subscriber after leaving this cell due to exceeding max distance;" \
|
|
|
|
" see also 'handover2 retries'\n" \
|
2017-12-07 00:55:58 +00:00
|
|
|
"Seconds\n") \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_penalty_failed_ho, 60, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "penalty-time failed-ho", "<0-99999>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_PENALTY_TIME \
|
2019-06-24 11:43:06 +00:00
|
|
|
"Time to suspend handover for a subscriber after a failed handover into this cell;" \
|
|
|
|
" see also 'handover2 retries'\n" \
|
2017-12-07 00:55:58 +00:00
|
|
|
"Seconds\n") \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_penalty_failed_as, 60, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "penalty-time failed-assignment", "<0-99999>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2017-12-07 00:55:58 +00:00
|
|
|
HO_CFG_STR_PENALTY_TIME \
|
2019-06-24 11:43:06 +00:00
|
|
|
"Time to suspend handover for a subscriber after a failed re-assignment within this cell;" \
|
|
|
|
" see also 'handover2 retries'\n" \
|
2017-12-07 00:55:58 +00:00
|
|
|
"Seconds\n") \
|
|
|
|
\
|
2021-07-08 16:16:42 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_penalty_low_rxqual_as, 60, \
|
|
|
|
"handover2 ", "penalty-time low-rxqual-assignment", "<0-99999>", atoi, "%d", as_is, \
|
|
|
|
HO_CFG_STR_HANDOVER2 \
|
|
|
|
HO_CFG_STR_PENALTY_TIME \
|
|
|
|
"Time to suspend re-assignment after an lchan was re-assigned because of low RxQual\n" \
|
|
|
|
"Seconds\n") \
|
|
|
|
\
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_ONE_MEMBER(int, hodec2_retries, 0, \
|
2018-02-15 02:59:17 +00:00
|
|
|
"handover2 ", "retries", "<0-9>", atoi, "%d", as_is, \
|
2018-02-14 18:56:23 +00:00
|
|
|
HO_CFG_STR_HANDOVER2 \
|
2019-06-24 11:43:06 +00:00
|
|
|
"Number of times to immediately retry a failed handover/assignment, before a penalty time is applied\n" \
|
2017-12-07 00:55:58 +00:00
|
|
|
"Number of retries\n") \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
|
2018-02-14 18:56:23 +00:00
|
|
|
#define HO_CFG_ALL_MEMBERS \
|
|
|
|
HO_GENERAL_CFG_ALL_MEMBERS \
|
|
|
|
HODEC1_CFG_ALL_MEMBERS \
|
|
|
|
HODEC2_CFG_ALL_MEMBERS \
|
|
|
|
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
|
|
|
|
/* Declare public API for handover cfg parameters... */
|
|
|
|
|
2018-02-15 02:59:17 +00:00
|
|
|
#define HO_CFG_ONE_MEMBER(TYPE, NAME, DEFAULT_VAL, VTY0, VTY1, VTY2, VTY3, VTY4, VTY5, VTY6) \
|
HO prep: introduce per-BTS handover config, with defaults on net node
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2017-11-27 20:29:33 +00:00
|
|
|
TYPE ho_get_##NAME(struct handover_cfg *ho); \
|
|
|
|
void ho_set_##NAME(struct handover_cfg *ho, TYPE val); \
|
|
|
|
bool ho_isset_##NAME(struct handover_cfg *ho); \
|
|
|
|
void ho_clear_##NAME(struct handover_cfg *ho); \
|
|
|
|
bool ho_isset_on_parent_##NAME(struct handover_cfg *ho);
|
|
|
|
|
|
|
|
HO_CFG_ALL_MEMBERS
|
|
|
|
#undef HO_CFG_ONE_MEMBER
|