internet geolocation and location-based services

IEEE Communications Magazine • April 2011102 0163-6804/11/$25.00 © 2011 IEEE

INTRODUCTION

The Internet has become an increasingly mobilenetwork. What started out as a small network oflarge machines in fixed locations has evolvedover the past 30 years into a large network ofsmall machines that move around. As the devicesthat people use to connect to the Internetbecome more mobile, information about theirgeolocation has become a critical piece of con-text that applications can use to customize ser-vices to the needs of users.

Location-based Internet services have actuallybeen around for several years, in a less visibleform. As websites began to serve internationaluser bases in the 1990s, the need arose to pro-vide customized content for users in differentparts of the world. For example, a user in Singa-pore might be presented a web page in English,while a user a few minutes north in Malaysiamight be presented the same web page in Malay.Modern search engines customize search results(and advertisements) based on the estimatedlocation of the user.

The use of geolocation in these cases is usual-ly transparent to the end user (it may or may notbe obvious that location information is beingused), but they are the applications that drovethe creation of the first Internet geolocation ser-vices, in the form of so-called IP-geo databases.These databases make estimates of the locationof an IP address — any IP address — based on avariety of exogenous factors, such as the contactaddresses listed in the WHOIS database. Despite

the inherent ambiguities and inaccuracies inthese databases, they are in wide use today, andseveral companies make a business of maintain-ing and providing access to them (e.g., MaxMindand Quova).

Much of the growth in the Internet today isbeing driven by the increasing use of cellulardevices for Internet access, and cellular networksare another place with a rich history of location-based services. In many jurisdictions, require-ments for emergency calling (e.g., E911 in theUS) have led cellular networks to deploy systemsfor determining their subscribers’ physical loca-tions. Based on these services, carriers have cre-ated value-added location-based services, whichallow subscribers to keep track of their childrenor get directions (to pick two popular examples).

The location services deployed by cellularnetworks, however, are usually accessible only bythe network itself or a small group of affiliates.Thus, as smart phones that are developed inde-pendently from the carriers have become morecommon, software on these phones has not beenable to take advantage of carrier-based geoloca-tion services. Since these applications still wantto have access to geolocation information, how-ever, there has been a third wave of “over-the-top” geolocation services, which rely onthird-party databases of network information(e.g., locations of WiFi access points or cell tow-ers).

The result of all these trends is that the stateof geolocation in the Internet today is somethingof a mishmash, with all of these design patternsin use at once. Moreover, each type of geoloca-tion system uses its own set of purpose-builtinterfaces, often with equivalent systems offeringvery different interfaces. While this diversityarose from legitimate needs to create services intheir original contexts, it makes it difficult for anapplication to use different services in differentcontexts in order to create an optimal overallservice across the various niches served by theindividual services.

The Internet Engineering Task Force (IETF)has been working on a framework for a unifiedlocation system for the Internet, called theGEOPRIV architecture for its joint focus ongeolocation and privacy. The GEOPRIV system

ABSTRACT

As the edge of the Internet becomes increas-ingly mobile, location-based Internet applica-tions have taken on a much more prominentrole. At the same time, though, the underlyinggeolocation systems that support these applica-tions were designed with specific circumstancesin mind, rather than being general to the wholeInternet. The IETF GEOPRIV architecture pro-vides a unified geolocation system for the Inter-net, allowing applications to benefit from currentgeolocation design patterns as well as some newsecurity and privacy features.

IETF STANDARDS UPDATE

Richard Barnes, BBN Technologies

James Winterbottom, Andrew Solutions

Martin Dawson, Andrew Solutions

Internet Geolocation andLocation-Based Services

BARNES LAYOUT 3/22/11 10:51 AM 02

IEEE Communications Magazine • April 2011 103

