Subject: [Int-area] GPS over wifi

From: Rob Brew <[email-masked]>
Date: Wed, 22 Jan 2020 12:05:12 +0000

Hi,

Except when you can install a GPS repeater.

We already have wireless networks covering each area of tube stations, this
makes the porvisioing of such functionality cheaper as the
infrastructure is already there,

I need to look at it.

Until then, I can tell that there is a GPS GATE software that captures
GPS signals and puts the data (NMEA?) on IP and distributes it to IP
receivers.  These IP receivers might be on WiFi too.

In this case, it might be that one needs to tell what is the format of
NMEA over IP.  It's very simple.

But, agreeing that NMEA is the best thing is a different thing.  On one
hand, NMEA has new versions.  But it uses WGS84 which might not be the
best coordinate system - it is good for smartphones and users, maybe
cars, but in some countries it is not used to locate some important
points.  These use other coordinate systems.  So maybe one wants to come
up with a more universal coordinate system that makes everyone happy,
and take _that_ and put on WiFi (not NMEA).  Because, IP is such
universal, we should put universal things on it.

Conversions between systems are huge opportunities for glitches to get
in.  These kinds of glitches ahppening very fast and added up may lead,
and have led, to disasters.

> As we know the IP Address contacting the server the server contains a
>  map containing the GPS location of each underground site, as
> referenced by IP address.  The  returns the phsycial GPS location and
> name of the site as a JSON array.
>
> To prevent false servers reporting inaccurate information https can
> be used to verify the authenticity of the server.
>
> Providing this service to mobile phone user's without a current WIfi
>  connection i propose going one stage further, create a hidden
> wireless network wih the name ".location". In cases where no GPS
> location can be found a mobile phone's GPS system can be programmed
> to seek such a network providing the same service.

Hold on, 'hidden wireless network', make sure 'hidden terminal problem'
is distinguished.

A phone that cant have WiFi connection - what kind of other IP
connection does it have, in a place that has no GPS coverage?  Is it a
cellular connection in underground metro station?  If yes, it means
either there are cellular base stations there, or there are cellular
repeaters: enhance them to repeat GPS as well.

> This would require alterations to th servics as provided by mobile
> phone providers such as Apple and Android.
>
> If you are interested in this concept please review it (and my code),
>  and maybe it will become something. For a video demonstration of
> this service please check the link at the github site.

I will look at the draft later.

Alex

---

From: Rob Brew <[email-masked]>
Date: Wed, 22 Jan 2020 12:13:57 +0000

Dear all.

Having received the post from Alex I have responded. If you would rather I
move this RFC to antarea I will do so.  Personally I feel it's more of an
internet problem as GPS is being delivered using HTTP protocols.

On Wed, Jan 22, 2020 at 12:05 PM Rob Brew <[email-masked]> wrote:

> We already have wireless networks covering each area of tube stations,
> this makes the porvisioing of this functionality cheaper as the
> infrastructure is already there.
>
>
>
> By hidden wireless network I mean a wireless netwowk which does not
boradcast it's ssid.

> repeaters: enhance them to repeat GPS as well.
By this I mean if there is no wif-fi connection and no GPS connection the
phone's GPS
location software can reach out to such a wireless network without an ssid
for the purposes of gaining it's GPS location. This would require some
reprogamming of GPS location software by Google and Apple.

> > this service please check the link at the github site.

All that is needed for this to happen is to reconfigure underground routers
and set up a server to deal with the requests, having populated a table on
the server of GPS locations.

Rob Brew,

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Jan 2020 13:43:38 +0100

Le 22/01/2020 à 13:13, Rob Brew a écrit :
> Dear all.
> 
> Having received the post from Alex I have responded. If you would rather 
> I move this RFC to antarea I will do so.  Personally I feel it's more of 
> an internet problem as GPS is being delivered using HTTP protocols.

Thank you for the explanation.

'antarea'?  I think it is meant 'apparea' - it is a funny mispelling 
which makes think why not joining intarea and apparea into one.

And, it is not an RFC, it is a draft.

It is not a draft RFC.  An RFC might have 'draft standard status' and 
some times people shorten than as 'draft RFC' to distinguish from a BCP 
RFC for example.  Yet there are many years between draft (Internet 
Draft, actually), RFC, draft standard RFC, and so on.

A 'draft' is like a tissue on which one sketches a few notes - maybe a 
few seconds after I will crumple it and through it in the bin.  Maybe 
yes maybe no.

An RFC is something far different: it is set in stone, it stays there 
forever.  People print it on tangible papers, put them on resumés as 
career achievements.  It requests comments just for the fun of it, 
because comments are no longer accepted.  It's called an 'RFC' because 
the original inventors of the term wanted a name to get around a few 
blockages from some Departments that are too process-oriented and that 
forbid communication.  One can't comment on an RFC but it's important 
that others think one might comment on them - they so write I-Ds.  The 
I-Ds _are_ taken into account.

