%ents;
]>
Location QueryThis specification defines an XMPP protocol extension for querying a compliant server or service for information about the geographical or physical location of an entity.
&LEGALNOTICE;
0255DeferredStandards TrackStandardsCouncilXMPP CoreNOT_YET_ASSIGNEDHelgeTimeneshelge@buddycloud.comhelge@buddycloud.comSimonTennantsimon@buddycloud.comsimon@buddycloud.comRossSavageross@buddycloud.comross@buddycloud.com0.62009-04-09psa

Defined registry; added nic type from list discussion.

0.52009-03-13ht

Added example with IP address

Corrected closing </iq> tags in examples

0.42009-02-17ht

Added IP address to the type of beacons

Changed the nomenclature from 'beacons' to 'references' as they may not always be active transmitters (as in the case of IP address)

Corrected <latitude/> and <longitude/> and tags in example 1 to <lat/> and <lon/>

This document defines a format for querying a location server for information about an entity's geographical location. The query must contain some location characteristics that the server can process to derive this information. These can be in the form of geodetic coordinates (from GPS receivers or other positioning equipment), in which case the server will perform "reversed geocoding" to derive the information. Alternatively, the location can be characterized by a geographically assigned IP address or a list of cellular telephone towers, wireless network access points, Bluetooth devices, RFID tags, network addresses, or other information observable from this location (from here on called 'location references', or just 'references'). In this case the location server must match the supplied characteristics with stored knowledge about the location references to derive the submitting entity's location. Client implementers are encouraged to supply both kinds of characteristics when available, as this can be utilized by self-learning location servers. The location information returned by the location server is structured according to &xep0080;, ensuring compatibility with systems using this standard for location information publishing.

The location query is designed to be used as a one-shot request or as a continuous query-result dialogue. The latter form will allow location servers to analyze changes with time, which in most cases yields improved fidelity and the possibility to derive motion state information.

The format defined herein was designed to address the following requirements:

It shall be usable on devices with no support for GPS or other geodetic positioning systems

It shall be usable on devices with support for GPS or other geodetic positioning systems

It shall be compatible with place-referencing systems

It shall support self-learning location servers

The result format shall be expressed as natural language location description

The result format shall be compatible with XEP-0080

The basic principle behind this XMPP extension is as follows: An XMPP clients collects characteristics about its current location that is not directly suitable for presentation to a human user, but from which human readable location information can be derived. The client sends this information to a location server that derives this information and returns it to the querying client. Here "location server" means a XMPP server application that supports the <locationquery/> payload defined in this document. It can either be an integral part of the XMPP server, or run as a component on the same or a different machine from the XMPP server itself.

Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a <locationquery/> element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a <iq> element with type set to get. The location result is provided by the location server and returned to the client in a <iq> element with type set to result. The location result is structured by means of a <geoloc/> element that is qualified by the 'http://jabber.org/protocol/geoloc' namespace (see XEP-0080).

Element Name

Datatype

Definition

Example

Notes

timestamp

xs:datetime

UTC time-stamp (MUST conform to the DateTime profile of &xep0082;).

2004-02-19T21:12Z

Optional. If individual location references contain own timing information, this time-stamp shall represent GPS time only, otherwise it shall represent all provided info in the query. If not set, the server may assume current time.

publish

xs:boolean

A flag specifying whether or not the server should publish the location result to subscribers of the submitting user's XEP-0080 compatible geoloc pub-sub node instead of returning it directly to the submitting user.

true

Optional. If present and "true", the server shall publish the entity's location details whenever it changes (suitable for periodic queries) and respond to the query with an empty <iq> stanza with type set to "result". If not specified or "false" the server shall return the location results to the submitting user in the form of a geoloc stanza (XEP-0080) embedded in a <iq> with type set to "result". Default is "false"

lat

xs:decimal

Latitude in decimal degrees
North.

39.75

Required if no location references present, otherwise optional. If present, this shall also be present in the result stanza. If not present, the location server SHOULD estimate a value based on submitted reference data and return with result stanza. The location server is free to decide if the value of this field should be piped directly through to result, or if it should be modified based on reference data or time history information. For instance: if the entity is indoors, the GPS signal will be inaccurate and unstable over time. If wifi references are submitted, the location server may decide that the entity is inside a known building, and return the latitude of this instead.