comprises a suite of protocols that Internet hostsand applications can use to locate sources ofgeolocation information and acquire geolocationinformation from them. As such, the GEOPRIVprotocols can support most of the commondesign patterns in use in current geolocation sys-tems, as well as some additional scenarios thatarise from generalizing these techniques to otherparts of the Internet. GEOPRIV supports bothmore traditional fixed endpoints as well as newand emerging classes of hosts that are moremobile. In addition, the GEOPRIV architecturehas a strong focus on maintaining the privacyand security of location information, so it addsseveral privacy and security features beyondwhat current services offer.

In the remainder of this article, we explore allof these issues in more depth. In order to pro-vide some more thorough background, we pre-sent an overview of the main geolocation systemsin use in the Internet today and the design trade-offs each system poses. Given this reality, we dis-cuss how some general Internet engineeringprinciples can be applied, and how the GEO-PRIV architecture applies these principles tocreate a more interoperable, private, and securelocation service for the Internet.

TRADITIONAL LOCATION SYSTEMSLocation services within public telecommunica-tions networks have existed for many decades.The digitization of the public switched telephonenetwork (PSTN) in the latter half of the 20thcentury allowed the calling-line identity of theendpoints to be communicated through the net-work. The calling-line identity, also known as the“phone number,” is the physical address of end-points on the PSTN. For conventional fixed linetelephony, the association of this physicaladdress to location only required the incorpora-tion of a relatively static database associating thephone number with the known location to whichthe line serving that address terminated. Thisfacility became an embedded function of net-works, and has been used to support applicationssuch as emergency call routing and dispatch (theso-called emergency automatic location identifi-cation, or ALI, systems), and for location-basedrouting of 800 free-call services to deliver callsto the local pizza franchise via a common nation-al number, for example.

With the arrival of mobile networks, a compli-cation was introduced. Rather than just havingfixed points of attachment to the PSTN, deviceswere now able to move around within geographi-cal areas of coverage even though their physicaladdress (the phone number) did not change. Itwas no longer sufficient to incorporate a staticdatabase associating phone numbers to location.It became necessary to provide a network infra-structure that allowed location to be dynamicallydetermined. Solving this problem was givenimpetus in 1996 when the U.S. Federal Commu-nications Commission (FCC) defined regulationrequiring mobile network operators to deliver thelocation of calls made to the 911 service and todo so with a specified level of accuracy. In con-trast to the format in which the location of fixedpoints of PSTN access was referenced, typically

as a civic street address, the location of devices onmobile networks would be provided in geodeticform — that is, using latitude and longitude val-ues and associated uncertainty.

A significant amount of work subsequentlyoccurred in standards and emergency servicefora to develop the architectural principles, func-tional specifications, and detailed interface andprotocol specifications to support this dynamiclocation service within mobile networks [1–4].

LOCATION DETERMINATION METHODSIn conjunction with this architectural develop-ment, vendors of network equipment invested indevelopment of technologies for performing thelocation determination of devices attached to thenetworks. The fastest, cheapest location determi-nation method in mobile networks involves iden-tifying the serving cell or base station to whichthe device is attached. A cell in a mobile networkhas a nominal area of geographic coverage, andthis area of uncertainty can be returned as thelocation of the device. Cell sizes are not fixedand can vary from tens of meters in dense urbanenvironments to many kilometers in rural envi-ronments. While this cell identity (CID) methodis the cheapest approach to providing location, ithas an accuracy issue in environments with largecells. The following provides a summary of moreadvanced methods used to determine location ofdevices on mobile networks.

Enhanced cell identity: Networks can takeadvantage of already existing network measure-ments and use them for location determination,typically air interface timing and signal strengthmeasurements. Such measurements can bequickly combined with data about the base sta-tion to determine an approximate location.

Radio frequency fingerprinting: A survey ismade of mobile network coverage across, forexample, a grid of regularly spaced samplepoints. When the network is asked to locate adevice, it compares signal strength measure-ments of the visible cell towers to signal strengthvalues in the survey database.

Uplink timing measurement: Location mea-surement units (LMUs) with synchronized clockscan precisely register times at which they receivemessages from a target device, and calculate thelocation of the device based on time differenceof arrival (TDOA) calculations. LMU-basedtechnology is widely deployed in the UnitedStates to support 911.

