6 Signalling protocols and interfaces

25.3053GPPRelease 17Stage 2 functional specification of User Equipment (UE) positioning in UTRANTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 LCS signalling between SRNC and MSC/SGSN

LCS signalling between SRNC and MSC/SGSN is handled through the Iu interface, which is described in clause 6.6.1.

6.2 SRNC signalling to a target UE

SRNC signalling to a target UE is handled through the Uu interface, which is described in clause 6.6.4.1.

6.3 Controlling RNC signalling to a standalone LMU

CRNC signalling to a standalone LMU is handled through the Uu interface, which is described in clause 6.6.4.2.

6.4 Controlling RNC signalling to an associated LMU

CRNC signalling to an associated LMU is handled through the Iub interface, which is described in clause 6.6.3.

6.5 RNC-to-RNC signalling for UE Positioning support

The RNC-to-RNC signalling for UE Positioning support is handled through the Iur interface, which is described in clause 6.6.2.

6.5a SAS to RNC signalling for PCAP

The SAS to RNC signalling is described in clause 6.6.5.

6.6 Interfaces

There are five interfaces through which the UE Positioning entities communicate. These are the Iu, Iur, Iub, Uu and Iupc.

NOTE: the interfaces between the Internal or External LCS applications and the 3G-MSC or 3G-SGSN are outside the scope of the present document.

6.6.1 Iu Interface

The Iu interface is used to communicate between the LCS functional entities in the CN and the UE Positioning entities in the UTRAN. Further specification of the messages and operations for LCS across the Iu interface may be found in reference [19].

6.6.2 Iur Interface

UE Positioning operations at the Iur interface are defined in [20].

The Iur interface is used to communicate between the UE Positioning functional entities associated with the SRNC and other RNC in the UTRAN. The Iur interface is also used to communicate between the SRNC and the Internal UE Positioning Applications in the UTRAN. The UE Positioning entities associated with the SRNC are responsible for co-ordinating and responding to positioning requests received from the LCS entities in the CN or Internal Clients.

When communicating between the SRNC and the UTRAN Internal UE Positioning Applications (e.g. located within other RNCs), the messages and protocols are those used over the Iur interface. Some positioning methods may require measurements by several LMU or Node B, some of which may be associated with other RNC. Commands and responses from these UE Positioning Entities are communicated over the Iur interface. In some cases, the UE Positioning Entities in the SRNC may make use of entities associated with other RNC. For example, a calculating function may be used in another RNC if the SRNC is too busy or does not contain the function or database information required by the chosen positioning method.

Iur shall be used for UE Positioning signalling whenever it is available, even in the case when the RNCs connected to different 3G-MSCs or 3G-SGSN.

Within UTRAN, Iur supports inter-RNC soft handover. Inter-RNC handover should also include UE Positioning, meaning that whenever an inter-RNC soft handover occurs, Iur should be able to support the functionality of the UE Positioning entities in RNCs.

Iur shall be used also to collect RTD and other UE Positioning information from Node Bs under different RNCs that are not involved in handover.

6.6.2.1 Signalling between SRNC and DRNC

Signalling between SRNC and DRNC is used to obtain LCS information specific to a UE that has an UE context to the DRNC.

The signalling between SRNC and DRNC is done by using RNSAP procedures specified in [20].

6.6.2.2 Signalling between SRNC and CRNC

Signalling between SRNC and CRNC is used to obtain UE Positioning information and request LCS related transmissions or other radio operation (e.g. information about IPDL configuration) that is needed by SRNC for a certain positioning method. The requested information may be e.g. GPS assistance data in case a reference GPS receiver is not available at the SRNC or RTD results that may be provided by the CRNC.

The procedures used for the signalling between SRNC and CRNC are not specified yet.

6.6.3 Iub Interface

UE Positioning operations at the Iub interface are defined in [21].

The Iub interface is used to communicate among the UE Positioning entities associated with the CRNC, the Node B and the associated LMU.

This interface passes the request for measurements, the measurement results and requests for UE Positioning related transmissions or other radio operations needed by the positioning method (e.g. broadcast of parameters needed for a UE-based positioning method). Measurement requests and results are signalled by using NBAP procedures.

