gmlc
gmlc copied to clipboard
RestComm
External interface to CGI latitude/longitude database
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.
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.
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?
@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 ?
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.
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?
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?
@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?
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?
@FerUy Yep, totally on the same page here. CGI -> lon/lat is the scope of this task and the proposed RA.
Great @Monix!
Again, on using the JCA Resource Adapter architecture for this, I would like @deruelle and @vetss opinion.
OK... @vetss do you agree in using JCA Resource Adapter architecture for this?
Hello @FerUy @Monix
when we are thinking how to implement it we need to undestand sources from which we can obtain data. It may be http://opencellid.org/ for example or something like this or a local database of an operator. So we need may be to think that it may be different source types and think that we will be able to add easily another source type for this (the architecture of solution must support it). If we support access to opencellid.org it weill be the best too.
For access to SQL databases like MySQL we usually use JDBC Resource Adaptor: http://docs.jboss.org/mobicents/jain-slee/2.5.0.FINAL/resources/jdbc/user-guide/en-US/html_single/
@vetss Exactly my thinking regarding the mixed types of sources. I was hoping we could get away with a generic RA that wouldn't have to care about the actual implementation of the adapter. Is it possible to use a JDBC RA for a local db and an external API (which are the 2 main usecases I think)?
@Monix
Is it possible to use a JDBC RA for a local db and an external API (which are the 2 main usecases I think)?
I think it is achievable. Which kind of "external API" are you going to use ?
@vetss I think we were considering ~~Firefox~~ Mozilla MLS to begin with.
Edit: I need to stop saying Firefox
@vetss MLS is a RESTful API (HTTPS call out w/ a JSON return). I think Lucas is suggesting we could create a cell-id RA that takes in cell information and returns a lat/lon, where internally it could be retrieving that data from a local DB or from the external API. Does that sound like a good approach to you?
Note: Direct to OpenCellID is a fine choice too, but MLS is even better really since it already has opencellid as a data source and also aggregates in other sources.
I like it... @angrygreenfrogs @Monix how much time do you foresee it will take to implement it?
Hard to say @FerUy, we can only work on the project in our spare time and I'm about to assign a pile of other work on to @Monix =). All of that being an excuse to say: roughly some time this month I'm sure.
OK @angrygreenfrogs... Planned for Milestone 2.0.0, just asking for planning sake. Looking forward to seeing that beauty :)