In a similar vein: if one is Da Vinci, even the funniest sketches can 
become worth much money, yet they are still not works of art.

Further, if one wants to write a sketch that is even more drafty sketchy 
than a real Internet Draft (in short, a 'draft'), then one is free to 
write a .txt file with vi and post it on a public web site like 
researchgate.  One might get a DOI for it, so it makes for a 
publication.  It might increase the resumé of somebody just for such a 
sketch, because Google hits it.

But an Internet Draft is better :-)

With some exceptions there are in principle two  kinds of Internet 
Drafts: a personal submission and a WG item (Working Group item).  A 
personal submission (or 'individual submission') is something in which 
only the main author(s) of the draft believe(s) - all the others dont 
give a dime, or maybe appreciate it a lot but dont know yet, or will 
never know about it.  That's where the GPS-over-wifi is now.

An I-D (short for Internet Draft) that is adopted by a WG means that 
people in the WG like it a little bit, or at least they dont reject it 
outright.  It might take several years before a personal submission I-D 
becomes a WG item.  Or it might be immediate because of some aura around 
the proposer.  Or it might lead to the creation of a new WG which does 
not exist as of yet.   And it's still not yet an RFC :-) Still years 
away :-)  Still need to persuade people :-)

There are fast tracks to that: are you on a fast track?

> On Wed, Jan 22, 2020 at 12:05 PM Rob Brew <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 

I think you mean there are cases when it is not possible to install GPS 
repeaters.

In this case, I would like to know why it is not possible to install GPS 
repeaters?

>     We already have wireless networks covering each area of tube
>     stations, this makes the porvisioing of this functionality cheaper
>     as the infrastructure is already there.

Cheaper to deploy software on an existing hardware than deploy new 
hardware - I suppose yes.  It is the SDN mantra.

But, is it as effective?

I have seen many trials and people tried many things to realize indoors 
localisation without a view to satellites.  Not one of them is as 
effective as the deployment of cheap GPS repeaters with thick RF cables.

I do know and admit that the perspective that you express about lack of 
necessity of GPS repeaters is a perspective shared in many places.  It 
is just I do not understand why.  To this perspective I propose the view 
of the existence of these cheap GPS repeaters - I wonder why people 
spent time and money to produce them.

Maybe it's just me.

Alex

> By this I mean if there is no wif-fi connection and no GPS connection 
> the phone's GPS
> location software can reach out to such a wireless network without an 
> ssid for the purposes of gaining it's GPS location. This would require 
> some reprogamming of GPS location software by Google and Apple.
> 
> All that is needed for this to happen is to reconfigure underground 
> routers and set up a server to deal with the requests, having populated 
> a table on the server of GPS locations.
> 
> Rob Brew,
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Jan 2020 05:18:57 -0800

Dear Rob,
At 04:13 AM 22-01-2020, Rob Brew wrote:
>Having received the post from Alex I have responded. If you would 
>rather I move this RFC to antarea I will do so.  Personally I feel 
>it's more of an internet problem as GPS is being delivered using 
>HTTP protocols.

The Internet-Draft (I-D) which you submitted would require some work 
as it looks more like a problem statement.  You might be able to get 
some feedback about how to move the I-D  forward by sending your 
request to a mailing list [1] in the Applications and Real-Time Area 
instead of the Internet Area as HTTP-related specifications are 
usually discussed in that area.

Regards,
S. Moonesamy

1. https://www.ietf.org/mailman/listinfo/art

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 Jan 2020 12:24:46 -0800

Rob,

What exactly do you mean by GPS over wifi?

Do you mean sending location/course/speed/etc. data over wifi?   Or somehow replicating the actual GPS satellite data?

I don’t see how the latter would work giving the timing requirements.

There are lots of current practice in sending NMEA sentences over IP networks.   I don’t know how well this is specified, but I have several devices that do this.

Bob

On Jan 22, 2020, at 4:05 AM, Rob Brew <[email-masked]> wrote:
> We already have wireless networks covering each area of tube stations, this makes the porvisioing of such functionality cheaper as the infrastructure is already there,
> 
> 
> I need to look at it.
>

---

From: Rob Brew <[email-masked]>
Date: Thu, 23 Jan 2020 15:20:29 +0000

Hi Bob,

I mean replicating the GPS data as statically defined by a server, deduced
by the incoming static IP address of the access point of the site querying
the serve
r.
The server knows the IP address being queried (which never changes), based
on the IP address for public sites which include underground rail stations.

Whilst there are GPS repeaters this approach does not require any new
hardware or cabling to be installed, making it (imho) a viable alternative
to GPS repeaters.

S. Moonesamy I will contact them now.

Thanks,
 Rob.

