let osmo-msc record location area from location update for LAC wide paging
The MSC is responsible to issue the paging commands to the BSS (BSC), it should know which BSC has which location area under its control in order to support LAC wide paging at some point. Since we automatically discover the BSCs we also need to discover automatically which location are is behind which MSC. The location area becomes known with the first location update a random phone is doing. We could just update a list with location areas we have got location area updates from. This list can than be used to find out which BSC, handles which location area.
In 3G we pass a subscriber's currently known LAC (in RAM in the VLR) to ranap_iu_page_cs(), which calls iu_page():
This iterates the connected RNCs (like BSC but for 3G) and transmits a paging request to its sccp address.
Each RNC's LAC is indeed picked up from a UE's InitialUE message, i.e. when a subscriber first shows up.
You'll see in iu_rnc_register() that we're so far undecided what to do if a UE sends a LAC that mismatches the LAC we've previously recorded for the same RNC:
If we're following 3G, a similar way could be implemented for A.
I believe there has once been talk about a common table of LACs across 2G BSCs and 3G RNCs, but the way the iu_client.c (recently moved to osmo-iuh.git) looks, it would be rather intricate to combine the two sensibly. We'd have to move the RNC lookup somehow back to osmo-msc.git, while an osmo-msc without Iu support can't really even know the rnc data type... Plus the SGSN uses the same code to page on IuPS, so then again we can't really move it out of osmo-iuh without creating code dup... I guess not worth the trouble to combine.
In an aside, with 3G, once we've sent the paging to an RNC with a given LAC, that RNC is practically our single OsmoHNBGW, which again needs to know which Iuh link corresponds to which LAC. OsmoHNBGW so far doesn't collect LACs at all, so in 3G we anyway end up paging on all Iuh links (For OsmoHNBGW, the standard procedure is to page everywhere when the first LAC didn't work, so it's not really that harmful I guess).
- Status changed from New to In Progress
- % Done changed from 0 to 20
I made some draft implementation that collects lac information from layer3compl messages. The context information is collected in a list in struct gsm_network. The reason why it is separate from the bsc_context information is because the same list also should be used by the Iu part in the future as well. I also added A vty command to introspect the collected information. The table does not necessarily have to be filled by the layer3compl messages. It also can be pre-filled manually using the VTY.
See also: pmaier/lac
On Tue, Apr 03, 2018 at 04:56:09PM +0000, dexter [REDMINE] wrote:
The reason why it is separate from the bsc_context information is
because the same list also should be used by the Iu part in the future
I'm really not sure it's worth adding yet another list, sorry :/
The rationale you are giving is one for further merging the A and Iu
code. There is really nothing different from collecting bsc_contexts
to collecting the analogous for Iu. The MSC also needs a list of RNCs
with their LAC/RAC, just like it needs it for A.
We can change the way of storing the LAC information of course, but I suggest to discuss the problem tomorrow together with neels.
Neels and me worked out the following requirements:
- Collect LAC / Pointcode tuples automatically during L3 COMPL (and the Iu equivalent)
- Allow making manual entries via VTY
- Allow deleting manual (and automatically) created entries via VTY
- Safe only entries that were entered manually
Probably we can have it all in one list. However, we need some more flags, but in general that is a good idea. I think the way to go here is to first unify the structs that handle A and Iu and then we add unify the lists.