Geopriv pdf

Location Request Examples. Context Creation and Update Examples. IANA Considerations. XML Schema Registration. Normative References. Informative References. L Identifier Choice. L Mobility Support. L Layer 2 and Layer 3 Provider Relationship.

L Legacy Device Considerations. L VPN Awareness. L Network Access Authentication. L Network Topology Unawareness. Introduction The location of a Device is information that is useful for a number of applications.

A Device might be able to determine this information using its own resources, but more often than not, the Device must rely on its access network to provide this information.

This document describes a protocol that can be used to acquire Location Information LI from a service within an access network. This specification identifies two methods for acquiring LI. Both of these methods are compatible, and both can be provided concurrently from the same LG so that application needs can be addressed individually. This protocol can be bound to any session-layer protocol, particularly those capable of MIME transport; an HTTP binding is included as a minimum requirement.

Exclusions This document defines a protocol for configuration purposes; that is, a protocol for requesting and receiving the information necessary to use LI. This document does not define a Geopriv Using Protocol. The LG is assumed to be present within the same administrative domain as the Device the access network , which limits the security threats that this protocol is exposed to.

This document does not specify how LI is derived. Determination of the physical location of a network termination point is dependent on the type of access network and the capabilities of networking equipment.

The specific methods that could be used are innumerable, therefore this is left to individual network and equipment implementations. How this URI is provided is not covered by this specification. This document does not define how an LG is discovered or configured. Service discovery techniques are described in [ I-D. Device or Target LI provided for the Device is often represented as the location of a user.

However, in this document LI is attributed to a Device and not a person. Primarily, this is because location determination technologies are generally designed to locate a Device and not a person. In addition to this, unless the Device requires active user authentication, there is no guarantee that any particular individual is using the Device at that instant.

Thus, if any claim of veracity is to be made for LI, the distinction between Target and Device must be made explicit. This distinction should not lead to the impression that the location of the Device does not impact the privacy constraints required by this protocol. Revealing the location of the Device almost invariably reveals some information about the location of the user of the Device, therefore the same level of privacy protection demanded by a user is required for the Device.

It is expected that, for most applications, this distinction will be unnecessary: LI for the Device will be used as an adequate substitute for the user's LI. This requires either some additional assurances about the link between Device and Target, or an acceptance of the aforementioned limitations. This document assumes that the Device is responsible for the protocol interactions described and that it does so with the authority of the Target and Rule Maker RM.

Detailing the interactions between these two entities requires a wider understanding of other interested parties. For the Device, the most important consideration is the Target. In some cases, this is the same as the Device, but it is more likely to be a human user. The foundation of this protocol is that the Target is able to direct the dissemination of LI, that is, the Target provides authorization policies and otherwise controls how LI is granted to Location Recipients LRs.

The LG exists as an access network service. The following diagram shows one possible configuration of the roles identified in [ RFC ] and where this protocol applies. REC-xmlschema ]. The schema definition is normative.

Examples of such organizations include telecommunication carriers, municipal utilities, larger enterprises with their own network infrastructure, and government organizations such as the military.

Civic addresses can be specialized for jurisdictional general use or postal message delivery purposes, or they can apply to either. Device: The technical device whereby the location is tracked as a proxy for the location of a Target. Geodetic Location: A location expressed in coordinate form. Note that the term LI does not include the representation of this data. Note that in this context, the Location Server is distinct from what is alternatively referred to as a Registrar in other contexts.

Rule Maker RM : The authority that creates rules governing access to location information for a target typically, this it the Target themselves. Using Protocol: A protocol that carries a Location Object. The LG needs to uniquely identify the Device within the access network. The source address of the request message is sufficient in most cases. Once the Device is identified, the LG uses network domain-specific information to determine the location of the Device.

An LI request does not need to include any identification information other than return addressing. Return routability also addresses a number of security concerns, see Section 8. The interface between Device acting as LS and Location Recipient LR is application-specific and outside the scope of this specification.

Related to privacy, a presentity URI and usage rules can be specified. The Device can also include a location estimate, or request a specific type of location information, including a request for a signed PIDF-LO. LI contained within a PIDF-LO document can be either geodetic coordinates using latitude and longitude or some other coordinate system or civic street or postal addresses. The Device can request that the LG provide a specific type of LI, including whether a jurisdictional or postal civic address is required.

