9.4 E-OTD and A-GNSS Positioning Procedures

3GPP43.059Functional stage 2 description of Location Services (LCS) in GERANRelease 17TS

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

9.4.1 General procedures

For any location request where the highest priority level is assigned and MS-based A-GNSS positioning is not used, the SMLC functionality shall provide sufficient assistance data to a target MS to enable a location estimate, velocity estimate, or location measurements to succeed according to the required QoS on the first attempt. The SMLC shall not assume in this case that the target MS already possesses assistance data. For a lower priority location request or when MS-based A-GNSS positioning is used, the SMLC may reduce the assistance data provided to a target MS on the first location attempt.

In the high priority case with MS-assisted GNSS for the first positioning attempt, acquisition assistance data shall be included in the RRLP measure position request message.

9.4.2 Positioning Request

This signaling flow is generic for all MS based or assisted location methods (MS Based E-OTD, MS Assisted E-OTD, MS Based A-GNSS, and MS Assisted A-GNSS). The signaling flow below applies to integrated and standalone SMLCs in a circuit switched network.

If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation, see clause 6.1.2, and transfer the LCS assistance data more reliably, this procedure may be preceded by an "Assistance Data Delivery" procedure. Note, that part of the entire set of assistance data may be included in the RRLP Measure Position Request even when the message is preceded by an "Assistance Data Delivery" procedure.

If the MS has indicated support for providing MS positioning capabilities using RRLP in the MS Classmark 3 IE for GSM (see 3GPP TS 24.008), in the PS LCS Capability IE for GERAN Gb mode (see 3GPP TS 24.008), or in the MS Positioning Capability IE for GERAN Iu mode, this procedure may be preceded by a “Positioning Capability Transfer” procedure.

Figure 30: E-OTD or A-GNSS Position Request Flow

1) The SMLC may precede the RRLP MEASURE POSITION REQUEST or Assistance Data Delivery procedure with a Position Capability Transfer procedure, if the MS supports the transfer of MS positioning capabilities using RRLP.

2) The SMLC may precede the RRLP MEASURE POSITION REQUEST with an optional Assistance Data Delivery procedure.

3) The SMLC determines possible assistance data and sends RRLP MEASURE POSITION REQUEST to the BSC.

4) The BSC forwards the positioning request including the QoS and any assistance data to the MS in a RRLP MEASURE POSITION REQUEST.

5) The MS performs the requested E-OTD or GNSS measurements, if needed assistance data is available in the MS. If the MS is able to calculate its own location and this is required and needed assistance data is available in MS, the MS computes a location estimate based on E-OTD or GNSS measurements. In case of E-OTD, any data necessary to perform these operations will either be provided in the RRLP MEASURE POSITION REQUEST or available from broadcast sources. In case of A-GNSS (both MS based and MS assisted) and first positioning attempt, a minimum set of A-GNSS assistance data will be either provided in the RRLP MEASURE POSITION REQUEST or available from broadcast sources. For further positioning attempt (failure in first attempt due to missing assistance data), sufficient A-GNSS assistance data, possibly excluding the assistance data sent in the first attempt, will be provided in the RRLP MEASURE POSITION REQUEST and possibly preceding RRLP ASSISTANCE DATA messages. The resulting E-OTD or GNSS measurements or E-OTD or GNSS location estimate (with optional velocity estimate) are returned to the BSC in a RRLP MEASURE POSITION RESPONSE. If the MS was unable to perform the necessary measurements, or compute a location, a failure indication identifying the reason for failure (e.g. missing assistance data) is returned instead. In case of A-GNSS, if the MS was unable to compute a location, the GNSS measurements are also optionally returned if allowed by the network. If the RRLP message is larger than the RRLP maximum PDU size, several RRLP MEASURE POSITION RESPONSE messages are sent (i.e. the RRLP pseudo-segmentation is used).

6) BSC forwards the RRLP MEASURE POSITION response to SMLC.

9.4.3 Assistance Data Delivery

This signalling flow is generic for MS Based and MS Assisted E-OTD, and MS Based or MS Assisted A-GNSS in a circuit switched network.

If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation and transfer the LCS assistance data more reliably, the sequence 1-4 illustrated in the figure below may be repeated several times to deliver more assistance data than can be sent by one RRLP Assistance Data Delivery message. In this case, each individual message is independent such that the data received in one message is stored in the MS independently of the other RRLP Assistance Data messages (i.e. an error of delivery of one message does not require a retransmission of all the RRLP Assistance Data messages). The SMLC shall indicate in the RRLP ASSISTANCE DATA message if more RRLP ASSISTANCE DATA messages will be used after the current one in order to deliver the entire set of assistance data. Data that is specific to the current cell should be sent in the last message this is recommended so that assistance data for the correct cell is available to the MS after a handover.