Proximity measurement: In indoor or urbansituations with complex signal environments, it iscommon for mobile network operators to usedistributed antenna and repeater systems(DARSs) with small antennae throughout abuilding. LMUs can identify a target device’slocation by determining which antenna a deviceis using.

Downlink timing: The target device collectstime of arrival of signals from all visible cell tow-ers and provides them to the network. The net-work is able to combine the TDOA measurementswith known information about the location of thecell towers and determine location. While thistechnique can be difficult to employ in unsyn-chronized networks, it works well for synchro-nized networks and is a primary method currently

With the arrival of

mobile networks, a

complication was

introduced. Rather

than just having

fixed points of

attachment to the

PSTN, devices were

now able to move

around within

geographical areas

of coverage even

though their physical

address (the phone

number) did not

change.

BARNES LAYOUT 3/22/11 10:51 AM Page 103

IEEE Communications Magazine • April 2011104

identified for Long Term Evolution (LTE) [5].(Assisted) GPS: The normal global position-

ing system (GPS), or “autonomous” GPS, is ofcourse based on a device reading signals from aconstellation of satellites. Because the networkknows the approximate location of the device(e.g. using CID), it is able to assist the device indetermining its position, say, by telling it whichsatellites should be in view or what the associat-ed Doppler shifts are. Because the network isassisting with the GPS procedure, this method isgenerally called assisted GPS (A-GPS).

Combined (hybrid) and other methods: Whenit comes to determining consistent, accuratelocation, measurements are critical. The greaterthe number of sources of measurements thereare, and the higher the volume and quality ofmeasurements, the better the location servicecan be. For example, combining GPS range mea-surements taken from a device with timing mea-surements taken by the network may result in amethod referred to as hybrid A-GPS.

The preceding descriptions have coveredthose technologies most commonly seen inmobile networks today. Additional sources ofmeasurements are being used and proposed on aregular basis. Looking at other types of physicalnetworks that make up the Internet leads toeven more positioning choices. WiFi networksignals are a common measurement source whichcan be referenced into a database of knownWiFi access point locations. In fixed line net-works, many techniques can be applied (e.g.,querying managed switches over Simple NetworkManagement Protocol, SNMP) to determine thetopological location of a device and thus itsphysical location.

NETWORK LOCATION ARCHITECTURESLocation service architectures for mobile net-works were developed most directly in responseto emergency requirements, and they mostly usea network-centric approach. The Third Genera-tion Partnership Project (3GPP) standards forGlobal System for Mobile Communications(GSM) and Universal Mobile Telecommunica-tions System (UMTS) [2] identified a gatewayfunction, the gateway mobile location center(GMLC), which provides location information tolocation-based applications, including both pub-lic safety answering points involved in 911, andcommercial services such as friend finders andfleet tracking applications. Access to the GMLCis typically done using the Open Mobile Alliance(OMA) Mobile Location Protocol (MLP) [4] or,for U.S.-specific emergency applications, theNational Emergency Number Association(NENA) E2 interface protocol [3]. Some fixednetworks provide a similar function using theEuropean Telecommunications Standards Insti-tute (ETSI) Parlay/X protocols [6]. Applicationsrequire operator permission to access the loca-tion service. This often leads to the characteriza-tion of the traditional mobile network locationservice as being in a “walled garden.”

In recent years, operators have been imple-menting an alternative location service architec-ture called secure user plane location (SUPL)[7] defined by the OMA. This architecturebypasses the specifics of the radio access net-

work; it relies completely on measurements thatcan be made by the device. Measurements areconveyed via the user data channel (primarilyover IP), and no location-service-specific controlplane procedures are involved. As with controlplane location solutions, applications ask forlocation by sending MLP queries to a server (inthis case an SUPL location platform), and accessto this server is tightly controlled.

Largely in response to the walled gardennature of the location service within mobile net-works, another category of location servicearchitecture has emerged that operates indepen-dent of the network, providing location informa-tion largely based on knowledge of the networkcollected through external observations. Exam-ples include the Skyhook location service, thelocation service used by Apple iOS devices, andthe Google location service used by manyAndroid devices.

