Feature #1609
closedInter-BSC hand-over is missing (MSC side)
Added by laforge about 8 years ago. Updated almost 5 years ago.
100%
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.
Files
| messages.txt | messages.txt | 2.71 KB | dexter, 01/08/2018 08:33 PM | ||
| first_ever_inter_bsc_ho_with_osmo_msc.pcapng | first_ever_inter_bsc_ho_with_osmo_msc.pcapng | 3.75 MB | neels, 03/14/2019 03:01 AM |
Related issues
Updated by laforge about 7 years 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
Updated by laforge almost 7 years ago
- Subject changed from Inter-BSC hand-over is missing to Inter-BSC hand-over is missing (MSC side)
Updated by laforge almost 7 years ago
- Related to Bug #2283: Inter-BSC hand-over is missing (BSC side) added
Updated by dexter over 6 years ago
- File messages.txt messages.txt added
(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.
Updated by dexter about 6 years 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.
Updated by laforge about 6 years 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.
Updated by neels about 6 years 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?
- CGI
- LAC+CI
- LAI
- just LAC
Updated by laforge about 6 years 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.
- 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
Updated by dexter about 6 years ago
We do not record the LAC from the location updates yet, but there is a ticket for that #2397
Updated by dexter about 6 years 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
Updated by neels about 6 years 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)
- 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.
- 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)
Updated by neels about 6 years 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.
Updated by neels about 6 years ago
- Blocked by Feature #2397: let osmo-msc record location area from location update for LAC wide paging added
Updated by dexter about 6 years 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.
Updated by dexter about 6 years 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.
Updated by dexter almost 6 years ago
- Status changed from In Progress to Stalled
Updated by laforge over 5 years ago
- Tags set to Inter-MSC HO
- Assignee deleted (
dexter) - Priority changed from Low to Normal
Updated by laforge over 5 years ago
- Blocks Feature #3618: Inter-MSC hand-over support added
Updated by laforge over 5 years ago
- Related to Feature #3621: TTCN-3 test suite for inter-BSC handover added
Updated by neels over 5 years ago
- Blocked by Bug #3355: OsmoMSC doesn't provide unique IDTAG_SERNR in IPA CCM added
Updated by neels over 5 years ago
Blocked by #3355 because in order to invent how to configure BSS' cell identifiers in osmo-msc.cfg, I need to know how OsmoMSC instances are going to be identified.
I want to avoid implementing something for inter-BSC HO just to notice that it clashes with inter-MSC HO, so first want this resolved.
Updated by neels over 5 years ago
Re above charts about a parent FSM and individual Conns:
3GPP TS 49.008 4.3 "Roles of MSC-A, MSC-I and MSC-T" defines different MSC roles that so far we handle in a single MSC, but may be spread across MSCs.
The inter-BSC HO FSMs are (probably) already going to be modeled according to that, i.e.
- an MSC-I FSM for an established BSSMAP connection,
- another MSC-T FSM for a new connection,
- and an MSC-A FSM to orchestrate MM using events that match the E-interface definition (the MAP messages between separate MSCs).
Updated by neels over 5 years ago
- Related to Feature #3236: Rx Assignment Failure from BSC does nothing added
Updated by msuraev over 5 years ago
- Related to Feature #3659: handover during LCLS directly between BTSs added
Updated by neels about 5 years ago
- Status changed from Stalled to In Progress
- % Done changed from 0 to 40
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
Updated by neels about 5 years ago
- File first_ever_inter_bsc_ho_with_osmo_msc.pcapng first_ever_inter_bsc_ho_with_osmo_msc.pcapng added
- % Done changed from 40 to 80
First ever inter-BSC HO with osmo-msc worked!
Historical pcap attached.
The remaining bit is about grooming patches and getting them merged.
Updated by neels about 5 years ago
after some fixes to osmo-bsc, now inter-BSC handover with osmo-msc also works when Ciphering is enabled.
osmo-bsc patches pending.
Updated by neels about 5 years ago
- Related to Bug #3871: osmo_scu_prim conn_id should be scoped per-user and direction, and should not correlate with the local-reference spoken on the SCCP wire added
Updated by neels almost 5 years ago
- % Done changed from 80 to 100
Inter-BSC Handover support is now merged to osmo-msc master
Updated by neels almost 5 years ago
- Status changed from In Progress to Resolved
