Project

General

Profile

Feature #1609

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

Added by laforge over 2 years ago. Updated 3 months ago.

Status:
Stalled
Priority:
Low
Assignee:
Category:
A interface (general)
Target version:
-
Start date:
11/21/2016
Due date:
11/21/2016
% Done:

0%

Estimated time:
Resolution:

Description

Right now we can only do intra-BTS and intra-BSC hand-over. The networks that we needed to support were happy with that.

Hoewever, for larger networks that use multiple OsmoBSC attached to one MSC, inter-BSC handover is required.

messages.txt messages.txt 2.71 KB dexter, 01/08/2018 08:33 PM

Related issues

Related to OsmoBSC - Bug #2283: Inter-BSC hand-over is missing (BSC side)In Progress2017-05-22

Blocked by OsmoMSC - Feature #2397: let osmo-msc record location area from location update for LAC wide pagingFeedback2017-07-24

Follows OpenBSC - Feature #1845: Full BSC/MSC split in NITB/MSCClosed2016-11-18

History

#1 Updated by laforge over 1 year ago

  • Due date set to 11/21/2016
  • Start date changed from 02/23/2016 to 11/21/2016
  • Follows Feature #1845: Full BSC/MSC split in NITB/MSC added

#2 Updated by laforge over 1 year ago

  • Assignee set to sysmocom

#3 Updated by laforge over 1 year ago

  • Project changed from OsmoNITB to OsmoMSC

#4 Updated by laforge over 1 year ago

  • Subject changed from Inter-BSC hand-over is missing to Inter-BSC hand-over is missing (MSC side)

#5 Updated by laforge over 1 year ago

  • Related to Bug #2283: Inter-BSC hand-over is missing (BSC side) added

#6 Updated by laforge about 1 year ago

#7 Updated by laforge 10 months ago

  • Assignee changed from sysmocom to dexter

#8 Updated by laforge 8 months ago

  • Category set to A interface (general)

#9 Updated by dexter 8 months ago

(While working out test scenarios for the MSC I had to go through the Handover topic too)

The attached file messages.txt contains, what I think is the minimal information that we have to exchange in order to perform an external handover. The messages in the order in which they were exchanged between BSC1, BSC2 and MSC. Most things seem to be pretty clear to me. However there are some open questions (see questionmarks). I think it will not make much sense to develop this on a laboratory setup since the things will get way to complicated then. We should go for TTCN3 here and do only the final tests with real base stations.

#10 Updated by dexter 5 months ago

Started to work out a testcase for TTCN3. My plan is to implement a HANDOVER REQUIRED request in TTCN3 and then implement the handling on the MSC side until I reach the point where the MSC can generate the HANDOVER REQUEST for the target BSC. I am not sure if the TTCN3 test can handle multiple BSC instances yet, maybe that isn't even a problem for the test we could just handover back to the originating BSC.

#11 Updated by laforge 5 months ago

On Mon, Mar 12, 2018 at 08:23:45PM +0000, dexter [REDMINE] wrote:

Started to work out a testcase for TTCN3.

great.

My plan is to implement a HANDOVER REQUIRED request in TTCN3 and then implement the handling on the MSC side until I reach the point where the MSC can generate the HANDOVER REQUEST for the target BSC.

good plan.

I am not sure if the TTCN3 test can handle multiple BSC instances yet,

The entire "BSC simulation stack" is encapsulated in the "BSSAP_Adapter",
of which the MTC_CT (main test component) currently has only one called g_bssap.

If you extend MTC_CT to have a second (or multiple) BSSAP_Adapters, and use
a separate set of SCCP address, M3UA ip/port, ... you end up simulating
multiple BSCs. It should be almost no effort on the TTCN-3 side, with the
primary effort being to configure all your IP/MTP/SCCP layer bits, particularly
on osmo-stp side.

#12 Updated by neels 5 months ago