Typically in these systems, WiFi and any cel-lular network interfaces on the device are usedto measure visible WiFi and/or mobile networkcell towers. The provider of the location servicemaintains a global database of WiFi accesspoints and cell towers with corresponding loca-tions, which it uses to compute an estimate ofthe device’s location.

Ideally these databases contain informationfor every access point and cell tower in theworld; such systems are also referred to as worldin a database (WiDB). Of course, in practice,these databases only cover portions of the world— the portions that are important to the majori-ty of the customers of the location service —and often contain stale information. So thisarchitecture frequently provides lower fidelitythan a dedicated network location service. Thebenefit of such architectures, however, is theiropenness, which allows location information tobecome a fundamental element of the operatingsystem, accessible via an application program-ming interface (API) to any application on thedevice. It is this alternative architecture that hasunderpinned the recent explosion of location-based applications, in contrast to the small num-ber of applications created over the previousdecade of conventional mobile network walledgarden location services.

SOME INTERNET DESIGN PRINCIPLESThe benefit of the variety of location solutionsdiscussed in the previous section is that there isa wealth of location information available forInternet location-based services. The challenge isthat none of these services provides high-qualitylocation information for the whole Internet;even a single host might be better located by dif-ferent services at different times.

For each of the above approaches, there aresituations where it has advantages over the oth-ers. Consider a single cellular device with a GPSchip and WiFi and cellular IP interfaces, as itmoves through different environments. Out inan open field, far from any network, with a clearview of the sky, GPS will clearly outperform anynetwork-based positioning system; in an urbanarea, wireless signals might provide a very pre-cise location where GPS is unable to work at all.

The benefit of the

variety of location

solutions is that

there is a wealth of

information available

for Internet location-

based services. The

challenge is that

none of these

services provides

high-quality location

information for the

whole Internet; even

a single host might

be better located by

different services at

different times.



Carrier-based positioning systems will often havebetter positioning than a system based on adatabase WiFi access points when the device isin an area where the carrier has many towers.But by the same token, when the device is notnear the carrier’s network, nearby WiFi accesspoints might provide a better indication of thedevice’s location.

So a host or an application cannot rely on asingle service to provide good location informa-tion in all situations; the best solutions will usethe best source for a given situation. The ques-tion then arises: What is the source for a givensituation? If a host is seeking information on itsown geolocation, which server should it query?If an application is seeking information about ahost, which server knows about that host?

These questions (precise answers to which wediscuss in the next section) demonstrate theimportance in this context of two of the key con-cepts underlying the Internet.

Dynamic service discovery: Most Internet ser-vices incorporate a service discovery function inorder to help locate the proper servers for agiven request. Dynamic Host Configuration Pro-tocol (DHCP) and Point-to-Point Protocol (PPP)allow networks to inform hosts about local DNSresolvers and local DNS prefixes. DNS records,in turn, direct clients to the proper applicationservers, using A records to point to IP addressesas well as SRV and NAPTR records for moreadvanced discovery functions.

For location, the discovery question is some-what different from the usual form. Normally, auser has directed his/her computer to connect toa given service, say to send an email to<[email protected]>; the discovery questionis thus “Which server knows about mail forexample.com?” For geolocation, the question israther “Which server knows about geolocationfor this host?”

As the previous section demonstrates, therecan be multiple answers to that question, but inthe Internet context, there is one entity in partic-ular that is likely to have some special insight —the access network to which the host is physicallyconnected. In many cases, the physical relation-ship that the network has to its connected hostsallows the network to provide geolocation infor-mation, or at least recommend a server that islikely to have it. As we discuss below, the GEO-PRIV system incorporates mechanisms for net-works to advertise location servers to bothconnected hosts and third parties.

