10 E-OTD and GPS Positioning Procedures

03.713GPPFunctional descriptionLocation Services (LCS)Release 1999Stage 2TS

10.1 General Procedures

For any location request where the highest priority level is assigned and MS-based GPS positioning is not used, the SMLC shall provide sufficient assistance data to a target MS to enable a location 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 GPS positioning is used, the SMLC may reduce the assistance data provided to a target MS on the first location attempt. For these cases, sections 10.2 and 10.3 indicate what reduced assistance data may be provided.

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

10.2 Positioning for BSS based SMLC

This signaling flow is generic for all MS based or assisted location methods (MS Based E-OTD, MS Assisted E-OTD, GPS and Assisted GPS). If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation and transfer the LCS assistance data more reliably, this procedure may be preceded by an “Assistance Data Delivery from BSS based SMLC” 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 from BSS based SMLC” procedure.

Figure 54: E-OTD/GPS Positioning Flow

1. The SMLC may precede the RRLP MEASURE POSITION REQUEST with an optional Assistance Data Delivery from BSS based SMLC procedure (see 10.4).

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

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

4. The MS performs the requested E-OTD or GPS 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 GPS measurements. In case of E-OTD, any data necessary to perform these operations may be either provided in the RRLP MEASURE POSITION REQUEST or available from broadcast sources. In case of Assisted GPS and first positioning attempt, a minimum set of GPS assistance data may 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 GPS 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 GPS measurements or E-OTD or GPS location 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.

5. BSC forwards the RRLP MEASURE POSITION response to SMLC.

10.3 Positioning for NSS based SMLC

This signaling flow is generic for all MS based or assisted location methods (MS Based E-OTD, MS Assisted E-OTD, GPS and Assisted GPS). If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation and transfer the LCS assistance data more reliably, this procedure may be preceded by an “Assistance Data Delivery from NSS based SMLC” 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 from NSS based SMLC” procedure.

Figure 55: E-OTD/GPS Positioning Flow

1. The SMLC may precede the RRLP MEASURE POSITION REQUEST with an optional Assistance Data Delivery from NSS based SMLC procedure (see 10.5).

2. The SMLC determines possible assistance data and sends RRLP MEASURE POSITION REQUEST to MSC.

3. The MSC forwards the RRLP MEASURE POSITION REQUEST to the BSC.

4. The BSC sends 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 GPS measurements, if needed assistance data is available in 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 an E-OTD or GPS location estimate. In case of E-OTD, any data necessary to perform these operations may be either provided in the RRLP MEASURE POSITOIN REQUEST or available from broadcast sources. In case of Assisted GPS and first positioning attempt, a minimum set of GPS assistance data may 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 GPS 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 GPS measurements or E-OTD or GPS location 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.

6. BSC sends measurement results in the MEASURE POSITION RESPONSE within BSSMAP Connection Oriented Information message to MSC.

7. MSC forwards the measurement results in the MEASURE POSITION RESPONSE within LCS Information Report message to SMLC.

10.4 Assistance Data Delivery from BSS based SMLC

This signaling flow is generic for all MS based location methods (MS Based and Assisted E-OTD and Network Based and Assisted GPS). 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 may be repeated one or 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.

Figure 56: E-OTD or GPS Assistance Data Delivery Flow with BSS based SMLC

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.

10.5 Assistance Data Delivery from NSS based SMLC

This signaling flow is generic for all MS based location methods (MS Based and Assisted E-OTD and Network Based and Assisted GPS). If the SMLC desires to avoid lower layer (e.g. BSSAP-LE) segmentation and transfer the LCS assistance data more reliably, the sequence 1-6 may be repeated one or 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.

Figure 57: E-OTD or GPS Assistance Data Delivery Flow with NSS based SMLC

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

2) The MSC forwards the RRLP ASSISTANCE DATA message to the BSC.

3) The BSC sends the assistance data to the MS in a RRLP ASSISTANCE DATA message.

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

5) The BSC sends the RRLP ASSISTANCE DATA Ack to the MSC.

6) The MSC forwards the RRLP ASSISTANCE DATA Ack to the SMLC.

10.6 Error Handling for E-OTD and GPS

This section describes error handling for positioning and transfer of assistance data for E-OTD and GPS. For a description of error handling involving segmentation, refer to section 7.11.4.

Case 1: When the RRLP request comes to BSC for E-OTD and GPS, 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 either the LCS Client or VMSC).

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 or VMSC if an abort was sent.

Case 4: If an inter-BSC (or inter-MSC) 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 either the LCS Client or VMSC.

10.6.1 NSS based SMLC

Figure 58

10.6.2 BSS based SMLC

Figure 59

10.7 Broadcast OF ASSISTANCE DATA

In MS Based E-OTD, MS Based GPS and MS Assisted GPS systems, there is 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-synchronized network) and Base Transceiver Station (BTS) coordinates. In addition, the broadcast data contains other information simplifying the E-OTD measurements. In GPS the broadcast of differential corrections to the MS increases the location accuracy for MS Based implementations. The broadcast of GPS ephemeris and clock correction data makes available the ephemeris and clock correction data. The broadcast of GPS almanac and other data makes available almanac data, ionospheric delay elements, universal time coordinate (UTC) offset, and other information The later two messages can be used by the MS to increase the sensitivity, enables LMU-independent GPS time dissemination and assists the acquisition of satellite signal for both MS Based and MS Assisted implementations.

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 neighbors 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 neighbor basestation coordinates) may be ciphered.