6.6.3.1 Signalling between CRNC and associated LMU

Signalling exchanges between an CRNC and a LMU under the control of that CRNC will be specified in the NBAP protocol for associated LMUs.

The protocol layers employed to enable signalling between the CRNC and an associated LMU are defined in [22]. The LMU signalling information elements are included directly in the NBAP protocol, defined in [22].

6.6.4 Uu Interface

UE Positioning operations at the Uu interface are generally defined in [13]. This specification defines in more detail the procedures needed for messaging for each individual positioning method.

The Uu interface is used to communicate among the UE Positioning entities associated with the SRNC, the UEs and the stand-alone LMU.

The Uu interface may pass measurement requests and results to and from the UE or the stand-alone LMU.

The Uu interface may also be used for broadcast of information that may be used by the UE or stand-alone LMU for their UE Positioning operations. This may, for example, include timing and code information about nearby Node B transmissions that may assist the UE or LMU in making their measurements.

The Uu interface is also used to transport signalling between LCS entities in the CN and the UE, e.g. positioning requests from internal or external LCS Applications at the UE. This is part of the NAS procedures and it is outside the scope of this specification.

6.6.4.1 Signalling between SRNC and Target UE

UE Positioning related signalling between an SRNC and a target UE is supported by the RRC protocol as specified in [18].

The positioning request to UE signalling flow is generic for all UE-based or UE-assisted positioning methods (OTDOA and Network-assisted GNSS).

Figure 6.1: OTDOA / GNSS Positioning Message Flow

1. The SRNC determines possible assistance data and sends a MEASUREMENT CONTROL request to the UE. The MEASUREMENT CONTROL message may contain a request for periodic reporting with an amount of reports greater than one. In networks that include an SAS, the assistance data is generated within the SRNC or in the SAS and passed to the SRNC over the Iupc interface. If both an SAS and an SRNC with SMLC internal functionality are available, selection is based on SRNC configuration.

2. The UE performs the requested measurements. If the UE is able to calculate its own position and optionally, velocity, and this is requested, the UE computes a position estimate, and optionally, a velocity estimate based on measurements. Assistance data necessary to perform these operations will either be provided in the MEASUREMENT CONTROL request and possibly in subsequent MEASUREMENT CONTROL messages or be available from broadcast sources. The resulting measurements or position and optional velocity estimates are returned to UTRAN in a MEASUREMENT REPORT response. If the UE cannot fulfil the request, a MEASUREMENT CONTROL FAILURE message is returned.

3. If periodic reporting was requested in step 1 with an amount of reports greater than one, the UE continues to send MEASUREMENT REPORT messages one reporting interval after the previous MEASUREMENT REPORT message until the requested amount of reports is attained, or until a request from the SRNC is received to stop the periodic reporting.

In case the UE is not able to fulfill the measurements because the assistance data stored in the UE is not sufficient or out of date the UE returns a MEASUREMENT REPORT requesting for more additional data.

Figure 6.2: OTDOA / GNSS Positioning Message Flow with additional assistance data request

1. The UE cannot fulfil the request or cannot continue to send UE Positioning measurements when the reporting criteria are fulfilled, because its assistance data is not sufficient or out of date, a MEASUREMENT REPORT message is returned requesting for additional assistance data.

2. The SRNC may send more or new assistance data based on UE request.

3. The requested measurement results are returned to the SRNC. The UE continues the measurement reporting according to the stored MEASUREMENT CONTROL information (e.g., when periodic reporting was requested).

6.6.4.1.1 Assistance Data Delivery to UE

The assistance data signalling flow illustrated here is generic for the point-to-point delivery of positioning related assistance data to the UE, including OTDOA and Network-assisted GNSS.

Figure 6.2b: OTDOA or GNSS Assistance Data Delivery Flow

1. The SRNC determines assistance data and sends it in the RRC ASSISTANCE DATA DELIVERY message to the UE. In networks that include an SAS, the UE Positioning assistance data is generated within in the SAS and passed to the SRNC over the Iupc interface.

