4 Functional Requirements

22.0713GPPLocation Services (LCS)Release 17Service descriptionStage 1TS

4.0 General

3GPP standards shall support location service features, to allow new and innovative location-based services to be developed. It shall be possible to identify and report in a standard format (e.g. geographical co-ordinates) the current location of the user’s terminal and to make the information available to the user, ME, network operator, service provider, value added service providers and for PLMN internal operations.

The location is provided to identify the likely location of specific MEs. This is meant to be used for charging, location-based services, lawful interception, emergency calls, etc., as well as the positioning services.

The standard shall support NG-RAN, E-UTRAN, GERAN and UTRAN to facilitate determination of the location of a mobile station.

The following subsections provide general descriptions of attributes that can be used to describe or characterize various location services.

The relative importance of these attributes varies from service to service. However, accuracy, coverage, privacy and transaction rate may be considered the primary distinguishing attributes that define a value-added service. Briefly:

• accuracy is the difference between actual location and estimated location,
• coverage is an expression of the geographic area in which the UE user will receive an adequate perceived quality of service,
• privacy describes the user’s perception of confidentiality of the location information, and
• transaction rate indicates how frequently network messaging is required to support the service.

A general comparison of the specific attributes of various location-based services is provided in Annex C of this document.

4.1 High Level Requirements

The following high-level requirements are applicable:

1 The supporting mechanisms should incorporate flexible modular components with open interfaces that facilitate equipment interoperability and the evolution of service providing capabilities.

2 The network should be sufficiently flexible to accommodate evolving enabling mechanisms and service requirements to provide new and improved services.

3 It shall be possible to provide multiple layers of permissions to comply with local, national, and regional privacy requirements.

4 Multiple positioning methods should be supported in the different Access Networks, including (but not limited to):

– Modernized GPS;

– SBAS (Satellite Based Augmentation Systems: EGNOS, WAAS, GAGAN, MSAS);

– QZSS (Quasi Zenith Satellite System);

– GLONASS

– BDS

– Galileo

– U-TDOA

– E-OTD

– IPDL-OTDOA

– Network Assisted GNSS (e.g. Network Assisted GPS or Network Assisted GALILEO)

– UE ambient condition sensors-based positioning

– Motion sensors (e.g. accelerometers, gyroscopes)

– Environmental sensors (e.g. barometer)

– Position sensors (e.g. magnetometers, orientation sensors)

– TBS

– Beacon identity for location lookup (e.g. WiFi access points or BLE beacons)

– RF Pattern Matching

– Methods using cell site or sector information and Timing Advance or RoundTrip Time measurements.

5 The location determining process should be able to combine diverse positioning techniques and local knowledge when considering quality of service parameters to provide an optimal positioning request response.

6 It should be possible to provide position information to location services applications existing within the PLMN, external to the PLMN, or in Mobile Equipment;

7 Support should be provided for networks based on Intelligent Network architecture (i.e. with specific support for CAMEL based Location Services).

8 Support may optionally be provided to enable the routing of emergency calls based on the geographic coordinates (latitude and longitude) of the calling party.

9 It shall be possible to provide the originating party’s serving cell id to the LCS client.

4.2 Location Information

Location Information consists of Geographic Location, Velocity, Civic Location and Quality of Service information, as described in the subsequent sections.

4.2.1 Geographic Location

Provision of the geographic location of a target UE is applicable to all LCS services.

Note: For services other than LCS the network may also determine within which Cell, Service Area, or Tracking Area the Target UE is located ("Service Area" and "Tracking Area" are UTRAN and E-UTRAN concepts respectively and both may consist of one (in R99) or more than one cell). The Service or Tracking Area information or Cell ID may be used for routing of calls or for CAMEL applications, if supported.

It should be noted that the Service and Tracking Area concepts are different from the Localized Service Area concept used for SoLSA.

4.2.2 Velocity

Velocity is the combination of speed and direction of a Target UE. It shall be possible for a UE to provide its velocity to the LCS server.

Note: This requirement only applies to satellite-based positioning systems.

For Value Added Services and PLMN Operator Services, the following is applicable:

Provision of the velocity of a target UE is application driven. Location Services may allow an LCS Client to request or negotiate the provision of velocity.

For Emergency Services there is no requirement to provide velocity.

4.2.3 Dispatchable Location

Provision of the Dispatchable Location of a target UE in civic form is applicable to Emergency Services based on regional regulatory requirements.

An example of Dispatchable Location regional regulatory requirements for the United States can be found in [12] and [13].

4.3 Quality of Service

4.3.1 Horizontal Accuracy

The accuracy that can be provided with various positioning technologies depends on a number of factors, many of which are dynamic in nature. As such the accuracy that will be realistically achievable in an operational system will vary due to such factors as the dynamically varying radio environments (considering signal attenuation and multipath propagation), network topography in terms of base station density and geography, and positioning equipment available.

The accuracy for location services can be expressed in terms of a range of values that reflect the general accuracy level needed for the application. Different services require different levels of positioning accuracy. The range may vary from tens of meters (navigation services) to perhaps kilometers (fleet management).

The majority of attractive value-added location services are enabled when location accuracies of between 25m and 200m can be provided.

Based on decreasing accuracy requirement some examples of location services are provided in table 4.1. The LCS service shall provide techniques that allow operators to deploy networks that can provide at least the level of accuracy required by the regional regulatory bodies (e.g. Annex A).

Table 4.1; Example of location services with decreasing accuracy requirement

· Location-independent	Most existing cellular services, Stock prices, sports reports
· PLMN or country	Services that are restricted to one country or one PLMN
· Regional (up to 200km)	Weather reports, localized weather warnings, traffic information (pre-trip)
· District (up to 20km)	Local news, traffic reports
· Up to 1 km	Vehicle asset management, targeted congestion avoidance advice
· 500m to 1km	Rural and suburban emergency services, manpower planning, information services (where are?)
· 100m (67%) · 300m (95%)	U.S. FCC mandate (99-245) for wireless emergency calls using network-based positioning methods
· 75m-125m	Urban SOS, localized advertising, home zone pricing, network maintenance, network demand monitoring, asset tracking, information services (where is the nearest?)
· 50m (80%)	U.S. FCC mandate [12] and [13] for wireless emergency calls
· 10m-50m	Asset Location, route guidance, navigation

Accuracy may be independently considered with respect to horizontal and vertical positioning estimates. Some location services may not require both, others may require both, but with different degrees of accuracy.

Given that the location estimate is the best possible within the bounds of required response time, the location estimates of a fixed position UE (assuming several estimates are made) will reveal a ‘spread’ of estimates around the actual UE position. The distribution of locations can be described by normal statistical parameters and suggests that a small proportion of location estimates may lie outside of the acceptable Quality of Service (QoS) parameters for specific services (as determined by the network operator).

It may be possible to provide information on the confidence that can be associated with a location estimate. This may be used by location services to decide if a position update should be requested, for example, if the reported accuracy falls below a threshold determined by the LCS Client or Network Operator for a specific service.

It may also be possible to determine velocity (speed and heading) information from a location request.

When delivered with a location estimate, the confidence region parameters, speed and heading may allow an application to improve the service delivered to the UE user. Some examples are given below:

a) Confidence Region: Simple measure of uncertainty that specifies the size and orientation of the ellipse in which an UE is likely to lie with a predetermined confidence (e.g. 67%). The size of the confidence region may be used by the network operator or the LCS Client to request an updated location estimate.

b) Speed: enables e.g. congestion monitoring, and average travel time estimates between locations.

c) Heading: the location estimate of a vehicle may be improved to identify the appropriate side of the highway. This may enable the provision of traffic information that relates only to the user’s direction of travel.

For Value Added Services and PLMN Operator Services, the following is applicable:

Accuracy is application driven and is one of the negotiable Quality of Service (QoS) parameters.

The precision of the location shall be network design dependent, i.e., should be an operator’s choice. This precision requirement may vary from one part of a network to another.