If a Device is capable of providing its own location it can include this in a request. The type of LI is inferred from the request when LI is provided. The LI sent in a request MUST follow the subset of those rules relating to the construction of the "location-info" element. The first aspect of the diagram shows how the Device acts as an agent for the Target and retrieves a Location URI, which it then provides to the Location Recipient.

If the LS is to be able to service queries for location directed at the Location URI, it must maintain certain information. This document does not make any normative statements about the interface between the LG and LS.

Any assumptions that are made about the nature of this interface are stated where necessary. A context contains sufficient information for the LS to identify the Device to the LG, so that LI can be generated as required, which could be on a per-request basis. The context also includes Winterbottom, et al.

The context contains an authorization policy that describes to whom, and how, LI is granted. This is a common-policy document [ I-D. Messages are defined as XML documents. The Location Request message is described in Section 4.

The parameters for the create context request are described in Section 4. The response to a context creation request includes Location URIs and a password that can be used to update the information contained in the context. The details stored by the LS can be updated at any time after creation using the update context request, described in Section 4.

Table 1 shows the basic set of messages supported by this protocol and their respective responses, successful or otherwise. Section 5 contains a more thorough description of the protocol parameters, valid values, and how each should be handled. Protocol Binding The HELD protocol is an application-layer protocol that is defined independently of any lower layers.

This means that any protocol can be used to transport this protocol providing that it can provide a few basic features: o The protocol must have acknowledged delivery. REC-soappart ] [ W3C.

REC-soappart ]. This request can be very simple, including no parameters; in fact, the HTTP binding includes a GET request that does not include a message body. A Device MAY make an assertion about its own location as part of a location request. Devices that have some means of acquiring LI, either from embedded technology like Global Positioning System GPS receivers or from user input, can use this to convey that information to the LG. The "assert" element can be used to convey this information.

The type of LI that a Device requests is determined by the type of LI that is included in the "assert" element. Alternatively, if the Device has created a profile in an LS context, the Device can provide a "context" element Winterbottom, et al. The location request is made by sending a document formed of a "locationRequest" element. This establishes a context at the LS. The create context request includes a time limit, which sets the maximum time that this context can be maintained.

The response to a create context request contains information that the Device can use to identify a context. A response to a context creation also includes a password that the Device uses to identify itself when updating the context at any time before the context expiry time.

Updating Contexts A Device can update any of the information it has provided for a context at any time. The update context request includes the same information as the create context request with the addition of information that identifies an existing context. A Device uses any one of the Location URIs provided to uniquely identify a context when updating context information. The context password MUST be provided when updating context information.

If a Device includes an authorization policy or ruleset in an update context request, the LS MUST refresh any stored copy of the authorization policy. The update context request is constructed using the "updateContext" element. A successful response is the "contextResponse" element, which is the same as the response to a create context response. This applies to the profile Section 5. The response to an update context request is identical in form to the create context response, with updated information about the context.

Terminating Contexts The update context request can be used to instruct the LS to terminate a context. Geopriv also defines various scenarios for the … Expand. View 2 excerpts, cites background. This document describes an object format for carrying geographical information on the Internet.

Engineering, Computer Science. This document describes procedures for conveying access network ownership and location information based on a civic and geospatial location format in Remote Authentication Dial In User Service … Expand. SIP presence location service. SIP-based location service provision. Internet Engineering Task Force ietf. The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.

This document describes threats to … Expand. Related Papers. Abstract Topics Citations Related Papers. For a rectangular distribution, the half-width of the distribution is used. The half- width h of the rectangular distribution is also indicated. Confidence for any given interval is the total probability of the "true" value being in that range, defined as the integral of the PDF over the interval. The probability of the "true" value falling between two points is found by finding the area under the curve between the points that is, the integral of the curve between the points.

Figure 2 shows how confidence is determined for a normal distribution. These definitions were intended to provide a common nomenclature for discussing uncertainty; however, these particular terms have many different uses in other fields and their definitions are not sufficient to avoid confusion about their meaning.

These terms are unsuitable for use in relation to quantitative concepts when discussing uncertainty and confidence in relation to location information. Accuracy as a Qualitative Concept Uncertainty is a quantitative concept. Accuracy is generally useful when describing qualitative aspects of location estimates. Accuracy is not a suitable term for use in a quantitative context. For instance, it could be appropriate to say that a location estimate with uncertainty "X" is more accurate than a location estimate with uncertainty "2X" at the same confidence.

