17 TBS positioning methods
25.3053GPPRelease 17Stage 2 functional specification of User Equipment (UE) positioning in UTRANTS
17.1 General
Terrestrial Beacon Systems (TBS) is the standard generic term for a network of ground-based transmitters broadcasting signals for geo-spatial positioning with wide-area or regional coverage. The following TBSs are supported in this version of the specification:
– Metropolitan Beacon Systems (MBS).
Each TBS can be used individually or in combination with others. When used in combination, the effective number of navigation signals would be increased.
Two positioning modes are supported:
– UE-Assisted: The UE performs TBS measurements without assistance from the network, and sends these measurements to the SAS where the position calculation takes place, possibly using additional measurements from other (non TBS) sources;
– Standalone: The UE performs TBS measurements and calculates its own location, possibly using additional measurements from other (non TBS) sources.
A UE with TBS capability operates without assistance from the network.
17.2 Information to be transferred between UTRAN Elements
This subclause defines the information (e.g., position, measurement data) that may be transferred between UTRAN elements.
17.2.1 Information that may be transferred from the UE to SAS
The information that may be signalled from UE to the SAS/RNC is listed in table 17.2.1-1.
Table 17.2.1-1: Information that may be transferred from UE to the SAS
|
Information |
UE‑assisted |
Standalone |
|
UE 3D Position estimate with uncertainty shape |
No |
Yes |
|
Timestamp |
Yes |
Yes |
|
Indication of used positioning methods in the fix |
No |
Yes |
|
TBS measurements (code phase (MBS)) |
Yes |
No |
|
Measurement quality parameters for each measurement |
Yes |
No |
The TBS information reported from the UE to the SAS depends on the positioning mode (i.e., standalone, or UE-assisted).
17.2.1.1 Standalone mode
In standalone mode, the UE reports the latitude, longitude and possibly altitude, together with an estimate of the location uncertainty, if available.
The UE should also report an indication of TBS method used and possibly other positioning methods used to calculate the fix.
17.2.1.2 UE-assisted mode
In UE-assisted mode, the UE reports the TBS associated measurements, together with associated quality estimates. These measurements enable the SAS/RNC to calculate the location of the UE, possibly using other measurements and data.
17.3 Location Information Transfer Procedure
The purpose of this procedure is to enable the SAS/RNC to request TBS measurements or location estimate from the UE, or to enable the UE to provide TBS measurements to the SAS/RNC for position calculation (e.g., in case of basic self location where the UE requests its own location).
17.3.1 SAS initiated TBS positioning procedure
The following describes the signalling for the optional initiation of the network TBS positioning procedure by the SAS.
Figure 17.3.1-1: TBS methods when initiated by the SAS
1. The operation begins with an authenticated request for positioning information about a UE from an application in the core network being received at the SRNC. The request from the CN may be a request for on-demand or periodic reporting. The SRNC acts as interface between the Core Network and the UE Positioning entities in the UTRAN.
2. The SRNC sends parameters received in the location request, including any periodic reporting information, together with the Cell ID and UE capability information to the SAS in a PCAP: Position Initiation Request message via the Iupc interface.
3. Depending on the UE capabilities, the SAS initiates a TBS positioning procedure by sending a PCAP: Position Activation Request message that allows for the use of TBS positioning (along with GPS or OTDOA, and optionally Barometric Pressure or WLAN, Bluetooth positioning methods) to the SRNC via the Iupc interface. The PCAP Position Activation Request message may include periodic reporting information (number of reports and reporting interval).
4. The SRNC forwards to the UE the TBS positioning request received from the SAS using RRC signalling. The SRNC also forwards in the RRC signalling message(s) the SAS request for either TBS measurements, in the case of UE assisted, or a position coordinate, in the case of standalone. The RRC signalling may include a request for periodic reporting as described in subclause 6.6.4.1 if this was received in step 3. For a description of standalone TBS mode, jump to step 9.
5. For UE assisted TBS, the SRNC requests from the UE the TBS measurements. These measurements may be made while the UE is in RRC connected mode CELL_DCH state.
6. The UE returns to the SRNC the available TBS measurements, together with a time stamp of when these values were obtained.
7. The information obtained in step 6 is sent from the SRNC to the SAS in a PCAP: Position Activation Response message.
8. The SAS calculates the UE position. If periodic reporting was not requested in step 2, the SAS returns the UE position to the SRNC in a PCAP: Position Initiation Response message. If periodic reporting was requested in step 2, the SAS forwards the position information to the SRNC in a PCAP Position Periodic Result message. The PCAP Position Initiation Response or PCAP Position Periodic Result message may include the positioning method(s) used and an indication of whether the position estimate satisfies the requested accuracy or not.
9. In case of standalone method, the UE returns the position estimate to the SRNC via RRC signalling. The SRNC forwards the position estimate to the SAS in a PCAP: Position Activation Response message. This estimate includes the position, the estimated accuracy of the results and the time of the estimate.
10. If periodic reporting was not requested in step 2, the SAS returns the resulting estimate to the SRNC in a PCAP: Position Initiation Response message. If periodic reporting was requested in step 2, the SAS forwards the position estimate to the SRNC in a PCAP Position Periodic Result message. The PCAP Position Initiation Response or PCAP Position Periodic Result message may include the positioning method(s) used and an indication of whether the position estimate satisfies the requested accuracy or not.
11. If there is insufficient information to yield a UE positioning estimate satisfying the requested accuracy, the SAS may start a new process from step 3.
12. The SRNC passes the position estimate received from the SAS to the CN including the positioning method (or the list of the methods) used to obtain the position estimate. If the CN has requested accuracy for the position estimate, the Location response shall include an indication whether the position estimate satisfies the requested accuracy or not.
13. If periodic UE reporting was requested in step 4, the UE continues to send TBS measurement reports one reporting interval after the previous measurement report. The SRNC forward the TBS measurement report information to the SAS in a PCAP Position Periodic Report message. The SAS may calculate the UE position and sends the position information to the SRNC in a PCAP Position Periodic Result message. The SRNC passes the new position estimate to the CN including, if available, the positioning method (or the list of the methods) used to obtain the position estimate. If the CN has requested accuracy for the position estimate, the Location response shall include an indication whether the position estimate satisfies the requested accuracy or not. This step 13 is repeated until the desired amount of reports has been attained or the procedure is cancelled by the CN or UTRAN. The SAS may send the final location estimate in a PCAP Position Initiation Response message to the SRNC, and the SRNC forwards the final location information to the CN.
14. If periodic UE reporting was not requested in step 4, but was requested in step 2, the SAS may repeat the steps 3 to 12 as for the first request until the desired amount of reports has been attained or the procedure is cancelled by the CN or UTRAN. When repeating step 10 for the final request, the SAS returns the resulting final position estimate to the SRNC in a PCAP: Position Initiation Response message.
Annex A (informative):
Definitions and Terms
This annex provides definitions and terms for the general LCS. Not all of these are applicable to the UTRAN environment.
CAMEL: CAMEL is a network functionality, which provides the mechanisms of Intelligent Network to a UE.
Current Position: after a location attempt has successfully delivered a position estimate and its associated time stamp, the position estimate and time stamp is referred to as the ‘current position’ at that point in time.
Deferred location request: a location request where the location response (responses) is (are) not required immediately.
Frequency reference: the frequency reference of the UE obtained from the UTRAN radio interface that may be used to minimize the frequency search associated with acquiring GPS satellite signals. When the UE acquisition process is aligned to this reference, the carrier Doppler uncertainty that must be searched for a particular satellite signal need only account for minor residual uncertainties related to UE dynamics and initial position. This frequency reference may also be used to maintain the UE’s estimate of GPS time between positioning events, thus making accurate GPS time available within the UE to support reacquisition of satellite signals.
Global Positioning System: the Global Positioning System (GPS) consists of three functional elements: Space Segment (satellites), User Segment (receivers), and Control Segment (maintenance etc.). The GPS receiver estimates its own location based on the observed times of arrival of the satellite signals.
Immediate location request: a location request where a single location response only is required immediately.
Initial Position: in the context of an originating emergency call the position estimate and the associated time stamp at the commencement of the call set-up is referred to as ‘initial position’.
Last Known Position: the current position estimate and its associated time stamp for Target UE stored in the LCS Server is referred to as the ‘last known position’ and until replaced by a later position estimate and a new time stamp is referred to as the ‘last known position’.
LCS (LoCation Services): LCS is a service concept in system (e.g. GSM or UMTS) standardisation. LCS specifies all the necessary network elements and entities, their functionalities, interfaces, as well as communication messages, due to implement the location service functionality in a cellular network.
NOTE: LCS does not specify any location based (value added) services except locating of emergency calls.
LCS Client: a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location information for one or more UEs. LCS Clients subscribe to LCS in order to obtain location information. LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting data and managing the user interface (dialogue). The LCS Client may reside in the UE.
LCS Client Access barring list: an optional list of MSISDNs per LCS Client where the LCS Client is not allowed to locate any MSISDN therein.
LCS Client Subscription Profile: a collection of subscription attributes of LCS related parameters that have been agreed for a contractual period of time between the LCS client and the service provider.
LCS Feature: the capability of a PLMN to support LCS Client/server interactions for locating Target UEs.
LCS Server: a software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services requests, and sends back responses to the received requests. The LCS server consists of LCS components, which are distributed to one or more PLMN and/or service provider.
Local Service: a service, which can be exclusively provided in the current serving network by a Value added Service Provider.
Local Information: information related to a given location, or general information, which is made available in a given location.
Location (Based) Application: a location application is an application software processing location information or utilising it in some way. The location information can be input by a user or detected by UTRAN or UE. Navigation is one location application example.
Location Based Service (LBS): a service provided either by teleoperator or a 3rd party service provider that utilises the available location information of the terminal. Location Application offers the User Interface for the service. LBS is either a pull or a push type of service (see Location Dependent Services and Location Independent Services).
Location Dependent Service: a service provided either by teleoperator or a 3rd party service provider that is available (pull type) or is activated (push type) when the user arrives to a certain area. It doesn’t require any subscription in advance, but the push type activation shall be confirmed by the user. The offered service itself can be any kind of service (e.g. a public Xerox machine or the discount list in a store).
Location Independent Service: a service provided either by teleoperator or a 3rd party service provider that is available and therefore can be activated anywhere in the network coverage. It is activated by the user’s request or by other user’s activated service, and therefore it requires a subscription in advance (pull type). The offered service itself can be any kind of service (e.g. MMS, SWDL, or LBS!).
Position Estimate: the geographic position of a UE expressed in latitude and longitude data, and optionally altitude data. The Position Estimate shall be represented in a well-defined universal format. Translation from this universal format to another geographic positioning system may be supported, although the details are considered outside the scope of the primitive services.
Positioning: positioning is a functionality, which estimates a geographical position (of e.g. a UE).
Positioning method: a principle and/or algorithm that the estimation of geographical position is based on, e.g. AOA, TOA, TDOA. For example, GPS is based on TOA, and E-OTD (on GSM) or OTDOA (on UMTS) are based on TDOA.
Positioning technology: a technology or system concept including the specifications of RF interfaces, data types, etc. to process the estimation of a geographical position, e.g. GPS, E-OTD (GSM), and IPDL-TDOA (UMTS).
PLMN Access barring list: an optional list of MSISDN per PLMN where any LCS Client is not allowed to locate any MSISDN therein except for certain exceptional cases.
Predefined area: a geographical area that is not related to cell or radio coverage. The UE may take special action when it recognises it has entered or left a predefined area.
Privacy Class: list of LCS Clients defined within a privacy exception class to which permission may be granted to locate the target UE. The permission shall be granted either on activation by the target UE or permanently for a contractual period of time agreed between the target UE and the service provider.
Privacy Exception List: a list consisting of various types of privacy classes (i.e. operator related, personal etc.). Certain types of classes may require agreement between the service provider and the target UE.
Prohibited area: an area where the UE must not activate its transmitter. The Prohibited area may be a Predefined area described above or related to radio cell(s).
Subscription Profile: the profile detailing the subscription to various types of privacy classes.
Target UE: the UE being located.
Velocity Estimate: the speed and direction of a UE expressed as horizontal speed and bearing data, and optionally vertical speed data.
Annex B (informative):
Reference Model of Functional Entities for UTRAN UE Positioning
The UTRAN functional entities for UE Positioning are shown in figure B.1 and figure B.2. In these reference models, the LCS clients in the core network communicate with the UTRAN UE Positioning entities across the Iu interface. The RNC LCS Handling Entities and the Positioning Handing Entities work together with the UE to measure and calculate the position information for the requested target UE. These entities within the UTRAN are described in more detail in the following subclauses.
The figure shows the general arrangement of the UE Positioning function in UTRAN. Communication among these entities makes use of the messaging and signalling capabilities of the UTRAN across the Iu, Iur, Iub, Iupc and Uu interfaces. A LMU is also added to the UTRAN to make measurements as needed by the selected positioning method.
This figure does not include elements of 3G Core Network, but focuses on those that participate with the UE Positioning functions in the UTRAN. The association of the LCS entities within the Core Network (CN) (e.g. with 3G-MSC or 3G-SGSN) is outside the scope of the present document and is not illustrated in the diagram.
Within the UTRAN, the UE Positioning Entities may be associated with, or part of the SAS, RNC, the Node B and the UE. Internal LCS Applications may also be part of the RNC and the UE.
The UE Position Calculation Function (PCF) is logically associated with the SRNC or with the SAS.
The UE Positioning in UTRAN also makes use of the standardised Iur interface between RNCs, when Node B information, measurements and results are collected.
The functional model presented in the figure includes functional entities for UE utilising either or both circuit switched (CS) and packet switched (PS) services. This model also supports of all the entities needed for different positioning methods (e.g. network-based, UE-based, UE-assisted, and network assisted (see note 1) methods) exploiting either uplink or downlink measurements.
NOTE 1: In this approach UE may use the GPS technique but still make use of auxiliary information from the serving network.
NOTE 2: Figure B.2 shows the SMLC as a node that implements the PCF. In actuality it is more than the PCF, for example, the SMLC can provide GPS assistance data. See Subclause 5.2.5 for the normative definition of an SMLC.
Figure B.1: UTRAN UE Positioning Functional Entities (RNC centric mode)
Figure B.2: UTRAN UE Positioning Functional Entities – SAS version (RNC centric mode)
Figure B.3: UTRAN UE Positioning Functional Entities – SAS version (SAS centric mode)
Several functional groupings may be defined to describe the UE Positioning functions. These groupings occur in both the CN and the UTRAN. The overall LCS functional grouping is described in reference [13]. Each grouping encompasses a number of functional components and functions.
Within UTRAN the functional entities may be grouped as follows:
– the Internal Client group that includes:
– Internal UTRAN Location Client Function (U-LCF);
– the UTRAN System Handling group that includes:
For RNC centric mode:
– UTRAN Location System Control Function (U-LSCF),
– UTRAN Location System Operations Function (U-LSOF);
For SAS centric mode:
– UTRAN Location Information Relay Function (U-LIRF)
– UTRAN Location System Control Function in SAS (U-LSCFS)
– UTRAN Location System Assistance Data Function (U-LSADF)
– the UTRAN Positioning group that includes:
– UTRAN Position Radio Co-ordination Function (U-PRCF),
– UTRAN Position Calculation Function (U-PCF),
– UTRAN Position Signal Measurement Function (U-PSMF),
– UTRAN Position Radio Resource Management (U-PRRM).
– UTRAN Position Related Communication Function (U-PRComF) for SAS centric mode.
The functions within the UTRAN are described in more detail in the following subclauses.
B.1 Internal Client Group
B.1.1 Internal UTRAN Location Client Function (U-LCF)
The UTRAN Location Client Function (U-LCF) represents a logical interface between the internal UTRAN LCS applications and the LCS RNC Handling entities (e.g. the Location System Control Function (U-LSCF) in the RNC).
NOTE: There is not necessarily a requirement for a LCCF (Location Client Control Function) for the UTRAN Internal Client as is described for external clients in reference [13] (the system stage specification).
The UTRAN may make use of positioning information for internal operations such as location assisted handover. In such a case, a U-LCF representing the internal UTRAN LCS application may communicate with the U-LSCF to request and receive the positioning information.
B.2 UTRAN System Handling group
B.2.1 UTRAN Location System Control Function (U-LSCF)
The UTRAN Location System Control Function (U-LSCF) in RNC is responsible for co-ordinating UE Positioning requests within the RNC handling entity. This function manages call-related and non-call-related UE Positioning requests and allocates network resources for handling them. This function "insulates" the Location clients in the Core Network from the detailed operation of the positioning method in order that the UTRAN may be used by several types of core network and with several positioning methods.
The U-LSCF provides flow control between simultaneous UE Positioning requests. Simultaneous UE Positioning requests must be queued in a controlled manner to account for priority requests (e.g. for Emergency Clients). The details of the flow control, priority selection and queuing are beyond the scope of the present document.
The U-LSCF will select the appropriate positioning method based on the availability of resources and parameters of the UE Positioning request. The U-LSCF co-ordinates resources and activities needed to obtain data (e.g. Node B geographic co-ordinates) needed for the positioning method. It also records LCS RNC usage data for the location service request that may be passed to a Location System Recording Function (U-LSRF) or OA&M function in the Core Network.
If the positioning method requires the broadcast of system information, the LSCF initiates and maintains this activity through the Position Radio Co-ordination Function (U-PRCF). Broadcast information (such as the geographic co-ordinates of the Node Bs) may be required, for example, to support a Position Calculation Function (U-PCF) located in the UE. These broadcasts may also include other information (such as currently observable satellites) that may assist a UE in the use of external location services.
The information to be broadcast is selected based on the positioning methods offered for use by the LCS and the needs of the UE. This broadcast information may be specially coded (i.e. encrypted) to ensure its availability only to subscribers of the service. The use of broadcasts or other methods for signalling to the UE or the LMU may be selected based on the chosen positioning method.
The information to be broadcast could include, for example:
– identification and spreading codes of the neighbouring Node Bs (the channels that are used for measurements);
– Relative Time Difference (RTD), i.e. the timing offsets, asynchronicity between Node Bs, could be obtained from measurement results obtained by LMUs;
– roundtrip delay estimates in connected mode;
– the geographic position, co-ordinates, of the neighbouring Node Bs;
– the idle period places within the frame structure for multiple Node Bs;
– the local time-of-day.
Some of this information may be broadcast to support other UTRAN operations (e.g. handover). The function of the LSCF is to ensure information is broadcast when needed for the LCS operations and the LSCF may make use of other UTRAN processes to do so.
B.2.2 UTRAN Location System Operations Function (U-LSOF)
The UTRAN Location System Operations Function (U-LSOF) is responsible for provisioning of data, positioning capabilities, data related to clients and subscription (LCS client data and UE data), fault management and performance management of LCS within the RNC.
An LSOF may be associated with each entity. The LSOF interacts with Internal (OAM) Clients for administration and maintenance of the data.
The Iur interface may pass messages relating to changes or reporting of the data associated with the LSOF in the RNC.
The Iub interface may pass messages relating to changes or reporting of the data associated with the LSOF in the Node B or the LMU.
The Uu interface may pass messages relating to changes or reporting of the data associated with the LSOF in the UE or the remote LMU. When the SAS is present, with either RNC or SAS centric mode, the U-LSOF may be split across SAS and SRNC.
B.2.3 UTRAN Location Information Relay Function (U-LIRF)
The UTRAN Location Information Relay Function (U-LIRF) is responsible for forwarding of Location Requests from to the LCS clients to the U-LSCFS and for forwarding of UE positioning estimates to the requesting LCS client. The U-LRIF also interfaces with the U-LSOF to obtain provisioned location information.
The U-LIRF communicates with the U-LSADF to handle assistance data requests received from the CN. The U-LIRF also forwards the UE positioning capability information and a coarse position estimate to the U-LSCFS.
B.2.4 UTRAN Location System Control Function in SAS (U-LSCFS)
The UTRAN Location System Control Function in SAS (U-LSCFS) is only used in the SAS centric mode. It performs similar tasks as the U-LSCF in the RNC centric mode, but instead of communicating directly with the LCS clients, it communicates with the U-LIRF in the SRNC.
B.2.5 UTRAN Location System Assistance Data Function (U-LSADF)
The UTRAN Location System Assistance Data Function (U-LSADF) is responsible for the handling location related assistance data within the RNC. This includes handling of location related assistance data requests from the CN and the broadcasting of location related assistance data, if requested by the U-LSCFS.
B.3 Positioning group
B.3.1 UTRAN Position Radio Co-ordination Function (U-PRCF)
The UTRAN Position Radio Co-ordination Function (U-PRCF) manages a UE Positioning for a UE through overall co-ordination and scheduling of resources to perform positioning measurements. This function interfaces with the U-PSMF, the U-PRRM and the U-PCF. The U-PRCF determines the positioning method to be used based on the UE Positioning request, the QoS, the capabilities of the UTRAN, and the UE’s capabilities. The U-PRCF also manages the needed radio resources through the U-PRRM. It determines which U-PSMFs are to be involved, what to measure, and obtains processed signal measurements from the U-PSMF.
Some positioning methods may involve measurements made at the UE. In this case the U-PRCF interfaces with the UE to obtain the measurements (or the positioning results if they have been determined by the UE). Some positioning methods may involve measurements or information from several sources, including radio units at several Node B (or other LMU) and involve a series of transmissions and receptions. The U-PRCF entity also provides ancillary measurements in case of network-assisted positioning method. Ancillary information may be extracted from navigating systems like GPS.
The U-PRCF forwards the signal measurement data to the U-PCF.
It is the function of the U-PRCF to co-ordinate the sequence of activities and compensate for failures (if they occur) to provide the position estimate. In SAS centric mode the U-PRCF communicates to LMU, NodeB and UE via the U-PRComF.
B.3.2 UTRAN Position Calculation Function (U-PCF)
The UTRAN Position Calculation Function (U-PCF) is responsible for calculating the position of the UE. This function applies an algorithmic computation on the collected signal measurements to compute the final position estimate and accuracy.
The U-PCF may also support conversion of the position estimate between different geographic reference systems. It may obtain related data (e.g.: Node B geographic co-ordinates) needed for the calculation. There may be more than one calculating function available within, or associated with, the calculation function of the UTRAN.
In the cell ID based positioning method, the U-PCF shall determine the geographical co-ordinates corresponding to the cell(s) associated with the target UE.
The PCF is also responsible for estimating the accuracy of the position estimate. This accuracy estimate should include, for example, the effect of geometric dilution of precision (GDOP), the capabilities of the signal measuring hardware, the effects of multipath propagation and the effects of timing and synchronisation unknowns. The accuracy should be returned as a measure of distance in the same units as the position estimate. The accuracy zone may be reported as the axis and orientation of an ellipse surrounding the position estimate.
B.3.3 UTRAN Position Signal Measurement Function (U-PSMF)
The UTRAN Position Signal Measurement Function (U-PSMF) is responsible for performing and gathering uplink or downlink radio signal measurements for use in the calculation of a UE position. These measurements can be positioning related or ancillary.
There may be one or more PSMF within a UTRAN and they may be located at the UE, the Node B, or a separate LMU. The PSMF, generally, may provide measurement of signals (i.e. satellite signals) in addition to measurements of the UTRA radio transmissions. The measurements to be made will depend on the selected positioning method.
B.3.4 UTRAN Position Radio Resource Management (U-PRRM)
The UTRAN Position Radio Resource Management (U-PRRM) entity is responsible for managing the effect of LCS operations on the overall performance of the radio network. This may ensure, for example, that the operation of the U-PSMF does not degrade the QoS of other calls. The U-PRRM handles following functions:
– controlling the variation of the UL and DL signal power level due to the LCS application;
– calculating the DL and UL power/interference due to UE positioning operations;
– to admit/reject the new LCS requests;
– co-operating with Admission Control, and entities of the RRM (such as power control) to provide the system stability in terms of radio resources;
– controlling the RTD obtaining mechanism. It may also forward the results of the UTRAN GPS timing of cell frames or SFN-SFN Observed Time Difference (or any similar timing parameter) measurements to the PRCF (or PCF);
– controlling the IPDL mechanism for positioning measurements. This may include the overall control of the periodical measurement fulfilment. Co-ordination among RNCs (e.g. to assure non-overlapping idle periods) will be communicated through the Iur interface.
B.3.5 UTRAN Position Related Communication Function (U-PRComF)
The UTRAN Position Related Communication Function (U-PRComF) manages the collection of positioning measurements as requested by the U-PRCF.
The U-PRComF terminates the NBAP protocol for positioning related measurements requested from NodeB or LMU.
The U-PRComF terminates the RRC protocol for positioning related measurements requested from the UE.
B.4 Assignment of LCS Functional Entities to UTRAN Elements
Figure B.1, Figure B.2, Figure B.3 and tables B.1 and B.2 show the generic configuration for different positioning methods, including network-based, UE-based, UE-assisted and network-assisted methods. With this approach both UTRAN and the UE are able to measure the timing of signals and compute the UE position estimate. Depending on the applied positioning method it is possible to utilise the corresponding configuration containing all needed entities. For instance, if a network-based positioning method is applied, the entities that are involved in measuring the UE’s signal and calculating its position estimate are allocated to the network elements of the access stratum. On the other hand, in case UE-based or network-assisted methods are used these entities should be allocated to the UE.
Table B.1: Example Allocation of LCS Functional Entities to Network Elements for RNC centric mode
|
UTRAN |
UE |
Node B |
LMU |
RNC |
SAS |
|
LCF |
X |
X |
|||
|
LSCF |
X |
||||
|
PRCF |
X |
||||
|
PCF |
X |
X |
X |
||
|
PRRM |
X |
||||
|
PSMF |
X |
X |
X |
||
|
LSOF |
X |
X |
X |
X |
Table B.2: Example Allocation of LCS Functional Entities to Network Elements for SAS centric mode
|
UTRAN |
UE |
Node B |
LMU |
RNC |
SAS |
|
LCF |
X |
X |
|||
|
LSCFS |
X |
||||
|
LIRF |
X |
||||
|
PRCF |
X |
||||
|
PCF |
X |
X |
|||
|
PRRM |
X |
||||
|
PSMF |
X |
X |
X |
||
|
LSOF |
X |
X |
X |
X |
X |
|
PRComF |
X |
Annex C (informative):
Location Services Categories
Generally there are four categories of usage of the location service:
– the Commercial LCS (or Value Added Services);
– the Internal LCS;
– the Emergency LCS;
– the Lawful Intercept LCS.
These location services categories are further defined in [13] and [5].
Annex D (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
12/1999 |
RP-06 |
RP-99635 |
– |
Approved at TSG-RAN #6 and placed under Change Control |
3.0.0 |
||
|
03/2000 |
RP-07 |
RP-000038 |
001 |
3 |
Network assisted GPS LCS |
3.1.0 |
|
|
RP-07 |
RP-000038 |
002 |
1 |
Enhancements for cell coverage based positioning |
3.1.0 |
||
|
RP-07 |
RP-000038 |
003 |
Replacement for Figure 4.1 |
3.1.0 |
|||
|
RP-07 |
RP-000038 |
004 |
1 |
Restructuring |
3.1.0 |
||
|
RP-07 |
RP-000038 |
006 |
Target UE-RNC signalling model |
3.1.0 |
|||
|
RP-07 |
RP-000038 |
007 |
LMU description |
3.1.0 |
|||
|
RP-07 |
RP-000038 |
008 |
2 |
LMU signalling description |
3.1.0 |
||
|
RP-07 |
RP-000038 |
009 |
Incorporation of R1 Liaisons R2-000022 and R2-000023 |
3.1.0 |
|||
|
RP-07 |
RP-000038 |
010 |
3 |
OTDOA – GPS Location Procedures |
3.1.0 |
||
|
RP-07 |
RP-000038 |
011 |
1 |
Clarification of the different LMU types |
3.1.0 |
||
|
06/2000 |
RP-08 |
RP-000218 |
013 |
2 |
Modifications to LCS text on cell-ID method |
3.2.0 |
|
|
RP-08 |
RP-000218 |
015 |
Editorial modifications of OTDOA descriptions for alignment with TDD |
3.2.0 |
|||
|
RP-08 |
RP-000218 |
016 |
Update on clause 5 |
3.2.0 |
|||
|
RP-08 |
RP-000218 |
017 |
1 |
Editorial additions |
3.2.0 |
||
|
RP-08 |
RP-000218 |
018 |
Clarification of OTDOA signalling operation |
3.2.0 |
|||
|
RP-08 |
RP-000218 |
019 |
1 |
Assisted GPS procedures |
3.2.0 |
||
|
09/2000 |
RP-09 |
RP-000356 |
020 |
Alignment of FDD and TDD positioning methods and editorial changes |
3.3.0 |
||
|
RP-09 |
RP-000356 |
021 |
3 |
Assisted GPS Procedures |
3.3.0 |
||
|
RP-09 |
RP-000356 |
022 |
2 |
TDD/FDD alignment of OTDOA and GPS assisted positioning methods |
3.3.0 |
||
|
RP-09 |
RP-000356 |
023 |
Clean-up |
3.3.0 |
|||
|
RP-09 |
RP-000356 |
024 |
Corrections from LCS Ad Hoc |
3.3.0 |
|||
|
12/2000 |
RP-10 |
RP-000566 |
025 |
1 |
Editorial and Minor Technical Clean-up |
3.4.0 |
|
|
RP-10 |
RP-000566 |
026 |
Editorial corrections |
3.4.0 |
|||
|
RP-10 |
RP-000566 |
027 |
Removal of SoLSA concepts |
3.4.0 |
|||
|
RP-10 |
RP-000566 |
029 |
1 |
Signalling flows on Iub and Iur |
3.4.0 |
||
|
RP-10 |
RP-000566 |
030 |
1 |
LCS functionality during SRNS relocation |
3.4.0 |
||
|
RP-10 |
RP-000566 |
031 |
UE Search Correction from R2-001721 (CR 021r3) |
3.4.0 |
|||
|
RP-10 |
RP-000566 |
032 |
2 |
Signaling Between RNC and Stand-Alone LMU |
3.4.0 |
||
|
RP-10 |
RP-000566 |
033 |
5 |
Use of RTT measurements in the Assisted GPS procedure |
3.4.0 |
||
|
RP-10 |
RP-000566 |
034 |
1 |
LCS assistance data delivery |
3.4.0 |
||
|
RP-10 |
RP-000566 |
035 |
2 |
Description for frequency reference |
3.4.0 |
||
|
RP-10 |
RP-000566 |
036 |
2 |
Editorial clean-up |
3.4.0 |
||
|
RP-10 |
RP-000566 |
038 |
2 |
Clarification on information to be transferred between UTRAN nodes |
3.4.0 |
||
|
RP-10 |
RP-000566 |
039 |
1 |
Moving of semantic descriptions from RRC |
3.4.0 |
||
|
03/2001 |
RP-11 |
RP-010023 |
040 |
Correction to Assistance Data Delivery procedure |
3.5.0 |
||
|
RP-11 |
RP-010023 |
041 |
1 |
Clarification of assisted GPS related parameters |
3.5.0 |
||
|
RP-11 |
RP-010023 |
042 |
Clarification of paging initiation |
3.5.0 |
|||
|
RP-11 |
RP-010023 |
045 |
1 |
Editorial Corrections |
3.5.0 |
||
|
RP-11 |
RP-010023 |
046 |
1 |
Clarification of Timing Assistance |
3.5.0 |
||
|
RP-11 |
RP-010023 |
047 |
Clarification of Integrity Monitor Function |
3.5.0 |
|||
|
RP-11 |
RP-010040 |
048 |
1 |
Introduction of IPDLs for TDD |
4.0.0 |
||
|
RP-11 |
RP-010044 |
044 |
4 |
Support of Stand-Alone A-GPS SMLC over an open interface |
5.0.0 |
||
|
06/2001 |
RP-12 |
RP-010306 |
053 |
Removal of positioning request transfer during SRNS relocation |
5.1.0 |
||
|
RP-12 |
RP-010325 |
054 |
Iupc architectural aspects modifications |
5.1.0 |
|||
|
RP-12 |
RP-010325 |
055 |
Removal of RAN3 dependency w.r.t. PCAP signalling flows |
5.1.0 |
|||
|
RP-12 |
RP-010325 |
056 |
1 |
PCAP message flows |
5.1.0 |
||
|
09/2001 |
RP-13 |
RP-010556 |
060 |
1 |
Support for all Rel. 4 positioning methods in standalone SMLC |
5.2.0 |
|
|
12/2001 |
RP-14 |
RP-010757 |
065 |
Correction of broadcast of assistance data |
5.3.0 |
||
|
RP-14 |
RP-010757 |
072 |
Migration of Descriptive Text from TS 25.331 |
5.3.0 |
|||
|
RP-14 |
RP-010770 |
062 |
Correction of RTD usage in TDD |
5.3.0 |
|||
|
03/2002 |
RP-15 |
RP-020080 |
074 |
Corrections Relating to IPDL and Timing Advance for 1.28 Mcps TDD |
5.4.0 |
||
|
RP-15 |
RP-020065 |
081 |
1 |
Correction to CELL ID positioning when UE is not reachable |
5.4.0 |
||
|
RP-15 |
RP-020090 |
075 |
Including IPDL, UE Timing Advance and Angle of Arrival for 1.28 Mcps TDD |
5.4.0 |
|||
|
03/2003 |
RP-19 |
RP-030110 |
085 |
Update to figure 5.1, LMU terminology |
5.5.0 |
||
|
06/2003 |
RP-20 |
RP-030290 |
088 |
Handling of UP assistance data |
5.6.0 |
||
|
RP-20 |
RP-030300 |
089 |
Addition of Position Method Used, to attributes returned with position estimate |
5.6.0 |
|||
|
09/2003 |
RP-21 |
RP-030481 |
092 |
Correction to UE Positioning privacy procedures |
5.7.0 |
||
|
RP-21 |
RP-030481 |
095 |
Alignment with 25.331 regarding A-GPS assistance data |
5.7.0 |
|||
|
RP-21 |
RP-030481 |
098 |
UE positioning support in the UE |
5.7.0 |
|||
|
12/2003 |
RP-22 |
RP-030613 |
101 |
2 |
Correction to Location Reporting procedure |
5.8.0 |
|
|
RP-22 |
– |
– |
Upgrade to Release 6 – no technical change |
6.0.0 |
|||
|
06/2004 |
RP-24 |
RP-040209 |
103 |
Corrections to time stamp in position information report and to SRNC relocation |
6.1.0 |
||
|
RP-24 |
RP-040216 |
104 |
Indication of achieved accuracy in position estimate |
6.1.0 |
|||
|
06/2005 |
RP-28 |
RP-050330 |
0105 |
Addition of the U-TDOA location method to the UTRAN |
7.0.0 |
||
|
09/2005 |
RP-29 |
RP-050478 |
0106 |
Enabling the Providing of Velocity |
7.1.0 |
||
|
RP-29 |
RP-050619 |
0107 |
1 |
Harmonization with the Stage 3 specification (TS 25.453) and addition of TDD functionality for the U-TDOA positioning method |
7.1.0 |
||
|
03/2006 |
RP-31 |
RP-060098 |
0108 |
7.68 Mpcs TDD Option (Release 7) |
7.2.0 |
||
|
06/2006 |
RP-32 |
RP-060356 |
0109 |
Introducing A-GNSS in UTRAN |
7.3.0 |
||
|
RP-32 |
RP-060357 |
0110 |
Addition of Periodic Location Procedures |
7.3.0 |
|||
|
09/2007 |
RP-37 |
RP-070577 |
0111 |
SAS-Centric A-GPS – UE requesting additional Assistance Data |
7.4.0 |
||
|
12/2007 |
RP-38 |
– |
– |
Upgrade to the Release 8 – no technical change |
8.0.0 |
||
|
12/2008 |
RP-42 |
RP-081029 |
0112 |
– |
Support for additional navigation satellite systems in UTRAN |
8.1.0 |
|
|
12/2009 |
RP-46 |
– |
– |
Upgrade to the Release 9 – no technical change |
9.0.0 |
||
|
09/2010 |
RP-49 |
– |
– |
– |
Upgrade to the Release 10 – no technical change |
10.0.0 |
|
|
RP-49 |
RP-100864 |
0119 |
1 |
Support of RF Pattern Matching in UTRAN |
10.0.0 |
||
|
09/2012 |
RP-57 |
– |
– |
– |
Upgrade to the Release 11 – no technical change |
11.0.0 |
|
|
12/2013 |
RP-62 |
RP-131997 |
0122 |
1 |
Introduction of BDS in UTRAN |
12.0.0 |
|
|
12/2014 |
RP-66 |
RP-142119 |
0123 |
– |
BDS Satellite Specific ICD update to version 2.0 |
12.1.0 |
|
|
RP-66 |
RP-142140 |
0124 |
– |
Cleanup corrections on abbreviations |
12.1.0 |
||
|
12/2015 |
RP-70 |
RP-152109 |
0125 |
3 |
RAT-Independent positioning enhancements |
13.0.0 |
|
|
03/2017 |
RP-75 |
– |
– |
Upgraded to Release 14 – no technical change |
14.0.0 |
||
|
06/2018 |
RP-80 |
– |
– |
Upgraded to Release 15 – no technical change |
15.0.0 |
||
|
2020-07 |
RP-88e |
– |
– |
– |
– |
Upgrade to Rel-16 version without technical change |
16.0.0 |
|
2022-03 |
RP-95e |
– |
– |
– |
– |
Upgrade to Rel-17 version without technical change |
17.0.0 |