Feature #2397

let osmo-msc record location area from location update for LAC wide paging

Added by dexter 8 months ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:




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.

Related issues

Related to OsmoMSC - Feature #2289: implement AoverIP (OsmoMSC side) Closed 05/24/2017


#1 Updated by dexter 8 months ago

  • Related to Feature #2289: implement AoverIP (OsmoMSC side) added

#2 Updated by dexter 8 months ago

@neels: You solved a similar problem for 3G. Is the described idea above coherent to your solution?

#3 Updated by neels 7 months ago

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

#4 Updated by laforge 3 months ago

  • Project changed from OpenBSC to OsmoMSC
  • Category deleted (OpenBSC)

#5 Updated by laforge 3 months ago

  • Priority changed from Low to Normal

Also available in: Atom PDF