Add support for uploading exact BTS GPS locations

[E3V3A]

Background:
We can already upload BTS measurements to OCID, but we cannot tell them when we have an exact GPS position of a certain cell tower. Understandingly, the reason is that it could seriously damage their database. However, the possibility to have exact GPS positions for all BTS in the downloaded data is extremely helpful for our purpose.

In OCID this is provided by the changeable column, which is the opposite as we have in the isGPSexact in our DBe_import table.

MLS does already support both download and upload (?) for exact positions.

What we have to do is:

• (a) Add MLS support to both our BTS Upload and Download code. (See Add Mozilla Location Services (MLS) support #446)
• (b) Allow to manually enter an exact GPS tower position (see Manual GPS location entry to prevent GPS blockage #309), and
• (c) subsequently analyze the position within or App. (I have two very good ideas here.)
• (d) Add appropriate settings for selecting what to download/upload.

As (b,c) would also require an additional DB table, called BtsLoc, I've also added the DATABASE tag to this issue.

Related Issues:
#220, #446, #71, #309

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[E3V3A]

For the finding the exact GPS BTS position there are two methods we can (and should) use. One very simple and one more complex. They are:

1. Guesstimating by visual/manual entry and using OCID/MLS data, with smart SQL queries.
2. By performing a Simulated Annealing analysis on the collected signal strengths.

Perhaps @KatrinaE, @zoulianmp would be interested in helping us out?

[E3V3A]

@ziem Can you help us implement a long press on the map in such a way to automatically add the pressed GPS coordinates to a DB table?

Those entries should be saved in:

CREATE TABLE "BtsLoc" (
    "_id"       INTEGER PRIMARY KEY AUTOINCREMENT,
    "elat"      REAL,           -- Manually Added BTS Lat postition
    "elon"      REAL,           -- Manually Added BTS Lon postition
    "cid_list"  TEXT,           -- A list of "|" separated CIDs in a BBOX around elat/elon
    "cid_guess" INTEGER         -- The best guess of CID at this location
);

Procedure:

1. Long press at a selected point on map
2. Directly add a black (so not to confuse with others) spot on the map (and to the DB table above)
3. If short pressing on already existing spot, make pop- up with two choices:
   • a) Remove/Delete spot
   • b) Move spot by dragging it elsewhere (for better precision).

[E3V3A]

To upload manual GPS positions to MLS, we have to use their Geosubmit Version 2 API which uses JSON for its POST request body. For the field called "source", it should be set to: manual.

source
The source of the position information. If the field is omitted, “gps” is assumed. The term gps is used to cover all types of satellite based positioning systems incl. Galileo and Glonass. Other possible values are "manual" for a position entered manually into the system and "fused" for a position obtained from a combination of other sensors or outside service queries.

As an example:

{"items": [{
    "timestamp": 1405602028568,
    "position": {
        "latitude": -22.7539192,
        "longitude": -43.4371081,
        "accuracy": 10.0,
        "age": 1000,
        "altitude": 100.0,
        "altitudeAccuracy": 50.0,
        "heading": 45.0,
        "pressure": 1013.25,
        "speed": 3.6,
        "source": "manual"
    },
    "cellTowers": [
        {
            "radioType": "lte",
            "mobileCountryCode": 208,
            "mobileNetworkCode": 1,
            "locationAreaCode": 2,
            "cellId": 12345,
            "age": 3000,
            "asu": 31,
            "primaryScramblingCode": 5,
            "serving": 1,
            "signalStrength": -51,
            "timingAdvance": 1
        }
    ],
}]}

Perhaps @hannosch can enlighten us to what minimum JSON entries are required for a successful BTS position upload?

[E3V3A]

To upload exact cell positions to OCID, we have to use a CLF version 3.0 file, formatted as:

//mcc+mnc;cellid;lac;rnc;lat;lon;ratio;data;rfu
26202;07812;03101;0;45.894375;31.51312;0;City Square;0

