Project

General

Profile

Actions

Bug #2283

closed

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

Added by laforge almost 7 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
A interface
Target version:
-
Start date:
05/22/2017
Due date:
% Done:

100%

Spec Reference:

Description

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)Resolvedneels11/21/201611/21/2016

Actions
Related to OsmoBSC - Feature #1749: add activation timeout in bsc_handover_start()Resolvedneels06/13/2016

Actions
Related to OsmoBSC - Bug #3211: gscon breaks dynamic timeslots: TCH/F_TCH/H_PDCH cannot switch from PDCH to TCHResolvedneels04/24/2018

Actions
Related to OsmoBSC - Feature #3505: ttcn3: test inter-BSC HO with encryption enabledNewneels08/28/2018

Actions
Related to OsmoBSC - Bug #3839: inter-BSC Handover lacks AoIP Transport Layer Address, i.e. only works with SCCPliteResolvedneels03/14/2019

Actions
Blocked by OsmoBSC - Bug #3296: TCH lchan allocation is non-modular and also riddled with holesResolvedneels05/28/2018

Actions
Blocked by OsmoBSC - Bug #3351: OML Channel OPSTART ACK of bts 1..N all end up handled for bts 0Resolvedneels06/15/2018

Actions
Actions #1

Updated by laforge almost 7 years ago

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

Updated by laforge over 6 years ago

Actions #3

Updated by laforge over 6 years ago

  • Priority changed from Normal to Urgent
Actions #4

Updated by laforge over 6 years ago

Actions #5

Updated by laforge over 6 years ago

Actions #6

Updated by laforge over 6 years ago

  • Assignee changed from 4368 to dexter
Actions #7

Updated by dexter over 6 years 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.

Actions #8

Updated by laforge over 6 years ago

  • Category set to A interface
Actions #9

Updated by laforge about 6 years 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.

Actions #10

Updated by dexter about 6 years 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)

Actions #11

Updated by laforge about 6 years ago

  • Status changed from Stalled to New
  • Assignee changed from dexter to neels
Actions #12

Updated by laforge about 6 years 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

  • 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
Actions #13

Updated by neels about 6 years 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.

Actions #14

Updated by neels about 6 years 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 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.

Actions #15

Updated by neels about 6 years ago

  • Status changed from In Progress to Stalled
Actions #16

Updated by laforge about 6 years 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

Actions #17

Updated by neels about 6 years ago

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

Actions #18

Updated by neels almost 6 years 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.
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?
Actions #19

Updated by neels almost 6 years 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?

Actions #20

Updated by neels almost 6 years ago

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

Actions #21

Updated by neels almost 6 years 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.

Actions #22

Updated by laforge almost 6 years 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.

Actions #23

Updated by neels almost 6 years ago

  • Related to Feature #1749: add activation timeout in bsc_handover_start() added
Actions #24

Updated by neels almost 6 years ago

  • Related to Bug #3211: gscon breaks dynamic timeslots: TCH/F_TCH/H_PDCH cannot switch from PDCH to TCH added
Actions #25

Updated by neels almost 6 years ago

  • Blocks Feature #3277: handover: for intra-cell re-assignment, use Assignment procedure, not Handover added
Actions #26

Updated by neels almost 6 years ago

  • Blocked by Bug #3296: TCH lchan allocation is non-modular and also riddled with holes added
Actions #27

Updated by neels almost 6 years ago

  • % Done changed from 20 to 80
Actions #28

Updated by neels almost 6 years ago

  • Blocked by Bug #3351: OML Channel OPSTART ACK of bts 1..N all end up handled for bts 0 added
Actions #29

Updated by neels over 5 years ago

  • Blocks deleted (Feature #3277: handover: for intra-cell re-assignment, use Assignment procedure, not Handover)
Actions #30

Updated by neels over 5 years ago

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.

Actions #31

Updated by neels over 5 years ago

  • Related to Feature #3505: ttcn3: test inter-BSC HO with encryption enabled added
Actions #32

Updated by neels over 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

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"

Actions #33

Updated by neels about 5 years ago

  • Related to Bug #3839: inter-BSC Handover lacks AoIP Transport Layer Address, i.e. only works with SCCPlite added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)