Project

General

Profile

Feature #3656

inter-BSC handover outgoing: compose Cell Identifier List from several ARFCN+BSIC

Added by neels about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Handover
Target version:
-
Start date:
10/15/2018
Due date:
% Done:

0%

Spec Reference:

Description

Thinking about inter-BSC handover, I may have made a naive choice when designing the outgoing inter-BSC mechanism:

  • The BSSMAP Handover Required message features a Cell Identifier List to name several remote-BSS target cells.
  • The current implementation associates each ARFCN+BSIC with a Cell Identifier List, and when we consider a given ARFCN+BSIC having good enough RXLEV, we send that ARFCN+BSIC's Cell Identifier List to the MSC.

However, I now think it was more intended like this:

  • We know each remote-BSS ARFCN+BSIC's single Cell Identifier.
  • We see several remote-BSS ARFCN+BSIC having good RXLEV.
  • When asking for handover, we compose a Cell Identifier List, adding each viable ARFCN+BSIC to the list and send that to the MSC.

I have often wondered how one ARFCN+BSIC would in practice correspond to several Cell Identifiers, and now I had a bit of a face-palm moment, realizing I probably put the cart before the horse there.

So maybe we should:

  • Roll back the ability to store several remote-BSS Cell Identifiers per ARFCN+BSIC key
    • in the VTY UI (most urgent).
    • maybe also in the internal neighbor_ident.c storage, in API and code complexity I have introduced (less urgent).
  • Handover decision algorithm 1: collect all remote-BSS neighbors with better RXLEV, if there are more than one -- might even make practical sense when an MS travels to in-between two remote-BSS cells and one of them is overloaded.
  • Handover decision algorithm 2: collect all "ok" remote-BSS neighbors instead of only the best one (algorithm 2 currently does handovers to remote-BSS only upon critical levels). Makes practical sense to find any one remote-BSS neighbor that helps to avert lchan loss due to critically low reception levels: the MS has already moved considerably far out of this BSS and might have several options to camp to. Maybe some of those are overloaded and the alternative ones would save the call.

Related issues

Related to OsmoBSC - Feature #1608: various handover improvements, meta-issueRejected2016-02-23

History

#1 Updated by neels about 1 month ago

  • Related to Feature #1606: hand-over for load distribution among BTSs added

#2 Updated by neels about 1 month ago

  • Related to deleted (Feature #1606: hand-over for load distribution among BTSs)

#3 Updated by neels about 1 month ago

  • Related to Feature #1608: various handover improvements, meta-issue added

#5 Updated by neels about 1 month ago

  • Category set to Handover

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)