various handover improvements, meta-issue
This issue ended up soaking in too much complexity and now just serves as a "related" hook for more concise issues.
#9 Updated by neels over 1 year ago
- % Done changed from 0 to 50
handover_decision_2.c which was recently merged does in fact include re-assignment and handover while changing the TCH type. It also employs an AFS bias, i.e. to handover half rate to full rate to improve the quality. Will keep this issue open as a reminder to somehow test how well this works in practice.
to enable, configure osmo-bsc with
network handover 1 handover algorithm 2
and see various handover2 * config options
#10 Updated by laforge about 1 year ago
Will keep this issue open as a reminder to somehow test how well this works in practice.
please create a separate ticket about missing automatic testing. We need proper TTCN-3 tests for all kinds of handover scenarios in the BSC, but that's not what this ticket was about originally. Also, this ticket is certainly not "New".
#12 Updated by neels about 1 year ago
- Status changed from New to Stalled
From my viewpoint, even though I haven't even started looking at and testing this specific aspect, the code we got "for free" from jolly's load-based HO code is already merged...
Hence I ended up with "New" and "50%". From outside this must surely look insane, yes.
ok then ...
The preliminary implementation is in handover algorithm 2.
We need testing in TTCN3, possibly also osmo-gsm-tester. Generally, testing by ttcn3 seems to make most sense, since for manual tests, we need to jump through hoops to make the equipment pick the desired lchans and then make those appear switch-worthy. In ttcn3 we can simply make up exactly the physical scenario we want to test in the messages sent.
Even though we have some code, we need to first decide what should be happening.
The precise scenarios to change between TCH/F and TCH/H are non-trivial and currently under-specified.
Here are some short notes/questions about scenarios that need refining:
- If we set min-free-tch-f, here is a scenario to test:
A cell has min-free-tch-f = 1, i.e. we want at least one TCH/F to remain open.
A new call could come in and pick the last remaining TCH/F slot.
Once the TCH/F lchan is used, the handover decision 2 algorithm notes that we now have 0 free TCH/F but want 1 free TCH/F.
Hence it would trigger re-assignment or handover to make one TCH/F free again.
This might go to a neighbor cell (if any), or re-assign to TCH/H within the cell.
- In previous point, we'd be a bit clumsy in first assigning TCH/F, using that for a few seconds and then re-assigning,
when we might have decided for TCH/H to begin with. (out of scope here?)
- Bad quality scenario: rxlev is ok, but rxqual drops below the min_rxqual threshold.
To test for this with real equipment, we could manipulate the min_rxqual threshold during a call.
In ttcn3, we could use measurement reports.
Handover decision 2 contains a switch from TCH/H to TCH/F to improve rxqual. See on_measurement_report() in handover_decision_2.c, by the comment "Bad Quality".
However, that condition seems buggy: "if (... av_rxqual > ho_get_hodec2_min_rxqual(bts->ho))" should probably be the flipped?
- To help against interference (good rxlev, low rxqual) it might even make sense to just go to a different timeslot with the same TCH kind.
Currently we explicitly avoid re-assigning to the same TCH kind though. (out of scope here?)
- Without 'min-free-slots' configured:
If a cell has TCH/H slots and TCH/F slots, and all TCH/F slots are busy, a new call being established would just go ahead and use a TCH/H slot, not needing re-assignment at all?
- If a new call is incapable of TCH/H, should that trigger another ongoing TCH/F to be re-assigned to TCH/H, to make space for the new call?
(out of scope here? so far we have no handover triggered by new calls being established, rather only re-arranging already ongoing TCH lchans.)
- With dynamic timeslots #3002, it could make sense to switch over from TCH/F to TCH/H and make more room.
When the "min-free-slots" for TCH/F is surpassed, that could be a trigger to switch TCH/F to TCH/H.
But at the same time that already is a trigger to ask handover to a different cell.
At which rxlevs do we favor changing to TCH/H vs. intra-BSC handover vs. inter-BSC handover?
For intra-BSC handover we could also take the cell load into account: only change to TCH/H in case the neighbor cells are already heavily loaded as well?
Trade-off by neighbor rxlev?
- If all lchans are in use, and one of them is a dynamic timeslot used as TCH/F, would we be able to take down the call, change over to TCH/H and re-assign? I guess not.
On Mon, Oct 15, 2018 at 10:11:21PM +0000, neels [REDMINE] wrote:
Maybe instead of adding these issue relations I should use a "Handover" tag...?
I would argue to use a Handover category, as categories describe work-areas / features / code-sections
within a given project.