There are three types of broadcast GPS assistance data. Their corresponding messages share the same message header that contains optional ciphering information for the rest of the message. One type of GPS assistance data to be broadcast is included in DGPS Correction Data message that consists of reference time, reference location, and GPS differential corrections. The amount of data is similar to the E-OTD assistance data, containing the maximum amount of 11 satellites which can be encapsulated into 82 octets message. The message contains, reference time, reference location, and the differential corrections. The second type of GPS assistance data to be broadcast is included in Ephemeris and Clock Correction Data message that consists of GPS ephemeris and clock correction data. The length of this message is 636 bits. The remaining 20 bits are filled with ‘0’ and are reserved for future expansion. The third type of GPS assistance data to be broadcast is included in Almanac and Other Data message that consists of GPS almanac data, ionospheric delay elements, UTC offset, and other information. The length of this message is 651 bits. The remaining 5 bits are filled with ‘0’ and are reserved for future expansion.

The contents of the broadcast message for the E-OTD and GPS assistance data is described in GSM TS 04.35. The support for these broadcast messages is optional for network and MS.

The broadcast channel which is used to broadcast the E-OTD and GPS assistance data make use of the existing basic or extended CBCH and SMSCB DRX service. The LCS broadcast messages ( E-OTD Assistance Data, DGPS Correction Data, GPS Ephemeris and Clock Correction Data, and GPS Almanac and Other Data ) need to be either scheduled, or prioritized over other broadcast messages to avoid any delay.

10.7.1 Point-To-Multipoint Assistance Data Broadcast Flow

This signaling flow is generic for MS Based E-OTD, MS Based GPS and MS Assisted GPS methods. The E-OTD/GPS 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 60: E-OTD/GPS 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 which indicate to which BTS the broadcast message is targeted and what time the broadcast should happen. LCS Broadcast Data message may also contain the SMSCB scheduling information which is broadcasted to MS in order that MS can utilize the SMSCB DRX feature specified in GSM 04.12 specification. SMSCB DRX operation is required in order that MS performance can be optimized.

2. CBC starts message transfer to BSC and BTS according to GSM 03.41.

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

4. BTS starts the message transfer to MS according to GSM 03.41.

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

10.7.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 NW for this purpose. The deciphering keys may be requested by MS during a location update (IMSI Attach, Normal or Periodic Location Update) with the generic DTAP MO-LR Location Services Invoke command. . The Follow-On Procedure operation is used to keep the point-to-point connection between MS and NW open after location update. The deciphering keys are Location Area specific.

The LCS Broadcast Data, when ciphered, will be ciphered according the LCS broadcast message definitions specified in GTS 04.35. The parts that will be ciphered in E-OTD LCS Broadcast Data message are neighbor RTD values, serving and neighbor BTS coordinates. For GPS the data are ciphered except the common message header of the DGPS Correction Data message, the Ephemeris and Clock Correction Data message, and the Almanac and Other Data message. The ciphering operation will be conducted by SMLC. The MS is capable to decipher the broadcast message (ciphered parts) using the cipher key (56 bits) delivered from NW to MS and using the Ciphering Serial Number (16 bits) included in the broadcast message.

10.7.3 Algorithm

The algorithm used for ciphering is the standard 56-bit DES algorithm. The deciphering of broadcast messages is done in the ME. The algorithm will utilize the deciphering keys delivered during location update with MO-LR. 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) requested with MO-LR

– 16-bit Ciphering Serial Number from broadcast message which is denoted here by IV (initialization 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 ciphertext data. First IV is concatenated with 0-bits in order to achieve a 64-bit block I1. This block is then encrypted by the DES algorithm using the key K. Output is a 64-bit block I2. 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 I2 again by the DES algorithm using the key K. Output is a 64-bit block I3. 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 Ij are discarded. Below figure describes the first two mask bit generations and the two ciphered 64-bit blocks.

Figure 61: 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 plaintext data.

10.7.4 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 unsyncronized 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 (valid for both BSS and NSS based LCS architecture) and in case several SMLCs in the location area then one coordinating SMLC for the deciphering key set control must be nominated (valid for BSS based architecture). The SMLC configuration is done with O&M procedures.

– The SMLC in NSS based LCS architecture has same functions as the coordinating SMLC in BSS based LCS architecture except sending the deciphering key set to other SMLCs (this may be supported still if needed). The SMLC in NSS based LCS architecture may support several location areas.

– The coordinating SMLC deliveres 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 MS may request the deciphering key set during the location update (IMSI Attach, Normal or Periodic Location Update) using the follow-on procedure defined in GSM 04.08. MS uses the DTAP MO-LR Location Services Invoke command to request the deciphering key set from the SMLC. The SMLC returns the deciphering key set to MS with DTAP MO-LR Location Services Return Result command. MS starts to use the new set immediately. 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 with MO-LR 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.

The following figure describes the deciphering key delivery mechanism.

Figure 62: Deciphering key delivery in periodic location updates

In above figure:

– 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.