Feature #1608

hand-over betwen TCH/H and TCH/F during call based on load / quality

Added by laforge over 2 years ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spec Reference:


If a cell gets loaded more, it may make sense to migrate existing calls to half-rate channels by intra-BTS hand-over.

Related issues

Related to OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typesStalled2016-07-21

Related to OsmoBSC - Bug #3002: HO2: handover decision for dynamic timeslotsNew2018-02-26


#1 Updated by laforge 10 months ago

#2 Updated by laforge 9 months ago

  • Assignee set to neels

#3 Updated by laforge 9 months ago

  • Priority changed from Normal to High

#4 Updated by laforge 9 months ago

  • Priority changed from High to Urgent

#5 Updated by neels 9 months ago

I'm not starting on this yet, please let me know in case I should start on this before completing #2618 / #2638

#6 Updated by neels 9 months ago

  • Related to Feature #1778: avoid mismatching TCH/F vs TCH/H pchan types added

#7 Updated by laforge 8 months ago

  • Project changed from OpenBSC to OsmoBSC
  • Category deleted (libbsc)

#8 Updated by laforge 8 months ago

  • Category set to Handover

#9 Updated by neels 6 months 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

 handover 1
 handover algorithm 2

and see various handover2 * config options

#10 Updated by laforge 3 months ago

neels wrote:

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".

#11 Updated by laforge 3 months ago


#12 Updated by neels 3 months 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.

#13 Updated by neels 3 months ago

  • Checklist item define scenarios added
  • Checklist item test in ttcn3 added

#14 Updated by neels 3 months ago

  • Related to Bug #3002: HO2: handover decision for dynamic timeslots added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)