The key here is the ratio field that should be set **-1** for an exact position.

[ga900]

Great... if we have exact position of the tower during any activity we could compare distance calculated from GPS position to BTS/NodeB with distance from Timing Advance (2G) or Propagation Delay (3G) or both (LTE) to detect abnormal cell in the network. Difference should not be more than one step in TA or PD due to reflections. If access to TA/PD parameter is not possible, calculated distance to bts in urban areas over 2-3km should be considered as abnormal behaviour.
Oh, add a possibility to import CLF GPS cell position database.

[ziem]

@E3V3A OK.

[hannosch]

@E3V3A the minimum example should be:

{"items": [{
    "position": {
        "latitude": -22.7539192,
        "longitude": -43.4371081,
        "source": "manual"
    },
    "cellTowers": [
        {
            "radioType": "lte",
            "mobileCountryCode": 208,
            "mobileNetworkCode": 1,
            "locationAreaCode": 2,
            "cellId": 12345
        }
    ],
}]}

[E3V3A]

@ziem Fantastic! This will help.
@hannosch Thank you.

I've also got contact with someone who might be able to help with the SA analysis.

[E3V3A]

So we have the following updates:

From OCID:

User can upload measurements with "exact position", but the system treats such measurements as normal ones. It means that only administrator is able to overwrite cell position uploading data with "exact positions".

From MLS:

Currently we can't handle exact cell tower positions. The Geosubmit v2 API has a position source field, but that field is still unused and simply ignored. We'd also internally would have to separate data about exact positions and average observation positions. Currently we only store and treat
everything as if it'd be the latter.

This understandable, but also make it perfectly clear that we're on our own in getting exact locations from within our app. (See my 2nd comment.)

[E3V3A]

Hi @ziem, have you had a chance to look at this?

[ziem]

Not yet, sorry 😞.

[E3V3A]

I've just added the BtsLoc DB table in 2e44d29 as per above comment.

@ziem No problem, but it would be good to know if you still intend to do it or not?

[ziem]

Since I don't have enough free time I won't be able to help. I pushed basic draft with:

• adding markers to map (long press)
• dragging (long press + move)
• click

I also created empty methodsl: loadUserDefinedCoordinates, saveUserDefinedCoordinates and updateUserDefinedCoordinates. Second and third method is invoked in right place so you can fill them with database operations and everything should work.

If you have any questions, let me know.

[SecUpwN]

@ziem, I know you don't have time left for our buggy project, but can you give this another attempt, please? We've had a huge downtime and I am trying to bring back our app to life. Thanks for helping!

[ziem]

@SecUpwN I can create pull request but due to the lack of time I won't be able to do anything more ;/.

[agilob]

User should not be able to manually change location of BTS measures. This is very risky and probably will cause more damage than help. Just think how easy it will be to abuse it.

[SecUpwN]

User should not be able to manually change location of BTS measures. This is very risky and probably will cause more damage than help. Just think how easy it will be to abuse it.

I agree. Data collected should be as exact as possible, but not to be manipulated via our app.

I can create pull request but due to the lack of time I won't be able to do anything more ;/.

@ziem, you should know by now that pull requests are preferred here on our GitHub, so yes, you're very invited to craft one for this Issue. Rest assured that the PR will be checked before I'm merging it in.

[smarek]

@agilob I agree, personally I'm against implementing this feature. Also the current PR draft has to be reworked a lot to be wide-usable

[SecUpwN]

I agree, personally I'm against implementing this feature. Also the current PR draft has to be reworked a lot to be wide-usable

@smarek, ok, then let's decide on this for now. I would like to hear @larsgrefer here before closing both.

[SecUpwN]

@timofonic, your Issue is another one, see #608. This one is about creating exact BTS locations to exactly map the BTS and possibly pinpoint attackers (at least that is what I think this might be good for).