Project

General

Profile

Feature #2397

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

Added by dexter 9 months ago. Updated 17 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
07/24/2017
Due date:
% Done:

20%

Resolution:

Description

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
Blocks OsmoMSC - Feature #1609: Inter-BSC hand-over is missing (MSC side) In Progress 11/21/2016 11/21/2016

History

#1 Updated by dexter 9 months ago

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

#2 Updated by dexter 9 months ago

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

#3 Updated by neels 9 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():
https://git.osmocom.org/osmo-iuh/tree/src/iu_client.c#n611
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.
https://git.osmocom.org/osmo-iuh/tree/src/iu_client.c#n293

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:
https://git.osmocom.org/osmo-iuh/tree/src/iu_client.c#n134

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 5 months ago

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

#5 Updated by laforge 5 months ago

  • Priority changed from Low to Normal

#6 Updated by neels 28 days ago

  • Blocks Feature #1609: Inter-BSC hand-over is missing (MSC side) added

#7 Updated by dexter 23 days ago

  • 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

#8 Updated by laforge 23 days ago

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
as well.

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.

#9 Updated by dexter 17 days ago

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.

Also available in: Atom PDF