Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.271  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   5…   6…   6.2…   7…   8…   9…   9.1.1A…   9.1.2…   9.1.5…   9.1.6…   9.1.8…   9.1.9…   9.1.12…   9.1.13…   9.1.15…   9.1.19…   9.2…   9.2.2…   9.2.3…   9.3…   9.4…   9.5…   9.6…   10…   11…   A…   B…   E   F…

 

6.2  Allocation of LCS functions to network elementsp. 38

Table 6.1 shows a summary of the Functional Groups and Functional Blocks for Location services. Table 6.2 and Figure 6.2 show the generic configuration for LCS and the distribution of LCS functional blocks to network elements. Different positioning methods, including network-based, mobile-based, mobile-assisted and network-assisted positioning methods may be used. With this configuration both the network and the mobiles are able to measure the timing of signals and compute the mobile's location estimate. Depending on the applied positioning method it is possible to utilise the corresponding configuration containing all needed entities. For instance, if network-based positioning is applied, the entities that are involved in measuring the mobile's signal and calculating its location estimate are allocated to the network elements of the access stratum. On the other hand, in case mobile-based or network-assisted methods are used these entities should be allocated to the UE.
LCS is logically implemented on the network structure through the addition of one network node, the Mobile Location Centre (MLC). It is necessary to name a number of new interfaces. The LCS generic architecture can be combined to produce LCS architecture variants.
Funct. Group Functional component Full name of Functional Block Abbrev.
Loc.Location Client(External) Location Client FunctionLCF
ClientComponentInternal Location Client FunctionLCF-internal
LCS Server in PLMNClient handling componentLocation Client Control FunctionLCCF
Location Client Authorization FunctionLCAF
Location Client Co-ordinate Transformation FunctionLCCTF
Location Client Zone Transformation FunctionLCZTF
System handling componentLocation System Control FunctionLSCF
Location System Billing FunctionLSBF
Location System Operations FunctionLSOF
Location System Broadcast FunctionLSBcF
Location System Co-ordinate Transformation FunctionLSCTF
Location IMS - Interworking FunctionLIMS-IWF
Subscriber Handling componentLocation Subscriber Authorization FunctionLSAF
Location Subscriber Translation FunctionLSTF
Location Subscriber Privacy functionLSPF
Positioning componentPositioning Radio Control FunctionPRCF
Positioning Calculation FunctionPCF
Positioning Signal Measurement FunctionPSMF
Positioning Radio Resource ManagementPRRM
Table 6.2 and Table 6.2a and Figure 6.2 illustrate the allocation of functional entities in the reference configuration of LCS. It is assumed that the CS and PS have either their own independent mobility management or use the joint mobility management through the optional Gs interface.
It is also seen that LCS may take benefit of the Iur interface between RNCs, when uplink radio information and measurement results are collected.
The functional model presented in the Figure includes functional entities for both CS and PS related LCS. In addition, it consists of all the entities needed for different positioning methods, i.e. network based, mobile based, mobile assisted, and network assisted positioning, exploiting either uplink or downlink measurements. Similarly, the velocity of a UE may be calculated in either the network or the UE. It is noted that the UE may use e.g. the GPS positioning mechanism, but still demand e.g. auxiliary measurements from the serving network. RAN specific functional entities are specified in TS 36.305 for E-UTRAN, TS 25.305 for UTRAN and in TS 43.059 for GERAN.
UE RAN GMLC SGSN MSC/MSC Server HLR/HSS PPR PMD Client
Location client functions
LCFXXXX
LCF InternalX
Client handling functions
LCCTFX
LCCFX
LCAFX
LCZTFX
System handling functions
LSCFXXX
LSBFXXX
LSOFXXXXX
LSBcFX
LSCTFX
LIMS-IWFX (Note 1)
Subscriber handling functions
LSAFXXXX
LSPFXXXXX
LSTFX
Positioning functions
PRCFX
PCFXX
PSMFXX
PRRMX
UE RAN GMLC MME E-SMLC HLR/HSS PPR PMD Client
Location client functions
LCFXXX
LCF Internal
Client handling functions
LCCTFX
LCCFX
LCAFX
LCZTFX
System handling functions
LSCFX
LSBFXX
LSOFXXXXX
LSBcFXX
LSCTFX
LIMS-IWFX (Note 1)
Subscriber handling functions
LSAFXXX
LSPFXXXX
LSTFX
Positioning functions
PRCFX
PCFXX
PSMFXX
PRRMX
Copy of original 3GPP image for 3GPP TS 23.271, Fig. 6.2: Generic LCS Logical Architecture
Figure 6.2: Generic LCS Logical Architecture
(⇒ copy of original 3GPP image)
Up

