| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: I4f9d6b59c4f4a0550fb6a386342be55dcd777de8
|
|
Related: OS#3487
Change-Id: I1639efb2dbcca4f0e9c33a74f3067606ce5f4209
|
|
These indicators are a legacy of early handover_decision_2.c work, where there
were no separate handover1 and handover2 config commands. No need to restate
the abundantly obvious anymore.
Change-Id: Id4d29542f7dd5bd125d6f10c7783569f13092612
|
|
Change-Id: Ie98a68de207aea69befd24af3f302b6ef9e6f8e4
|
|
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
|
|
Handover decision 2 arguments are now configured by 'handover2 foo'. To match
that scheme, rename the previously 'handover foo' args for handover decision 1
to 'handover1 foo'.
For backwards compatibility, still provide aliases of the original VTY
commands. Writing back the config will result in 'handover1' though.
Change-Id: I7305ae7c04cc70082cd80d42b2ba32ffa399f51a
|
|
Change-Id: Ie597eae82722baf32546331e443dd9d94f1f25e6
|
|
Do not share config items between the current handover decision and the
upcoming handover_decision_2.
Rename current handover config items to hodec2_* and duplicate the ones
relevant to handover decision algorithm 1 with name prefix of hodec1_*.
I considered moving hodec2 parameters to an entirely separate .c file and
struct, but that causes considerable code bloat. Rather use the nice
handover_cfg net/bts level mechanism as-is, and simply prefix the names.
In the VTY, the hodec1 parameters are configurable by 'handover foo 23'
commands, while the hodec2 parameters are by 'handover2 foo 23'. The generic
VTY commands to enable/disable handover and to choose the algorithm are still
'handover (0|1)' and 'handover algorithm (1|2)'.
(Note, a subsequent commit will rename the 'handover foo' for hodec1 to
'handover1 foo' and add backwards-compat aliases.)
For example, the 'window rxlev averaging 5' command now exists both for
handover decision 1 and handover decision 2, and its values are independent.
This is valid config:
network
# set up handover decision algorithm 1
# (pending rename of these items to 'handover1 ...')
handover window rxlev averaging 5
handover window rxlev neighbor averaging 5
# set up handover decision algorithm 2
handover2 window rxlev averaging 7
handover2 window rxlev neighbor averaging 7
handover2 penalty-time max-distance 10
# enable handover
handover 1
bts 0
handover algorithm 1
bts 1
handover algorithm 2
In this example, bts 0 uses algo 1 with rxlev averaging of 5, while bts 1 uses
algorithm 2 where rxlev averaging of 7 is in effect.
Change-Id: I6475b2543b18d21710a6d774b214cb484f36ec8e
|
|
Change-Id: I8811ee8a75be09048042b511ee4bd9bc1de63976
|
|
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
|