The LCS shall allow an LCS Client to specify or negotiate the required horizontal accuracy. The LCS shall normally attempt to satisfy or approach as closely as possible the requested or negotiated accuracy when other quality of service parameters are not in conflict. The achieved accuracy level of location information shall be indicated using the shapes and uncertainty areas defined in 3GPP TS 23.032 [2].

For Emergency Services (where required by local regulatory requirements) the following requirements shall be met:

– When providing a Location Estimate, the LCS Server shall attempt to obtain the horizontal location of the calling UE, in terms of universal latitude and longitude coordinates, and shall provide this to an Emergency Service Provider. The accuracy shall be defined by local regulatory requirements. Annex A shows such requirements as exist in the United States.

– For Emergency Services within some countries, a network may be allowed to report accuracy at the cell id level. If the UE and the serving network are capable of delivering a more accurate location, indication of this capability may, as a national option, be supplied to the authorities along with the location. This indication will notify the authorities that they are able to request location with a high accuracy QoS.

NOTE: The LCS Server provides the location service capabilities but the mechanism by which location is reported to an emergency service provider is outside the scope of this service.

4.3.2 Vertical Accuracy

For Value Added Services, and PLMN Operator Services, the following is applicable:

– When providing a Location Estimate, the LCS Server may provide the vertical location of a UE in terms of either absolute height/depth or relative height/depth to local ground level. The LCS Server shall allow an LCS Client to specify or negotiate the required vertical accuracy. The LCS Server shall normally attempt to satisfy or approach as closely as possible the requested or negotiated accuracy when other quality of service parameters are not in conflict.

– The vertical accuracy may range from about three metres (e.g. to resolve within 1 floor of a building) to hundreds of metres.

For Emergency Services (where vertical location is required by local regulatory requirements) the following is applicable:

– The LCS Server shall attempt to obtain the vertical location or elevation of the calling UE and shall provide this to an Emergency Service Provider.

– The vertical location of the UE shall be expressed in terms defined by local regulatory requirements which may include absolute height/depth or relative height/depth to ground level.

– The vertical location accuracy shall be defined by local regulatory requirements. Annex A shows such requirements that exist in the United States.

NOTE 1: The LCS Server provides the location service capabilities but the mechanism by which location is reported to an emergency service provider is outside the scope of this service.

NOTE 2: The only known regulations for vertical accuracy for Emergency Services is in the United States (see Annex A.) The vertical accuracy requirements in these regulations only apply to Emergency Services usage over E-UTRAN and later defined access.

4.3.3 Response Time

Different location-based services, or different LCS Clients, may have different requirements (depending on the urgency of the positioning request) for obtaining a response. The location server may need to make trade-offs between requirements for positioning accuracy and response time.

For Value Added Services, and PLMN Operator Services, the following is applicable:

Response Time is one of the negotiable QoS parameters. Support of response time by a Public Land Mobile Network (PLMN) is optional. The LCS Server may allow a LCS Client to specify or negotiate the required response time (in the context of immediate location request, see table 1) either at provisioning or when the request is made. The LCS Server may optionally ignore any response time specified by the LCS Client that was not negotiated. If response time is not ignored, the LCS Server shall attempt to satisfy or approach it as closely as possible when other quality of service parameters are not in conflict.

For immediate location request response time options are as follows:

a) “no delay”: the server should immediately return any location estimate or Dispatchable Location that it currently has. The LCS Server shall return either the Initial or Last Known Location of the Target UE. If no location estimate or Dispatchable Location is available, the LCS Server shall return the failure indication and may optionally initiate procedures to obtain a location estimate or Dispatchable Location (e.g. to be available for a later request).

b) “low delay”: fulfilment of the response time requirement takes precedence over fulfilment of the accuracy requirement. The LCS Server shall return the Current Location with minimum delay. The LCS shall attempt to fulfil any accuracy requirement, but in doing so shall not add any additional delay (i.e. a quick response with lower accuracy is more desirable than waiting for a more accurate response).

c) “delay tolerant”: fulfilment of the accuracy requirement takes precedence over fulfilment of the response time requirement. If necessary, the server should delay providing a response until the accuracy requirement of the requesting application is met. The LCS Server shall obtain a Current Location with regard to fulfilling the accuracy requirement.