6.3  Functional description of LCS per network elementp. 41

6.3.1  Access Networkp. 41

The Access Network is involved in the handling of various positioning procedures.
The LCS specific functionalities of the radio access network elements are specified in TS 36.305 for E-UTRAN, TS 25.305 for UTRAN and TS 43.059 for GERAN.

6.3.2  LCS Clients, LCS applications and Requestorsp. 42

There are two classes of LCS Application - Internal applications and External applications. Internal applications represent entities internal to the GSM/UMTS/EPC that make use of location information for the (improved) operation of the network. Internal LCS client can be identified by LCS client internal ID. LCS client Internal ID distinguishes the following classes: (LCS client broadcasting location related information, O&M LCS client in the HPLMN, O&M LCS client in the VPLMN, LCS client recording anonymous location information, LCS Client supporting a bearer service, teleservice or supplementary service to the target UE). External applications represent entities (such as Commercial or Emergency services) that make use of location information for operations external to the mobile communications network. External LCS client can be identified by LCS client external ID. The LCS Applications interface to the LCS entities through their Location Client functions (LCF). Location requests from the external LCS clients may be originated by external entities (i.e. Requestor). LCS client should authenticate the Requestor Identity but this is outside the scope of this specification.
LCS client may indicate the type of the Requestor identity in the LCS service request. The type of the Requestor identity can be one of the following:
  • Logical name
  • MSISDN (TS 23.003)
  • E-mail address (RFC 2396 [33])
  • URL (RFC 2396 [33])
  • SIP URL (RFC 3261 [34])
  • IMS public identity (TS 23.228)
The LCS Client, LCS applications and Requestors are outside the scope of the present document.
Up

6.3.3  Gateway Mobile Location Centre, GMLCp. 42

The Gateway Mobile Location Centre (GMLC) contains functionality required to support LCS. In one PLMN, there may be more than one GMLC.
A GMLC is the first node an external LCS client accesses in a PLMN (i.e. the Le reference point is supported by the GMLC). The GMLC may request routing information from the HLR via the Lh interface or HSS via the SLh/Lh interface. After performing registration authorization, it sends positioning requests to either VMSC, SGSN, MSC Server or MME and receives final location estimates from the corresponding entity via the Lg, Lgd or SLg interface.
Information needed for authorisation, location service requests and location information may be communicated between GMLCs, located in the same or different PLMNs, via the Lr interface. The target UE's privacy profile settings shall always be checked in the UE's home PLMN prior to delivering a location estimate. In order to allow location request from a GMLC outside the HPLMN while having privacy check in the HPLMN, the Lr interface is needed.
The "Requesting GMLC" is the GMLC, which receives the request from LCS client.
The "Visited GMLC" is the GMLC, which is associated with the serving node of the target mobile.
The "Home GMLC" is the GMLC residing in the target mobile's home PLMN, which is responsible for the control of privacy checking of the target mobile.
The Requesting GMLC can be the Visited GMLC, and either one or both of which can be the Home GMLC at the same time.
Up

6.3.3A  Location Retrieval Function, LRF |R9|p. 43

Location Retrieval Function (LRF) may be collocated with the GMLC or separate and is responsible for retrieving or validating location information, providing routing and/or correlation info of an UE that has initiated an IMS emergency session. The information is provided to the E-CSCF via the Ml interface. For detail, refer to TS 23.167.

6.3.4  LCS support in the UEp. 43