Common, interoperable protocols: The adapt-ability created by a dynamic discovery system isnot of much value if the client has to use a dif-ferent protocol for every server it discovers —the burden of implementing multiple protocols(e.g., one for fixed access and one for wirelessaccess) and choosing which one to use with eachserver would be too large. So a critical prerequi-site for clients to be able to use multiple locationsources is for these sources all to present a com-mon interface to the client (i.e., to enable theclient to query each server in more or less thesame way).

Obviously, the situation today is more theformer than the latter. One of the major designgoals of the GEOPRIV system is to create a sin-

gle protocol framework that a client can use totalk to many different types of positioning sys-tems. As we describe in the next section, thisrole will be played by the HELD protocol, a sim-ple common location protocol based on XMLand HTTP that can support all of the position-ing mechanisms described above, as well as sev-eral more.

THE GEOPRIV LOCATION SERVICEThe IETF GEOPRIV working group was estab-lished to specify standard mechanisms for loca-tion acquisition, representation, and privacyacross the Internet. The importance of this workhas grown in recent years with the rapid acceler-ation of IP communication and rapid decline ofmore traditional circuit-switched networks.

LOCATION PROTOCOLS AND SERVICE DELIVERYThe primary product of the GEOPRIV work-

ing group is a pair of location configuration pro-tocols (LCPs), which provide an Internet hostwith information about its own location so thatthe host can then use this location informationwith location-based services. Just as the Internetuses standard protocols for standard servicesregardless of the underlying access technology,these protocols are designed to provide locationservices in a consistent way regardless of theunderlying network or the positioning technolo-gy being used.

The first LCP to be developed was a set of

Figure 1. Location by value and location by reference.

ServiceTarget

2. Location responsevalue

1. Location request

3. Locationconveyance

Location by value

LIS

Access network Internet

ServiceTarget

2. Location responseURI

1. Location request

3. Locationconveyance

5. Location response

4. Location request

Location by reference

LIS

Access network Internet



extensions to DHCP that allow a network opera-tor to configure connected hosts with locationinformation alongside other network configura-tion (IP addresses, DNS resolvers, etc.). Theseextensions can encode location information inthree forms:• Geodetic: As a set of coordinates (latitude,

longitude, altitude) [8, draft-ietf-geopriv-rfc3825bis]

• Civic: As an address comprised of asequence of typed labels (country, state,city, street, number, etc.) [9]

• Reference: A URI pointing to one of theabove. [8, draft-ietf-geopriv-rfc3825bis]There are two distinctions here that are con-

sistent throughout the GEOPRIV system. First,location information can be presented directly“by value” or indirectly “by reference”; and sec-ond, location values can be presented in civic orgeodetic form. The operational differencebetween location by value and by reference isillustrated in Fig. 1.

While these DHCP extensions are simple touse in principle, they cannot address many usecases. For instance, hosts behind a residentialgateway usually cannot receive DHCP informa-tion from the upstream ISP. (Most residential

gateways act as Network Address Translators[NATs]. They thus provide their own DHCP ser-vice, independent of the ISP’s, and do not prop-agate ISP-provided DHCP information into thelocal DHCP service.) Many of the positioningsystems described above require richer interac-tion between the device and a location server.These cases are addressed by the HTTP-EnabledLocation Delivery (HELD) protocol, whichdefines an XML syntax for location requests andresponses carried in HTTP [10].

In its most basic form, HELD enables a clientto send a query that says “Where am I?” and theserver to respond with a location value and/orlocation reference. (In this case, the server mustdetermine location solely on the basis of theclient’s IP address, and possibly remote mea-surements.) When location is provided by value,it is in the form of an extended presence docu-ment, using the PIDF-LO format [11]. Figure 2illustrates a basic HELD exchange, in which theclient requests location information in any form,and the server replies with a PIDF-LO objectcontaining a geodetic location — a point describ-ing the client’s position.