That is, to say that the "accuracy" for the first location estimate is "X" would be an erroneous use of this term. A location estimate is subject to uncertainty like any other observation. However, unlike a simple measure of a one dimensional property like length, a location estimate is specified in two or three dimensions. Uncertainty in two or three dimensional locations can be described using confidence intervals.

The confidence interval for a location estimate in two or three dimensional space is expressed as a subset of that space. Areas or volumes that describe regions of uncertainty can be formed by the combination of two or three one-dimensional ranges, or more complex shapes could be described for example, the shapes in [ RFC ]. While this is clearly false in virtually all scenarios with any practical application, it is often a reasonable simplifying assumption to make.

To a large extent, whether this simplification is valid depends on the size of the target relative to the size of the uncertainty region. When locating a personal device using contemporary location determination techniques, the space the device occupies relative to the uncertainty is proportionally quite small.

Even where that device is used as a proxy for a person, the proportions change little. This assumption is less useful as uncertainty becomes small relative to the size of the Target of the PIDF-LO or conversely, as uncertainty becomes small relative to the Target.

For instance, describing the location of a football stadium or small country would include a region of uncertainty that is only slightly larger than the Target itself. In these cases, much of the guidance in this document is not applicable. Indeed, as the accuracy of location determination technology improves, it could be that the advice this document contains becomes less relevant by the same measure.

Absence of uncertainty information in a PIDF-LO document does not indicate that there is no uncertainty in the location estimate. Uncertainty might not have been calculated for the estimate, or it may be withheld for privacy purposes. The same principle applies on the altitude axis for two-dimension shapes like the Circle. Uncertainty and Confidence for Civic Addresses Automatically determined civic addresses [ RFC ] inherently include uncertainty, based on the area of the most precise element that is specified.

In this case, uncertainty is effectively described by the presence or absence of elements. To the recipient of location information, elements that are not present are uncertain. To apply the concept of uncertainty to civic addresses, it is helpful to unify the conceptual models of civic address with geodetic location information.

This is particularly useful when considering civic addresses that are determined using reverse geocoding that is, the process of translating geodetic information into civic addresses. In the unified view, a civic address defines a series of sometimes non-orthogonal spatial partitions.

The first is the implicit partition that identifies the surface of the earth and the space near the surface.

The second is the country. Each label that is included in a civic address provides information about a different set of spatial partitions. Some partitions require slight adjustments from a standard interpretation: for instance, a road includes all properties that adjoin the street. Each label might need to be interpreted with other values to provide context. For non-orthogonal partitions, only the portion of the partition that fits within the existing space is selected. Each defined element selects a partition of space.

The resulting location is the intersection of all selected spaces. The resulting spatial partition can be considered as a region of uncertainty. Note: This view is a potential perspective on the process of geo- coding - the translation of a civic address to a geodetic location. Uncertainty in civic addresses can be increased by removing elements. This does not increase confidence unless additional information is used.

Similarly, arbitrarily increasing uncertainty in a geodetic location does not increase confidence. DHCP Location Configuration Information and Uncertainty Location information is often measured in two or three dimensions; expressions of uncertainty in one dimension only are rare. The "resolution" parameters in [ RFC ] provide an indication of how many bits of a number are valid, which could be interpreted as an expression of uncertainty in one dimension.

This is consistent with the transformation of those forms into the uncertainty representations from [ RFC ]. Representation of Confidence in PIDF-LO On the whole, a fixed definition for confidence is preferable, primarily because it ensures consistency between implementations.

Location generators that are aware of this constraint can generate location information at the required confidence. Location recipients are able to make sensible assumptions about the quality of the information that they receive. The addition of a confidence element provides information that was previously unavailable to recipients of location information.

This scaling process significantly degrades the quality of the information, because the location server might not have the necessary information to scale appropriately; the location server is forced to make assumptions that are likely to result in either an overly conservative estimate with high uncertainty or a overestimate of confidence. Both of these choices degrade the quality of the information provided. The addition of a confidence element avoids this problem entirely if a location recipient supports and understands the element.

A recipient that does not understand - and hence ignores - the confidence element is in no worse a position than if the location server ignored confidence. This element expresses the confidence in the associated location information as a percentage.

A special "unknown" value is reserved to indicate that confidence is supported, but not known to the Location Generator. The confidence element optionally includes an attribute that indicates the shape of the probability density function PDF of the associated region of uncertainty.

