Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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.

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

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)

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¶

• send dBSSMAP HO REQUIRED to MSC
  • MSC may legally ignore those requests, we need to retransmit periodically (T7?)
• receive BSSMAP HANDOVER COMMAND from MSC
  • 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
• receive BSSMAP HANDOVER REQUEST
  • 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
  • send BSSMAP HANDOVER DETECTED to MSC
• wait for LAPDm establishment on new lchan
  • send BSSMAP HANDOVER COMPLETE to MSC

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.

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 https://gerrit.osmocom.org/#/c/6509/. 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 http://git.osmocom.org/osmo-bsc/log/?h=pmaier/fsm3 http://git.osmocom.org/osmo-bsc/log/?h=neels/fsm3 . 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.

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

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

I have started off with trivial message composition and ttcn3 tests for only the BSC side.
http://git.osmocom.org/osmo-ttcn3-hacks/diff/?h=neels/inter-bsc-ho&id=eb15e339b027c22781c0de3347a4514715503792
(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."
    here:
    

    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
    "TC_ho_into_this_bsc(16)"
    Is there something obvious I can fix there?

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?

• 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?

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

48.008 3.1.5.1.1 "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.)

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.

inter-BSC handover is now present in osmo-bsc master, but it is not properly tested yet. All configuration items and implementations are present, but it very likely still "hasn't learnt to walk".

a) pending: I have ttcn3 tests on a branch that I fail to have good progress with, mostly because I'm ttcn3 retarded.

b) pending: testing actual inter-bsc handover with an MSC implementation that supports it.

Tests with an SCCPlite MSC have shown that we now have inter-BSC handover support in osmo-bsc.
This is merged to master as of
commit 5ac4d800e5c104eec8eac99147457c3aa13d8321
Change-Id: Ice37242c90c19adbf0795618fd16fe75f0809317
"inter-BSC HO outgoing: fix L3 forwarding"