Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 22.071  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   A   B…   C…

 

6  Service ProvisionWord‑p. 26

6.1  Identification of a Target UEWord‑p. 26

For value added services, the following is applicable:
The LCS client shall identify a target UE using the MSISDN or SIP URL.
The LCS Client shall be able to identify the target UE using IP addressing.
For PLMN operator services, the LCS client may identify a target UE using any of the following:
MSISDN
SIP URL
IMSI
An identifier internal to the PLMN
For emergency services (where required by local regulatory requirements), the LCS client may identify a target UE using any one of the following:
MSISDN
SIP URL
IMSI
NA-ESRK + (optionally) IMEI, applicable for regions using the ANSI standards
IMEI, applicable for regions using the ETSI standards
IMEI is used for unauthorized UEs or UEs without SIM/USIM. In regions using ETSI standards it shall be indicated that the use of this identification is triggered by an emergency call.
It shall be possible for the target mobile's user to hide her true identity from the requestor and the LCS client and replace it with an alias. The alias shall be a unique identification that has a one-to-one relationship to the true identity of the subscriber and may be permanent or temporary. The target mobile user shall be able to know her own alias so that she can pass the alias to the LCS client, e.g. when invoking a location-based service.
Up

6.2  Location Information Provided to the LCS ClientWord‑p. 27

For value added services, the following is applicable:
The LCS Server shall provide, on request, the current or most recent Location Information (if available) of the Target UE or, if positioning fails, an error indication plus optional reason for the failure.
For PLMN operator services (where allowed by local regulatory requirements and restrictions on UE privacy), Location Information for a particular target UE may be provided to a PLMN operator LCS client either on request or on the occurrence of an event in the LCS server that has been defined to equate to such a request.
For emergency services (where required by local regulatory requirements), the geographic location or Dispatchable Location may be provided to an emergency services LCS Client either without any request from the client at certain points in an emergency services call (e.g. following receipt of the emergency call request, when the call is answered, when the call is released) or following an explicit request from the client. The former type of provision is referred to as a "push" while the latter is known as a "pull". In the case of a "pull", the emergency service LCS Client shall identify the Target UE as defined in clause 6.1. Table 3 shows the information that may be provided to the client for either a "push" or a "pull".
Type of Access Information Items
Push Current Dispatchable Location (if available)
Current Geographic Location (if available)
MSISDN
SIP URL
IMSI
IMEI
NA-ESRK
NA-ESRD
State of emergency call - unanswered, answered, released (note 1)
Pull Dispatchable Location (note 2), either:
Current civic location or
Initial civic location at start of emergency call Geographic location (note 2), either:
Current location or
initial location at start of emergency call
Both Dispatchable Location and geographic location (note 2), either:
Current location or
initial location at start of emergency call
Up

6.3  LCS Client SubscriptionWord‑p. 28

It shall be possible for an LCS Client to subscribe to the LCS feature for third-party location with or without subscription to other services. An LCS Client may subscribe to one or more service providers' LCS feature in one or more PLMNs. The LCS Client Subscription Profile of a client may contain the range of QoS and subscriptions that the LCS Client is allowed to request.
For certain authorized LCS Clients internal to the PLMN, a subscription profile may be unnecessary. For these LCS Clients subscription to LCS feature is given implicitly as a result of subscription to an authorized PLMN service (e.g. supplementary services). These LCS Clients are empowered to access the LCS Server and request location information for a Target UE.
For emergency services, the subscription requirements to the LCS feature may not be needed.
Up

6.4  Target UE SubscriptionWord‑p. 28

6.4.1  Privacy Subscription OptionsWord‑p. 28

It shall be possible for a Target UE Subscriber to subscribe to various types of privacy classes. The default treatment in the absence of the information to the contrary in the Target UE Subscription Profile shall be to assume that access is restricted to all LCS Clients (unless using privacy overriding, or otherwise overridden by local regulatory requirements).
Privacy Attributes consist of:
Codeword:
an additional level of security that may be set by a Target UE user to determine which Requestors are allowed to request location information;
Privacy Exception List:
determines which LCS Clients, services and classes of LCS Clients may position a Target UE;
Service Type Privacy:
determines whether the service type allows the LCS Clients to get the position of a Target UE;
Privacy Override Indicator:
determines applicability of the Privacy Exception List.
Up

6.4.2  CodewordWord‑p. 29