Figure 31: E-OTD or A-GNSS Assistance Data Delivery Flow

1) The SMLC determines assistance data and sends it in the RRLP ASSISTANCE DATA message to the BSC.

2) The BSC forwards the assistance data to the MS in a RRLP ASSISTANCE DATA message.

3) The MS acknowledges the reception of complete assistance data to the BSC with a RRLP ASSISTANCE DATA Ack.

4) The BSC forwards the RRLP ASSISTANCE DATA Ack message to the SMLC.

9.4.3a Positioning Capability Transfer

The purpose of this procedure is to enable the SMLC to obtain the positioning capabilities of the MS, the types of assistance supported and the types of assistance data that may be needed from the SMLC. MS support for this procedure can be indicated to the SMLC using the MS Classmark 3 IE for GSM (see 3GPP TS 24.008), the PS LCS Capability IE for GERAN Gb mode (see 3GPP TS 24.008) and the MS Positioning Capability IE for GERAN Iu mode.

Figure 31a: RRLP Position Capability Transfer Flow

1) The SMLC determines that the target MS supports MS Positioning Capability Transfer using RRLP and sends a Positioning Capability Request message to the BSC.

2) The BSC forwards the Positioning Capability Request message to the MS.

3) The MS sends the Positioning Capability Response message to the BSC. The response message shall include the positioning capabilities of the MS and the types of supported assistance data (if applicable). The message may include the types of assistance needed by the MS to obtain a location estimate or positioning measurements.

4) The BSC forwards the Positioning Capability Response message to the SMLC.

9.4.4 Error Handling for E-OTD and A-GNSS in CS Domain

This clause describes error handling for positioning and transfer of assistance data for E-OTD and A-GNSS. For a description of error handling involving segmentation, and more details on usage of a BSSLAP Abort, Reject and Reset refer to clause 8.5 Exception Procedures.

Case 1: When the RRLP request comes to BSC for E-OTD and A-GNSS, The BSC will send a BSSLAP reject message to SMLC if the request cannot be supported in the BSC for reasons other than an ongoing intra BSC or inter BSC handover or other ongoing RR management procedure. For an ongoing intra BSC HO or other RR management procedure, the BSC shall return a BSSLAP Reset when the handover or RR management procedure is complete. The SMLC may then start the RRLP request (if there is time) again. For ongoing inter-BSC HO, the BSC shall return a BSSLAP Abort. The location service request may then restart from the LCS Client, VMSC or SGSN.

Case 2: When the RRLP request comes to BSC from SMLC, BSC sends the "RRLP request" to the MS if there is no ongoing HO or other RR management procedure at that point. If an intra-BSC HO or other RR management procedure is initiated in BSC, the BSC sends the HO or other RR management command to MS. A timer will then be started in BSC, the duration of which is network dependent, but typically 6 (six) seconds. Upon receiving the HO of other RR management command, the MS will stop the location procedure and start on handover or other RR management procedure, since this has higher priority than location. The MS will then send the HO complete or other RR management response message to BSC. When this message is received before the expiration of BSC timer, a BSSLAP Reset message will be sent to SMLC from BSC. The Reset will tell SMLC to start another location service request if there is enough time.

Case 3: During intra-BSC HO or other intra-BSC RR management procedure, if a HO complete or RR management procedure completion was not received in BSC and the corresponding timer expired. In this case a reset or abort message will be sent to SMLC indicating MS timeout. The location service may then restart from either the SMLC if a reset was sent or from the LCS Client, VMSC or SGSN if an abort was sent.

Case 4: If an inter-BSC handover is needed during a location procedure or if the BSC times out on an RRLP response from the target MS, the BSC shall send a BSSLAP Abort to the SMLC. The location service attempt may then be restarted from the LCS Client, VMSC, or SGSN.

9.4.5 Error Handling for the SMLC in CS Domain

Figure 32: Error Handling for the SMLC in the CS Domain

9.4.5a Error Handling for E-OTD and A-GNSS in PS Domain

Case 1: When the RRLP request comes to BSS for E-OTD and A-GNSS, the BSS will send a BSSLAP reject message to SMLC if the request cannot be supported in the BSS.

Case 2: When the RRLP request comes to BSS from SMLC, BSS sends the "RRLP request" to the MS via the SGSN and starts position supervision timer. After this, if the BSS determines that the current location procedure cannot be continued, the BSS sends an abort message to the SMLC. Notice that an MS reselection to a new cell is not a reason for the BSS to abort the procedure.