6.6.4.1.2 Error Handling

The error handling for signalling on the Uu interface is handled by the RRC protocol in [18].

6.6.4.1.3 Broadcast of Assistance Data

For OTDOA and GNSS, UTRAN may broadcast assistance data to the UE.

The assistance data to be broadcast for OTDOA contains the reference and neighbour cells to measure and for each neighbour cell the approximate cell timing and possibly IPDL information. The approximate cell timing may be used to simplify OTDOA measurements. Additionally, RTD values (e.g. in case of a non-synchronised network) and Node B co-ordinates for UE based OTDOA may be included for each neighbour cell. The length of the message depends on how many neighbours are included in the assistance data. Part of the broadcast message (e.g. the serving and neighbour Node B geographic co-ordinates) may be ciphered.

The assistance data to be broadcast for assisted GNSS may contain a subset of or all of the following information: reference time, reference position, DGNSS corrections, ephemeris and clock corrections, and almanac and other data. The broadcast message may be ciphered.

The broadcast channel that is used for the OTDOA and GNSS assistance data makes use of the common UTRAN broadcast service specified in [18].

6.6.4.1.4 Signalling Flow for Assistance Data Broadcast Using the Common UTRAN Broadcast Service

The UTRAN may broadcast positioning related assistance data to UEs within the system information.

Figure 6.3: Broadcast of system information

6.6.4.1.5 UE Positioning Assistance Data Ciphering

To allow control of access to the assistance data, parts of the broadcast assistance data may be ciphered. Ciphering is done with a specific ciphering key delivered by the CN for this purpose. The management of the key is described in the System Aspects Stage 2 ([13]).

6.6.4.1.6 UE Positioning Assistance Data Ciphering Algorithm

The algorithm used for ciphering the UE Positioning assistance data is the standard 56-bit Data Encryption Standard (DES) algorithm.

The deciphering of broadcast assistance messages is done in the UEs. The deciphering will utilize the deciphering keys delivered during the location update request. Details can be found in [25].

The RNC ciphers the parts of the UE Positioning Broadcast Data message to be protected using the 56-bit DES algorithm and a ciphering keys (56 bits) and Ciphering Serial Number (16 bits) for the broadcast location area.

The ciphered part is variable in length with one bit resolution. By using the UE Positioning Broadcast Data message header, the UEs can determine what part of message is ciphered.

Inputs to the 56-bit DES algorithm are the following:

– 56-bit key K (deciphering key);

– 16-bit Ciphering Serial Number from broadcast message, which is denoted here by IV (Initialisation Vector);

– plain-text bits (the ciphered part of broadcast message).

The ciphering process is illustrated in the following diagram. Ciphering is done by producing a mask bit stream, which is then "XORed" bit-by-bit to the plain-text data to obtain the cipher-text data. First, the Initialisation Vector (IV) is concatenated with 0-bits in order to achieve a 64-bit block I₁. This block is then encrypted by the DES algorithm using the key K. Output is a 64-bit block I₂. This constitutes the first 64 bits of the mask bit stream. If the message is longer than 64 bits, then more bits are needed. These are produced by encrypting I₂again by the DES algorithm using the key K. The output is a 64-bit block I₃. This is the next 64 bits of the mask bit stream. This iteration is continued until enough bits are produced. The unnecessary bits from the last 64-bit block I_j are discarded. The figure below illustrates the first two mask bit generations and the two ciphered 64-bit blocks.

Figure 6.4: Data Assistance Ciphering Algorithm

Deciphering is done similarly. The same mask bit stream is produced and these are XORed, bit-by-bit, to the cipher-text data bits. The result will be the plain-text data.

6.6.4.2 Signalling between RNC and stand-alone LMU

Signalling exchanges between an RNC and a stand-alone LMU under the control of that RNC will be specified in the RRC protocol for stand-alone LMUs. This does not preclude a stand-alone LMU from also communicating with other networks (e.g. GSM) through interfaces (e.g. LLP protocol) that are not part of the present document.