It shall be possible for a Requestor and an LCS client to request location information by indicating a Codeword associated with the Target UE user. The codeword shall be either checked by the Target UE/user or by the LCS server in the home network. In the former case, the codeword supplied by the requestor and forwarded by the LCS client with the request shall be forwarded to the Target UE/user for verification and acceptance. In the latter case, the codeword shall be registered with the LCS server by the Target UE user (or subscriber) in advance. Optionally, the UE and/or network may have the capability to generate and/or distribute codewords. The generation of codewords and the distribution of those codewords are out of scope of this specification. A comparison of the codeword sent by the Requestor and the registered codeword shall be performed. A location request shall only be accepted if this comparison is successful. In the case where the Target UE/user does not check the codeword, the codeword need not be sent to the Target UE/user. In the case where the codeword is checked by the Target UE/user, the Target UE subscriber need not register the codeword in advance.
The other privacy settings should also be checked even when the codeword has been checked.
The Target UE Subscriber may register multiple codewords for multiple requestors. Once the codeword has been set and properly distributed, the Target UE user would be protected against location requests from third parties, which do not know the appropriate codeword.
It should be possible for a Target UE subscriber to enable and disable codeword checking for each of the LCS Clients.
The codeword is applicable to the value-added services only.
Up

6.4.2.1  Enhanced codeword |R6|Word‑p. 29

It shall be possible for the target UE/ user to secure the codeword from being misused. Only the intended requestor or LCS client shall be able to use the secured codeword.
It shall be possible for the target UE/user to ensure that the secured codeword can be used only within a specific time period, as determined by the target UE/user. It shall be possible for the target UE/user to ensure that a secured codeword can be used only a specific number of times, as determined by the target UE/user.
The user of the target UE shall not need to be involved in checking the validity of the secured codeword during the location service request. The secured codeword shall be checked by the LCS server.
Up

6.4.3  Privacy Exception ListWord‑p. 29

To support privacy, the LCS Server shall enable each Target UE Subscriber to subscribe to a "privacy exception list" containing the LCS Client identifiers, the service identifiers, classes of LCS Clients, the target subscriber notification setting (with/without notification) and the default treatment, which is applicable in the absence of a response from the Target UE for each LCS Client and service identifiers.
The privacy exception list shall support a minimum of 20 clients. For each client the privacy exception list shall support a minimum of 10 services. The maximum number of clients and services shall be determined by implementation constraints.
If the target subscriber notification is set as "notification with verification", each positioning request from the LCS Client or the service shall be notified to the target UE before positioning. If the target subscriber notification is set as "notification with verification based on current location", positioning requests from the LCS Client or the service shall be notified to the target UE after positioning is performed if the current location of the target UE is within the areas specified to require notification. The treatment for location request from the LCS Client or service, which is not registered in the privacy exception list, shall also be specified in the privacy exception list. An empty privacy exception list shall signify an intent to withhold location from all LCS Clients.
The classes that can be included are as follows.
  • Universal Class: location services may be provided to all LCS Clients;
  • Call/session-related Class: location services may be provided to any value added LCS clients or a particular value added LCS client or a particular service or particular group of value added LCS Clients - where each LCS Client, service or group of LCS Clients is identified by a unique international identification, e.g. E.164 - that currently has a temporary association with the Target UE in the form of an established voice, data call or PS session originated by the Target UE. For each identified LCS Client, service or group of LCS Clients, one of the following geographical restrictions shall apply:
    1. Location request allowed from an LCS Client or service served by identified PLMN only;
    2. Location request allowed from an LCS Client or service served in the home country only;
    3. Location request allowed from any LCS Client or service;
  • Call/session-unrelated Class: location services may be provided to a particular value added LCS Client or a particular service or particular group of value added LCS Clients - where each LCS Client, service or group of LCS Clients is identified by a unique international identification, e.g. E.164. For each identified LCS Client, service or group of LCS Clients, one of the following geographical restrictions shall apply:
    1. Location request allowed from an LCS Client or service served by identified PLMN only;
    2. Location request allowed from an LCS Client or service served in the home country only;
    3. Location request allowed from any LCS Client or service;
  • PLMN Operator Class: location services may be provided by particular types of LCS clients supported within the HPLMN or VPLMN. The following types of clients are distinguished (see note):
    1. Clients broadcasting location related information to the UEs in a particular geographic area - e.g. on weather, traffic, hotels, restaurants;
    2. O&M client (e.g. an Operations System) in the HPLMN
    3. O&M client (e.g. an Operations System) in the VPLMN
    4. Clients recording anonymous location information (i.e. without any UE identifiers) - e.g. for traffic engineering and statistical purposes
    5. Clients enhancing or supporting any supplementary service, IN service, bearer service or teleservice subscribed to by the target UE subscriber.