How does the MSC know which BSC to send the Handover Requested to?
It doesn't seem like the BSCs tell the MSC which LAC or LACs they are responsible for.
How does the MSC tell the BSCs apart, and how does it know where to direct the inter-BSC handover?

It will get a cell identifier list from the BSC in the Handover Required message, containing one or more entries of one of these kinds:
  • CGI
  • LAC+CI
  • LAI
  • just LAC

#13 Updated by laforge 5 months ago

Hi Neels,

a BSC is normally responsible for an entire pool/list of LACs.

As we only serve one MCC/MNC from one MSC, it basically boils down to having a way
to have a per-BSC LAC table.

We are already constructing such a table dynamically as we receive location updates,
and/or even the BSMAP RESET?

Of course it could be a problem if you re-start the MSC, then that table is gone. However,
at that point the entire VLR state is lost and without the subscribers having performed a location
update, you don't know where they are in general.

So it's a trade-off between
  • automatically discovering BSCs and their LACs (at the moment)
  • explicitly configure BSCs and their LACs via VTY (should be an option)
It will get a cell identifier list from the BSC in the Handover Required message, containing one or more entries of one of these kinds:
  • CGI
  • LAC+CI
  • LAI
  • just LAC

you simply discard the MCC,MNC + CI from those and do the lookup on the LAC

#14 Updated by dexter 5 months ago

We do not record the LAC from the location updates yet, but there is a ticket for that #2397

#15 Updated by dexter 5 months ago

  • Status changed from New to In Progress

There is an update on the TTCN3 side: We now have templates for HANDOVER REQUIRED and support for multiple BSC instances:

https://gerrit.osmocom.org/7549 Cosmetic: Update MSC_Tests.cfg
https://gerrit.osmocom.org/7550 MSC_Tests: Add support for multiple BSC
https://gerrit.osmocom.org/7530 BSSMAP_Templates: Add templates for HANDOVER REQUIRED

#16 Updated by neels 5 months ago