For Emergency Services (where required by local regulatory requirements) there may be no requirement to support negotiation of response time. The network shall then provide a response as quickly as possible with minimum delay. Response time supervision is implementation dependent.

4.3.4 LCS QoS Class

The LCS QoS Class defines the degree of adherence by the Location Service to the quality of service parameters (Accuracy and Response Time).

For Value Added Services and PLMN Operator Services, the following is applicable:

LCS QoS Class is a non-negotiable QoS parameter. Support of QoS Class by a Public Land Mobile Network (PLMN) is optional. The LCS Service may allow a LCS Client to specify the required QoS Class (in the context of immediate location request) either at provisioning or when the request is made. The LCS Service shall attempt to satisfy as closely as possible the other quality of service parameters regardless of the use of QoS Class.

For immediate location request response, LCS QoS Class options are:

a) “Assured”: The other QoS parameters shall be adhered to strictly. The LCS Service shall obtain a Current Location with regard to fulfilling the requirements set by the other QoS parameters. If the location request response does not satisfy the other QoS parameters, the response shall be discarded by the LCS Service.

b) “Best Effort”: The other QoS parameters do not have to be adhered to strictly. The LCS Service shall obtain a Current Location, using only one attempt with a single technology, with regard to fulfilling the requirements set by the other QoS parameters. Even if the location request response does not satisfy the other QoS parameters, the response may be forwarded to the LCS Client.

4.3.5 Dispatchable Location accuracy

Dispatchable Location accuracy can be expressed in terms of civic location granularity.

Dispatchable Location granularity refers to the specificity of the elements of civic location obtained. For example, a civic address with a street number, street name, city, state and country provides a less specific civic location than apartment number, floor, street number, street name, city, state and country. The expression of civic location granularity is in terms of the mandatory civic location elements such as:

• City or Town
• Street number and name
• Floor number within a building
• Apartment, Suite, or Room number within a building

An example of regional regulatory requirements for Dispatchable Location granularity applicable to Emergency Services can be found in [12] and [13].

For Emergency Services (where required by local regulatory requirements) the following requirements shall be met:

– When providing a Dispatchable Location, the LCS Server shall attempt to obtain the civic location of the calling UE in terms of civic information elements (i.e. country, street name, floor), and shall provide this to an Emergency Service Provider. The accuracy (granularity) shall be defined by local regulatory requirements. Annex A shows such requirements as exist in the United States.

4.4 Reliability

Reliability provides a measure of how often positioning requests that satisfy QoS requirements are successful. For some applications, such as cross-country vehicle tracking, this may not be especially critical. If a positioning attempt fails, due to lack of coverage or transient radio conditions, etc, another positioning attempt may be made. This attempt should be specified in Location Service Request. (see the section 5.3.1.1). However, for other services, perhaps such as child tracking, reliability may be more important.

The network shall provide statistical reporting of reliability (QoS parameters) data.

4.5 Priority

Location requests for different services may be processed with different levels of priority.

For Value Added Services, and PLMN Operator Services, the following is applicable:

The LCS Server may allow different location requests to be assigned different levels of priority. A location request with a higher priority may be accorded faster access to resources than one with a lower priority and may receive a faster, more reliable and/or more accurate location estimate.

For Emergency Services (where required by local regulatory requirements) the location request shall be processed with the highest priority level.

4.6 Timestamp

For Value Added Services, and PLMN Operator Services, and Emergency Services (where required by local regulatory requirements), the LCS Server shall timestamp all location estimates or Dispatchable Location provided to a LCS Client indicating the time at which the estimate was obtained.

4.7 Security

Specific local, national, and regional security regulations must be complied with.

Position information should be safeguarded against unapproved disclosure or usage. Position information should also be provided in a secure and reliable manner that ensures the information is neither lost nor corrupted. Audit records should be maintained of positioning requests and responses to facilitate resolution of security violations.

The LCS Client may be authorized by the LCS Server. Existing security mechanisms as well as security mechanisms of the LCS Server shall be used for authorizing the LCS Client and its request for location information.