lon

xs:decimal

Longitude in decimal degrees East

-104.99

See notes for lat

alt

xs:decimal

Altitude in meters above or below sea level

1609

Optional. If present, this shall also be present in the result stanza with identical value.

bearing

xs:decimal

GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north

See notes for alt

datum

xs:string

GPS datum (See XEP-0080)

See notes for alt

accuracy

xs:decimal

Horizontal GPS accuracy in meters

10

See notes for lat

speed

xs:decimal

The speed at which the entity is moving, in meters per second

52.69

See notes for alt

references

locationquery:reference

A list of identifiable location references observed by the entity

Required if no lat and lon values specified, otherwise optional. See Table 2 for type definition.

Element Name

Datatype

Definition

Example

Notes

id

xs:string

A world-wide unique reference identifier. This SHALL be composed as follows:

For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code Values of Mobile Country Codes (MCC) are specified by Annex to ITU Operational Bulletin No. 897 – 1.XII.2007.), MNC is the network carrier code, LAC is the area code and CID is the cell ID.

Optional. If query contains info from multiple location reference scans, specifying the timestamp for each reference may lead to improved temporal analysis (movement state etc).

Element Name

Datatype

Definition

Example

Notes

alt

xs:decimal

Altitude in meters above or below sea level

1609

Piped directly through from query alt field if set.

area

xs:string

A named area such as a campus or neighborhood

Central Park

bearing

xs:decimal

GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north

Piped directly through from query bearing field if set.

building

xs:string

A specific building on a street or in an area

The Empire State Building

country

xs:string

The nation where the user is located

USA

datum

xs:string

GPS datum (See notes for XEP-0080)

Piped directly through from query datum field if set.

description

xs:string

A natural-language name for or description of the location

Bill's house

If location is mapped to a place in a place oriented service, this should hold the place description.

accuracy

xs:decimal

Horizontal GPS accuracy in meters

10

Piped directly through from query accuracy field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.

floor

xs:string

A particular floor in a building

102

lat

xs:decimal

Latitude in decimal degrees
North

39.75

Piped directly through from query lat field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.

locality

xs:string

A locality within the administrative region, such as a town or city

New York City

lon

xs:decimal

Longitude in decimal degrees East

-104.99

Piped directly through from query lon or estimated by location server based on the other information in query and, if possible, differences between several queries over time.

postalcode

xs:string

A code used for postal delivery

10027

region

xs:string

An administrative region of the nation, such as a state or province

New York

room

xs:string

A particular room in a building

Observatory

speed

The speed at which the entity is moving, in meters per second

52.69

xs:decimal

Piped directly through from query speed field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.

street

xs:string

A thoroughfare within the locality, or a crossing of two thoroughfares

34th and Broadway

text

xs:string

A catch-all element that captures any other information about the location

Northwest corner of the lobby

Best practice tip: This field can be used by the server to combine several fields in a natural language style, suitable for simple one-line location presence text. Example: "Near Bob's place" (description + accuracy), "On the road in New York" (locality + speed)

timestamp

xs:datetime

UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of XEP-0082)

2004-02-19T21:12Z

Piped directly through from query timestamp field.

uri

A URI or URL pointing to
information about the location

http://beta.plazes.com/plazes/1940:jabber_inc

xs:anyURI

Only applicable to place-oriented services

NOTE: The datatypes specified above are defined in &w3xmlschema2;.

The location results SHOULD be distributed means of &xep0060; or the subset thereof specified in &xep0163;. This can be done automatically by requesting the "publish" location query result format, in which case the location server will publish the results on the user's behalf. Alternatively the it can be done client side as outlined in XEP-0080.

The does not have to determine a value for all fields of the <geoloc> stanza, but it SHOULD determine values for as many as possible. At the very least a value for 'country' should be set.

If no GPS coordinate and accuracy information is submitted in the query, and the server determines location coordinates from submitted reference data, a value for the returned geoloc 'accuracy' field SHOULD be returned. The magnitude of this should be derived based on the ranges of the location references used to determine the location, if known.

The server should make no assumptions about how often a entity submits a query. It should support occasional manually triggered queries as well as periodic automated queries. In the latter case it should analyze changes over time, as this can greatly increase the fidelity of the result.

