Bug #2283

Inter-BSC hand-over is missing (BSC side)

Added by laforge 10 months ago. Updated about 20 hours ago.

In Progress
A interface
Target version:
Start date:
Due date:
% Done:


Spec Reference:


We would like to have inter-BSC hand-over support on the A interface, and test that with the related inter-BSC hand-over support in OsmoMSC (see #1609)

Related issues

Related to OsmoMSC - Feature #1609: Inter-BSC hand-over is missing (MSC side) New 11/21/2016 11/21/2016


#1 Updated by laforge 10 months ago

  • Related to Feature #1609: Inter-BSC hand-over is missing (MSC side) added

#2 Updated by laforge 7 months ago

#3 Updated by laforge 5 months ago

  • Priority changed from Normal to Urgent

#4 Updated by laforge 5 months ago

#5 Updated by laforge 5 months ago

#6 Updated by laforge 5 months ago

  • Assignee changed from sysmocom to dexter

#7 Updated by dexter 4 months ago

There is not much done here yet. I am currently reading the specification when there is some spare time.

Since we start at the BSC we can either be in the situation of the BSC that hands the subscriber over, or we can be in the situation of the BSC that receives the subscriber. Given that the MSC is controling the two BSCs independently and the two BSC never talk to each other (its only a MSC<==>BSC SCCP link) we should probably simulate this two cases separately.

#8 Updated by laforge 3 months ago

  • Category set to A interface

#9 Updated by laforge 3 months ago

  • Status changed from New to Stalled

let's stall this issue until we have a test case in the BSC tester against which we can test the development.

#10 Updated by dexter about 1 month ago

Note: This problem should be fixed with the GSCON FSM, but in its current state it does not yet support any type of handover (see also #2823)

#11 Updated by laforge about 1 month ago

  • Status changed from Stalled to New
  • Assignee changed from dexter to neels

#12 Updated by laforge about 1 month ago

so we have two parts to this:

a) BSC is handing the connection out
b) BSC is handing the connection in

Outbound from BSC

For the outbound case, we need to:

Handover decision

  • advertise "foreign" neighbor cell ARFCNs
  • determine if a candidate in the neighbor list / measurement results is a local or a foreign cell
  • in case of local cells, behave like before
  • in case of a good foreign cell candidate, start outbound handover

Handover execution

    • MSC may legally ignore those requests, we need to retransmit periodically (T7?)
    • forward it to BTS/MS over old channel
  • clear channel on BSSMAP CLEAR COMMAND from MSC (which we already do, unrelated to HO)
    • mgw state is cleared at this normal CLEAR COMMAND as usual

Inbound Handover

  • accept SCCP connection from MSC
    • allocte lchan like in intra-BSC handover or on assignemnt command
    • build RR Handover Command message with channel description of allocated lchan
  • respond with BSSMAP HANDOVER REQUEST ACK (containing HO CMD)
  • wait for access bursts, RR HANDOVER ACCEPT on new lchan
  • wait for LAPDm establishment on new lchan

#13 Updated by neels 25 days ago

  • Status changed from New to In Progress

I have started to warm up to the ttcn3-testsuite, which shall feature a test to trigger inter-BSC handover and verify that osmo-bsc sends all the right messages to the (as yet virtual) MSC.
Will base the new test upon copying BSC_Tests.TC_int_ho and expanding from there.

#14 Updated by neels 24 days ago

It doesn't really make sense to write code for this before two ongoing efforts are merged:

  1. the cell identifier list, worked on by stsp, see This changes the API to compose cell identifier lists, to be used in the Handover Required message sent to the MSC for inter-BSC handover.
  2. the gscon FSM in osmo-bsc, worked on by pmaier, see . This changes the logic around events happening for a subscriber connection.

Both would require a considerable part of the code to be refactored if they get merged before I'm done, or if I were first, would complicate merging those other patches. Particularly the gscon patch is likely to substantially change where to trigger events from...

It's better to wait for those to be merged and start on that basis, placing new code in all the right places to begin with.

#15 Updated by neels 24 days ago

  • Status changed from In Progress to Stalled

#16 Updated by laforge 24 days ago

Seems like a great opportunity not to stall this issue but to work on first writing the tests before writing the actual bsc code

#17 Updated by neels 23 days ago

I can try, but since ttcn3 is new to me I will probably write nonsense without ongoing verification.

#18 Updated by neels 2 days ago

  • Status changed from Stalled to In Progress
  • % Done changed from 0 to 20

