Various embodiments relate generally to positioning technologies for location-based services. More particularly, various embodiments relate to obtaining accurate time information at a terminal.
This section is intended to provide a background or context to various embodiments that are recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Location services based on the location of mobile devices are becoming increasingly widespread. Assistance data for assisted navigation systems, such as global navigation satellite systems (GNSS), have been specified and standardized for cellular systems, e.g., global positioning systems (GPS), European Galileo, and Russian Global Navigation Satellite System (GLONASS). An exemplary GNSS can comprise a network of satellites that broadcasts navigation signals including time and distance data. GNSS receivers pick up these broadcasted navigation signals and calculate a precise global location based thereon. Other examples of GNSS include, but are not limited to, satellite-based augmentation systems (SBAS), local area augmentation systems (LAAS), quasi-zenith satellite systems (QZSS), and hybrid receivers.
The delivery of such assistance data can be built on top of cellular system-specific control plane protocols including, e.g., the radio resource location services protocol (RRLP) for GSM networks, the radio resource control (RRC) protocol of layer 3 in wideband code division multiple access (WCDMA) networks, and IS-801 for Code Division Multiple Access (CDMA) networks, standardized in the 3rd Generation Partnership Project (3GPP) and 3GPP2 standards. In addition, the control plane protocols also support Radio Access Network (RAN)-specific positioning methods. Examples include Enhanced Observed Time Difference (EOTD) in RRLP and Idle Period DownLink—Observed Time Difference Of Arrival (IPDL-OTDOA). It should be noted that assistance data as described herein, can refer to GNSS assistance containing, but not limited to, navigation models, time assistance, reference location, atmosphere models, differential corrections, sensor assistance and acquisition assistance. The assistance data can also include e.g. position information, high-accuracy position information, multi-frequency multi-GNSS measurement data, computationally-generated measurements, sensor measurements, route information and waypoint information.
As described above, assistance data may include, amongst other data, navigation models for the satellites, reference location and reference time. Whether the reference location and time are accurate or not has a major impact on performance and thus, information regarding GNSS time is crucial in solving the GNSS receiver's position. Keeping accurate time in, e.g., an Assisted GNSS (AGNSS) terminal/receiver (where time information is provided as assistance data) requires, for example, either an accurate and expensive oscillator, power-consuming miniature atomic clock, frequent connection to the satellites, or frequent requests of the time assistance from the network. Frequent connections to, e.g., satellites and/or a network, are power-consuming and thus degrade the user experience.
In technical terms, accurate time assistance together with reference position allows for the prediction of a code phase and Doppler frequency search space for spread spectrum satellite broadcasts. Having a small search window improves sensitivity contributing to Time-To-First-Fix (TTFF) and availability. Both aspects are important from the customer-satisfaction point-of-view.
It should be noted that other assistance data, such as ephemerides, have a lifetime of several hours. Therefore, the need to update such information needs is relatively rare. However, with conventional oscillators, time can be kept sufficiently accurate in a terminal on the order of only tens of minutes. Hence, it would be beneficial to be able to maintain an accurate time relation in a terminal by some other system or method.
When a mobile terminal is operating in a network that is synchronized to GNSS time, it can use this information to maintain accurate time even when moving from one cell to another within the same network. However, in networks that may be either synchronous or asynchronous, such as Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN), the terminal does not know about the network's synchronization status and cannot utilize this potential. In certain synchronized networks, such as IS-95/2000 and WiMAX, synchronization is a feature that is defined in the standard. That is, time transfer is an intrinsic feature of, e.g., the IS-95/2000 system, where the 3GPP RRLP and 3GPP RRC define the time assistance for control using cell frame timings. In addition, IS-95 is directly synchronized to GPS time, so accurate GPS time is readily available from every cell, making the maintenance of accurate time in the handsets unnecessary. Hence the information is available to the terminal in the design phase. Moreover, these networks also broadcast the GPS time information.
Open Mobile Alliance secure user plane location (OMA SUPL) protocol does the same in the user plane, where a reference time is given in the form of a difference between the GNSS time and the cell frame timing of the serving base station. In IP-networks, clocks can be synchronized using protocols specifically designed for this purpose. Additionally, certain systems enable AGNSS receiver time assistance over IP/an IP network connection by utilizing different combinations of at least one of the following: a time transfer protocol; a time server; a GNSS-receiver for obtaining the relationships between the time-server's time and the GNSS time scales; a time server synched to a specified GNSS time; a service providing differences between GNSS time scales; and user plane assistance protocols for transferring the relationship(s) from a server to a terminal.
One exemplary embodiment relates to a method of providing network synchronization status to a terminal comprising receiving a transmission from a network. The method further comprises determining a synchronization status of the network from the transmission, where accurate time is maintained based on the synchronization status of the network.
Another exemplary embodiment relates to an apparatus comprising an electronic device. The electronic device is configured to receive a transmission from a network. The electronic device is further configured to determine a synchronization status of the network from the transmission, where accurate time is maintained by the electronic device based on the synchronization status of the network.
These and other advantages and features of various embodiments of the present invention, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein like elements have like numerals throughout the several drawings described below.
Various embodiments are described by referring to the attached drawings, in which:
The availability of assistance data, e.g., time information, described above can greatly affect GNSS receiver performance. For example, in scenarios where good signal conditions exist, approximately 30 seconds are typically needed for a GPS receiver to extract a copy of a navigation message from a signal broadcasted by a satellite. Therefore, if no valid copy (e.g., from a previous session) of a navigation model is available, at least 18 seconds (a theoretical minimum, although 30 seconds is a more typical value) elapse before the satellite can be used in position calculations. With regard to Assisted GPS (AGPS) receivers, a cellular network sends a receiver a copy of a navigation message. Therefore, the receiver need not extract navigation data from the satellite broadcast, but rather can obtain it directly from the network. TTFF can be reduced to 10 seconds or less (as opposed to the 30 seconds required for conventional GPS systems). This reduction in TTFF is crucial in scenarios when, for example, positioning an emergency call is required. Additionally, this reduction in TTFF can improve the user experience in various use cases.
Various embodiments provide a network's synchronization status to a terminal when the terminal receives a transmission from the network in question. This network synchronization status can be indicated utilizing various methods including, but not limited to the following: with a status flag in a (system) message from the network; in a network capability indication; in a network's positioning capability indication; in GNSS time, i.e., cell/network time relation information; in a time relation information of different Radio Access Technologies (RATs); and/or implicitly with another parameter and/or by a request for a certain measurement (e.g., certain assistance data that is only provided in a synchronized network or OTDOA measurement that is only requested in a synchronized network). Additionally, it should be noted that the transmission can be either a broadcast transmission or point-to-point signalling.
For example and with regard to the aforementioned RATs, “pseudo-synchronization” can be achieved between networks. That is, if the terminal obtains network synchronization status information of a first network, e.g., a 3GPP Long-Term Evolution (LTE) network, and consequently, maintains accurate time, this information can be used to “pseudo-synchronize” the LTE network with another network. Hence, a multi-mode receiver that supports, e.g., LTE and Global System for Mobile Communications (GSM) communication standards/technologies, can use the LTE network synchronization status information to indirectly relate the asynchronous GSM cells to an accurate time reference. Therefore, the benefits of a first network's synchronization status information can be extended to one or more other networks.
When the network's synchronization status is determined, accurate time information/time assistance data can be maintained at the terminal. Thus, the terminal, e.g., an AGNSS receiver, can predict the code phases and the Doppler frequencies for spread spectrum satellite broadcasts. That is, the satellite signals in view (i.e., above horizon) and hence, the receiver can find the satellite signals very quickly because of the reduced code and frequency search space. Accurate reference location and time information avoid scenarios such as when the AGNSS receiver may only be able to calculate which satellites are above the horizon and should be searched, where when either the reference location or time is unavailable, the other may become obsolete and the AGNSS receiver is required to do a full-sky search.
Maintaining accurate time in a terminal in accordance with various embodiments results in fewer assistance data requests (i.e., less traffic in the network), as well as improved location experience due to faster location determination, e.g., in cases where a terminal does not need to request additional assistance data from the network. Moreover, sensitivity and therefore availability are improved, if accurate time assistance is available. Additionally and assuming very accurate synchronization, using network-based measurements in hybrid (GNSS+network measurement) positioning becomes possible, where the network-based measurements can be either OTDOA or time-of-arrival (TOA)-type measurements, for example. Further still, savings in a terminal's power consumption can also be realized because the terminal is able to determine the location of a user of the terminal in a substantially shorter time than is conventionally possible.
For exemplification, the system 10 shown in
The exemplary communication devices of the system 10 may include, but are not limited to, an electronic device 12 in the form of a mobile telephone, a combination personal digital assistant (PDA) and mobile telephone 14, a PDA 16, an integrated messaging device (IMD) 18, a desktop computer 20, a notebook computer 22, etc. The communication devices may be stationary or mobile as when carried by an individual who is moving. The communication devices may also be located in a mode of transportation including, but not limited to, an automobile, a truck, a taxi, a bus, a train, a boat, an airplane, a bicycle, a motorcycle, etc. Some or all of the communication devices may send and receive calls and messages and communicate with service providers through a wireless connection 25 to a base station 24. The base station 24 may be connected to a network server 26 that allows communication between the mobile telephone network 11 and the Internet 28. The system 10 may include additional communication devices and communication devices of different types.
The communication devices may communicate using various transmission technologies including, but not limited to, Code Division Multiple Access (CDMA), GSM, Universal Mobile Telecommunications System (UMTS), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol (TCP/IP), Short Messaging Service (SMS), Multimedia Messaging Service (MMS), e-mail, Instant Messaging Service (IMS), Bluetooth, IEEE 802.11, IEEE 802.16, LTE, etc. A communication device involved in implementing various embodiments may communicate using various media including, but not limited to, radio, infrared, laser, cable connection, and the like.
Various embodiments described herein are described in the general context of method steps or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), compact discs (CDs), digital versatile discs (DVD), etc. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.
Various embodiments may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware may reside, for example, on a chipset, a mobile device, a desktop, a laptop or a server. Software and web implementations of various embodiments can be accomplished with standard programming techniques with rule-based logic and other logic to accomplish various database searching steps or processes, correlation steps or processes, comparison steps or processes and decision steps or processes. Various embodiments may also be fully or partially implemented within network elements or modules. It should be noted that the words “component” and “module,” as used herein and in the following claims, is intended to encompass implementations using one or more lines of software code, and/or hardware implementations, and/or equipment for receiving manual inputs.
Individual and specific structures described in the foregoing examples should be understood as constituting representative structure of means for performing specific functions described in the following the claims, although limitations in the claims should not be interpreted as constituting “means plus function” limitations in the event that the term “means” is not used therein. Additionally, the use of the term “step” in the foregoing description should not be used to construe any specific limitation in the claims as constituting a “step plus function” limitation. To the extent that individual references, including issued patents, patent applications, and non-patent publications, are described or otherwise mentioned herein, such references are not intended and should not be interpreted as limiting the scope of the following claims.
The foregoing description of embodiments has been presented for purposes of illustration and description. The foregoing description is not intended to be exhaustive or to limit embodiments to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. The embodiments discussed herein were chosen and described in order to explain the principles and the nature of various embodiments and its practical application to enable one skilled in the art to utilize various embodiments and with various modifications as are suited to the particular use contemplated. The features of the embodiments described herein may be combined in all possible combinations of methods, apparatus, modules, systems, and computer program products.
Number | Name | Date | Kind |
---|---|---|---|
5353332 | Raith et al. | Oct 1994 | A |
5893044 | King et al. | Apr 1999 | A |
6321088 | Dempo | Nov 2001 | B1 |
6321090 | Soliman | Nov 2001 | B1 |
6353412 | Soliman | Mar 2002 | B1 |
6407986 | Dutta | Jun 2002 | B1 |
6424297 | Tamura et al. | Jul 2002 | B2 |
6452541 | Zhao et al. | Sep 2002 | B1 |
6763241 | Gous et al. | Jul 2004 | B2 |
6788249 | Farmer et al. | Sep 2004 | B1 |
7009948 | Carlsson et al. | Mar 2006 | B1 |
7359706 | Zhao | Apr 2008 | B2 |
7579983 | Matsumoto | Aug 2009 | B2 |
7613148 | Hong et al. | Nov 2009 | B2 |
7710944 | Yoon | May 2010 | B1 |
8050296 | Osterling | Nov 2011 | B2 |
8265006 | Ahmadi et al. | Sep 2012 | B2 |
20010009544 | Vanttinen et al. | Jul 2001 | A1 |
20020027993 | Vanttinen | Mar 2002 | A1 |
20020075833 | Dick et al. | Jun 2002 | A1 |
20020089946 | Hutchings | Jul 2002 | A1 |
20020135511 | Zhao et al. | Sep 2002 | A1 |
20020167441 | McBurney et al. | Nov 2002 | A1 |
20020167918 | Brewer | Nov 2002 | A1 |
20030011511 | King et al. | Jan 2003 | A1 |
20030016167 | Dooley et al. | Jan 2003 | A1 |
20030040331 | Zhao | Feb 2003 | A1 |
20030067903 | Jorgensen | Apr 2003 | A1 |
20030096574 | Anderson et al. | May 2003 | A1 |
20030109264 | Syrjarinne et al. | Jun 2003 | A1 |
20030148761 | Gaal | Aug 2003 | A1 |
20040142660 | Churan | Jul 2004 | A1 |
20050003842 | Harju et al. | Jan 2005 | A1 |
20050020282 | Pande et al. | Jan 2005 | A1 |
20050058149 | Howe | Mar 2005 | A1 |
20050080561 | Abraham et al. | Apr 2005 | A1 |
20050175038 | Carlson et al. | Aug 2005 | A1 |
20060003775 | Bull et al. | Jan 2006 | A1 |
20060050660 | Wells | Mar 2006 | A1 |
20060099910 | Anderson et al. | May 2006 | A1 |
20070183486 | Cheng et al. | Aug 2007 | A1 |
20080089269 | Tsutsui | Apr 2008 | A1 |
20080316091 | Wigren et al. | Dec 2008 | A1 |
20090052430 | Gorokhov et al. | Feb 2009 | A1 |
20090290555 | Alpert et al. | Nov 2009 | A1 |
20110103433 | Krasner | May 2011 | A1 |
20130089030 | Yu | Apr 2013 | A1 |
Number | Date | Country |
---|---|---|
101076979 | Nov 2007 | CN |
1784954 | May 2007 | EP |
WO-2008013404 | Jan 2008 | WO |
WO-2008058162 | May 2008 | WO |
WO-2009026557 | Feb 2009 | WO |
Entry |
---|
3GPP TS 25.331 V8.4.0 (Sep. 2008), pp. 425-444. |
3GPP TS 44 031 V8.1.0 (Dec. 2008), pp. 8-17. |
International Search Report for PCT Application No. PCT/IB2009/00773 dated Apr. 30, 2010. |
J. Syrjärinne et al. “Setting a New Standard: Assisting GNSS receivers that use Wireless Networks,” InsideGNSS, vol. 1, No. 7, pp. 26-31, Oct. 2006. |
Number | Date | Country | |
---|---|---|---|
20100156710 A1 | Jun 2010 | US |