Up

6.4.4  Privacy Override IndicatorWord‑p. 30

The privacy override indicator is applicable to lawful intercept and emergency services as allowed by local regulatory requirements. It is not applicable to value added and PLMN operator services. The Privacy Override Indicator shall be used to determine whether Subscriber Privacy of the Target UE subscriber should be overridden or not. This indicator will be set for certain special LCS Clients when it is justified. Each LCS Client shall be associated with a particular value of a position privacy override indicator during the LCS Client provisioning. The privacy override indicator is normally only valid when the LCS Server for the LCS client is located in the same country of the Target UE. If agreed by bi-lateral agreements between operators, the privacy override indicator shall also be valid when the LCS client is not located in the same country as the Target UE.
Up

6.4.5  Subscription to Mobile Originating Location |R5|Word‑p. 30

The UE subscriber may subscribe to the following types of Mobile Originating Location (as defined in clause 4):
  1. Basic Self Location
  2. Semi-autonomous Self Location
  3. Transfer to Third Party

6.4.6Void

6.4A  Requestor |R6|Word‑p. 31

The Location Request issued by the LCS client to GMLC shall optionally include also the identity of the originator of the location request, i.e. the Requestor, not only the identity of the LCS client.
The requestor shall be authenticated by the LCS client and/or the network.
The identity of the Requestor shall be included in the privacy interrogation request. It may be either checked by an entity in the network, the Target UE or the user.
It shall be possible for the requestor to use an alias, so that the true identity of the requestor is unknown to the LCS client. The alias shall be a unique identification that has a one-to-one relationship to the true identity of the requestor and may be permanent or temporary. The LCS client shall indicate the requestor alias instead of the real requestor identity in the location request. The target mobile user in this case authorizes the requestor based on the requestor's true identity, after it has been decrypted in the requestor's operator's network.
Up

6.5  SecurityWord‑p. 31

The LCS Server may authorize the LCS Client. There may be security mechanisms to authorize the LCS Client's request for locating a Target UE based on:
LCS Client access barring list(s),
PLMN/SP access barring list,
Point of origin of a location request.

6.6  ChargingWord‑p. 31

The LCS Server shall enable a PLMN to charge LCS Clients for the LCS features that the PLMN provides. . The information that the operator uses to generate a bill to an LCS Client is operator or service provider specific. The charging information may be collected both for the LCS Client and for inter-network revenue sharing.
To support charging and billing for location services, additional information will need to be provided in call detail records.
Charging for value added location services may be provided on a transaction basis, periodically, or a mixture of both.
To support transaction-based charging where applicable, service associated call detail records may need to include (as a minimum) the following additional information (depending on the specific service):
  • Type and Identity of the LCS Client;
  • Identity of the target UE;
  • Results (e.g. success/failure, method used, position, response time, accuracy)
  • Time Stamp;
  • Type of coordinate system used.
Up

6.7  LCS Open Service Architecture and Application Programming Interface |R4|Word‑p. 31

7  Provisioning and AdministrationWord‑p. 32

7.1  Procedures for an LCS ClientWord‑p. 32

These procedures are concerned with the LCS client's provisioning and administration to the LCS feature.

7.1.1  ProvisioningWord‑p. 32

Provisioning is an action to make the LCS feature available to a subscriber.
Provisioning may be:
  • General: where the service may be made available to all subscribers without prior arrangements being made with the service provider (i.e. emergency calls).
  • Pre arranged: where the service is made available to an individual LCS Client only after the necessary arrangements have been made with the service provider.

7.1.2  WithdrawalWord‑p. 32

Withdrawal is an action taken by the service provider to remove an available LCS feature from a LCS Client's subscription profile.
Withdrawal may be:
  • General: where the LCS feature is removed from all LCS Clients.
  • Specific: where the LCS feature is removed on an individual basis per LCS Client.

7.1.3  InvocationWord‑p. 32

Invocation is an action to invoke the LCS feature, taken by the LCS Client (e.g. issuing a location request) or automatically by the LCS server as a result of a particular condition (e.g. periodic location request, mobile originating emergency call, etc.).