Each update of the LMU measurement (including the initial one) is triggered by a LCS request from the client that is internal to UTRAN. The request may be made directly to the UTRAN LCS entities as the internal clients are considered to be "pre-authorised" (clause 5) or comes from CN with authentication.

The following figure illustrate the protocol layers used to support signalling between an RNC and a stand-alone LMU over the Uu interface.

The protocol layers employed to enable signalling between the RNC and a stand-alone LMU are defined in [18]. The LMU signalling information elements are included directly in the RRC protocol, also defined in [18].

Figure 6.5: Signalling between an RNC and a Stand-Alone LMU using a signalling bearer

6.6.5 Iupc Interface

UE Positioning operations on the Iupc interface are described in [27]. That specification defines in more detail the procedures needed for messages for the UE positioning method.

The Iupc interface is used to allow communication between an RNC and an SAS. This interface is used to signal position and optionally, velocity estimate requests and responses as well as UE Positioning related information using mechanisms consistent with the other internal UTRAN interfaces. The Iupc interface is used for providing the RNC with UE Positioning data to be used for both point-to-point and broadcast purposes. The Iupc interface uses an Iups-like protocol stack for the transport layer which is described in [28].

6.6.5.1 Signalling between RNC and SAS

The signalling between RNC and SAS is done by using PCAP procedures specified in [27].

6.6.5.1.1 PCAP Position Calculation

The PCAP Position Calculation message flow illustrates how an SRNC invokes an SAS to calculate a position estimate of a UE. This message flow is repeated by the SRNC as needed for a periodic location procedure.

The SRNC initiates the PCAP Position Calculation message flow in the RNC centric mode for UEs that support the following positioning method types:

– UE assisted;

– UE assisted is preferred, but UE based is allowed;

– UE based is preferred, but UE assisted is allowed;

when the chosen positioning method type is ‘UE Assisted’.

For UEs that only support the UE based positioning method or that, supporting both, have selected the ‘UE Based’ option, the PCAP Position Calculation message flow is not applicable.

The SRNC also inititates the PCAP Position Calculation Request message flow to invoke the U-TDOA positioning method in the case that U-TDOA is initiated from the SRNC and not from the SAS.

Figure 6.6: PCAP Position Calculation Request Message Flow

1. The SRNC initiates a PCAP Position Calculation Request Message. This message contains data necessary for the SAS to calculate a position, and optionally a velocity estimate for a UE and, if required, initiate U-TDOA positioning for the UE. The PCAP Position Calculation Request message may contain periodic location information (reporting interval and number of outstanding requests for the overall periodic location procedure) to enable the SAS to better fulfil future such requests.

2. If the SAS is able to calculate the position, and optional velocity estimate, possibly after performing U-TDOA positioning if requested in step 1, it shall return it to the SRNC in a PCAP Position Calculation Response Message. If the SAS cannot fulfil the request, it shall return a PCAP Position Calculation Failure Message to the SRNC.

6.6.5.1.2 PCAP Information Exchange

The PCAP Information Exchange message flow illustrates how an RNC initiates and terminates an exchange of UE Positioning related information with an SAS. The UE Positioning related information received from the SAS can be used by the RNC to either provide assistance data to a particular UE through dedicated signalling or to build up System Information Blocks containing assistance data to be broadcast to UEs in a particular area.

Figure 6.7: PCAP Information Exchange Message Flow

1. The RNC initiates a PCAP Information Exchange Initiation Request Message. This message contains data necessary for the SAS to provide the requested UE Positioning related information to the RNC. Upon reception of this message, the SAS shall provide the requested UE Positioning related information according to the reporting parameters given in the request. These parameters specify how the UE Positioning related information is to be reported (i.e. on-demand, periodically, or on-modification).

2. If the SAS is able to determine the information requested by the RNC, it shall respond with a PCAP Information Exchange Initiation Response Message.

3. If the SAS cannot provide the requested UE Positioning related information, it shall return a PCAP Information Exchange Initiation Failure Message.

4. In cases where the RNC has specified that the UE Positioning related information is to be reported periodically or on-modification, the SAS shall return the requested information in one or more PCAP Information Report Messages.