Three values are possible: unknown, normal and rectangular. Indicating a particular PDF only indicates that the distribution approximately fits the given shape based on the methods used to generate the location information.

A Point shape does not have uncertainty or it has infinite uncertainty , so confidence is meaningless for a point; therefore, this element MUST be omitted if only a point is provided. This restriction, while not always practical, allows for more accurate scaling, if scaling is necessary.

A confidence element MUST be included with all location information that includes uncertainty that is, all forms other than a point. A special "unknown" is used if confidence is not known. Effectively communicating the probability that a location is incorrect to a user can be difficult. It is inadvisable to simply display locations of any confidence, or to display confidence in a separate or non-obvious fashion.

If locations with different confidence levels are displayed such that the distinction is subtle or easy to overlook - such as using fine graduations of color or transparency for graphical uncertainty regions, or displaying uncertainty graphically, but providing confidence as supplementary text - a user could fail to notice a difference in the quality of the location information that might be significant.

Depending on the circumstances, different ways of handling confidence might be appropriate. Section 5 describes techniques that could be appropriate for consumers that use automated processing. Providing that the full implications of any choice for the application are understood, some amount of automated processing could be appropriate. In settings where there is an opportunity for user training, some of these problems might be mitigated by defining different operational procedures for handling location information at different confidence levels.

Manipulation of Uncertainty This section deals with manipulation of location information that contains uncertainty. The following rules generally apply when manipulating location information: o Where calculations are performed on coordinate information, these should be performed in Cartesian space and the results converted back to latitude, longitude and altitude.

A method for converting to and from Cartesian coordinates is included in Appendix A. While some approximation methods are useful in simplifying calculations, treating latitude and longitude as Cartesian axes is never advisable. The two axes are not orthogonal. Errors can arise from the curvature of the earth and from the convergence of longitude lines. When rounding, the region of uncertainty always increases that is, errors are rounded up and confidence is always rounded down see [ NIST.

TN ]. This means that any manipulation of uncertainty is a non-reversible operation; each manipulation can result in the loss of some information. Reduction of a Location Estimate to a Point Manipulating location estimates that include uncertainty information requires additional complexity in systems. In some cases, systems only operate on definitive values, that is, a single point. This section describes algorithms for reducing location estimates to a simple form without uncertainty information.

Having a consistent means for reducing location estimates allows for interaction between applications that are able to use uncertainty information and those that cannot. Note: Reduction of a location estimate to a point constitutes a reduction in information. Also, there is a natural tendency to misinterpret a point location as representing a location without uncertainty. This could lead to more serious errors. Therefore, these algorithms should only be applied where necessary.

Several different approaches can be taken when reducing a location estimate to a point. Different methods each make a set of assumptions about the properties of the PDF and the selected point; no one method is more "correct" than any other. For any given region of uncertainty, selecting an arbitrary point within the area could be considered valid; however, given the aforementioned problems with point locations, a more rigorous approach is appropriate. Given a result with a known distribution, selecting the point within the area that has the highest probability is a more rigorous method.

Alternatively, a point could be selected that minimizes the overall error; that is, it minimizes the expected value of the difference between the selected point and the "true" value. If a rectangular distribution is assumed, the centroid of the area or volume minimizes the overall error. Minimizing the error for a normal distribution is mathematically complex. Therefore, this document opts to select the centroid of the region of uncertainty when selecting a point.

Centroid Calculation For regular shapes, such as Circle, Sphere, Ellipse and Ellipsoid, this approach equates to the center point of the region. For regions of uncertainty that are expressed as regular Polygons and Prisms the center point is also the most appropriate selection.

For the Arc-Band shape and non-regular Polygons and Prisms, selecting the centroid of the area or volume minimizes the overall error. This assumes that the PDF is rectangular. Note: The centroid of a concave Polygon or Arc-Band shape is not necessarily within the region of uncertainty. Polygon Centroid Calculating a centroid for the Polygon and Prism shapes is more complex.

Polygons that are specified using geodetic coordinates are not necessarily coplanar. For Polygons that are specified without an altitude, choose a value for altitude before attempting this process; an altitude of 0 is acceptable. The method described in this section is simplified by assuming that the surface of the earth is locally flat. This method degrades as polygons become larger; see [ GeoShape ] for recommendations on polygon size.