Inter-BSC hand-over is missing (MSC side)
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.
- File 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.
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.
On Mon, Mar 12, 2018 at 08:23:45PM +0000, dexter [REDMINE] wrote:
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,
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.
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?
- just LAC
#13 Updated by laforge about 18 hours ago
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:
- just LAC
you simply discard the MCC,MNC + CI from those and do the lookup on the LAC