5. In cases where the RNC has specified that the UE Positioning related information is to be reported periodically or on-modification, the SAS may initiate an Information Exchange Failure Indication Message to notify the RNC that the requested information associated with a particular reporting activity can no longer be reported.

6. In cases where the RNC has specified that the UE Positioning related information is to be reported periodically or on-modification, the RNC may terminate a particular information reporting activity by initiating a PCAP Information Exchange Termination Request Message. Upon reception, the SAS shall terminate the particular information exchange activity indicated by the RNC.

6.6.5.1.3 PCAP for SAS based Positioning Method Selection

As a configuration option, the SAS shall be able to determine the positioning method used for individual positioning events. In this case the SRNC shall allow A-GNSS, OTDOA, Cell ID, U-TDOA, WLAN, Bluetooth, Barometric Pressure and TBS positioning events to be originated by the SAS via PCAP messages on the Iupc interface.

Figure 6.8: Fundamental SAS centric signal flow over the Iupc interface

1. The SRNC forwards the information contained in the RANAP Location Reporting Control message plus Cell ID and UE capability information to the SAS in a PCAP Position Initiation Request message.

2. The SAS may initiate a specific positioning method by sending a PCAP Position Activation Request message to the SRNC containing the required positioning method and any assistance data and instructions associated with that positioning method. For positioning methods which require RRC signalling (e.g., OTDOA or A-GPS), the positioning instructions include the required settings for the "measurement validity" IE in the RRC signalling message (e.g., CELL_DCH, all states except CELL_DCH, or all states) [18].

3. The SRNC performs the positioning procedure requested by the SAS including any signalling interaction with the UE in the case of UE assisted or UE based positioning (e.g. for A-GNSS or OTDOA).

4. The SRNC sends a PCAP Position Activation Response message to the SAS confirming the requested action and providing any information required by the requested positioning method; e.g. UE channel information for the U-TDOA positioning method or A-GNSS measurements for UE assisted A-GNSS. If periodic UE reporting is activated by the SRNC in step 3, the PCAP Position Actiation Response message includes the used settings for the IE "measurement validity" in the corresponding RRC signalling [18].

5. The SAS instigates any further positioning associated with the posititioning method chosen in step 2 – e.g. obtains measurements from LMUs in the case of U-TDOA.

Note:

Repeating steps 2, 3, 4 and 5 to invoke additional positioning methods may provide higher location accuracy or successfully provide UE locations under difficult propagation circumstances, e.g. the hybrid positioning method. When steps 2, 3, 4 and 5 are repeated, the SAS shall not send a new PCAP Position Activation Request message until the SRNC has responded to a previous request or the SAS has timed out on a response. The SAS may, however, send a new PCAP Position Activation Request message in a repetition of step 2 while SAS positioning for a previous step 5 is ongoing. In this case, SAS positioning (e.g. for U-TDOA) could execute in parallel with SRNC positioning (e.g. for A-GNSS or OTDOA) thereby reducing overall response time.

6. If an RNC positioning procedure has been invoked in step 3 which requests periodic UE reporting according to subclause 6.6.4.1, the subsequent periodic UE measurement reports (e.g. for A-GPS or OTDOA) are conveyed to the SAS using one or more PCAP Position Periodic Report messages.

NOTE: If a periodic RNC positioning procedure has been invoked by the SRNC in step 3, the PCAP Position Activation Response message in step 4 may be returned immediately (i.e., before step 3) confirming the requested action and not including any measurements. In that case, all periodic measurement reports are conveyed to the SAS using PCAP Position Periodic Report messages.

7. If periodic positioning was invoked in step 1, the successive periodic position estimates (or an indication of positioning failure) are conveyed to the SRNC using one or more PCAP Position Periodic Result messages.

8. The SAS provides the UE location or, when periodic positioning was invoked in step 1, the final UE location to the SRNC in a PCAP Position Initiation Response message. In case of periodic positioning, the final location estimate may be provided, as an implementation option, in a PCAP Position Periodic Result message followed by a PCAP Position Initiation Response message that does not contain any UE location estimate.