Case 3: If the position supervision timer times out in BSS before the RRLP response from the target MS is received, the BSS shall send a BSSLAP Abort to the SMLC. The location service attempt may then be restarted from the LCS Client, VMSC, or SGSN.

Figure 32a: Error Handling for the SMLC in PS domain

9.4.6 Broadcast of Assistance Data

In MS Based E-OTD, MS Based GPS and MS Assisted A-GNSS systems, there may be a need for assistance data to be broadcast to the MS. The assistance data to be broadcast for MS Based E-OTD contains the Real Time Difference (RTD) values (in case of a non-synchronised network) and Base Transceiver Station (BTS) coordinates. In addition, the broadcast data contains other information simplifying the E-OTD measurements. The broadcast of A-GNSS assistance data may make available the same information as in A-GNSS point-to-point signalling. It improves the location accuracy for MS Based implementations, increases the sensitivity, enables LMU-independent time dissemination and assists the acquisition of satellite signals for both MS Based and MS Assisted implementations.

The CS mechanism (Cell Broadcast on CBCH) is used for broadcast of assistance data for all MSs, irrespective of which domain (CS or PS) they are located in. Notice that it may take longer for an MS in the PS domain compared to the CS domain to read all the broadcast data. This is because the PBCCH is not co-ordinated with the CBCH and therefore, the MS may have to skip reading a CBCH slot in order to listen for a potential paging message.

The E-OTD assistance data to be broadcast is in compressed format where the redundant information is not included. The MS is capable to reconstruct the E-OTD assistance data using the message header information. The length of the message is depending on how many neighbours are included in the E-OTD assistance data as well as whether the redundant information can be removed from the message. The typical size of one broadcast message will be less than 82 octets. Part of the broadcast message (serving and neighbour base station coordinates) may be ciphered.

The contents of the broadcast message for the E-OTD and A-GNSS assistance data is described in 3GPP TS 44.035 [16]. The support for these broadcast messages is optional for network and MS.

The broadcast channel which is used to broadcast the E-OTD and A-GNSS assistance data make use of the existing basic or extended CBCH and SMSCB DRX service. The LCS broadcast messages need to be either scheduled, or prioritised over other broadcast messages to avoid any delay.

9.4.6.1 Point-To-Multipoint Assistance Data Broadcast Flow

This signalling flow is generic for MS Based E-OTD, MS Based A-GNSS and MS Assisted A-GNSS methods. The E-OTD/A-GNSS Assistance Data Broadcast Message is created in SMLC and the whole message including the ciphered parts and parameters to control the transfer are transferred with below flow from SMLC to MS. SMSCB DRX service is used for LCS assistance data broadcast. Prior receiving the first schedule message MS should read first block of each message lot to be able to receive the LCS Broadcast Data or the schedule message. After receiving the schedule message MS should receive the LCS Broadcast Data messages according the schedule information.

Figure 33: E-OTD/A-GNSS Broadcast Data Flow

1) SMLC sends the complete broadcast message to CBC with LCS Broadcast Data message. This LCS Broadcast Data message contains the data to be broadcasted as well as parameters that indicate to which BTS the broadcast message is targeted and what time the broadcast should happen. LCS Broadcast Data (data & parameters) message may also contain the SMSCB scheduling information which can be utilised for the SMSCB DRX feature specified in 3GPP TS 44.012 [13] specification. SMSCB DRX operation is required in order that MS performance can be optimised.

2) CBC starts message transfer to BSC and BTS according to 3GPP TS 23.041 [6].

3) LCS Broadcast Data Response message from CBC to SMLC is used to indicate that the LCS Broadcast Data has been delivery request has been fulfilled. This message is not mandatory

4) BTS starts the message transfer to MS according to 3GPP TS 23.041 [6].

Implementations that have SMLC and/or CBC integrated into BSC may use other message signalling.

9.4.6.2 Ciphering

In order for the operators to control the access to the assistance data, parts of the broadcast data may be ciphered. Ciphering is done with a specific key delivered by the network for this purpose. The deciphering keys may be requested by the MS as described in 3GPP TS 23.271 [7]. The LCS Broadcast Data, when ciphered, will be partially ciphered according to the LCS broadcast message definitions specified in 3GPP TS 44.035 [16]. The parts that will be ciphered in E-OTD LCS Broadcast Data message are neighbour RTD values, serving and neighbour BTS coordinates. For A-GNSS, all assistance data may be ciphered, The MS is capable to decipher the broadcast message (ciphered parts) using the cipher key (56 bits) delivered from the Core Network to MS and using the Ciphering Serial Number (16 bits) included in the broadcast message.