The UE may be involved in the various positioning procedures. Specific UE involvement is specified in each of the positioning procedures specified in TS 36.305 in E-UTRAN, TS 25.305 for UTRAN and TS 43.059 for GERAN.
The UE interacts with the measurement co-ordination functions to transmit the needed signals for uplink based LCS measurements and to make measurements of downlink signals. The measurements to be made will be determined by the chosen location method.
The UE may also contain LCS applications, or access a LCS application through communication with a network accessed by the UE or an application residing in the UE. This application may include the needed measurement and calculation functions to determine the UE's location with or without assistance of the GSM/UMTS/EPS LCS entities.
In GSM the positioning methods supported by the UE are signalled by the UE to the core network and radio access network using Classmark3 in CS mode, as specified in TS 24.008.
In UMTS the UE capability to support different positioning methods is only communicated within UTRAN, as specified in TS 25.331.
In EPS the positioning methods supported by the UE may be signalled by the UE to the core network using LPP by the initial location service invocation as specified in TS 36.305. Also, in EPS the UE capabilities to support LCS Notification for an MT-LR and LPP for positioning are exchanged at the initial EPS attach procedure. The indication of the UE LPP capability will be forwarded by MME to E-SMLC as specified in TS 29.171.
The UE informs the core network about its capability to support privacy invocation request and response using Classmark2 in CS mode and MS Network Capability in PS mode, as specified in TS 24.008.
The UE may also, for example, contain an independent location function (e.g. Global Satellite Positioning Service GPS) and thus be able to report its location, independent of the RAN transmissions. The UE with an independent location function may also make use of information broadcast by the RAN that assists the function.
The UE may support multiple simultaneous location sessions.
Up

6.3.5  MSC/VLRp. 43

The MSC/VLR contains functionality responsible for UE subscription authorization and managing call-related and non call related positioning requests of LCS. The MSC is accessible to the GMLC via the Lg interface. The LCS functions of MSC are related to charging and billing, LCS co-ordination, location request, authorization and operation of the LCS services. If connected to SGSN through the Gs interface, it checks whether the UE is GPRS attached to decide whether to page the UE on the A/Iu or Gs interface.
The MSC/VLR may inform HLR/HSS about the UE's LCS Capabilities and may include the IP address of the V-GMLC associated with the MSC/VLR in the MAP UPDATE LOCATION message, during Registration and Inter MSC Update Location procedures.
Up

6.3.6  MSC Serverp. 43

The MSC Server handles the same functionality as the MSC/VLR including charging and billing, LCS co-ordination, location request, authorization and operation of the LCS services. The MSC Server is accessible to the GMLC via the Lg interface.

6.3.7  SGSNp. 44

The SGSN contains functionality responsible for UE subscription authorization and managing positioning requests of LCS. The SGSN is accessible to the GMLC via the Lg (MAP-based) or Lgd (Diameter-based) interface. The LCS functions of SGSN are related to charging and billing, LCS co-ordination, location request, authorization and operation of the LCS services.
The SGSN may inform HLR/HSS about the UE's LCS Capabilities for GPRS and may include the IP address of the V-GMLC associated with the SGSN in the MAP UPDATE GPRS LOCATION message, during Attach and Inter SGSN Routing Area Update procedures.
The SGSN forwards the circuit-switched paging request received from the Gs interface to the BSS/RNC.
Up

6.3.8  Home Location Register, HLRp. 44

The HLR contains LCS subscription data and routing information. The HLR is accessible from the GMLC via the Lh interface. For a roaming UE, HLR may be in a different PLMN.

6.3.9  HSS |R5|p. 44

The HSS contains LCS subscription data and routing information. The HSS is accessible from the GMLC via the Lh/SLh interface. For roaming UEs, HSS may be in a different PLMN.

6.3.10  gsmSCFp. 44

The Lc interface supports CAMEL access to LCS and is applicable in CAMEL Phase 3 and later. The procedures and signalling associated with it are defined in TS 23.078 and TS 29.002, respectively.

6.3.11  Privacy Profile Register, PPR |R6|p. 44

Privacy check may be done in the privacy profile register. The HLR or HSS contains the address to the PPR. The PPR is accessible from the H-GMLC via the Lpp interface. PPR may be a standalone network entity or the PPR functionality may be integrated in H-GMLC.

6.3.12  Pseudonym Mediation Device, PMD |R6|p. 44

The pseudonym mediation device (PMD) functionality maps or decrypts the pseudonym into the corresponding verinym (i.e. IMSI or MSISDN). PMD functionality may be a standalone network entity or the PMD functionality may be integrated in PPR, GMLC or other network entity. If PMD functionality is not part of GMLC it may be accessed using the Lid interface. The detail of PMD functionality is out of scope, and only the interface between GMLC and PMD functionality is specified in this specification.

6.3.13  Mobility Management Entity, MME |R9|p. 44

