External interface to CGI latitude/longitude database

[vetss]

GMLC now can only obtain LAC / CellId values from GSM network for mobile suscribers.
If we need to get lattitude / longitude valies for a subscriber we need to get somehow lattitude / longitude values for each cell with LAC / CellId.

I suggest to implement for this an external interface that will request such data fom an external database.

The details of the interface API we need still to discuss.

[FerUy]

On SS7 based mobile core networks, agreed for 2G (GSM), as we only have MAP ATI to retrieve GCI (Global Cell Identification) including CI (Cell Id), LAC (Location Area Code) and other location information parameters like MCC, MNC, age of location info (as we are already achieving with GMLC). So, the only way to provide geographic coordinates in that scenario (with a big accuracy error margin) is the way you mention.

However, for 3G (UMTS and beyond), we need to implement two further SS7 operations: MAP SRIforLCS (Send Routing Information for Location Services) and MAP PSL (Provide Subscriber Location) and MAP SLR (Subscriber Location Report). If there's a Standalone SMLC in the MNO's core network, the MAP PSL will trigger procedures between the SMLC and UTRAN (UMTS Terrestrial Radio Access Network) to obtain location information including geographic coordinates of the involved user equipment (not the base station) and will inform it back to the GMLC.

For 4G LTE, it's conceptually the same, but in this context Diameter procedures are needed as per 3GPP TS 29.172/29.173.

[Vanit]

I'm interested in seeing some progress on this so I've started researching what an RA for this might look like.

Is there a good reference for a preferred "restcomm style" JCA RA? Is this one https://github.com/RestComm/jain-slee.javaee?

[angrygreenfrogs]

@monix I'd like to suggest we start by creating an interface to MLS (https://location.services.mozilla.com/api)

Their API is open, easy to use, and has a great stumbler mobile app for assisting users with adding local cells to the database.

@FerUy I'm thinking to assign this one over to @monix ?

[FerUy]

OK @angrygreenfrogs.

Just to be clear, this issue will only involve CGI - lat/long conversion, right?

I just don´t want to mix up concerns when we have location estimate and CGI data on 3G and LTE location services (in best case scenario, we'll both have lat/long of the target mobile equipment and CGI information -Cell ID, LAC, MCC, MNC- of the base station or (e)nodeB which is providing radio service, which are different geographic points). Having this clear, this enhancement could be very powerful and cover many use cases covered in Restcomm Geolocation API definition.

[Vanit]

All good, Firefox MLS sounds fine. Frankly though, choosing and implementing the EIS is the easy part.

Am I right in assuming we should be using the JCA Resource Adapter architecture for this?

[FerUy]

Hi @monix. On using the JCA Resource Adapter architecture for this, I would frankly like @deruelle and @vetss opinion.

Just in case, on the rest we are on the same page, right?

[Vanit]

@FerUy You might need to clarify that sorry! Are you talking about keeping the cell x/y from this integration separate from any other location that may be returned by the other protocols?

[FerUy]

Hi @monix, what I am saying is that either in 3G or LTE location procedures, the response may contain a location estimate in latitude/longitude which is the calculation of the current position of the user equipment made by several antennas. Along with that location information in geographic coordinates, the GCI (Cell Id, LAC, MCC, MNC) may also come in the response. So, you will have the information of a regular MAP ATI plus a location estimate of the current position of the target equipment. Hence, we must take into consideration this so we don't mix concerns.

The implementation regarding this issue is about matching GCI with their latitude/longitude. Are we on the same page now?