The target UE user shall be authenticated before being allowed to access (to modify/query) her personal data or query/cancel an LCS request.

For Value Added Services, the following is applicable:

Only authorized LCS Clients shall be able to access the LCS Server. Before providing the location of a Target UE to any authorized LCS Client, the LCS Server shall verify both the identity and authorization privileges of the LCS Client .

Once the LCS Server has verified that a particular LCS Client is authorized to locate a particular Target UE, any location estimate or Dispatchable Location requested shall be provided to the LCS Client in a secure and reliable manner, such that the location information is neither lost, corrupted nor made available to any unauthorized third party.

For PLMN operator services, location information shall be provided in a secure and reliable manner. The ability to obtain location information shall depend on local regulatory laws and requirements in conjunction with requirements for UE privacy.

For Emergency Services (where required by local regulatory requirements) the following requirements shall be met:

Position information shall be provided to the Emergency Services Network as an authorized LCS client. Target UE authorization checks normally performed for value added services are not applicable (privacy is over-ridden). The position information shall be provided to the Emergency Services Network in a secure and reliable manner, such that the location information is neither lost, corrupted, nor made available to any unauthorized third party.

4.8 Privacy

Specific local, national, and regional privacy regulations must be complied with, and multiple layers of permissions may be required.

Location information must always be available to the network service provider.

Means shall be provided for the UE subscriber to control privacy for value added services.

The user shall be able to change the setting of the Privacy exception list at any time.

Unless required by local regulatory requirements, or overridden by the target UE User, the target UE may be positioned only if allowed in the UE subscription profile. In general, for valued added location services, the target UE being positioned should be afforded the maximum possible privacy, and should not be positioned unless the positioning attempt is explicitly authorized. In the absence of specific permission to position the target UE, the target UE should not be positioned.

It may also be possible for a target UE to authorize positioning attempts after the target UE is notified of a positioning request and the target UE grants permission for positioning. It shall also be possible to make the notification conditional on the current location of the target UE. In this case the notification shall be performed after the target UE is positioned but before reporting the location of target UE to LCS Client. This notification condition (notification with privacy verification) shall be specified in the Target UE Subscription Profile. (See the subsequent "target subscriber notification" section of this document for charging and billing aspects.) The operator shall be able to determine the location of the target UE (e.g. for lawful interception or emergency call).

The privacy of an inanimate asset for an embedded target UE may be completely defined by the UE subscriber.

Additionally, specific privacy exceptions may exist for compliance with mandated location-based services (such as for emergency services or lawful intercept) which are required by national or local regulatory requirements.

For Value Added Services, the following is applicable:

The Target UE Subscriber shall be able to restrict access to the Location Information (permanently or on a per attempt basis). The LCS Client access shall be restricted unless otherwise stated in the Target UE Subscription Profile. The home network shall have the capability of defining the default circumstances in which the Target UE’s Location Information is allowed to be provided – as required by various administrations and/or network requirements.

The privacy check shall be performed in the Home Environment of the target UE subscriber. This makes it possible for operators to ensure the privacy of their own subscribers i.e. the privacy settings that are used for privacy checks are always up to date and as specified by the Home Environment of the target UE subscriber. It shall be possible for privacy check to take into account Home Environment specific information such as time of day, subscriber location. It shall be possible to ensure that privacy checks are performed according to the latest information as available in the Home Environment.

It shall be possible for location services to support conditional positioning. Under these conditions, an application that is granted conditional positioning authorization must notify and obtain positioning authorization from the user of the target UE prior to performing the positioning process. Thus, the user of the target UE shall be able to accept or reject the positioning attempt.

It shall be possible for location services to support conditional reporting if the target UE is within specified geographical areas. Under these conditions, an application that is granted conditional positioning authorization must notify and obtain positioning authorization from the user of the target UE after the positioning process is preformed but before reporting the location of the target UE to the LCS Client

The default treatment, which is applicable in the absence of a response from the Target UE, shall be specified in the Target UE Subscription Profile. Thus, for some location services the default treatment may be to accept the positioning request, whereas for other location services the default treatment may be to reject the positioning attempt.