The Mobility Management Entity (MME) contains functionality responsible for UE subscription authorization and managing positioning requests of LCS. The MME is accessible to the GMLC via the SLg interface. The LCS functions of MME are related to charging and billing, LCS co-ordination, E-SMLC selection, location request, authorization and operation of the LCS services.
The MME may inform HLR/HSS about the UE's LCS Capabilities for EPS and may include the IP address of the V-GMLC associated with the MME in the Update Location Request message, during Attach and Inter MME Tracking Area Update procedures.
The MME selects an available E-SMLC to serve the location request for a UE. The selection is based on network topology and should provide load balancing between E-SMLCs. Other criteria for E-SMLC selection may include LCS Client type and requested QoS. When the MME needs to know the country of a UE as described in clause 4.13.4 of TS 23.401, the MME sends an indication included in the location request to E-SMLC.
When assistance data is broadcast by the EPS in ciphered form, the MME receives ciphering keys from the E-SMLC and forwards to suitably subscribed UEs using mobility management procedures.
Up

6.3.14  Evolved Serving Mobile Location Centre, E-SMLC |R9|p. 45

The E-SMLC manages the overall co-ordination and scheduling of resources required for the location of a UE that is attached to E-UTRAN. It also calculates the final location and velocity estimate and estimates the achieved accuracy. The E-SMLC interacts with the UE in order to exchange location information applicable to UE assisted and UE based position methods and interacts with the E-UTRAN in order to exchange location information applicable to network assisted and network based position methods. The E-SMLC may provide broadcast assistance data via E-UTRAN in ciphered or unciphered form and forward any ciphering keys to subscribed UEs via the MME. The E-SMLC maps location estimate to a country or an international area based on request from MME.
Up

6.4  Addressing the target UE for LCS purposesp. 45

6.4.1  Verinyms for the target UE |R5|p. 45

It shall be possible to address and indicate the target UE using MSISDN and SIP-URI. It may be possible in certain cases to address the target UE using IP address when a static or dynamic IP address (IPv4 or IPv6) has been allocated for the UE.
In the mobile terminated location request procedures in the PS domain (as well as in the CS domain), the target UE is identified using either MSISDN or IMSI.
Up

6.4.2  Pseudonyms for the target UE |R5|p. 45

National regulations require support for the anonymity of the target mobile user in some countries. It shall therefore be possible to address and indicate the target UE using a pseudonym. The pseudonym may be the IMSI or MSISDN of the target UE encrypted e.g. using the public key of the home operator. The address of the network element that issued the pseudonym, i.e. the PMD address, shall either be attached to the pseudonym, if required or this address can be deduced from the pseudonym. The H-GMLC address may also either be attached to the pseudonym or be deduced from the pseudonym. It is outside the scope of this specification how the requestor and the LCS client will receive and handle the pseudonym, but some examples are described in the informative Annex E.
Up

6.4.3  Non-dialable callback numbers |R5|p. 45

In case of a SIM-less emergency call, or in case of a non-registered (U)SIM emergency call, a non-dialable callback number shall be used to identify the target UE. The format and structure of the non-dialable callback number is according to national or regional regulations. The non-dialable callback number in North America shall, according to J-STD-036 [32], be the digits 911 + the last 7 digits of IMEI expressed in decimal numbers.
Up

6.5  Quality of Service Information |R6|p. 45

LCS Quality of Service information is characterised by 3 key attributes:
  • LCS QoS Class
  • Accuracy
  • Response Time
The use of quality of service to characterise location requests is optional and if not requested the default shall be either network operator determined or client negotiated.

6.5.1  LCS QoS Classp. 46

The LCS QoS Class defines the degree of adherence by the Location Service to another quality of service parameter (Accuracy), if requested. The LCS Server shall attempt to satisfy the other quality of service parameter regardless of the use of QoS Class.

6.5.1.1  Best Effort Classp. 46

This class defines the least stringent requirement on the QoS achieved for a location request. If a location estimate obtained does not fulfil the other QoS requirements, it should still be returned but with an appropriate indication that the requested QoS was not met. If no location estimate is obtained, an appropriate error cause is sent.

6.5.1.2  Assured Classp. 46

This class defines the most stringent requirement on the accuracy achieved for a location request. If a location estimate obtained does not fulfil the other QoS requirements, then it shall be discarded and an appropriate error cause sent.

Up   Top   ToC