Bug #2283

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

Added by laforge 10 months ago. Updated about 12 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 4 months ago

#6 Updated by laforge 4 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 29 days ago

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

#12 Updated by laforge 29 days 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 24 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 23 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 23 days ago

  • Status changed from In Progress to Stalled

#16 Updated by laforge 22 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 21 days ago

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

#18 Updated by neels about 12 hours 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?

Also available in: Atom PDF