However, considering that in general, users shall be afforded the maximum possible privacy, and shall not be positioned unless the target subscriber authorizes the requesting location application to perform positioning, the default condition shall normally be to deny the positioning attempt.

For PLMN operator services, the target UE subscriber may be able to restrict access to location information used to enhance or support particular types of service. The LCS client access shall be restricted unless stated otherwise in the Target UE subscription profile. The target UE user shall not be notified of any authorized location attempt.

For Emergency Services (where required by local regulatory requirements) Target UEs making an emergency call may be positioned regardless of the privacy attribute value of the subscriber associated with the Target UE (or ME) making the call.

For Lawful Interception Services (where required by local regulatory requirements), target UEs may be positioned under all circumstances required by local regulatory requirements. The target UE user shall not be notified of any location attempt.

All location requests (LRs) shall be done with a privacy check except for the following:

– LRs relating to lawful interception

– LRs related to emergency calls

– LRs from the serving network related to anonymous tracking for statistical and O&M purposes

– LRs from the home network as requested by the home network operator for its own internal purposes. The home network operator should not use the UE location information, which was obtained from the visited network without privacy checks, for value added services or to forward such location information to any third party (except for the cases of lawful interception or emergency calls).

4.8.1 Service Type Privacy

The user may wish to differentiate between privacy requirements even with one LCS Client, depending on which service the user requests from this LCS client or which service the LCS client offers to the user.

The users shall be able to allow or deny their location information to be given to LCS clients providing an indicated type of service. The user could e.g. allow all dating type services to get location information but decline other types of services to get the user’s location. The location request message issued by the LCS client may include a service identity, and the LCS Server may interpret that the indicated service belongs to a certain Service Type. The subscriber shall be able to define and set privacy rules based on service type, so that services belonging to that service type shall be handled according to the corresponding service type privacy setting.

It shall be possible to verify that the service type indicated by the LCS client is correct. The service type privacy check may be done by the LCS server or by the user of the target mobile.

The LCS Server shall be aware of what service types a certain LCS Client supports. The LCS Server shall map the service identity given by the LCS client to a service type, as described below. The PLMN operator defines to what service type the given service identity belongs to.

4.8.1.1 Standardized Service Types

Annex C lists the attributes of specific location-based services as determined by the GSM Alliance Services Working Group. The standardized Service Types to be used in privacy checking are listed in table 4.2 and are based on the services listed in Annex C. It is noted that not all services listed in Annex C need belong to a standardized service type.

It should be noted that only the names and identities (number) of the Service Types are standardized.

It shall be possible for the network operator/service provider to define additional, non-standardised service types that need not be globally unique.

Table 4.2, Standardized Service Types

Location based services categories	Standardized Service Types
Public Safety Services	Emergency Services
	Emergency Alert Services
Location Sensitive Charging
Tracking Services	Person Tracking
	Fleet Management.
	Asset Management
Traffic Monitoring	Traffic Congestion Reporting
Enhanced Call Routing	Roadside Assistance
	Routing to Nearest Commercial Enterprise
Location Based Information Services	Traffic and public transportation information
	City Sightseeing
	Localized Advertising
	Mobile Yellow Pages
	Weather
	Asset and Service Finding
Entertainment and Community Services	Gaming
	Find Your Friend
	Dating
	Chatting
	Route Finding
	Where-am-I
Service Provider Specific Services

Note: It should not be possible for the target UE subscriber to block the emergency services Service Type, so maybe this Service Type is not needed, this is FFS.

4.9 Service Authorization

Requests for positioning information should be processed only if the requesting application is authorized. The identity and authorization privileges of the requesting application should be verified prior to processing positioning requests.

4.10 Service Activation and De-Activation

To maximize the adoption of location services, the service activation process must be simple. Three types of service package, may be distinguished, each of which may require a different service activation process:

1 On Demand: the user accesses services only when required.

2 Period Subscription: the subscriber requires periodic availability of the service

3 Mixed: some services provided on subscription and the remainder on-demand.

The process of activation + service delivery + deactivation may be provided in a single transaction. It may be possible for a subscriber to activate a location service on one occasion before deactivating an existing invocation.