7.2  Procedures for a Target UEWord‑p. 32

These procedures are concerned with a Target UE's privacy exception list. For emergency services, provisioning and withdrawal for Target UEs may not apply.

7.2.1  ProvisioningWord‑p. 32

Provisioning is an an action to make the privacy exception list with its privacy classes available to a Target UE. The provision may be:
  • General: where the list is made available to all Target UE's without prior arrangements being made with the service provider. The list shall contain the default privacy class.
  • Pre arranged: where any extra privacy permission class (--granting permission to locate an UE Client) shall be capable of being independently provisioned for a target UE as agreed with the service provider for a certain contractual period.
Up

7.2.2  WithdrawalWord‑p. 32

Withdrawal is an action taken by the service provider to remove an available privacy class from a target UE's PEL. Withdrawal may be:
  • General: where a privacy class is removed from all target UEs provided with this privacy class.
  • Specific: where each of the privacy classes in the privacy exception list shall be independently withdrawn at the subscriber's request or for administrative reasons.

7.2.3  User Control |R4|Word‑p. 33

The user shall be able to change the following settings in the privacy exception list:
  • the LCS Client and/or group of LCS Clients list
  • the codeword
  • the requestor
  • the service types
  • the target subscriber notification setting (with/without notification)
  • the default treatment, which is applicable in the absence of a response from the Target UE for each LCS Client identifiers.

7.3  Barring Capability of the Location Service |R6|Word‑p. 33

It shall be possible for operators to bar the Location Service of a specific user at any time. i.e. any location requests towards the user's Target UE and her own location requests towards her own Target UE are barred.
If the LCS request fails due to barring, then an error cause is returned to the LCS Requestor.
For Emergency Services and other services where required by local regulatory requirements, and for PLMN operator Services, the location request shall be processed with the highest priority level regardless of the barring status of LCS.
Up

8  Interactions with Bearer and Teleservices and Other ServicesWord‑p. 33

LCS shall support location of any Target UE that is idle or has established any CS teleservice, bearer service or PS session.
Location of a GPRS terminal or a UE using SMS may be supported.
Provision of location services to assist supplementary services and CAMEL is outside the scope of this specification. The operation of location services shall be independent of other services - including Number Portability, private numbering, CAMEL, supplementary services, teleservices, and bearer services.

9  Cross Phase Compatibility between releasesWord‑p. 33

This section details the cross-phase compatibility requirements relating to the service requirements in this document.

9.1  Compatibility With Existing StandardsWord‑p. 33

Where the service and operational requirements in this document relate to a core network functionality, compatibility is required.
UTRAN, E-UTRAN, and NG-RAN LCS shall be developed to maximise synergies with earlier LCS phases.

9.2  Compatibility With Future ReleasesWord‑p. 34

It is envisaged that 3GPP standards will evolve in future releases, for example with the addition of new service requirements. The standards which define the technical implementation of LCS should be developed in such a way that it is practical to add the requirements in this section in a backward compatible manner.
Following chapters include requirements that are foreseen for future release.

9.2.1Void

9.2.2  Location determination in call or PDP context activation and releaseWord‑p. 34

A possible future enhancement in LCS is that location information of a specific target UE may be obtained at the activation of a Call or PDP Context. A corresponding mechanism to obtain the location information of a specific target UE at the release of a Call or PDP Context may also be feasible.

9.2.3Void

9.2.4  Defined geographical areasWord‑p. 34

It shall be possible to specify a geographical area as ellipse to a resolution that will be limited by the accuracy capability of the part of the serving network where the user is registered.
It may be possible to identify and report when the user's terminal enters or leaves a specified geographic area.
In order to enable ME to determine itself if it enters or leaves a defined geographical area information about the defined geographical area shall be made available to client. The method is FFS, one alternative is that cells covering parts of the geographical area broadcasts information about the geographical area.
Up

9.2.5  Continuous check of locationWord‑p. 34

The client may continuously check its current location with or without requesting signalling support from the network using the Self Location feature. In this way the client may become aware of entering or leaving a predefined geographical area, as defined above, and/ or it can supply the user or an application with real-time tracking information.

9.2.6  Identification of a Target UEWord‑p. 34

In future releases usage of IP addresses for UE identification shall be supported by the standard.

9.2.7Void

9.2.8  VHEWord‑p. 34

LCS shall support VHE TS 22.121.

Up   Top   ToC