osmo-bsc/src/osmo-bsc/handover_vty.c

180 lines
5.7 KiB
C
Raw Normal View History

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
/* OsmoBSC interface to quagga VTY for handover parameters */
/* (C) 2009-2010 by Andreas Eversberg <jolly@eversberg.eu>
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
* (C) 2009-2010 by Harald Welte <laforge@gnumonks.org>
* (C) 2017-2018 by sysmocom - s.f.m.c. GmbH <info@sysmocom.de>
*
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
* All Rights Reserved
*
* Author: Andreas Eversberg <jolly@eversberg.eu>
* Neels Hofmeyr <nhofmeyr@sysmocom.de>
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
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
*/
#include <osmocom/bsc/gsm_data.h>
#include <osmocom/bsc/vty.h>
#include <osmocom/bsc/handover_cfg.h>
#include <osmocom/bsc/handover_decision_2.h>
#include <osmocom/bsc/bts.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
static struct handover_cfg *ho_cfg_from_vty(struct vty *vty)
{
switch (vty->node) {
case GSMNET_NODE:
return gsmnet_from_vty(vty)->ho;
case BTS_NODE:
OSMO_ASSERT(vty->index);
return ((struct gsm_bts *)vty->index)->ho;
default:
OSMO_ASSERT(false);
}
}
#define HO_CFG_ONE_MEMBER(TYPE, NAME, DEFAULT_VAL, \
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) \
DEFUN_ATTR(cfg_ho_##NAME, cfg_ho_##NAME##_cmd, \
VTY_CMD_PREFIX VTY_CMD " (" VTY_CMD_ARG "|default)", \
VTY_DOC \
"Use default (" #DEFAULT_VAL "), remove explicit setting on this node\n", CMD_ATTR_IMMEDIATE) \
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 = ho_cfg_from_vty(vty); \
const char *val = argv[0]; \
if (!strcmp(val, "default")) { \
const char *msg; \
if (ho_isset_##NAME(ho)) {\
ho_clear_##NAME(ho); \
msg = "setting removed, now is"; \
} else \
msg = "already was unset, still is"; \
vty_out(vty, "%% '" VTY_CMD_PREFIX VTY_CMD "' %s " VTY_WRITE_FMT "%s%s", \
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
msg, VTY_WRITE_CONV( ho_get_##NAME(ho) ), \
ho_isset_on_parent_##NAME(ho)? " (set on higher level node)" : "", \
VTY_NEWLINE); \
} \
else \
ho_set_##NAME(ho, VTY_ARG_EVAL(val)); \
return CMD_SUCCESS; \
}
HO_CFG_ALL_MEMBERS
#undef HO_CFG_ONE_MEMBER
/* Aliases of 'handover' for 'handover1' for backwards compat */
#define HO_CFG_ONE_MEMBER(TYPE, NAME, DEFAULT_VAL, \
VTY_CMD_PREFIX, VTY_CMD, VTY_CMD_ARG, VTY_ARG_EVAL, \
VTY_WRITE_FMT, VTY_WRITE_CONV, \
VTY_DOC) \
HO: vty: clearly mark 'handover foo' as legacy alias for 'handover1 foo' The ALIAS_DEPRECATED causes the legacy commands to no longer show up in the command listing, hence making it more clear which commands are general and which are for hodec1 only: == BEFORE: == OsmoBSC(config-net)# list ... handover (0|1|default) handover algorithm (1|2|default) handover1 window rxlev averaging (<1-10>|default) ... handover2 window rxlev averaging (<1-10>|default) ... handover2 retries (<0-9>|default) handover window rxlev averaging (<1-10>|default) <-- legacy handover window rxqual averaging (<1-10>|default) handover window rxlev neighbor averaging (<1-10>|default) handover power budget interval (<1-99>|default) handover power budget hysteresis (<0-999>|default) handover maximum distance (<0-9999>|default) handover2 congestion-check (disabled|<1-999>|now) OsmoBSC(config-net)# handover ? 0 Disable in-call handover 1 Enable in-call handover default Enable/disable handover: Use default (0), remove explicit setting on this node algorithm Choose algorithm for handover decision window Measurement averaging settings <-- legacy power Neighbor cell power triggering maximum Maximum Timing-Advance value (i.e. MS distance) before triggering HO OsmoBSC(config-net)# handover? handover Handover general config <-- unchanged == AFTER: == OsmoBSC(config-net)# list ... handover (0|1|default) handover algorithm (1|2|default) handover1 window rxlev averaging (<1-10>|default) ... handover2 window rxlev averaging (<1-10>|default) ... handover2 retries (<0-9>|default) handover2 congestion-check (disabled|<1-999>|now) <-- no more legacy OsmoBSC(config-net)# handover ? 0 Disable in-call handover 1 Enable in-call handover default Enable/disable handover: Use default (0), remove explicit setting on this node algorithm Choose algorithm for handover decision <-- no more legacy OsmoBSC(config-net)# handover? handover Handover general config <-- unchanged The "Legacy" doc string actually never shows on the VTY console, but it will show in the reference manual. (Even with ALIAS(), a 'handover?' would only show the "Handover general config" doc string, so no loss there from using ALIAS_DEPRECATED().) Change-Id: I86be674d82242f9ca73a4d0040015c1c79f2422d
2018-02-19 16:17:11 +00:00
ALIAS_DEPRECATED(cfg_ho_##NAME, cfg_ho_##NAME##_cmd_alias, \
"handover " VTY_CMD " (" VTY_CMD_ARG "|default)", \
HO: vty: clearly mark 'handover foo' as legacy alias for 'handover1 foo' The ALIAS_DEPRECATED causes the legacy commands to no longer show up in the command listing, hence making it more clear which commands are general and which are for hodec1 only: == BEFORE: == OsmoBSC(config-net)# list ... handover (0|1|default) handover algorithm (1|2|default) handover1 window rxlev averaging (<1-10>|default) ... handover2 window rxlev averaging (<1-10>|default) ... handover2 retries (<0-9>|default) handover window rxlev averaging (<1-10>|default) <-- legacy handover window rxqual averaging (<1-10>|default) handover window rxlev neighbor averaging (<1-10>|default) handover power budget interval (<1-99>|default) handover power budget hysteresis (<0-999>|default) handover maximum distance (<0-9999>|default) handover2 congestion-check (disabled|<1-999>|now) OsmoBSC(config-net)# handover ? 0 Disable in-call handover 1 Enable in-call handover default Enable/disable handover: Use default (0), remove explicit setting on this node algorithm Choose algorithm for handover decision window Measurement averaging settings <-- legacy power Neighbor cell power triggering maximum Maximum Timing-Advance value (i.e. MS distance) before triggering HO OsmoBSC(config-net)# handover? handover Handover general config <-- unchanged == AFTER: == OsmoBSC(config-net)# list ... handover (0|1|default) handover algorithm (1|2|default) handover1 window rxlev averaging (<1-10>|default) ... handover2 window rxlev averaging (<1-10>|default) ... handover2 retries (<0-9>|default) handover2 congestion-check (disabled|<1-999>|now) <-- no more legacy OsmoBSC(config-net)# handover ? 0 Disable in-call handover 1 Enable in-call handover default Enable/disable handover: Use default (0), remove explicit setting on this node algorithm Choose algorithm for handover decision <-- no more legacy OsmoBSC(config-net)# handover? handover Handover general config <-- unchanged The "Legacy" doc string actually never shows on the VTY console, but it will show in the reference manual. (Even with ALIAS(), a 'handover?' would only show the "Handover general config" doc string, so no loss there from using ALIAS_DEPRECATED().) Change-Id: I86be674d82242f9ca73a4d0040015c1c79f2422d
2018-02-19 16:17:11 +00:00
"Legacy alias for 'handover1': " VTY_DOC \
"Use default (" #DEFAULT_VAL "), remove explicit setting on this node\n");
HODEC1_CFG_ALL_MEMBERS
#undef HO_CFG_ONE_MEMBER
static inline const int a2congestion_check_interval(const char *arg)
{
if (!strcmp(arg, "disabled"))
return 0;
return atoi(arg);
}
static inline const char *congestion_check_interval2a(int val)
{
static char str[9];
if (val < 1
|| snprintf(str, sizeof(str), "%d", val) >= sizeof(str))
return "disabled";
return str;
}
DEFUN_ATTR(cfg_net_ho_congestion_check_interval, cfg_net_ho_congestion_check_interval_cmd,
"handover2 congestion-check (disabled|<1-999>|now)",
HO_CFG_STR_HANDOVER2
"Configure congestion check interval\n"
"Disable congestion checking, do not handover based on cell load. Note: there is one global congestion check"
" interval, i.e. contrary to other handover2 settings, this is not configurable per individual cell.\n"
"Congestion check interval in seconds (default "
OSMO_STRINGIFY_VAL(HO_CFG_CONGESTION_CHECK_DEFAULT) ")\n"
"Manually trigger a congestion check to run right now\n",
CMD_ATTR_IMMEDIATE)
{
if (!strcmp(argv[0], "now")) {
hodec2_congestion_check(gsmnet_from_vty(vty));
return CMD_SUCCESS;
}
hodec2_on_change_congestion_check_interval(gsmnet_from_vty(vty),
a2congestion_check_interval(argv[0]));
return CMD_SUCCESS;
}
static void ho_vty_write(struct vty *vty, const char *indent, struct handover_cfg *ho)
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_ONE_MEMBER(TYPE, NAME, DEFAULT_VAL, \
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) \
if (ho_isset_##NAME(ho)) \
vty_out(vty, "%s" VTY_CMD_PREFIX VTY_CMD " " VTY_WRITE_FMT "%s", indent, \
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_CONV( ho_get_##NAME(ho) ), VTY_NEWLINE);
HO_CFG_ALL_MEMBERS
#undef HO_CFG_ONE_MEMBER
}
void ho_vty_write_bts(struct vty *vty, struct gsm_bts *bts)
{
ho_vty_write(vty, " ", bts->ho);
}
void ho_vty_write_net(struct vty *vty, struct gsm_network *net)
{
ho_vty_write(vty, " ", net->ho);
if (net->hodec2.congestion_check_interval_s != HO_CFG_CONGESTION_CHECK_DEFAULT)
vty_out(vty, " handover2 congestion-check %s%s",
congestion_check_interval2a(net->hodec2.congestion_check_interval_s),
VTY_NEWLINE);
}
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
static void ho_vty_init_cmds(int parent_node)
{
#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
install_element(parent_node, &cfg_ho_##NAME##_cmd);
HO_CFG_ALL_MEMBERS
#undef HO_CFG_ONE_MEMBER
/* Aliases of 'handover' for 'handover1' for backwards compat */
#define HO_CFG_ONE_MEMBER(TYPE, NAME, DEFAULT_VAL, VTY0, VTY1, VTY2, VTY3, VTY4, VTY5, VTY6) \
install_element(parent_node, &cfg_ho_##NAME##_cmd_alias);
HODEC1_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
#undef HO_CFG_ONE_MEMBER
}
void ho_vty_init()
{
ho_vty_init_cmds(GSMNET_NODE);
install_element(GSMNET_NODE, &cfg_net_ho_congestion_check_interval_cmd);
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_vty_init_cmds(BTS_NODE);
}