Furthermore, a location service may be ‘enabled’ at the point of sale as part of the service package purchased by the UE subscriber. The use of Over-The-Air (OTA) provisioning may allow the location feature to be enabled for UE-based positioning methods.

4.11 Coverage

In general a UE user should be able to access a location service anywhere within the operator’s coverage area, or within the roaming area. Three levels of coverage may be considered:

1 Home Network – Complete

2 Home Network – Partial

3 Roaming Networks

Considering network topography and dynamically varying environmental factors, a network operator may not be able to guarantee homogeneous service quality across the entire home network geographic area, or roaming partners’ networks. Even within those areas where service is offered, the provided quality of service may vary due to dynamic environmental (i.e. radio) conditions. Additionally, the location method may have an accuracy that depends on the UE location, for example due to varying radio conditions, cell configuration and cell density in different areas, and geometric dilution of precision.

Furthermore, the roaming partner’s network may not accept a similar location method to that experienced by the user in the home network.

Finally, the service may not be available in a roaming partner’s network despite technical interoperability between the location method supported by the UE and the network.

Therefore, coverage may be considered not only to be a technical attribute, but may also be related to roaming contracts between network operators. In general, provided that a roaming agreement exists, any properly authorized location-based service may position a Target UE in either the Home PLMN (HPLMN) or a Visited PLMN (VPLMN). It may also be noteworthy that some location-based services (such as location-based information services) may be especially attractive to subscribers roaming outside their home networks.

4.12 Roaming Target UE

With respect to roaming, specific local, national, and regional privacy regulations must be complied with, and multiple layers of permissions may be required.

Many location-based services may be especially attractive to subscribers roaming outside their home PLMN. As such, support should be provided for the transparent and consistent provision of location-based services to the fullest extent possible. Consideration for roaming support should be provided with the following priorities:

1. Roaming between 3GPP networks.

2. Roaming between 3GPP systems and IMT 2000 family networks.

3. Roaming between 3GPP and ANSI-41 or other systems.

If the location capability in the VPLMN is compatible with that provided in the HPLMN, the same parameters must be provided to the location server in the VPLMN that would be provided to the server in the HPLMN to enable provision of the same services.

For Value Added Services, the following is applicable:

Provided that a roaming agreement exists, the LCS feature shall allow any properly authorized LCS client to request and receive the location of a particular Target UE when the Target UE is either located in its Home PLMN (HPLMN) or Visited PLMN (VPLMN). The LCS client shall be authorised by the HPLMN of the subscriber whose UE is the target of the location attempt. Any PLMN not supporting the LCS feature shall return a suitable error response to any other PLMN from which an LCS request is received. The requesting PLMN shall then infer that the LCS feature is not supported and provide a suitable error response in turn to the requesting LCS Client.

For PLMN Operator Services, location of any roaming target UE shall be supported in the VPLMN as allowed by both local regulatory requirements and considerations, where applicable, of UE privacy.

For Emergency Services (where required by local regulatory requirements) the Serving PLMN shall support the positioning of all Target UEs including roaming Target UEs currently serviced by that serving PLMN. There is no requirement for a HPLMN to position Target UEs that have roamed outside the HPLMN.

4.13 Support for all UEs

For value added services, and PLMN operator services, the LCS feature may be supported for all UEs.

For Emergency Services (where required by local regulatory requirements), positioning shall be supported for all UEs (i.e. including legacy UEs) where coverage is provided, and also UEs without a SIM/USIM. In such a case, the location of the caller may be determined using the identity associated with the Mobile Equipment (ME) involved in the call.

Both “active” and “idle” UEs shall be capable of being positioned.

4.14 Support for Unauthorized UEs

For value added services, support of unauthorized UEs may be provided by the PLMN.

For PLMN operator services, positioning of unauthorized UEs may be provided by the PLMN as required by local regulatory requirements.

For Emergency Services (where required by local regulatory requirements), the PLMN shall support positioning for unauthorized UEs (i.e. including stolen UEs and UEs without a SIM/USIM).

