Re: [Int-area] GPS over wifi

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 22 January 2020 12:43 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE91200C1 for <int-area@ietfa.amsl.com>; Wed, 22 Jan 2020 04:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level:
X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_19jVD7XZqs for <int-area@ietfa.amsl.com>; Wed, 22 Jan 2020 04:43:41 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6223120077 for <int-area@ietf.org>; Wed, 22 Jan 2020 04:43:40 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 00MChc76003180 for <int-area@ietf.org>; Wed, 22 Jan 2020 13:43:38 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3D1820413F for <int-area@ietf.org>; Wed, 22 Jan 2020 13:43:38 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D462A2043D2 for <int-area@ietf.org>; Wed, 22 Jan 2020 13:43:38 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 00MChcMm012214 for <int-area@ietf.org>; Wed, 22 Jan 2020 13:43:38 +0100
To: int-area@ietf.org
References: <CANBjToUnvmmUYj=M1a2hET+E9XrWxz9omce-RjJuf9tbaaGO6A@mail.gmail.com> <CANBjToVsNZLvemoN7ttr7kOtcZMkaqOiH8Rh4miTXEv_znKLNg@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <71045f0f-4177-3365-8b47-231981f13526@gmail.com>
Date: Wed, 22 Jan 2020 13:43:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CANBjToVsNZLvemoN7ttr7kOtcZMkaqOiH8Rh4miTXEv_znKLNg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/ZYpJvPlpEYVZo8F-reGOz4TNRm0>
Subject: Re: [Int-area] GPS over wifi
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 12:43:43 -0000


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 <sputnik2012@gmail.com 
> <mailto:sputnik2012@gmail.com>> wrote:
> 
>     Hi,
> 
>     Except when you can install a GPS repeater.

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

> 
> 
> 
>     > 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.
> 
> By hidden wireless network I mean a wireless netwowk which does not 
> boradcast it's ssid.
> 
>     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.
> 
> 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 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.
> 
> 
> 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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>