HELD also comes with two extensions thatallow it to replicate the major design patternsdescribed above. The HELD identity extensionsallow clients to specify identifiers for the targetdevice [12]. In a basic HELD, location is provid-ed based on the client’s IP address, but manycurrent location servers — such as the GMLCsand SLPs described above — only provide loca-tion based on other identifiers, such as a tele-phone number, IMSI, or MSISDN. If a clientincludes one of these identifiers in a HELDrequest, the server can use it in addition to theclient’s IP address in determining the client’slocation — possibly by sending a request to alegacy location function like a GMLC or SLP.An example request is shown in Fig. 3.

Note also that when location is based only onthe identifier provided in HELD and not on theclient’s IP address, the client doesn’t have to bethe target of the request; location-based servicescan request location directly. This fact meansthat using the identity extensions, HELD can beused in the same manner as MLP or Parlay/X,with the additional benefit that it supports iden-tifiers beyond the traditional telephone-basedidentifiers that the legacy protocols use. In addi-tion to things like IMSIs and MSISDNs, HELDcan carry IP address, MAC addresses, TCP portnumbers, DHCP unique IDs, and others.

To support positioning mechanisms that requiremeasurements to be passed between a client and aserver, the HELD measurement extensions pro-vide an XML syntax for encoding network mea-surements of many types, including things likeUMTS or LTE cell ID information, WiFi signaland timing measurements, and DHCP relay agentinformation [13]. The goal of this extension is tocover many different types of observations that anInternet host might be able to make, and to providean extensible container for defining additionaltypes of measurements as the Internet evolves. Anexample request from a device with WiFi and cel-lular interfaces is shown in Fig. 3.

Ultimately, the point of all these locationprotocols is to deliver a location-based service.Figure 2. A basic HELD request and response.

POST /location HTTP/1.1Host: lis.example.com:43951Content-Type: application/held+xml;charset=utf-8Content-Length: 87

<?xml version="1.0"?><locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>

HTTP/1.1 200 OKServer: Example LISDate: Sat, 20 Feb 2010 03:42:29 GMTExpires: Sat, 20 Feb 2010 03:42:29 GMTCache-control: privateContent-Type: application/held+xml;charset=utf-8Content-Length: 913

<?xml version="1.0"?><locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"><presence xmlns="urn:ietf:params:xml:ns:pidf"

xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"xmlns:gml="http://www.opengis.net/gml "xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy ">entity="pres:[email protected]"><tuple id="b650sf789nd"> <status>

<gp:geopriv><gp:location-info><gml:Point srsName="urn:ogc:def:crs:EPSG::4326">

<gml:pos>-34.407 150.88001</gml:pos></gml:Point>

</gp:location-info><gbp:usage-rules>

<gbp:retransmission-allowed>false</gbp:retransmission-allowed><gbp:retention-expiry>

2010-02-17T03:42:28+00:00</gbp:retention-expiry>

</gbp:usage-rules></gp:geopriv>

</status><timestamp>2010-02-16T03:42:28+00:00</timestamp>

</tuple></presence>

</locationResponse>



HELD and DHCP can be used to support threebasic service models, illustrated in Fig. 5. Thepreferred model is for the target host to useDHCP or HELD to obtain location informationand then convey it to the location-based service.The information can be provided using either aprotocol that is designed to carry location infor-mation, for example, in a SIP Geolocation head-er [14], or an API on the device, such as theW3C Geolocation API [15], the iOS CoreLoca-tion API, or the Android LocationManager API.

An alternative model that is useful for transi-tioning legacy location services or location-basedservices is for the location-based service to querythe location server directly, using a HELD requestcontaining an identity extension to identify thedesired client. This case presents a couple of chal-lenges, however, since the service has to have away to find the proper location server to ask abouta given client (recalling that no one server coversthe whole Internet), and the location server needssome way to know whether the target has autho-rized the service to obtain location information (inorder to protect the user’s privacy).

The use of location by reference creates athird service delivery model, in which the deviceobtains a location URI and provides it to a loca-tion-based service; then the server dereferencesthe URI to obtain the device’s location. Thisextra dereference step can be used as a controlpoint to enforce the client’s privacy preferencesor the server’s access control preferences.