NOTE: A subscriber is in general identified as a UE containing in it the SIM/USIM associated with the subscriber. In some exceptional cases (e.g., an Emergency call), a UE without a valid subscription recognized in the PLMN can become a Target UE. In such a case, the subscriber may be identified by the identity associated with the Mobile Equipment (ME) involved in the call.

4.15 Periodic Location Reporting

Periodic location reporting is the act of the LCS Server initiating multiple position locations spread over a period of time.

The periodic reporting function is generally applicable for asset management services and exists as several variants, each applicable to different value-added services:

· Location reporting only within predetermined period	e.g. commercial asset tracking and, subject to provision of privacy, manpower planning.
· Periodic location reporting within specified period and reporting triggered by a specific event	e.g. high value asset security, stolen vehicle monitoring, home zone charging.
· Periodic location reporting triggered by a specific event	e.g. 24hr depot management, transit passenger information systems

Periodic location determination and reporting increases network traffic. However, scheduling the periods of location monitoring and reporting will reduce this. Finally, event-based logic provided by the network operator that monitors the asset (location and status) and only reports events that meet conditions agreed with the application may reduce network traffic further without reducing the QoS.

If this event-based or time-based decision process is the responsibility of the application and not the network operator then all of the above services can be regarded as periodic location reporting.

For value added services, and PLMN operator services, support of periodic location reporting may be provided by the PLMN.

When an LCS client activates Periodic Location Reporting, the LCS server shall be able to inform the target UE of this activation according to the Privacy Exception List.

Optionally, it may be possible for the target UE at any time to query the LCS server about any valid requests activated for that target UE, and/or cancel the request.

When a request is cancelled by the target UE, the LCS server shall inform the LCS client of this cancellation.

It should be possible for more than one LCS client to activate requests for the same target UE.

For Emergency Services (where required by local regulatory requirements), there is no requirement for the PLMN to support periodic location reporting.

4.16 UE-Based Location Calculation

UE-Based Location Calculation may be supported on either a per-request basis or semi-autonomously whereby a single request from a UE subscriber enables UE based location calculation over an extended period without further interaction with the PLMN.

For Commercial Services, the following may be applicable for semi-autonomous location:

The network may broadcast location assistance information to mobiles, which enables mobiles to calculate their own location. The network may encrypt the location assistance information. If the location assistance information is encrypted, a single common standardized encryption algorithm shall be used.

The location assistance information may be available to the UE at all times, continuously in idle mode and during a call, without additional point to point signalling. The network may request location information from the UE for operator or for service provider applications. For this purpose, a point to point signalling connection must be established.

4.17 UE_Assisted LCS Location Calculation

The UE-Assisted Location Calculation is accomplished by network resources based upon radio ranging measurements provided by the UE.

For Commercial Services, the following may be applicable for UE-Assisted location services:

The network may broadcast assistance information to mobiles, which enables mobiles to obtain the appropriate radio ranging measurements. The network may encrypt the assistance information. If the assistance information is encrypted, a single common standardized encryption algorithm shall be used.

The assistance information may be available to the UE at all times, continuously in idle mode and during a call, without additional point to point signalling. The network may request radio ranging measurement data from the UE for operator or for service provider applications. For this purpose, a point to point signalling connection must be established. Optionally, this point to point connection can be used to deliver the resulting location to the UE.

4.18 Mobile Originating Location

Mobile Originating Location is the capability of the mobile station to obtain its own geographical location or have its own geographic location transferred to another LCS client.

For Value Added Services, the following may be applicable:

There are three classes of mobile originating location:

Basic Self Location – The mobile station needs to interact with the network for each separate location request

Semi-autonomous Self Location – One interaction with the network assists the mobile station to obtain multiple location positionings over a predetermined period of time.

NOTE: Autonomous Self Location – The mobile needs no interaction with the network and is therefore considered to be outside the scope of this technical specification.

Transfer to Third Party – The location of the mobile station is transferred by request of the mobile station to another specified LCS client.

4.19 Network support for LCS

The provision of location services shall be possible without significantly adversely impacting the radio transmission or the signalling capabilities of the network.