9.4.6.2.1 Algorithm

The algorithm used for ciphering is the standard 56-bit DES algorithm. The deciphering of broadcast messages is done in the MS. SMLC ciphers the LCS Broadcast Data message (part of message is ciphered) using the deciphering keys (56 bits) and Ciphering Serial Number (16 bits) included in broadcast message using 56-bit DES algorithm.

The ciphered part is variable length with one bit resolution. From LCS Broadcast Data message header MS can compute 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);

– plaintext bits (the ciphered part of broadcast message).

Encryption is done by producing a mask bit stream which is then added bit-by-bit to the plaintext data (XOR-operation) to obtain the cipher text data. First 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. Those are produced by encrypting I₂again by the DES algorithm using the key K. Output is a 64-bit block I₃. This constitutes 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. Below figure describes the first two mask bit generations and the two ciphered 64-bit blocks.

Figure 34 : Ciphering Algorithm

Decryption is done similarly. The same mask bit stream is produced. This time the mask stream bits are added bit-by-bit (XORed) to the ciphertext data bits. The result will be the plain text data.

9.4.6.3 Deciphering key control and delivery to MS

The deciphering keys are needed in MS if the LCS Broadcast Data (ciphered parts) is ciphered. The deciphering keys’ control system contains two keys (the Current Deciphering Key and the Next Deciphering Key) and the Ciphering Key Flag (indicating the current Ciphering Key Flag state in the location area in the time that the deciphering key set is delivered from SMLC to MS). Two Deciphering Keys are needed in order to overcome the problem of unsynchronised nature of the periodic location updates that MSs make in the location area. The SMLC controls the keys and there are following requirements related to the deciphering keys:

– Deciphering Key Set (Current and Next Deciphering Key, Ciphering Key Flag) are always location area specific.

– One SMLC controls the deciphering key set changes inside the location area and in case several SMLCs in the location area then one coordinating SMLC for the deciphering key set control must be nominated. The SMLC configuration is done with O&M procedures.

– The coordinating SMLC delivers the new deciphering key set to the other SMLCs with SMLCPP protocol when the deciphering key set changes. The Ciphering Key Flag in the LCS Broadcast Data message is changed only when the coordinating SMLC changes the deciphering key set and delivers the new set to other SMLCs in the same location area.

– The SMLCs upon receiving the new deciphering key set, start using immediately the new set in the LCS Broadcast Data message. The coordinating SMLC also starts using the new set same time.

The deciphering key set changes always following way when the new set is generated:

– The Next Deciphering Key comes to the Current Deciphering Key in the new set.

– One new key is taken into use and named as the Next Deciphering Key.

– The Ciphering Key Flag changes the state.

The Ciphering Key Flag controls the MS key usage (Current/Next Deciphering Key) as follows:

– After receiving the new deciphering key set, MS starts using the new set immediately.

– The Ciphering Key Flag in the LCS Broadcast Data message and the one received returned to the MS should have same polarity. This means that MS starts using the Current Deciphering Key immediately.

– When the Ciphering Key Flag state changes in the LCS Broadcast Data message then MS starts to use the Next Deciphering Key for deciphering the broadcast message. The Next Deciphering Key becomes now the Current Deciphering Key in MS.

Figure 35 describes the deciphering key delivery mechanism.

Figure 35: Deciphering key delivery

– First the key A is the Current Deciphering Key and key B is the Next Deciphering Key.

– When the SMLC changes to use the key B (Next Deciphering Key) then the Deciphering Key Flag state is changed in the LCS Broadcast Data message. At this point the coordinating SMLC delivers the new deciphering key set to other SMLCs in the same location area as well as to MS when MS is requesting the keys during the location update (IMSI Attach, Normal or Periodic Location Update).

– The new deciphering key set contains now key B as the Current Deciphering Key, key C as new Next Deciphering Key and the Ciphering Key Flag currently in use in that location area.

– When the SMLC changes to use the key C (Next Deciphering Key) then the Ciphering Key Flag state is changed in the LCS Broadcast Data message. At this point the coordinating SMLC delivers the new deciphering key set to other SMLCs in same location area as well as to MS when MS is requesting the new set during the location update (IMSI Attach, Normal or Periodic Location Update).

– The new deciphering key set contains now key C as the Current Deciphering Key, key D as new Next Deciphering Key and the Ciphering Key Flag currently in use in that location area.

The process continues as above when the keys are changed. The lifetime of one key (Current/Next Ciphering Key) is minimum one periodic location update period used in the location area.