ADAPTABILITY, PRIVACY, AND SECURITYAs discussed above, no single location server iscapable of providing high-quality location infor-mation for the entire Internet, or even all thenetworks to which a single device can connect.The GEOPRIV system thus includes a simplemechanism for networks to recommend a loca-

tion server to connected hosts, so hosts can dis-cover and use the location server that is mostlikely to provide good results [16].

In order to advertise a location server, thenetwork needs to inform the client of an HTTPURI to which the client should direct its HELDrequests. The discovery mechanism leveragestwo existing Internet protocols for dynamic ser-

Figure 3. A HELD request including WiFi and cellular measurements.

<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"><device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

<uri>sip:[email protected]</uri><mac>A0-12-34-56-78-90</mac><msisdn>11235550123</msisdn>

</device><measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"

time="2011-04-29T14:33:58"><wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">

<nicType>Intel(r)PRO/Wireless 2200BG</nicType><servingWap>

<ssid>wlan-home</ssid><bssid>00-12-F0-A0-80-EF</bssid><channel>7</channel><rssi>-55</rssi>

</servingWap></wifi><cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">

<servingCell><mcc>465</mcc><mnc>20</mnc><eucid>80936424</eucid>

</servingCell><observedCell>

<mcc>465</mcc><mnc>06</mnc><eucid>10736789</eucid>

</observedCell></cellular>

</measurements></locationRequest>

Figure 4. Service delivery models.

Geolocation information

Device-mediated Legacy / third-party request

Locationserver

Userdevice

LBS Locationserver

Userdevice

LBS

Location by reference

Locationserver

Userdevice

LBS

Location reference

Service request/delivery



vice discovery: DHCP and DNS. When the clientconnects to the network, the network provides aspecial discovery extension with a domain namethat identifies the network. (This name is dis-tinct from the domain names usually provided inDHCP, which provide a prefix for making DNSqueries.) The client then sends a DNS query torequest NAPTR records that contain the desiredURIs, as illustrated in Fig. 4.

One interesting feature of this discoverymodel is that it can also be used when the accessnetwork cannot provide DHCP information toclients (as in the residential gateway scenario) [8,draft-ietf-geopriv-res-gw-lis-discovery]. If thenetwork provider provisions the proper NAPTRrecords in the “reverse DNS” tree (under in-addr.arpa or ip6.arpa), any client that knows itspublic-facing IP address can make a reverseDNS query with the IP address in order to findits local location server. Provisioning NAPTRrecords in the reverse DNS also allows third-party location services to discover the properlocation server for an IP address.

As the name suggests, the GEOPRIV archi-tecture includes several mechanisms for ensuringthe privacy and security of location information[8, draft-ietf-geopriv-arch]. The first step toward abetter privacy model is the explicit intermediationof the device in the delivery of location-based ser-vices, as illustrated above. Location by referenceprovides another step, by allowing the endpoint tocontrol location distribution at two points: bychoosing who receives the URI, and choosingwho can dereference the URI (via privacy rulesprovisioned on the location server and [8, draft-ietf-geopriv-policy-uri; 17]. Providing precise loca-tion only by reference can allow a location serverto protect its interest in location information (byselectively granting access to partner applica-tions), while still allowing users a choice of whichapplications have access to their location [18].

REFERENCES[1] J-STD-036B, “Enhanced Wireless 9-1-1 Phase 2,” TIA,

2006.[2] 3GPP TS 23.271, “Functional Stage 2 Description of

Location Services (LCS).”[3] NENA-05-001, “NENA Standard for the Implementation

of the Wireless Emergency Service Protocol E2 Inter-face,” Dec. 2003.

[4] OMA-TS-MLP-V3_3-20100831-C, “Mobile Location Pro-tocol 3.3 Candidate Version 3.3,” Aug. 31, 2010.

[5] 3GPP TS 36.305, “Stage 2 Functional Specification ofUser Equipment (UE) Positioning in E-UTRAN.

[6] ETSI standard 202 915-1 V1.2.1, “ Open Service Access(OSA): API; Part 1: Overview,” 2003.

[7] OMA-AD-SUPL-V2_0-20091208-C, “Secure User PlaneLocation Architecture Candidate Version 2.0,” Dec. 8,2009.

[8] IETF GEOPRIV working group drafts, http://tools.ietf.org/wg/geopriv/.

[9] H. Schulzrinne, “Dynamic Host Configuration Protocol(DHCPv4 and DHCPv6) Option for Civic Addresses Con-figuration Information,” IETF RFC 4776, Nov. 2006.

[10] M. Barnes, Ed., “HTTP Enabled Location Delivery(HELD),” IETF RFC 5985, Sept. 2010.

[11] J. Peterson, “A Presence-based GEOPRIV LocationObject Format,” IETF RFC 4119, Dec. 2005.

[12] J. Winterbottom et al., “Use of Device Identity in HTTP-Enabled Location Delivery (HELD),” RFC 6155, Mar. 2011.

[13] M. Thomson and J. Winterbottom, “Using Device-pro-vided Location-Related Measurements in Location Con-figuration Protocols,” draft-ietf-geopriv-held-measurements-00, July 2010, work in progress.

[14] J. Polk, B. Rosen, and J. Peterson, “Location Conveyancefor the Session Initiation Protocol,” draft-ietf-sipcore-loca-tion-conveyance-03), July 2010, work in progress.