I have started off with trivial message composition and ttcn3 tests for only the BSC side.
(So far it's all crammed in BSC_Tests.ttcn, bound to change probably)

I could use some help with the ttcn3:

  • In f_tc_ho_out_of_this_bsc(),
    • How do I expect that RR Handover Command to go out towards the MS? One problem is that it is running on the wrong entity,
      the other is apparently the message type. I was expecting IPA_RSL but that doesn't seem to like the RR message.
      So I need compose some RSL_Message with IEs in it containing the RR??
    • The test fails at the final BSSAP.receive(tr_BSSMAP_ClearComplete); When I omit that it currently actually passes this WIP state. With the Clear Complete I get:
      "BSSMAP_Emulation.ttcn:392 Dynamic test case error: Sending data on the connection of port CLIENT to 10:BSSAP failed. (Broken pipe)"
      How do I get rid of this failure?
  • In f_tc_ho_into_this_bsc()
    • I send a first Handover Request from the MSC by using f_bssap_tx_ud() like in the paging tests.
      I see this Handover Request in the trace, yay. But I seem to continue in the wrong way from there,
      because I get this error from f_start_handler(), i.e. from code that should Just Start the Test(TM):
      "BSC_Tests.ttcn:1405 Dynamic test case error: Using the value of an unbound component reference."
      function f_start_handler(void_fn fn, charstring id) runs on test_CT return MSC_ConnHdlr {                 
              var MSC_ConnHdlr vc_conn;                                                                         
              vc_conn := MSC_ConnHdlr.create(id);                                                               
              connect(vc_conn:BSSMAPEM, g_bssap.vc_BSSMAP:PROC);                 <------ on this line

      When I try to debug the unboundness with a log() I can't get anything loggable besides vc_conn, which logs just
      Is there something obvious I can fix there?

#19 Updated by neels 1 day ago

Another basic question: how do I get proper identification of the neighbor cell to the MSC?
The measurement reports see which ARFCN and BSIC would be suited.
But towards the MSC, I need to communicate like a LAI and Cell ID. How do I get from ARFCN+BSIC to a LAI?

Possible neighbor cell identification I can send to the MSC are:
  • CGI
  • LAC+CI
  • LAI
  • just LAC

Do we need to add manual config to osmo-bsc to have a table to convert BSIC to LAI?

#20 Updated by neels 1 day ago

how do I get proper identification of the neighbor cell to the MSC?

48.008 "Generation of the HANDOVER REQUIRED message" has to say only this:

[...]the "Cell Identifier List (preferred)" shall identify "n" preferred cells. The
identified cells are given in order of preference. The algorithm by which the BSS produces this list is Operator
dependent and is not addressed in the present document.

So it seems that we indeed have to invent a way how the BSC knows about neighbor BSSs' ARFCN+BSICs,
translate those to LAC+CI to send to the MSC in the Cell Identifier List.

(And also teach the MSC which LAC+CI are served by which BSS that have happened to connect via A, as commented over in #1609.)

#21 Updated by neels 1 day ago

Hope it's the right way: I've added a fairly trivial list of ARFCN+BSIC -> Cell Identifier List mapping configurable in the config VTY, so that an ARFCN+BSIC that is not known in the local BSS can be resolved to a Cell Identifier List to send to the MSC. It's possible to add multiple entries, but I guess in practice the Cell Identifier List will have only one entry; The list struct is already useful to allow setting an entry of any of the types in that union, and that struct is also what the "Handover Required" API expects.

#22 Updated by laforge about 20 hours ago

On Wed, Mar 21, 2018 at 11:50:38PM +0000, neels [REDMINE] wrote:

Another basic question: how do I get proper identification of the neighbor cell to the MSC?

out-of-band configuration.

Do we need to add manual config to osmo-bsc to have a table to convert BSIC to LAI?

yes. "Normally" the "OMC" would do that as per the 3GPP architecture. The OMC is where
you enter all your BTSs and related network configuration, and it then generates configuration
for all the BSCs. All aspects of this, including related protocols are implementation specific.

I believe there's an SCCP sub-system number for BSSOMAP (BSS organization and maitenance protocol) but no
actual definition, i.e. every vendor could do what they want, whether SCCP based or not.

I would suggest whatever we do for definition of those LAC lists per
BSC, we should make sure it's a properly self-contained part of code,
[to possibly put it in one of our libraries, if needed, not sure?] and
make sure there's a [tested] VTY + CTRL interface for it. This way we
keep the path open for a later central tool that would then push the
related configs.

For now, I guess our assumption is that we're not running a
self-organized network and hence the configuration is rather static.
This means that one can suggest to use some generic configuration file
templating mechanism in larger production deployments, as some of the
sysmocom customers are already using for years.

Also available in: Atom PDF