DELIVERY OF NON-STANDARDIZED ASSISTANCE DATA IN E-OTD/GNSS HYBRID LOCATION SYSTEMS1 Israel Martin-Escalona, Francisco Barcelo, Josep Paradells Dept. d'Enginyeria Telemàtica, Universitat Politècnica de Catalunya (UPC) c/ Jordi Girona 1-3, Mod. C3, 08034 Barcelona, Spain; e-mail:
[email protected] Abstract - This paper shows the need to transmit extra assistance data in hybrid location systems. The proposal presented here uses the current network protocols in order to deliver these non-standardized assistance data in 2G/2.5G location systems. To this end, a complete analysis of the available protocols and methods of identifying a nonstandard assistance data source is performed. Keywords – LBS assistance data, hybrid location systems, E-OTD/A-GPS. I. INTRODUCTION After a period of high growth, mobile operators are seeing how the telecommunications market is beginning to slow down. Facts such as the delay in the 3G start-up and expensive 3G-network equipment and licenses have made operators look for new and attractive services. This search seems to have concluded with a new set of services called location-based services (LBS). Emergency services, tracing and tracking services, billing depending on position, special offers depending on the location, etc. are some examples of these new LBS. In addition, the knowledge of the Mobile Station (MS) position could enable radio resources to be managed better. In [1] the use of location information in order to increase the capacity of a CDMA network is proposed. In 2G and 3G networks, knowing the MS position enables new handoff strategies based on forecasting the position of the MS and therefore the necessary channels for handoff. These strategies help to minimize the interruption probability and thus increase the quality of service offered by the network. Several location techniques are already well developed, such as Cell Identification (CI), Time Advance information (TA), E-OTD [2, 3, 4, 5], Angle Of Arrival (AOA), OTDOA and Assisted GPS (A-GPS) [5, 6]. However, the requirements of high accuracy and full geographical and population coverage are not achieved by any of the location techniques presented above as standalone, and thus some location services are not available in some specific environments. In order to minimize these limitations, some hybrid solutions are being developed [7, 8, 9]. This paper aims to introduce some issues arisen during the EMILY development, a hybrid E-OTD/A-GPS location system, and to propose solutions in order to overcome them.
II. LOCATION METHODS A. Introduction to location methods Nowadays, there are several methods of calculating the position of mobile stations [2, 3, 4, 5, 6]. However, none of them are able to offer both high availability and high accuracy. Table 1 points out typical coverage and accuracy figures for the most important location-calculation methods. These location techniques can be organized into three main groups. The first is composed of CI and TA, which are network-based location techniques and are always available. However, they are the least accurate. The second group includes GPS techniques, which are the most accurate, and offer high availability in rural and suburban environments but show some problems in indoor scenarios. Finally, the third set consists of Time Difference Of Arrival (TDOA) techniques, which offer high coverage in suburban/urban environments but much less accuracy than GPS-based technology. The need for at least three BS also decreases availability in rural environments. Table 1: Location method capabilities Location Technique CI TA GPS A-GPS E-OTD OTDOA CI CI + TA GPS A-GPS E-OTD OTDOA
Horizontal Vertical Accuracy Accuracy Rural environment 10km – 30km 550m (radial) 20m 25m 3m – 20m 5m – 25m 50m – 400m 90m 30m – 200m 90m Urban environment 100m – 3km 550m (radial) 20m 25m 3m – 20m 5m – 25m 50m – 400m 30m – 200m
Availabilit y 100 % 100 % 95 % 95 % 70 % 70 % 100 % 100 % 70 % 95 % 95 % 95 %
As Table 1 indicates, none of the location methods are able to achieve a high coverage with a high accuracy standalone. Because of this, some hybrid location techniques have been proposed in order to compensate for the
1
This research work has been funded by the European Commission through IST Project EMILY IST-2000-26040 and the Spanish Government through CICYT project TIC2000-1041-C03-01.
0-7803-7589-0/02/$17.00 ©2002 IEEE
PIMRC 2002
drawbacks associated with the use of each stand-alone technique. B. A proposal for E-OTD/A-GPS hybrid system EMILY is a hybrid mobile-based E-OTD/A-GPS solution, which is assisted with network information, such as CI and TA. The combination of all these techniques allows the system to provide location services to any mobile terminal, whether or not it is a specific EMILY-compliant handset with GSM/GPS capabilities. The following points present some location concepts that are necessary for a full understanding of the proposed architecture. • OTD (Observed Time Difference). This is the time difference between the arrivals of two signals. • RTD (Real Time Difference). This is associated with an OTD value, and measures the lack of synchronization between the clocks of two different signal sources at burst emission time. • A-GPS assistance data. These data enable some improvements in GPS systems, such as shorter Time To First Fix (TTFF) and higher accuracy. Depending on the system, this information may include the ephemeris data, the almanac data and/or the differential corrections associated with GPS systems. • Assistance data. This can be the RTDs, the A-GPS assistance data or both. Mainly, there are two approaches for hybridizing location information. The first, and simplest, is to obtain independent position information (x, y, z) from different location techniques. Then, this information is somehow hybridized. The second approach bases its performance on hybridizing measurements instead of positioning values. One of the most innovative factors introduced by EMILY is its hybridization technique, named tight/full [10], which follows the second approach. GPS Satellite
one. However, two new variables have been introduced in the process: the OTDBTS-SAT, which represents the observed time difference between the Base Transceiver Station (BTS), which serves the MS, and the satellite constellation; and the RTDBTS-SAT, which contains the RTD between both elements. It must be noted that an E-OTD stand-alone position calculation needs 3 available BTSs (for 2D location) and AGPS stand-alone position calculation also needs 3 available satellites in order to compute the 2D position. Thus, a combination of both location methods would need at least 3 BTS and 3 satellites to improve accuracy and/or availability. However, the addition of the new above-mentioned variables allows the location calculation to be performed with only 3 elements, either BTS or satellites [10], by hybridizing heterogeneous location measurements. Therefore, the position calculation may be performed with only 2 satellites and 1 BTS or 1 satellite and 2 BTSs, and the geographical and population coverage of the location system is thus greatly increased. III. DELIVERING NEW ASSISTANCE DATA A. Introduction As the previous section presented, the EMILY solution allows the position to be calculated from 3 available signal sources, either BTSs or satellites, with the only requirement of adding new non-standardized assistance data called RTDBTS-SAT. RTDs
LMU
SMLC1
RTDs A-GPS
MS
RTDs Lp interface
SMLC2
GPS Satellite
Figure 2: Assistance data flow Pseudo Ranges RTDBTS-SAT
OTDBTS-SAT
OTD
RTD Base Station
Base Station
Figure 1: EMILY location calculation procedure Figure 1 shows the location calculation procedure in EMILY systems. As the figure illustrates, the EMILY location procedure is very similar to a conventional E-OTD
However, it should be noted that the addition of this assistance information needs the support of the current network protocols, which takes charge of delivering these data from Location Measurement Unit (LMU), where they are calculated, to the MS, where the position is calculated. Figure 2 illustrates the assistance data flow followed in an EMILY location process. Table 2 also enumerates all the protocols involved in the assistance data delivery. Some concepts related to Serving Mobile Location Center (SMLC) element are explained in detail in Table 3. Table 2: Delivering of E-OTD assistance data Protocol LLP [11] SLMCPP [12] RRLP [13]
From LMU SMLC1 SMLC2
To SMLC1 / SMLC2 SMLC1 / SMLC2 MS
Nowadays, all the location protocols presented in Table 2 only allow E-OTD and A-GPS information to be carried; no other sources of assistance data are permitted. This makes necessary to propose an alternative way of sending some non-standardized assistance data using the current versions of the location protocols. Accordingly, EMILY takes advantage of the definition of RTDBTS-SAT. This new variable is, in fact, a conventional RTD but it measures the lack of synchronization between the clock of the reference BTS of an LMU and the common clock of the satellite constellation. Therefore, this RTD could be managed as a conventional RTD as long as the associated SMLC1/SMLC2 knows about the special consideration it has to provide to this singular value. This approach may be extended to any other signal source as long as the E-OTD technique may be emulated, i.e. working in terms of GTD/OTD/RTD [10]. Thus, this architecture becomes a highly-upgradeable hybridization model. Table 3: SMLC Types SMLC Type SMLC1 SMLC2
Meaning This is an SMLC, but not the SMLC that is serving the MS involved in the location process. This is the SMLC that is serving the MS involved in the location process.
Considering satellites (or any other external signal source) as a single BTS involves identifying them in the same way as BTS, i.e. considering them as virtual BTSs. These methods for identifying BTSs depend on each protocol. Table 4 points out the location standards defined by 3GPP that are involved in a 2G/2.5G-location solution, and the BTS identification methods that they allow. Those methods, which may include some different identification information, have been numbered because more than one can be used with the same location protocol. The following paragraphs define each of the identification methods introduced in Table 4. Table 4: BTS identification methods Protocol LLP RRLP SMLCPP
LAC
Identification information CI SINL BSIC BCCH (1) (2) (1) (2) (1)
Location Area Code (LAC) The LAC is an encoding number used in order to refer to a location area. This is a 2-byte code with a range of possible values from 0 to 65535 as [12] indicates. Cell Identifier (CI) The CI is a code that identifies a cell inside a location area. This is a 2-byte code with a range of possible values from 0 to 65535 [12, 13].
System Information Neighbor List (SINL) The SINL is the list of the BTSs that the MS considers as neighbors. This information can be used in order to identify the BTS. Base transceiver Station Identity Code (BSIC) The BSIC is a 6-bit code used in order to identify a base station. The BSIC is transmitted in the BCCH channel. Figure 3 illustrates the encoding of BSIC values. As this figure shows, the BSIC encoding is composed of two different codes. The first one is the Network Color Code (NCC), which takes charge of identifying the mobile network where the MS is located. [14] presents the values recommended by ETSI for this field, depending on the country where the PLMN is located. The second code is the Base transceiver site Color Code (BCC), which is used by the MS in order to identify the neighbor BTS. 6
5
4
3
2
NCC
BCC
3 bits
3 bits
1
Figure 3: BSIC structure Broadcast Common CHannel (BCCH) Identification The BCCH channel of each BTS is identified by means of an Absolute Radio Frequency Channel Number (ARFCN). This information allows us to know the absolute frequency, at which the BCCH is being transmitted. The ARFCN encoding presents a range of values from 0 to 1023 inclusive. [14] contains all the values for this code, which depends on the frequency GSM band that the mobile network is using. Table 5 gathers these ARFCN values and the carrier frequencies for downlink (Fl(n)) and uplink (Fu(n)) associated with them. Table 5: ARFCN depending on the GSM band GSM Band Fl(n) ARFCN P-GSM 900 890 + 0.2*n 1 ≤ n ≤ 124 0 ≤ n ≤ 124 E-GSM 900 890 + 0.2*n 975 ≤ n ≤ 1023 890 + 0.2*(n-1024) 0 ≤ n ≤ 124 R-GSM 900 890 + 0.2*n 955 ≤ n ≤ 1023 890 + 0.2*(n-1024) DCS 1800 1710.2 + 0.2*(n-512) 512 ≤ n ≤ 885 PCS 1900 1850.2 + 0.2*(n-512) 512 ≤ n ≤ 810 259 ≤ n ≤ 293 GSM 450 450.6 + 0.2*(n-259) 306 ≤ n ≤ 340 GSM 480 479 + 0.2*(n-306) GSM 850 824.2 + 0.2*(n-128) 128 ≤ n ≤ 251
Fu(n) Fl(n) + 45 Fl(n) + 45 Fl(n) + 45 Fl(n) + 95 FI(n) + 80 Fl(n) + 10 Fl(n) + 10 Fl(n) + 45
B. Analysis of BTS Identification methods The evaluation of the available methods in order to deliver the special RTD values takes into account the following considerations:
1. 2. 3.
Capacity of identifying BTS without ambiguity. Number of location protocols in which the identification method is available. Impact on already deployed location systems.
The following paragraphs show the advantages and drawbacks of using each identification method. CI The use of CI implies some constraints, which are pointed out in the following points: • Any CI value can be re-used in different location areas. • The range of values used in each location area depends on the network topology. All or none of the values can be used. Therefore, no CI can be reserved in order to identify virtual BTSs (such as a satellite constellation). • This identification method is not present in RRLP. Therefore, the use of CI in already deployed location systems involves reserving some special CI code in all the cells and, possibly, redefining the CI map. Another problem could be the service in a roaming situation, which would mean that all the networks should reserve the same CI code for the special RTDs, or define some way of alerting the MS about the reserved CI value. LAC and CI (LAC+CI) This method of BTS identification is based on the CI approach, which the LAC information is added to. Even with the addition of LAC information, the LAC+CI identification method has the same drawbacks as CI, with the addition of one more: the availability of this identification method is reduced to SMLCPP, as is shown in Table 4. BSIC There are some constraints on the use of only BSIC code in order to identify the source of some non-standardized assistance data. The following points show the main ones: • All the BCC codes can be used. • The NCC values depend on which country the PLMN is in and can be reused among countries. • The roaming service may present the same problems that were commented on the case of CI. SINL and BSIC This approach does not seem to be valid for the transmission of non-standardized assistance data in the form of fictitious RTD, since the real signal sources (satellite constellation in EMILY approach) are not really a BTS and therefore they are not part of SINL. BSIC and BCCH These two values may be used in order to identify completely any non-standardized RTD, such as that
associated with the Global Navigation aeronautical Satellite System (GNSS) constellation in the case of EMILY location system. Table 5 gathers the ARFCN values defined for the GSM system nowadays, in order to indicate the BCCH channel associated with a single BTS. There would be two approaches of performing the identification of a virtual BTS. • Choosing an ARFCN that is forbidden in the GSM band used by the PLMN. • Choosing an ARFCN that is forbidden in all the GSM bands. Table 6 points out all the ARFCN values associated with the GSM carriers that remain free of use, taking into account the data set out in Table 5. Table 6: Free ARFCNs ARFCN 125 ≤ n ≤ 127 252 ≤ n ≤ 258 294 ≤ n ≤ 305 341 ≤ n ≤ 511 886 ≤ n ≤ 954 The first approach, which is to choose an ARFCN that is forbidden in the PLMN, could be used in order to identify virtual BTSs. However, this does not provide a solution for roaming since different network operators could choose different special ARFCN values for this use. Therefore, the method that appears to be a complete solution for identifying virtual BTSs is to choose an ARFCN that is forbidden in all the GSM bands. This value indicates that the RTD belongs to a virtual BTS. The value of the BSIC code may be used in order to specify the type of RTD, which enables 64 different signal sources. However, there is still a drawback in the use of BCCH for the identification of non-standardized assistance data. This is the fact that SMLCPP does not allow RTD to be identified by means of BCCH. Actually, this only becomes a drawback in scenarios in which only some LMUs are able to provide the non-standardized assistance data. For example, the EMILY system could perform with a reduced number of GPS-equipped LMUs. This results in the fact that only some LMUs are able to calculate the RTDBTS-SAT. In this kind of environment, it may be necessary to deliver the special RTD information from an SMLC1 to an SMLC1/SMLC2 (see Figure 2), by means of SMLCPP. However, it must be noted that SMLCPP only allows BTSs to be identified by means of LAC + CI (see Table 4). Therefore, a reserved LAC + CI value should be set up in order to indicate the delivering of new non-standardized RTD measurements, even if it shows up some problems when LBSs are intended to be provided during roaming service.
C. Proposal for the identification method The identification method proposed in this study is set up taking into account the current versions of the location protocols involved in the delivery of E-OTD assistance data, in 2G/2.5G mobile networks. Thus, a BCCH encoding forbidden in all the GSM bands is chosen in order to identify some special assistance information. It must be noted that this singular ARFCN value not only identifies a single non-standard RTD, but can be used to allow the delivery of any other kind of non-standardized RTD. Thus, the EMILY enables the further use of some other signal sources that may be considered as a virtual BTS in the EOTD approach, such as Loran-C [8] or Digital Audio Broadcast (DAB) [9]. The BSIC value would be responsible for identifying the non-standardized signal source. As mentioned in the previous section, in cases in which only some LMUs are able to calculate non-standard RTDs, SMLCPP could be used in order to send this value to the SMLC2. In this kind of scenario, the network operator should reserve a LAC value in order to identify a special value of Absolute Time Difference (ATD)/RTD (in the same way that the reserved BCCH value does), while CI would indicate the type of ATD/RTD which is being transmitted (as the special set of BSIC values already does). Following this approach, external signal sources (such as satellite constellation in the case of EMILY system) may be identified as a virtual BTS and only software changes are required in the SMLCs and MSs in order to handle the nonstandard RTD values.
REFERENCES [1]
[2]
[3] [4]
[5] [6] [7]
[8]
It must be noted that the inclusion of LAC and CI encoding due to the use of SMLCPP protocol, may impose some restrictions when LBSs are provided in roaming service. IV. CONCLUSION This paper presents a strategy for delivering nonstandardized assistance data in hybrid location systems by means of the location protocols defined for 2G/2.5G mobile networks. A complete analysis of all the available methods for identifying different sources of non-standardized data was carried out. As a result of this study, some BSIC+BCCH special values are proposed for identifying location sources other than BTS (e.g. a satellite in EMILY, but any other source in general). In cases in which only some LMUs are able to provide these non-standardized data, the SMLCPP protocol becomes necessary and some LAC+CI special values must be reserved in order to transmit these new data. The use of LAC+CI values may introduce some problems when the location service is provided in roaming.
[9]
[10]
[11] [12]
[13]
ACKNOWLEDGMENT The authors thank their colleagues in the EMILY project for their comments. The EMILY partners are Thales Navigation, Télit, Bouygues Telecom, ERTICO, MOGID and Universidad Politecnica de Cataluña.
[14] [15]
D. J. Y. Lee and W. C. Y. Lee, “Optimize CDMA System Capacity with Location”, in Proc. of IEEE PIMRC 2001, San Diego, USA, pp. 17-21, October 2001. L. L.; Viller, E. and Ludden, B., “GSM standards activity on location”, Proc. of IEE Colloquium on Novel Methods of Location and Tracking of Cellular Mobiles and Their System Applications, pp. 7/1 -7/7, 1999. C. Drane, M. Macnaughtan and C. Scott, “Positioning GSM Telephones”, IEEE Communications Magazine, volume 36, pp. 46-59, April 1998. Silventoinen, M.I.; Rantalainen, T., “Mobile station emergency locating in GSM”, Proc. of IEEE International Conference on Personal Wireless Communications, pp. 232-238, 1996. 3GPP TS 03.71 v8.3.0, “Location Services (LCS)”. M. S. Grewal, L. R. Weill and A. P. Andrews, Global Positioning Systems, Inertial Navigation, and Integration, John Wiley & Sons Inc., 2001. S. Soliman, P. Agashe, I. Fernandez, A. Vayanos, P. Gaal and M. Oljaca, “gpsOneTM: A hybrid position location system”, Proc. of IEEE 6th International Symposium on Spread Spectrum Techniques and Applications, volume 1, pp. 330 – 335, 2000. K. Enge, Frona B. Vicksell and R. V. Goddard, “Combining pseudoranges from GPS and Loran-C for air navigation”, in Proc. of Position Location and Navigation Symposium, 1990. Record. The 1990's - A Decade of Excellence in the Navigation Sciences. IEEE PLANS '90, pp. 36 – 43, 1990. S. Rooney, P. Chippendale, R. Choony, C. Le Roux and B. Honary, “Accurate Vehicular Positioning using a DAB-GSM Hybrid System”, Proc. of IEEE VTC2000, Volume 1, pp. 97-101, Spring 2000. N. Bourdeau, M. Gibeaux, J. Riba and F. Sansone, ”Hybridised GPS and GSM positioning technology for high performance Location Based Services”, Proc. of IST Mobile & Wireless Telecommunications Submit 2002, June 2000. 3GPP TS 04.71 v8.3.0, “Location Services (LCS); Mobile radio interface layer 3 specification”. 3GPP TS 08.31 v8.1.0, “Location Services (LCS); Serving Mobile Location Centre – Serving Mobile Location Centre (SMLC – SMLC); SMLCPP specification”. 3GPP TS 04.31 v8.6.0, “Location Services (LCS); Mobile Station (MS) - Serving Mobile Location Centre (SMLC); Radio Resource LCS Protocol (RRLP)”. 3GPP TS 05.05 v8.11.0, “Radio Transmission and Reception”. Deliverable 8 of EMILY project, “Interface and Protocols Definition Report”.