Summarizing the above and a discussion on #osmocom:

  • We have a list of connected BSCs, populated by BSSMAP Reset
    • We record all LACs coming in from Complete Layer 3 Information IEs with the respective BSC (#2397).
  • The dynamic list of BSCs and LACs works well as soon as each LAC has been recorded with a Complete Layer 3 message.
    • To allow inter-BSC handover even before a LAC has been recorded dynamically, we also allow adding static entries to the list of BSCs, associating the SCCP Called/Calling Party address with a LAC.
      (In practice, the effect of such static entries can be seen close to zilch, since it is likely that Complete Layer 3 come flooding in on every cell pretty quickly.
      More unusual setups may need such config though -- extreme example is a completely private network with only one subscriber wanting to be handovered across BSCs)
  • We enforce: each BSC can handle N different LACs, but they must be distinct from LACs on other BSCs.
    • if the MSC ever sees that the same LAC reports via multiple BSCs then that should trigger a big fat ERROR message,
    • and this assumption/constraint must be well documented in the manuals
  • the MSC extracts the LAC from the Handover Required message, looks it up in the table of connected BSCs, and forwards the Cell Identifier List to that BSC.
    • If there are multiple LACs in the Cell Identifier List, just take the first match with any connected BSC.
    • If there is a matching LAC with a "static" entry as described above, but that BSC is currently not connected, skip that entry.
    • Future feature: if a BSSMAP Handover Request fails with a given BSC, try the next entry in the list.
      (complexities: stay within timeout of the first BSC giving up; do not try the same BSC multiple times)

#17 Updated by neels 5 months ago

  • We limit ourselves to a single PLMN across the entire network, so no need to handle anything besides LAC yet in the MSC.
    • But I'm thinking, if we get the full CGI in the Complete Layer 3 Info, we might as well record the whole thing already in our list of BSCs.

#18 Updated by neels 5 months ago

  • Blocked by Feature #2397: let osmo-msc record location area from location update for LAC wide paging added

#19 Updated by dexter 4 months ago

I have a draft for the LAC problem ready, however it is not satisfactory yet. See #2397. However, I can now dump the LACs that the MSC has "learned" from the L3 COMPL messages on the VTY. The next thing we need is a TTCN3 test for this. The test I am working on will perform two Location updates from the two different, simulated BSCs. This will let the MSC "learn" the LAC numbers and we can start with the Handover procedure.

On the TTCN3 side the support for the HANDOVER REQUIRED message is complete enough to work with. However I discovered that the "multi BSC support" needs some additional features. There is still some handling missing. At the moment we are able to perform a BSSMAP RESET from two different BSCs, but we yet able to do the same with the LU. When I get the things right we really need two truly independent BSSAP adapters with two independed TTCN3 test ports, so that it is really two independed module instances an not just different BSSAP sender addresses.

#20 Updated by dexter 4 months ago

Notes about Inter-BSC-handover in osmo-msc:

At the moment the subsciber handling is handled by a single osmo fsm,
implemented in subscr_conn.c. The connection related information is held in
struct gsm_subscriber_connection (see gsm_data.h).

In order to handle an Inter-BSC-handover the MSC must be toughtened to handle
two SCCP connections at the same time. Technically the SCCP related connection
data is nearly the same for Iu and A so some unification is desired. (see
struct gsm_subscriber_connection, subsructs a and iu) However, merging the date
whould require fundamental changes to osmo-iuh, so a less dramatic change is
required. In order to reach at least some grade of unification, both substructs
may be put into a separate struct as union, so they could be just used from
gsm_subscriber_connection as (two) normal struct variables.

Unfortunately unifiying those structs alone does not provide an infrastructure
that is sufficient to handle Inter-BSC-handover since we still need to deal
with the two connections. This means depending from where an SCCP message is
received, the right action must be taken and the right data must be altered.

The most logical apporoach to it is to modularize the Subscr_Conn FSM with two
child FSMs that model the up to two active connections:

    +------------------------------------+
    |                                    |
    |   PARENT FSM                       |
    |                                    |
    |   +------------+ +------------+    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   |  CONN #1   | |  CONN #2   |    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   +------------+ +------------+    |    
    |                                    |
    |                                    |
    |                                    |
    +------------------------------------+

At first the Subscr_Conn FSM should be renamed to something that expresses the
relation to mobility management better. We suggest to call it just "MM_FSM" and
the sub FSMs that modle the individual connections are just called C_FSM (or
maybe alternatively CONN_FSM?):

    +------------------------------------+
    |                                    |
    |   MM_FSM                           |
    |                                    |
    |   +------------+ +------------+    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   |  C_FSM #1  | |  C_FSM #2  |    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   |            | |            |    |
    |   +------------+ +------------+    |    
    |                                    |
    |                                    |
    |                                    |
    +------------------------------------+

In general, when it comes to clearing of one connection the child FSM will send
an EV_TERM event to the MM_FSM in order to inform it that the connection has
terminated. The MM_FSM then checks if there is one other open connection
present. If no other connection is present, then the MM_FSM terminates itsself.

We will now discuss the full handover procedure on a flow chart:

RAN #1           C_FSM #1           MM_FSM           C_FSM #2           RAN #2
  |                  |                  |                  |                  |
  | CR+(COMPL L3 +   |                  |                  |                  |
  |(CM SERV. REQ))   |                  |                  |                  |
  |--------------->  |ALLOC             |                  |                  |
  |                  |----------------->|ALLOC             |                  |
  |                  |                  |                  |                  |

        (A call is established,
       regular signalling is
       taking place. Nothing
       handover related yet)

  |                  |                  |                  |                  |
  |    HO RQD        |                  |                  |                  |
  |                  |                  |                  |                  |
  |----------------->|PARSE MSG         |                  |                  |
  |                  |ALLOC FSM         |                  |                  |
  |                  |                  |                  |                  |  
  |                  |   HO RQD STRUCT  |                  |                  |
  |                  |----------------->|                  |                  |
  |                  |                  |----------------->|ALLOC FSM         |
  |                  |                  |                  |                  |
  |                  |                  |  HO REQ STRUCT   |                  |
  |                  |                  |----------------->|GENERATE MSG      |
  |                  |                  |                  |                  |
  |                  |                  |                  |   CR+(HO REQ)    |
  |                  |                  |                  |----------------->|
  |                  |                  |                  |                  |
  |                  |                  |                  |       CC         |
  |                  |                  |                  |<-----------------|
  |                  |                  |                  |                  |  
  |                  |                  |                  |    HO REQ ACK    |
  |                  |                  |         PARSE MSG|<-----------------|
  |                  |                  |                  |                  |

                             (The selected BTS in RAN #2 has
                     now opened a channel and waits
                     for the ms to change over)

  |                  |                  |    HO REQ ACK    |                  |
  |                  |                  |      STRUCT      |                  |
  |                  |                  |<-----------------|                  |
  |                  |   HO CMD STRUCT  |                  |                  |
  |      HO CMD      |<-----------------|                  |                  |
  |<-----------------|                  |                  |                  |
  |                  |                  |                  |                  |    

       (When the MS receives it will
        now change over to the
    selected BTS in RAN #2)

  |                  |                  |                  |      HO DET      |    
  |                  |                  |         PARSE MSG|<-----------------|    
  |                  |                  |                  |                  |
  |                  |                  |  HO DET STRUCT   |                  |    
  |                  |                  |<-----------------|                  |    
  |                  |                  |                  |                  |

                  (At the moment where the handover
             the RTP stream is switched over)

  |                  |                  |                  |                  |
  |                  |                  |                  |                  |
  |                  |                  |                  |     HO COMPL     |    
  |                  |                  |         PARSE MSG|<-----------------|    
  |                  |                  |                  |                  |
  |                  |                  | HO COMPL STRUCT  |                  |    
  |                  |                  |<-----------------|                  |
  |                  |                  |                  |                  |

                   (The handover has been completed,
              now the old SCCP connection has
              to be terminated. The C_FSM #2
              now takes on the role of C_FSM
              #2, we are now ready for another
              handover)

             <!> What happens when the next HO
             is made while we are still clearing?
             probably we might want to implement
             a model where n C_FSMs are permitted?

  |                  |     EV_DESTROY   |                  |                  |
  |                  |<-----------------|                  |                  |
  |    CLEAR CMD     |                  |                  |                  |
  |<-----------------|                  |                  |                  |
  |                  |                  |                  |                  |
  |    CLEAR COML    |                  |                  |                  |  
  |----------------->|                  |                  |                  |
  |                  |                  |                  |                  |
  |       RLSD       |                  |                  |                  |
  |<-----------------|                  |                  |                  |
  |                  |     EV_TERM      |                  |                  |  
  |                  |----------------->|                  |                  |
  |       RLC        |                  |                  |                  |
  |----------------->|DEALLOC FSM       |                  |                  |
  |                  |                  |                  |                  |

                           (The process is done now, the call
                     continues as normal, another handover
                     may occurr.)

The message parsing is implemented inside the C_FSM. The parsed messages are
then passed to the MM_FSM in form of events. The MM_FSM then inspects the
content, takes operational actions (e.g switching over the RTP stream) and
finally sends an appropiate event to the other C_FSM.

This approach is oriented on a 2G handover. A 3G or even a 2G to 3G handover may
look different, but the principle is the same. When the parsing of the messages
is handled in the C_FSM directly and only parsed structs are passed on to the
MM_FSM. Then it should be possible to have a 3G capable C_FSM implementation
(e.g. C_FSM_3G) as well which may be just dropped in at some later point.

#21 Updated by dexter 3 months ago

  • Status changed from In Progress to Stalled

#22 Updated by laforge 3 months ago

  • Priority changed from Normal to Low

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)