Re: [Geopriv] New indoor location - standards needed

"Rosen, Brian" <> Tue, 25 November 2014 18:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1A2E91ACECF for <>; Tue, 25 Nov 2014 10:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.433
X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yyRicwPUgI6z for <>; Tue, 25 Nov 2014 10:51:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC4DC1A877A for <>; Tue, 25 Nov 2014 10:51:03 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.7/8.14.7) with SMTP id sAPIk12V007576; Tue, 25 Nov 2014 13:51:02 -0500
Received: from ([]) by with ESMTP id 1qvsnarrkf-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 13:51:02 -0500
Received: from ([]) by ([::1]) with mapi id 14.03.0158.001; Tue, 25 Nov 2014 13:51:01 -0500
From: "Rosen, Brian" <>
To: Henning Schulzrinne <>
Thread-Topic: [Geopriv] New indoor location - standards needed
Thread-Index: AQHQCODBto5m9qG+t0y2Pq7CkyfJCw==
Date: Tue, 25 Nov 2014 18:51:00 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7633 signatures=670583
X-Proofpoint-Spam-Reason: safe
Cc: "" <>
Subject: Re: [Geopriv] New indoor location - standards needed
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Geographic Location/Privacy <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Nov 2014 18:51:08 -0000

I certainly think HELD is appropriate for NEAD query (query with MAC, respond with address in PIDF-LO form), but the general problem is that creating a centralized database is difficult, and it’s much more likely to be highly distributed.  I think the IETF is the ideal venue for working on that problem.  I think the problem the NAED deals with is that the WiFi AP is not operated by the origination service provider, and that service provider doesn’t know which AP/WiFi network the MAC address is connected to.  So, what is needed is a way to connect the WiFi networks in a way where you can reasonably query only those networks that might reasonably have that MAC address.  I think that’s probably based on serving cell site.  The NAED would know which WiFi networks were inside the serving cell area, and it would query (all of) them to see which one has the MAC address, and thus the location (if nothing else, the location of the AP that is serving the MAC).  That’s a guess based on some existing work done by some geoprivers who might give us more information.

I think working on the barometric pressure thing would be fascinating, and I think we’re probably at least as qualified to do the work as anyone else.  Perhaps we could get the OGC to work on in with us.  I think of that as combining the existing elevation datasets with building floor height data to produce a floor number from the barometric data.  I’d guess some compensation from weather data would be needed.   Crowdsourcing might be interesting, but what would we use to actually get the right data (how does the source know/enter floor data?)  Hah - sound analysis on an elevator ride!  Listen for the dings and floor announcements.  Watching steps and pressure is probably a decent way to figure out what floor you are on if you walk up a stairway.


> On Nov 25, 2014, at 12:32 PM, Henning Schulzrinne <> wrote:
> See
> In particular, the need for standards is called out in two areas:
> - for the National Emergency Address Database (NEAD)
> - for delivery of barometric pressure information to obtain z-axis (altitude) information.
> The FCC is not a party to the agreement. It seems at least plausible that existing GEOPRIV work, such as HELD, or RFC 7105, can be extended to meet those needs. I'd appreciate hearing opinions on technical options from the WG.
> Henning
> _______________________________________________
> Geopriv mailing list