Furthermore, no assumptions should be made about the number and types of location references being logged in each query. Some handset manufacturers limit the access programmers have to cell tower and access point information. Some may only offer the currently connected cell ID, such that even if the handset can "see" many cell towers, only the one to which the handset is connected at the moment can be read. In this case the cell tower readings may not be constant, even if the querying entity is not moving. Rather it may jump round-robin style to each visible cell with variable time spent on each. The location server should account for this to avoid yielding results indicating that a user is running around in cell-sized circles when he is in fact stationary. Again, analysis of variation of submitted queries over time is recommended.

As no guarantees can be made that a given location reference stays at one fixed physical location throughout it's lifetime, the server should implement means to detect this. Generally it can be assumed that cell towers seldom move (could happen when a network operator changes the way it allocates cell IDs or when a tower is physically moved to a different location). Wireless access points move a bit more frequently (for instance when their owners move, or if they are installed in moving vehicles such as busses or trains). Bluetooth devices can generally be assumed to be mobile and should, unless specific knowledge to the contrary exists, not be used to locate an entity to a specific physical location. Rather, Bluetooth devices (and other mobile references) can be used to co-locate entities to other entities for which a physical location is known. An example: Entity A submits query with GPS coordinates and the ID of some Bluetooth device. It is located based on its submitted coordinates. Entity B submits a query with the same Bluetooth device ID, but no GPS coordinates. Given this, and the fact that Bluetooth transmitters have a very limited range, the server can then derive that A and B are at the same physical location (it may add 10-20 m to the accuracy of the location of B to account for the Bluetooth range).

The "radio landscape" is by no means constant. New cells and access points are added continuously, and old ones are phased out. A location server will have to adapt to this shifting landscape, either by means of operator-supplied databases (in case of cell towers) or by means of user generated information. This standard was written with the latter in mind, and it is recommended that location servers utilize any queries with both GPS coordinates and location references to "learn" the approximate physical location of the provided references. For server implementation that rely on user generated information only, it is also recommended to supply additional means for the users to feed back location context in cases where the client does not have any GPS access, or when the server produces the wrong results. One way to do this would be to let the users define "placemarks" (a name, street, city etc) that can be associated with the references seen by this user at the time of definition. This is however beyond the scope of this XEP.

For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver.

For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)

Because the character data contained in the location results is intended to be readable by humans, the location query SHOULD possess an 'xml:lang' attribute specifying the natural language of such character data &rfc4646;. If so, the server SHOULD equip the <geoloc/> element, of the result stanza with an identical attribute

It is imperative to control access to location information, at least by default. Imagine that a stalker got unauthorized access to this information, with enough accuracy and timeliness to be able to find the target person. This scenario could lead to loss of life, so please take access control checks seriously. If an error is deliberately added to a location, the error SHOULD be the same for all receivers, to minimize the likelihood of triangulation. In the case of deliberate error, the <accuracy/> element SHOULD NOT be included.

Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

&NSVER;

The XMPP Registrar shall maintain a registry of values for the <type/> child of the <reference/> element when qualified by the 'urn:xmpp:locationquery:0' namespace.

&REGPROCESS;
the machine-readable name for the reference typea natural-language description of the reference type
]]>

The registrant can register more than one reference type at a time, each contained in a separate <reftype/> element.

As part of this document, the following reference types are registered:

bluetooth
The device address as determined by Bluetooth technologies as defined in
the IEEE 802.15.1 standards.
cell
A cell tower address, formatted as "MCC:MNC:LAC:CID" (where MCC is
the mobile country code, MNC is the network carrier code, LAC is the
area code, and CID is the cell ID).
ip
An Internet Protocol (IP) address possessed by or assigned to the
client.
nic
The link layer (Media Access Control) address of one of the Network
Interface Controllers (NICs) associated with the client sending the
request. Most commonly, this will take the form of a 48-bit Ethernet
address formatted in six colon-separated groups of two hexadecimal
digits, in transmission order. Some location servers might be able to
use this information to query network elements through which the client
is connected to deduce location data.
rfid
The device address as determined by Radio Frequency Identification
technologies.
wifi
The device address as determined by WiFi technologies as defined in
the IEEE 802.11 standards.
wimax
The device address as determined by Worldwide Inter-operability for
Microwave Access technologies.
]]>
]]>