Location Privacy Mechanisms in 3GPP

Cellular network specifications are a useful starting point when LCS concepts are being discussed. This is because LCS functionality is relatively mature in this category of networks. Using the 3GPP specification as a point of reference, the functionality in place in support of privacy can be studied and some general principles can be derived. The discussion of privacy legislation highlighted that four types of location requesters are pertinent :

• Those with implicit permission
• Those with explicit permission
• Emergency services
• Law enforcement

Implicit permission exists where access to, and use of, the location information is associated with an existing service arrangement. A clear example of this is the cellular telephony service itself. In order to route a call to a subscriber, the cellular network needs to locate that subscriber, at least to the precision of the current serving cell. That is, locating the person and using the location information is part and parcel of the service arrangement, is understood in principle as being required to provide that service, and implicit permission to do so therefore exists. Emergency services are well understood as a service in which permission to provide location is offered implicitly in the act of dialing the service. This is essentially an example of implicit permission. The principles of legislation, however, indicate that location may also be disclosed where there are reasonable grounds to believe that the person's or other persons' safety may be in danger. In this case, the requester of location effectively assumes that the person would give their permission if they could. If any network privacy constraints exist, a mechanism by which they can be overridden is required in this kind of scenario.

Explicit permission is more obvious. This can occur at the time of a location request-when a notification is sent to the person's handset indicating that a particular person would like the location of the handset. A positive response is explicit permission to provide that location in this particular instance. Alternatively, permission may be provided in advance. For instance, the handset location may be provided to any predefined group of "friends" who may be authenticated by a PIN or other mechanism. Law enforcement agencies are typically provided with privileged access to information which would otherwise be held in confidence when it is necessary to proceed with investigations relating to crime and/or national security. These privileges are generally defined in some separate legislation relating to these activities. Due process incorporating the desired checks and balances will normally require the application and granting of a warrant or other formal permission before the information can be accessed and used. As for emergency services, a network mechanism is required that permits properly controlled requests for location in a valid lawful requirement scenario.

To see how 3GPP supports these different requester types, reference is made to the Stage 2 LCS specifications. The "portal" through which applications may request location in a 3GPP network is called the gateway mobile location center (GMLC). To begin with, LCS clients can be placed in one of four categories:

• Emergency Services
• Value Added Services
• PLMN Operator Services
• Lawful Intercept Services

Once an application is authenticated as being of type Emergency Services or PLMN (Public Land Mobile Network) Operator, then permission is considered to be implicit and/or any preference for denial is legitimately overridden. Similarly, an authenticated Lawful Intercept-type service will override privacy restrictions without any notification to the user of the device. Value Added Services are those that require some form of conscious user permission and this may be required to be explicit. From the perspective of the GMLC, the permission may be considered implicit, particularly where the exchange of permission occurred at the application layer. This may have been permission granted as part of the process of subscribing to the application, or it may be granted as part of execution of the application. For example, the user may select a checkbox on their web browser if the restaurant-finder application they are using asks for permission to automatically locate them at the time of each use of the service. In this case, by the time the application requests location via the GMLC, permission is considered to have been already granted. Other value-added services, particularly those where the user of the target device is not also the user of the service, may require that the user be notified via the device before location is provided. Continuing with providing location may also require the subsequent granting of permission via the device. With this model in mind, the references describes the information that each subscriber can define with respect to their LCS privacy preferences. For example, each user can specify the default privacy preference, and/or for a list of specific LCS clients they can specify precise preferences just for those services. The following options are defined preferences that a subscriber can assign to a given LCS client:

• Location not allowed
• Location allowed without notification
• Location allowed with notification
• Location with notification and privacy verification; location allowed if no response
• Location with notification and privacy verification; location restricted if no response

There are more aspects than those just described, which govern the application of LCS privacy in a 3GPP network, including privacy being determined based on whether the user is currently on a call to the application requesting the location. This is known as a call-related-type request. Thus, in the 3GPP model, privacy is controlled at two separate points. First of all, the LCS client (the application) is authenticated at the GMLC. The GMLC associates the correct characteristics with the application such as whether it is an emergency service or a value-added service and it includes this information in the location request sent to the serving network. Final permission approval is determined in the visitor location register (VLR) just before location determination procedures are invoked. The VLR contains a copy of the subscriber's privacy preferences as stored in the HLR. If the application information doesn't indicate that privacy preferences should be overridden, the VLR consults the list of specific LCS clients identified for the subscriber. If found, the preferences are observed. For example, the request is denied, permitted, or some combination of notification and permission granting occurs. If the service is not specifically listed, then the subscriber's default privacy preference prevails.

Privacy Control Mechanisms in 3GPP

The preceding description of LCS privacy controls for a 3GPP network is as documented up to Release 5 of those standards. In recent times, an additional network element has been added called the Privacy Profile Register (PPR). This can be found in Release 6 onwards of the 3GPP specifications. This modification moves the hosting of the subscriber privacy preferences from the HLR and VLR into the PPR. This was done to provide a mechanism whereby privacy preference checking could be constrained to the home network. Privacy checking done in the VLR requires this to be done in the visited network. The protocol for interacting with the PPR, the Privacy Checking Protocol (PCP), is still to be defined. While some additional functionality is available, such as actually restricting location information based on the location itself, the effective capability is much as previously described. The identification of the PPR as a standalone function, however, is a significant move as, with its associated query protocol, it establishes a mechanism whereby any appropriately authorized network element can perform privacy checks on behalf of a given user. Doing the privacy checking in the VLR tightly coupled this operation with the services control of the 3GPP network. Placing the privacy rule evaluation in an external element means that this evaluation may be requested by another network element which is independent of the service provider. For example, an LIS may be informed of the identity of the PPR and given permission by a device to evaluate requests for location by referring to that PPR.