[15] A. Popescu, Ed., “W3C Geolocation API Specification,”Dec. 2008.

[16] M. Thomson and J. Winterbottom, “Discovering theLocal Location Information Server (LIS),” IETF RFC 5986,Sept. 2010.

[17] H. Schulzrinne et al., “Common Policy: A DocumentFormat for Expressing Privacy Preferences,” IETF RFC4745, Feb.2007.

[18] R. Barnes and M. Lepinski, “Using Imprecise Locationfor Emergency Context Resolution,” draft-ietf-ecrit-rough-loc-03, Aug. 2010, work in progress.

BIOGRAPHIESRICHARD BARNES ([email protected]) is a leader in standardsrelated to security and real-time applications on the Inter-net. He currently chairs the IETF GEOPRIV and ECRIT work-ing groups, and serves on the program committee for theEmergency Services Workshop.

JAMES WINTERBOTTOM ([email protected])has 24 years of experience in the telecommunicationsindustry beginning with Telecom Australia back in 1986.For the last eight years he has been actively involved innext-generation emergency calling standards around theglobe. He has been actively involved in the IETF GEOPRIVwork focusing on location information and is the co-authorof several RFCs. He has also been involved in the IETF ECRITworking group since its formation. He has led a number ofNENA working groups dealing with NG9-1-1 location issuesin North America and is currently the co-chair of the Loca-tion Information Server (LIS) working group.

MARTIN DAWSON ([email protected]) has over 30years of experience in the embedded control, networking,and telecommunication industries. He is currently directorof the CommScope GeoLENs location server business. Priorto CommScope, he spent 10 years with Nortel working oncellular location technologies, intelligent network services,and wireless intelligent networks. Previously, he wasinvolved in intelligent network platform development forTelstra, and doing IN service creation and speech recogni-tion system development at British Telecom Research Labsin the United Kingdom. He worked at the University ofSydney doing network and server management includingthe deployment of one the world's first campus-wide Eth-ernet networks. Prior to his involvement in networking, heworked on the development of real-time control systemsand software in BHP and then GEC Digital.

Figure 5. Location server discovery records in theforward and reverse zones.

example.com. IN NAPTR 100 10 "u" "LIS:HELD""!*.!https://lis.example.org:4802/?c=ex!".

1.2.0.192.in-addr.arpa. IN NAPTR 100 10 "u" "LIS:HELD""!*.!https://lis.example.org:4802/?c=ex!".

Providing precise

location only by ref-

erence can allow a

location server to

protect its interest in

location information

(by selectively grant-

ing access to partner

applications), while

still allowing users a

choice in which

applications have

access to their

location.


internet geolocation and location-based services

Documents