On Wed, Jan 22, 2020 at 8:24 PM Bob Hinden <[email-masked]> wrote:

> Do you mean sending location/course/speed/etc. data over wifi?   Or
> somehow replicating the actual GPS satellite data?
>
> There are lots of current practice in sending NMEA sentences over IP
> networks.   I don’t know how well this is specified, but I have several
> devices that do this.
>
> Bob
>
>
>
> this makes the porvisioing of such functionality cheaper as the

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 23 Jan 2020 16:10:26 +0000

> On 23 Jan 2020, at 15:20, Rob Brew <[email-masked]> wrote:
> 
> The server knows the IP address being queried (which never changes), based on the IP address for public sites which include underground rail stations.
> 

Doesn’t that depend on the network architecture?

The IP address of the client may well be a NAT address with a public address that covers many railway stations.

- Stewart

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Jan 2020 16:10:54 -0500

On Wed, Jan 22, 2020 at 8:31 AM S Moonesamy <[email-masked]> wrote:
> as it looks more like a problem statement.

s/some work/lots of work/

I should point out that this is not "GPS" (which has a defined
meaning), this is IP based geo-location - which is already in use. See
[2] for some background / resources.

The document talks about: "The Server, with the aforementioned outline
code, knows the IP address of the WiFi hot spot." - this may come from
a misunderstanding of how wireless networks are typically provided.
When your device makes a connection to a server, the server sees an IP
from a subnet which spans a large physical area (in the case of v6),
or a NATed address which covers a subnet covering a large physical
area (v4) -- the address (generally) isn't the address of the access
point you connect to -- in order to improve the user experience (and
make the network work better / easier to manage, etc) wireless
networks try to let you keep the same address for as long as possible
(see WiFi roaming, etc)

>From the GitHub:
"providing GPS locations over WiFI using remote IP detection for a
server to respond with the correct name of clients location and the
clients GPS location.

The Java application here will look at a connection request's IP
address and from there return a latitude and longitude plus name for
that location."

This makes the assumption that a: the IP address is tightly
constrained to an area - the example video
(https://www.youtube.com/watch?v=pqURqmVVwYk) shows 82.13.105.104 as
being tightly geo-located to London bridge, but this is likely part of
a much larger subnet, spanning a much larger area than just one tube
station
and b: these geo-maps are very imprecise / and dynamic.

As an example, MaxMind's (rather good) geolocation for the above IP address is:
Address: 82.13.105.104
Location: Camden, Camden, England
Approximate Coordinates* 51.5245, 0.1567
Accuracy Radius (km): 10
Entering this into Google Maps gives: https://goo.gl/maps/9hA8ADm2TaXfywkj8

For this to work, London Underground / TfL *and every other
underground system wanting to use this* would need to be willing to:
A: have very small subnets tied to each "location" - this provides a
poor user experience as the devices need to roam between location at
whatever granularity you choose, and so change their IP, and
B: be willing to share this address -> location mapping with some
third party (and keep it up to date). This makes privacy regulators
twitch...

Many mobile devices already do something which achieves much of your
goal -- they look at the *BSSID* of the AP, and use it as a location
signal -- see e.g https://wigle.net/ as an example. This is also one
of the reasons devices like iOS say things like: "AirDrop, AirPlay and
**improved location accuracy** require Wi-Fi", and why services like
SkyHook have things like:
https://www.skyhook.com/submit-access-point [0]

So, if this were to move forward, it would need a lot more work (and
research into what already exists), and figure out if / how the
granularity and privacy concerns can be addressed.
I'm really not trying to dissuade you from this, but it will require a
lot more fleshing out / and understanding of what already exists...

W
[0]: as an interesting aside, we've had to white / blacklist the IETF
Meeting AP MAC addresses from these sorts of services to help with the
location issues. They would learn that AP101 lives in Prague[1], and
then be irritated / confused when it shows up in Singapore...

[1]: Not a bad first order guess. Other than being in a warehouse in
California, somewhere on the second floor, V Celnici 7, Prague, 110
00, CZ is indeed the most likely place to find an AP :-P

[2]: Useful resources:
https://dyn.com/blog/finding-yourself-the-challenges-of-accurate-ip-geolocation/
https://www.iplocation.net/
https://www.iplocation.net/geolocation-accuracy
https://datatracker.ietf.org/doc/draft-google-self-published-geofeeds/
https://www.maxmind.com/en/geoip-demo

>  You might be able to get

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Jan 2020 11:51:59 -0800

Hi Warren,
>s/some work/lots of work/

Yes.

>networks try to let you keep the same address for as long as possible

Thanks for elaborating on the above point.

>lot more fleshing out / and understanding of what already exists...

There is, for example, location information services.  A search on 
that should turn up a few RFCs as a starting point.

Regards,
S. Moonesamy