JP5078352B2 - Partial almanac collection system - Google Patents

Description

(Cross-reference of related applications)
This application was filed on Aug. 15, 2003, claiming the benefit of US Provisional Patent Application No. 60 / 403,836 entitled “GPS System Interface” filed on Aug. 15, 2002. The name of the invention “Partial Almanac Collection System” filed on September 18, 2003, which is a continuation-in-part of PCT application PCT / US2003 / 025821, entitled “GPS System Interface”. Claims priority based on US patent application Ser. No. 10 / 666,551. Both of these applications are hereby incorporated by reference in their entirety.

(Technical field)
The present invention generally relates to a global positioning system (GPS). In particular, the present invention relates to an almanac collection system for collecting piecewise almanac information from GPS satellites.

(Background technology)
Two-way radio, portable television, personal digital assistant (PDA), cellular phone (also called wireless phone, wireless phone, mobile phone, mobile phone, mobile station), satellite radio receiver, and United States (US) also called NAVSTAR The global use of wireless devices (also referred to as “mobile devices”), such as satellite positioning systems (SATPS) such as the Global Positioning System (GPS), is rapidly advancing. As the number of people using wireless devices increases, these products are integrated into other products, and the number of functions provided by wireless service providers is also increasing.

  Since the beginning of the 1970s, the United States Department of Defense (DoD) Joint Program Office (JPO) founded NAVSTAR, and there have been a number of civilian applications using new GPS related technologies. These new technologies include, for example, personal GPS receivers that allow users to determine their location on the ground, code division multiple access (CDMA), time division multiple access (TDMA), etc. that operate using GPS clock standards, etc. A number of communication networks are included. As a result of these new technologies, the location of mobile devices that can transmit location, especially in an emergency, incorporate location information into the communication device, identify and track the location of travelers, children and the elderly, and ensure the safety of valuable assets. The demand is growing.

  In general, the GPS system is a satellite (also called spacecraft or SV) based navigation system. Examples of GPS include the United States (US) Naval Navigation Satellite System (NNSS) (also called “TRANSIT”), LORAN, Shoran, Decca, TACAN, NAVSTAR, NAVSTAR Russia, known as the Global Navigation Satellite System (GLONASS) Versions and future Western European GPS, etc. proposed in the “Galileo Project” etc. are included, but are not limited to them.

  NAVSTAR GPS (hereinafter simply referred to as “GPS”) was originally developed as a military system to meet the requirements of the US military, but the US Congress subsequently expanded its US defense to promote civilian use of GPS. Directed to the Ministry. As a result, GPS is now a shared system accessible by both US government agencies (such as the US military) and the private sector. The GPS system is described in Hofmann-Wellenhof, Richtenegger and Collins, “Theory and Practice of GPS” 5th edition (revised edition), Springer-Verlag Wien New York, 2001. The entire document is hereby incorporated by reference.

In general, the use of GPS includes identifying the exact location on the earth and synchronizing telecommunication networks such as military communication networks, cellular telephone networks such as CDMA and TDMA type systems.
In addition, US Congressional requests via the US Federal Communications Commission (FCC) for cellular phone networks that can provide cellular phone user locations within 50 feet in an emergency (generally “Extended 911” service or “E911” With the advent of (referred to as ")", GPS is used for both positioning and synchronization in many cellular applications.

  In general, when a group of GPS satellites (also called “GPS satellites”) transmits highly accurate time-coded information, the GPS receiver calculates its position for latitude and longitude on the earth and altitude from the sea level. it can. GPS provides a basic navigation system with accuracy to within about 100 meters for non-military users, higher accuracy for military and other authorized users (if the Selective Availability “SA” setting is on) Designed to be.

  GPS generally includes three major system segments: space, control, and user. The GPS space segment is a group of satellites orbiting the earth, and includes a transmitter for sending highly accurate timing information to a GPS receiver on the earth. Currently implemented GPS satellites include 21 main operational satellites and 3 active standby satellites. These satellites are arranged in six orbits, each orbit containing three or four satellites. Their orbital planes form an angle of 55 ° with the equator. These satellites orbit about 10,898 nautical miles (20,200 kilometers) above the earth, and each satellite has an orbital period of about 12 hours.

  As an example, in NAVSTAR, each orbiting satellite includes four high-precision atomic clocks (two rubidium clocks and two cesium clocks). These atomic clocks provide precise timing pulses that are used to generate unique binary codes (also called pseudo-random “PRN codes” or pseudo-noise “PN codes”) that are transmitted to the Earth. The PRN code identifies a specific satellite in the GPS satellite group. In addition, the satellite transmits a set of digitally encoded information, which includes two types of orbital parameters for determining the satellite's position in the universe, these orbital parameters including almanac data and ephemeris data.・ It is called data.

  Ephemeris data (also called “orbital calendar”) reveals the exact orbit of a satellite. The ephemeris data indicates the location of the satellite at any time, and its position identifies the satellite's ground track as an accurate latitude and longitude measurement. Information in the ephemeris data is encoded and transmitted from the satellite to provide an accurate indication of the satellite's position relative to the earth at any given time. Usually, the current ephemeris data can well determine the position in space up to several meters or tens of meters at the current SA level. The ground control station updates the ephemeris data every hour to ensure accuracy. However, after about 2 hours, the accuracy of the ephemeris data begins to decline.

  Almanac data is a subset of ephemeris data. Almanac data contains less accurate information about the satellite positions of all satellites. Almanac data contains relatively few parameters and generally can determine the location in space well up to several kilometers. Each GPS satellite broadcasts almanac data for all GPS satellites in the GPS satellite group at a period of 12 and a half minutes (12.5 minutes). Therefore, simply tracking one satellite provides almanac data for all other satellites in orbit. Almanac data is updated every few days and is useful for almost several months. Because of its relatively long lifetime, GPS receivers that have been turned off for several hours or more typically use almanac data to determine which GPS satellites are in view. However, both almanac data and ephemeris data are only valid for a limited time. Also, unless these data are updated at appropriate time intervals, the satellite positions based on this information will become increasingly inaccurate as the almanac and ephemeris data ages.

  The ephemeris data includes three sets of data that can be used to determine the position vector and velocity vector of the satellite in the earth reference coordinate system at any moment. These three sets of data are almanac data (as described above), broadcast orbit calendar, and fine orbit calendar. These data differ in accuracy and can be used either in real time or after the fact. Usually, the purpose of almanac data is to provide the user with less accurate data in order to facilitate the satellite search of the receiver and to plan tasks such as view map calculations. Almanac data is updated at least once every six days and broadcast as part of a satellite message. The almanac data in the satellite message basically includes parameters for all satellite orbits and satellite clock correction terms. For GPS almanac data, see “GPS Interface Management Document ICD-GPS-200” for “NAVSTAR GPS Space Segment and Navigation User Interface”, NavTech Seminars & NavTech Book and Software Store, Arlington, Va., February 1995. It is described in. That document is incorporated herein by reference.

  In a typical operation example, when the GPS receiver is turned on for the first time (commonly referred to as “cold start”) or restarted from a long standby state of several hours or more, the GPS receiver scans and uses the GPS spectrum. Capture GPS signals sent from possible GPS satellites. Once the GPS signal is acquired, the GPS receiver downloads GPS almanac data, ephemeris data and clock correction information for the GPS satellites from the acquired GPS satellites. Once the almanac data is downloaded, the GPS receiver scans the GPS spectrum for available (ie, “in sight”) GPS satellites indicated by the almanac data. Ideally, if enough time is given and the environment around the GPS receiver is such that it can capture two to three GPS satellites in another field of view, It receives both distance information and timing information from 3 to 4 satellites and calculates its position on the earth.

  Unfortunately, in many applications, both in time and environmental conditions limit the ability of a GPS receiver to download GPS almanac data, especially in indoor situations and when sky viewing conditions are limited. Time related problems are usually described by initial positioning time (TTFF) values. If the TTFF value is high, the use of the GPS receiver is limited because it takes too much time to determine the initial position.

  As an example, in a wireless or cellular phone application, a cellular phone or personal digital assistant (PDA) integrated with a GPS receiver may require (requires) the GPS receiver to download the GPS almanac before making a call. You must wait at least 12.5 minutes (assuming perfect environmental conditions where you can see all the satellites in sight). This is unacceptable for most applications.

  In cellular telephone applications, this limitation becomes even less acceptable in terms of E911 requests where the cellular telephone needs to send its location information to emergency personnel in an E911 emergency call. When a user encounters an emergency situation when their own GPS-enabled cellular phone is off or in a long-waiting situation, an emergency call is sent that sends the user's location to the emergency personnel (Usually because GPS receivers need a strong signal to reliably capture almanac and ephemeris data) until the satellite's field of view is not continuously interrupted. You must wait for at least 12.5 minutes. In a typical city or in an environment that is blocked by nature, the waiting time is longer than 12.5 minutes because the environmental conditions make it difficult to capture the first satellite. This is of course unacceptable, especially in life-threatening situations.

  Past methods to reduce the amount of time required to download almanac data include certain almanacs (eg factory-installed almanacs) in a memory unit (eg read-only memory “ROM”) in the GPS receiver. -Storing data). In general, this pre-stored almanac data is used to reduce TTFF in cold start conditions.

  In this approach, cold start conditions typically still include relatively long TTFF times due to uncertainties associated with satellite position and pre-stored almanac age. Once the first position is acquired, the GPS receiver downloads updated almanac data from the acquired satellite and updates the ROM (or read access memory “RAM”) for future use. However, this approach still requires the GPS receiver to receive updated almanac data (ie, a “fresh” copy of the almanac data) from the satellite for future acquisition. Receiving updated almanac data also requires a significant amount of time that affects the performance of the GPS receiver.

  Therefore, what is needed is a system that can acquire almanac information in a more efficient manner that overcomes the above problems.

  Depending on these issues, assist GPS receivers by providing assistance data from the communication module (also called “call processor” or “CP”) for purposes such as acquisition, position calculation, sensitivity enhancement, etc. Support techniques have been developed for mobile phones. Some examples of these support techniques include US Pat. No. 6, issued to inventor Krasner on August 13, 2002, entitled “GPS receiver time determination method and apparatus”. US Pat. No. 6,421,002, entitled “GPS receiver using communication link”, granted to inventor Krasner on July 16, 2002, entitled “GPS receiver utilizing communication link”; inventor Moeglein In addition, US Pat. No. 6,411,254, entitled “Satellite Positioning Reference System and Method” granted on June 25, 2002; granted to inventor Krasner on June 4, 2002. No. 6,400,314, named “Invention Sheynblat et al.” On November 6, 2001, entitled “GPS receiver utilizing communication link”. U.S. Patent No. 6,313,786, entitled "Satellite Positioning System (SPS) Signal Measurement Processing Method and Apparatus", which was granted on July 10, 2001 to the inventor Krasner. In addition, US Pat. No. 6,259,399, entitled “GPS receivers and clothes including GPS receivers and methods of using these GPS receivers”, named inventor Moeglein et al. U.S. Patent No. 6,215,441, entitled "Satellite Positioning Reference System and Method", assigned to the inventor, and named inventor Krasner on March 27, 2001. US Pat. No. 6,208,290, “GPS receiver utilizing communication link”; the name of the invention granted on February 6, 2001 to the inventor Krasner et al. US Pat. No. 6,185,427, entitled “Distributed Satellite Positioning System Processing and Applications Network”; inventor Krasner on November 21, 2000, named the invention “Time Determination of GPS Receiver” US Pat. No. 6,150,980, entitled “Method and apparatus”; the title of the invention, granted to inventor Krasner on October 17, 2000, is “Method and apparatus for capturing satellite positioning system signals”. US Pat. No. 6,133,874; assigned to inventor Krasner on May 16, 2000, entitled “GPS receiver utilizing communication link”, US Pat. No. 6,064, No. 336; the name of the invention granted to the inventor Krasner on August 31, 1999, and the name of the invention is “GPS receiver time determination method and device”. No. 5,945,944; US Pat. No. 5,825,327, assigned to inventor Krasner on November 24, 1998, entitled “GPS receiver utilizing communication link”. And US Pat. No. 5, assigned to the inventor Krasner on Oct. 20, 1998, entitled "GPS apparel and clothing including GPS receivers and methods of using these GPS receivers". , 825,327. These documents are incorporated herein by reference. Unfortunately, these support techniques in wireless networks are typically cellular networks (ie, cellular platforms such as TDMA, GSM, CDMA, etc.) and vendor specific, and geolocations located in the cellular network Provided by the server station. As a result, GPS receivers in mobile phones (also referred to as “mobile stations” or “MS”) must generally be compatible with cellular network geolocation server stations.

  However, many network assistance systems are not yet implemented, and even when implemented, they incorporate geolocation server stations that utilize geolocation server station protocols that are not compatible with each other. Therefore, there is a need for a system that allows a GPS receiver that can operate with a number of geolocation server stations independent of the geolocation server station protocol.

(Summary)
A partial almanac collection system is disclosed. The partial almanac collection system includes a global positioning system (GPS) module and a control unit that performs signal communication with the GPS module and the call processing unit, and the control unit responds to a request from the call processing unit. Instruct the GPS module to collect piecewise almanac data.

  In operation, the partial almanac collection system collects the piecewise GPS almanac by receiving a GPS almanac download request from the call processor, and receives the GPS almanac accordingly in the piecewise process. The piecewise process includes receiving a plurality of subsets of GPS almanac and storing the plurality of subsets of GPS almanac in a memory device. In addition, the piecewise process further includes identifying when the last subset of the GPS almanac subsets is received and combining all subsets of the GPS almanac subsets to generate a complete GPS almanac. The process to do is included.

  Other systems, methods, features and advantages of the present invention will be or will be apparent to those of ordinary skill in the art upon reviewing the accompanying drawings and the following detailed description. Such additional systems, methods, features, and advantages are included in the description herein, are within the scope of the invention, and are intended to be protected by the appended claims.

  First, refer to FIG. In FIG. 1, a diagram 100 of an example of a known global positioning system (GPS) is shown. In operation, the GPS receiver 102 located on the earth 104 is designed to simultaneously detect signals 106, 108, 110 and 112 from multiple GPS satellites 114, 116, 118 and 120. The GPS receiver 102 decodes the information and calculates the position of the GPS receiver 102 on the earth 104 using time and ephemeris data. The GPS receiver 102 typically includes a floating point processor (not shown) that performs the necessary calculations and can output a decimal or graphical display of latitude, longitude, and altitude on the display 122. In general, signals 106, 108 and 110 from at least three satellites 114, 116 and 118 are required for latitude and longitude information. A fourth satellite signal 112 from satellite 120 is needed to calculate altitude.

  FIG. 2 shows a diagram 200 of various known applications of GPS. In FIG. 2, a number of example devices 202, 204, 206, 208 that receive and utilize GPS signals 214, 216, 218, 220, 222, and 224 from a GPS satellite group 226 (individual satellites are not shown). 210 and 212 are shown. Examples of devices include a portable GPS receiver 202, an in-vehicle GPS receiver 204, a cellular phone integrated GPS receiver 206, a personal digital assistant (PDA) integrated GPS receiver 208, a portable computer (generally (Such as a “laptop” or “notebook” computer)) an integrated GPS receiver 210, a computer (non-portable) integrated GPS receiver 212, or any other type that can also incorporate a GPS receiver Device included.

  As will be apparent to those skilled in the art, in the past, GPS receivers have generally been stand-alone devices that receive GPS signals from GPS satellites 226 without assistance from external sources. However, due to the U.S. Congress's E911 requirements and the constant development of wireless communications in both cellular and non-cellular networks, to meet E911 requirements and / or for assistance assisted by the network, More communication devices are beginning to integrate GPS receivers inside.

  These new integrated communication devices communicate with the cellular telephone communication network via a connection node such as the base station tower 228 or communicate with the non-cellular communication network via a non-cellular connection point 230. Can do. The cellular communication network may be a TDMA, CDMA, GSM (registered trademark), W-CDMA (registered trademark), CDMA2000, UMTS, 3G (registered trademark), GPRS or AMPS type cellular network. Non-cellular communication networks include Bluetooth, a wireless fidelity (Wi-Fi®) network based on IEEE 802.11, or other similar wireless network. As an example, a portable GPS receiver 202, an in-vehicle GPS receiver 204, a cellular phone integrated GPS receiver 206, a PDA 208, and a portable computer 210 are connected to signal paths 232, 234, 236, 238 and 240, respectively. Can communicate with the cellular base station 228. Similarly, portable GPS receiver 202, PDA 208, and portable computer 210 can be in signal communication with non-cellular connection point 230 via signal paths 242, 246 and 244.

  As an example of an integrated GPS receiver in a non-wireless communication environment, the non-portable computer 212 is integrated on a motherboard, via a peripheral device added inside, or as a peripheral device connected to the outside. GPS receivers (not shown) may be included. In this example, an integrated GPS receiver (not shown) can receive assistance from network server 248 via network 250 and modem 252. The network 250 may be a known general telephone service (POTS), Ethernet, the Internet, or other similar network. Of course, other devices connected to POTS, Ethernet and the Internet, such as vending machines, office equipment and office equipment, or other critical equipment, are used in the same manner as the non-portable computer 212. You can also.

  FIG. 3 shows a known wireless mobile positioning system architecture 300 with network assistance that receives GPS data from GPS satellites 226 via signal paths 302, 304. Architecture 300 includes mobile device 306, base station 308, wireless network communication infrastructure 310, geolocation server station 312, GPS reference receiver 314 and optionally end user 316. The GPS reference receiver 314 receives GPS signals from the GPS satellite group 226 via the signal path 302. The mobile device 306 receives a GPS signal from the GPS satellite group 226 via the signal path 304 and performs signal communication with the base station 308 via the signal path 318. In general, the mobile device 306 includes a call processing unit 320 and a GPS module 322. Both the call processing unit 320 and the GPS module 322 perform signal communication via the signal path 324. As will be apparent to those skilled in the art, the call processing unit 320 and the GPS module 322 may be respective functional units mounted on separate semiconductor chips or a common semiconductor chip or die.

  In general, in the architecture 300 shown in FIG. 3, the GPS module 322 needs to use the same protocol used by the geolocation server station 312 to receive any GPS assistance information from the geolocation server station 312. is there.

  FIG. 4 shows an implementation example of the mobile device 400 including the call processing unit 402 that performs signal communication with the GPS module 404 via the signal path 406. The mobile device 400 may be any of the device examples 202, 204, 206, 208, 210, and 212 shown in FIG. The call processing unit 402 performs signal communication with the base station 308 via the signal path 318, and the GPS module 404 receives GPS data from the GPS satellite group 226 via the signal path 304. Here, as a matter of course, the call processing unit 402 and the GPS module 404 may be respective functional units mounted on separate semiconductor chips or one common semiconductor chip or die. As an example, if the call processor 402 and the GPS module 404 are physically separate devices, the signal path 406 can be implemented using an RS232 data link.

  In normal operation, the mobile device 400 receives the GPS signal 304 from the GPS satellite group 226 of FIG. 3 and the communication infrastructure 310 of the cellular telephone communication network via the base station tower 308 of FIG. A communication signal 318 is received using a non-cellular communication network (not shown) over the network.

  4 performs one-way or two-way communication with an external communication network such as the communication base 310 of the cellular telephone communication network of FIG. 3 or a non-cellular wireless network or a non-wireless network (not shown). Any possible communication device may be used. Call processor 402 includes dedicated hardware (not shown) and software (not shown) for establishing and managing telecommunications connections.

  Examples of cellular telephone type call processor 402 include Motorola, Inc. of Schaumburg, Illinois. Cellular Phone Call Processing Integrated Dispatch Extension Network (iDEN®), Nokia, Finland, Sony Ericsson, Sweden, Qualcomm, Inc., San Diego, California. Or any similar type of GSM / CDMA / TDMA / UMTS type communication device capable of communicating with a GPS receiver in the GPS module 308. Examples of non-cellular telephone-type communication devices are capable of communicating with SX45 GPS accessories from Siemens SA, Germany, wireless fidelity (Wi-Fi) networks based on Bluetooth and IEEE 802.11, or other similar wireless networks Any communication device is included. The GPS module 404 can include any GPS receiver that can communicate with the call processor 402.

  In FIG. 5, an embodiment of a protocol independent wireless mobile positioning system architecture 500 is shown. In FIG. 5, the architecture 500 includes a mobile device 506, a base station 508, a wireless network communication infrastructure 510, a geolocation server station 512, a GPS reference receiver 514, and optionally an end user 516. Mobile device 506 and GPS reference receiver 514 receive GPS signals from GPS satellite group 226 via signal paths 504 and 502, respectively.

  The mobile device 506 includes a call processing unit 520, a GPS module 522, and a protocol independent interface (referred to herein as “PI2”) 524. The call processing unit 520 and the GPS module 522 may be functional units mounted on separate semiconductor chips or one common semiconductor chip or die. PI2 524 is an interface that allows the GPS module 522 to receive assistance data from the geolocation server station 512 without using the same protocol that the GPS module 522 uses. Thus, PI2 524 eliminates the need for GPS module 522 to individually implement multiple protocols for various geolocation server stations. The PI2 524 may be an RS232 link, a logical interface through a software data structure memory sharing, or other type of electrical and / or logical interface.

  In operation, each geolocation protocol can be implemented via a converter in PI2 524. The converter converts the geolocation server station 512 protocol into an independent protocol used by the GPS module 522. By changing the manner in which the mobile device 506 receives assistance data and the method of sending location or other geolocation results from the call processor 520 to the geolocation server station 512, the mobile device 506 may change from one wireless communication standard to another. Even when handing off to a standard, geolocation information can be used seamlessly. As a result, all the unique geolocation protocols (IS-817, IS-801, etc.) of various radio interfaces used in various regions around the world can be used without reconfiguring or reconfiguring the GPS module 522. It is served by the GPS device 506. This is because the PI2 524 can convert the GPS information from the geo-location server station 512 of the communication system applied by the user (not shown) of the mobile device 506 into a protocol used by the GPS module 522. Examples of PI2 524 include SiRF Technology, Inc. of San Jose, California. Assisted Independent Interoperability Interface (AI3) developed and owned by

  As will be apparent to those skilled in the art, there are various geolocation standards developed for various types of wireless networks. As an example, the interface 526 between the base station 508 and the communication infrastructure 510 may be an arbitrary radio wave interface. Normally, interface 526 is managed by the manufacturer of call processor 520. Typically, PI2 524 includes two interfaces commonly referred to as an “F” interface (not shown) and a “G” interface (not shown).

  The F interface, which is the client system interface between the GPS module 522 and the call processor 520, functions as an always present bootstrap protocol, and how the call processor 520 runs in the support encapsulation layer at runtime. Allows selection of whether to send assistance to the GPS module 522. The call processing unit 520 can select a certain radio wave interface (such as the interface 526 in the case of an end-to-end system architecture) or a G interface. The F interface performs the following tasks: hardware management (power on / off, reset) of the GPS module 522 from the call processor 520; if available, an implicit support interface, ie call processing Transmission of time and frequency from the network (or from the real time clock of the call processing unit 520) and the approximate location of the mobile device 506 (if present, normally not visible to the network) via the unit 520 Opening / closing a session (ie, notifying the GPS module 522 that the radio interface connection has been opened / closed); notifying the GPS module 522 which radio interface is on in the dual mode mobile device 506, and accordingly , Geolocation radio interface protocol throat Set the notification to one of the GPS module 522 used in the interaction with SLS.

  Unlike the F interface, the G interface is used to send GPS assistance information received from the base station 508 to the GPS module 522. Since there are generally many geolocation protocols, the G interface is designed to be available for a wide range of geolocation standards and independent of the radio interface. That is, it is specific to the applicable radio interface. PI2 524 can be implemented as removing applicable geolocation standards.

  During operation, the call processing unit 520 sends location request information and network support information in the PI2 format to the GPS module 522 via the G interface. In response, the GPS module 522 sends a location result or error notification to the call processing unit 520 via the same interface. Of course, all geolocation protocols including SAMPS, GSM, and CDMA function under an interaction paradigm. Base station 508 sends back only what mobile device 506 has requested. In general, the strategy for performing the interaction is highly dependent on the knowledge of the processing of the GPS module 522.

  Furthermore, unlike the stack level of many protocols, the geolocation protocol is an application protocol, which means it handles message semantics. Thus, they do not simply move data from one side to the other without error correction and exchange and removal of iterations, as in a TCP-IP stack. Also, any entity that handles the protocol (eg, determines some data requirements) knows what the data is used for, and the meaning of all parameters exchanged on the protocol. (I.e., need to know what is happening on the GPS side). Also, those who implement the geolocation protocol should be “familiar” with GPS.

  Thus, PI2 524 utilizes a radio interface finite state machine (FSM) (not shown). In general, this gives the state currently held by the FSM by the current knowledge of the contents of the GPS memory (not shown), in order to complete the somewhat incomplete GPS information embedded in the FSM itself. Is decided to send.

  FIG. 6 also shows a typical block diagram of an IS-801 based CDMA mobile device 600 that utilizes FSM. The mobile device 600 includes a call processing unit 602 and a GPS module 604. The call processing unit 602 includes a radio wave interface CP module 606, a radio wave interface protocol to GPS module interface converter 608, a GPS module data structure 610, a GPS module radio wave interface assembler / disassembler 612, and a GPS module / CP system. Includes a message protocol assembler / disassembler 614 and a GPS module interface module 616. The GPS module 604 includes a CP interface module 618, a PI2 interface module 620, a PI2 data structure 622, a CP system interface FSM 624, and a GPS core 626. The GPS core 626 receives a GPS signal from the GPS satellite group 226 via the signal path 632, and the radio wave interface CP module 606 performs signal communication with a base station (not shown) via the signal path 630.

  Referring to FIG. 7, FIG. 7 shows an RRLP-based handset (ie, GSM-based cellular telephone) mobile device 700 that utilizes FSM in a CDMA environment. The mobile device 700 includes a call processing unit 702 that performs signal communication via a signal path 706 and a GPS module 704. The call processing unit 702 includes a radio wave interface CP module 708, a radio wave interface protocol to GPS module interface converter 710, a GPS module PI2 data structure 712, a PI2 interface message assembler / disassembler 714, a CP / GPS module, A system message protocol assembler / disassembler 716 and a GPS module interface module 718 are included. The GPS module 704 includes a CP interface module 720, a PI2 interface module 722, a PI2 data structure 724, a CP system interface FSM 726, and a GPS core 728. The GPS core 728 receives a GPS signal from the GPS satellite group 226 via the signal path 732, and the radio wave interface CP module 708 performs signal communication with a base station (not shown) via the signal path 730.

  FIG. 8 shows an example of an RRLP to PI 2 message flow diagram 800 between the geolocation server station 802, the call processor 804 and the GPS module 806. FIG. 8 illustrates the above process.

  FIG. 9 shows an example of a flow diagram 900 of a PI2 message between the call processor 902, the GPS module 904 and the base station (BS) 906. The call processing unit 902 includes a base station interface handler 908, a PI2 converter 910, an F interface handler 912, and a G interface handler 914. FIG. 9 illustrates the above process.

  FIG. 10 shows an example implementation of a communication GPS integrated system 1000 similar to any of the example devices 202, 204, 206, 208, 210 and 212 shown in FIG. The communication GPS integrated system 1000 may be a GPS signal 1002 of FIG. 10 from the GPS satellite group 226 of FIG. 2 and a cellular telephone communication network (not shown) via the base station tower 228 of FIG. A non-cellular communication network (not shown) via point 230 is used to receive communication signal 1004 of FIG. The communication GPS integrated system 1000 includes a communication module 1006 (call processing unit “CP” or the like), a GPS core 1007 in the GPS module 1008 that performs signal communication with the call processing unit 1006, and a partial almanac collection system (PACS) 1010. Can be included.

  The call processing unit 1006 is an arbitrary communication capable of one-way or two-way communication with an external communication network such as a cellular telephone communication network (not shown) or a non-cellular wireless network or a non-wireless network (not shown). It may be a device. Examples of cellular telephone type communication module 1006 include Motorola, Inc. of Schaumburg, Illinois. Cellular Phone Call Processing Integrated Dispatch Extended Network (iDEN), Nokia, Finland, Sony Ericsson, Sweden, Qualcomm, Inc., San Diego, California. Or any similar kind of GSM / CDMA / TDMA / UMTS type communication device capable of communicating with the GPS module 1008. Examples of non-cellular telephone-type communication devices are capable of communicating with SX45 GPS accessories from Siemens SA, Germany, wireless fidelity (Wi-Fi) networks based on Bluetooth and IEEE 802.11, or other similar wireless networks Any communication device is included. The GPS module 1008 can include any GPS receiver that can communicate with the communication module 1006. The GPS core 1007 is a general GPS function block in the GPS receiver, receives a GPS signal from the GPS satellite group 226, and extracts GPS data from the received GPS signal.

  The PACS 1010 includes a control unit 1012, a memory device 1014 such as a nonvolatile memory and / or storage device for storing data, an interface 1018 (such as the above-described PI2 interface), and a control unit 1012, a memory device 1014, an interface 1018, a call A PACS communication bus 1016 that performs signal communication with the processing unit 1006 and the GPS module 1008 can be included. The PACS 1010 may be integrated in the call processing unit 1006 or the GPS module 1008 (for example, integrated on the same integrated circuit semiconductor substrate), or may be a separate external device in the communication GPS integrated system 1000. Good. PACS 1010 may also be a separate external device external to communication GPS integrated system 1000, such as an external add-on card or device. Further, the PACS 1010 may be integrated on a single integrated circuit semiconductor substrate including the call processing unit 1006, the GPS module 1008, and the PACS 1010.

  The control unit 1012 can collect and collect the almanac data by the processor (not shown) of the call processing unit 1006, the processor (not shown) of the GPS module 1008, or the GPS module 1008. It may be an arbitrary processor type control unit including an external processor that can control how data is passed to the call processing unit 1006. The controller 1012 may be a microprocessor, a digital signal processor (DSP), or an application specific integrated circuit (ASIC). In the case of a microprocessor or DSP, the operation of the control unit 1012 can be controlled using software (not shown). This software can be a control unit 1012, a call processing unit 1006, a GPS module 1008, or a removable memory disk (such as a flexible disk, CDROM, DVD or other similar type media) or card (memory stick, compact -It may be provided in a removable memory (not shown), such as a flash (R), xD (R), smart media or other similar media.

  As an example of operation, the PACS 1010 allows the GPS module 1008 to receive a partial (ie, piecewise or fragmented) almanac from the GPS satellite group 226. In this case, the communication GPS integrated system 1000 does not need to wait for a long time while maintaining a continuous and uninterrupted satellite view of the GPS module 1008 in order to download all almanac data of the almanac data.

  The PACS 1010 allows the GPS module 1008 to receive almanac data and provide that information to the PACS 1010 when individual satellite information becomes available. The PACS 1010 can receive information such as the almanac week and time of arrival (TOA) from the GPS module 1008, and can associate the almanac week and TOA with each satellite's datum provided by the GPS module 1008. The PACS 1010 then edits the satellite information received from the GPS module 1008 and tracks the freshness of each satellite in the almanac. As a result, the PACS 1010 can operate with an almanac having a mix of multiple satellites with different almanac week and TOA information.

  In general, the control unit 1012 of the PACS 1010 can start and end an almanac download session with the GPS module 1008 via the PACS communication bus 1016. Also, the control unit 1012 of the PACS 1010 can determine whether sufficient satellite information has been received from the GPS module 1008 to maintain tracking of the status of each satellite in the almanac. Thereafter, the control unit 1012 stores the almanac in the nonvolatile memory 1014 of the PACS 1010 via the PACS communication bus 1016 for future use. The PACS 1010 can also pass almanac data to the call processor 1006 and / or the GPS module 1008 via the PACS communication bus 1016.

  In general, the PACS 1010 can operate in two ways. The first method is called polling processing (that is, polling method). When the PACS 1010 is a separate device from the call processing unit 1006, if a piecewise download request is received from the call processing unit 1006, if possible , PACS 1010 requests a piecewise almanac download from GPS module 1008. The PACS 1010 either receives the almanac completely (indicated by the receive all almanac flag) or until the PACS 1010 decides to close the session with the GPS module 1008 before the complete download of almanac data is complete. The GPS module 1008 continues to send periodic requests to gather the status of The PACS 1010 can also close the session with the GPS module 1008 before a full download of almanac data for a variety of reasons. The reason for this is when the power is turned off (that is, when the user turns off the communication GPS integrated device 1000), when considering power saving, or when all the almanac has already been received for the call processing unit 1006. Or when the call processing unit 1006 requests the session to be closed to execute a call or execute another function that competes with the open session with the GPS module 1010.

  The second method is called a non-polling method. When the PACS 1010 receives a request from the call processing unit 1006, the PACS 1010 again requests the GPS module 1008 to download a piecewise almanac, if possible. However, in this case, the control unit 1012 determines how the GPS module 1008 responds to a request from the call processing unit 1006. If the GPS module 1008 receives sufficient time to complete the collection of all almanacs, the PACS 1010 responds to the call processor 1006 that all the almanacs have been downloaded as if they were stored in the memory 1014. To do. If the PACS 1010 decides to close the session with the GPS module 1008 for any reason before the GPS module 1008 can download the full almanac, the PACS 1010 responds to the call processor 1006 that the partial almanac has been downloaded. To do. If the environmental conditions change while the GPS module 1008 is collecting almanac data and the GPS module 1008 can download only the partial almanac, the PACS 1010 responds to the call processor 1006 that the partial almanac has been downloaded. . Further, when the PACS 1010 determines that the GPS module 1008 cannot collect the almanac information within the time limit given by the call processing unit 1006, the PACS 1010 responds to the call processing unit 1006 that no almanac data could be collected. To do.

  Referring now to FIG. 11, a flow diagram 1100 illustrates an example of a PACS operating method in polling and non-polling processing. In a typical polling process, processing begins at step 1102 and continues from decision step 1104 to step 1106. In step 1106, the call processor opens a session with the PACS, and then in step 1108, the call processor determines that the PACS downloads the piecewise almanac from the satellite (also called “spacecraft” or “SV”). Request. In response, at step 1110, the PACS downloads the piecewise almanac. Thereafter, the call processor polls the PACS to see if all almanacs have been downloaded. If all almanacs have been downloaded at decision step 1112, processing continues at step 1114 where the PACS returns the status of all almanacs to the call processor. Thereafter, in step 116, the call processing unit closes the session with the PACS, and the processing ends in step 1118.

  Alternatively, if the entire almanac has not been downloaded, processing continues from decision step 1112 to decision step 1120. If the call processing unit closes the session with the PACS at decision step 1120, the process ends at step 1118.

  However, if the call processor has not closed the session with the PACS, processing continues from decision step 1120 to step 1122. In step 1122, the PACS returns the satellite almanac status collected in response to the polling request of the call processing unit to the call processing unit. Thereafter, processing continues at step 1124, where the call processor periodically polls the PACS to collect piecewise almanacs. In step 1110, the PACS responds by downloading a piecewise almanac for each poll, and processing continues to steps 1112, 1120, 1122, until the entire almanac is downloaded or the call processor closes the session. 1124 and 1110 are repeated. In this case, the process ends via steps 1114, 1116 and 1118, or steps 1120 and 1118.

  In a typical non-polling process, the process similarly begins at step 1102 and continues from decision step 1104 to step 1126. In step 1126, the call processor opens a session with the PACS, and in step 1128, the call processor requests that the PACS download the piecewise almanac from the satellite. In step 1130, the PACS downloads the piecewise almanac, and in step 1132, the state of the almanac from which the PACS is collected is returned to the call processing unit. In step 1134, the call processor requests the status of the almanac, and in decision step 1136, the PACS determines whether sufficient time has been received for the PACS to complete the download of all almanacs. Of course, the call processor may make this same decision.

  If the PACS receives enough time to complete the download of the entire almanac, processing continues from decision step 1136 to step 1138. In step 1138, the PACS reports the status of all almanacs to the call processor, and in response, in step 1140, the call processor closes the session with the PACS. Thereafter, at step 1142, the PACS stores the almanac data in memory (ie, storage), and then at step 1144, the PACS sends an acknowledgment to the call processor. Thereafter, the process ends at step 1118.

  If the PACS has not received enough time to complete the download of the entire almanac, processing continues from decision step 1136 to decision step 1146. If, at decision step 1146, the call processor performs a session close operation before the PACS has downloaded the entire almanac, processing continues to step 1148. In step 1148, the PACS reports the partial almanac download status to the call processor, and in step 1140, the call processor closes the session with the PACS accordingly. Thereafter, at step 1142, the PACS stores the almanac data in memory (ie, storage), and then at step 1144, the PACS sends an acknowledgment to the call processor. Thereafter, the process ends at step 1118.

  Alternatively, if the call processor has not performed a session closing operation before the PACS has downloaded the entire almanac, processing continues from decision step 1146 to decision step 1150. If, at decision step 1150, the call processor and / or PACS determines that the signal state has changed so that the PACS will only collect partial almanacs, then at step 1148, the PACS is partially transferred to the call processor. Report the status of the almanac. In response, at step 1140, the call processor closes the session with the PACS. Thereafter, at step 1142, the PACS stores the almanac data in memory (ie, storage), and then at step 1144, the PACS sends an acknowledgment to the call processor. Thereafter, the process ends at step 1118.

  Also, if the call processor and / or PACS determines that the signal state has not changed such that the PACS will only collect partial almanacs, processing continues to decision step 1152. If, at decision step 1152, the call processor and / or PACS determines that the PACS cannot collect all almanacs within a predetermined time defined by the call processor and / or PACS, processing continues to step 1154. In step 1154, the PACS returns a status indicating that the almanac cannot be collected to the call processing unit. In response, at step 1140, the call processor closes the session with the PACS. Thereafter, at step 1142, the PACS stores the almanac data in memory (ie, storage), and then at step 1144, the PACS sends an acknowledgment to the call processor. Thereafter, the process ends at step 1118.

FIG. 12 shows a signal flow diagram 1200 of a typical polling process performed by the PACS 1202. In this exemplary process, the call processing unit 1204 makes a download request for a piecewise almanac to the PACS 1202. The call processor 1204 sends the almanac status to the PACS 1202 until the call processor 1204 receives the download status of all almanacs or until the call processor 1204 decides to close the session before the entire almanac is completed. You will have to make regular requests for gathering.
In general, the process requires the PACS 1202 to request that the call processor 1204 open a session with the PACS 1202 (possibly via the PI2 interface) and collect the download of the piecewise satellite (SV) almanac. Performing periodic polling so that the PACS 1202 collects piecewise almanacs, causing the PACS 1202 to respond to the status of the collected SV almanac each time there is a polling request, and all downloads When completed, a step of causing the call processing unit 1204 to close the session with the PACS 1202 is included. Then, before the session between the PACS 1202 and the call processing unit 1204 is closed, the PACS 1202 stores the almanac data in the memory device 1260 (flash or the like). The PACS 1202 receives an instruction from the call processing unit 1204 to collect the satellite almanac when the signal state exceeds a predetermined level (eg, greater than 28 dB Hertz), and an indicator as to whether the call processing unit 1204 provides some almanac support. You will receive instructions that include operating parameters. However, the instructions are not limited to them.

  As shown in FIG. 12, the call processing unit 1204 sends a session opening request 1206 to the PACS 1202 via an interface 1208 (PI2 interface or the like). The PACS 1202 sends an approval 1210 for the request to open session 1206. Thereafter, the call processing unit 1204 sends a piecewise almanac request 1212 to the PACS 1202. The PACS 1202 then passes a piecewise almanac request 1214 from the interface 1208 to the controller 1216, which passes the request 1218 to the GPS core 1220 in the GPS module (not shown) and approves 1222 to the call processor 1204. Send.

  Thereafter, the GPS core 1220 receives the GPS signal 1224 from the GPS satellite group 1226. The GPS core 1220 extracts the received almanac data from the received GPS signal 1224 and passes the received almanac data 1228 to the control unit 1216. Thereafter, the control unit 1216 determines the pseudo random noise (PRN), the arrival time (TOA), and the week number from the almanac data, and the PRN, TOA, and week number are transmitted from the PACS 1202 to the call processing unit 1204 via 1230 and 1232. Pass the almanac data including. In response, the call processor 1204 makes a periodic request 1234 for the piecewise almanac via a request for an almanac update status. Of course, the GPS core 1220 always receives GPS signals 1224 and 1236 from the GPS satellite group 1226, and the controller 1216 periodically makes requests 1238, 1240 and 1242, and 1244, 1246 and 1248 from the GPS core 1220 to the almanac.・ Receive data.

  The controller 1216 responds with a piecewise almanac data 1250 from the PACS 1202 to the call processor 1204 through 1252 in response to a periodic request for the piecewise almanac from the call processor 1204. The controller 1216 then manages the almanac database and applies any mixed almanac processing. At some point, the call processor 1204 sends a session close request 1254 to the PACS 1202 in response to a status received from the PACS 1202 for all collected almanacs or a status indicating that the PACS cannot collect the almanac. When the call processing unit 1204 sends a session closing request 1254 to the PACS 1202, the session closing request 1256 is passed to the control unit 1216. Thereafter, the control unit 1216 passes the almanac data to the memory device 1260 through 1258. Thereafter, the control unit 1216 sends an approval response to the call processing unit 1204 via 1262 and 1264.

  In a typical non-polling process, the call processing unit makes a request for downloading an almanac to the PACS (for example, downloading a piecewise almanac). The PACS then decides to report the status of the download of the almanac based on the following scenario. (1) If the PACS receives enough time to complete the collection of all almanacs, the PACS reports the status of all almanac downloads. (2) If the call processor closes the session for any reason before the PACS completes the download of the full almanac, the PACS reports the status of the partial almanac download. (3) While the PACS is collecting the almanac, if the signal state changes and only the partial almanac can be collected, the PACS reports the partial almanac download status. (4) If the PACS cannot collect the almanac within a predetermined time such as 5 seconds (generally the signal state is weak), the PACS reports the state that the almanac could not be collected to the call processing unit. Thereafter, before closing the session with the call processor, the PACS stores the almanac data in a memory device (such as a flash) and sends an approval to the call processor.

  As an example, FIG. 13 shows a signal flow diagram 1300 of a typical non-polling process performed by the PACS 1302. In this exemplary process, the call processing unit 1304 initiates a session with the PACS 1302 and requests the PACS 1302 to download an almanac (such as a piecewise almanac download). The PACS 1302 receives an instruction from the call processing unit 1304 to collect satellite almanac when the signal state exceeds a predetermined level (eg, greater than 28 dB Hertz), an index as to whether the call processing unit 1304 provides some almanac support, etc. You will receive instructions that include operating parameters. However, the instructions are not limited to them. Thereafter, the PACS 1302 returns an approval to the request from the call processing unit 1304, starts collecting almanac, and responds to the call processing unit 1304 with an almanac status message. Thereafter, the call processing unit 1304 requests an update state of the almanac from the PACS 1302 via a message request. The PACS 1302 responds to the request from the call processing unit 1304 with a message of the almanac status of the collected almanac data for all satellites. The message includes the almanac PRN, TOA, and almanac week number. The PACS 1302 then manages the almanac database and applies any mixed almanac processing. At some point, the call processor 1304 closes the session with the PACS 1302 by sending a session close request. Thereafter, the PACS 1302 stores the almanac in the memory device 1360 (flash or the like) and sends an approval to the call processing unit 1304.

  As shown in FIG. 13, the call processing unit 1304 sends a session opening request 1306 to the PACS 1302 via the interface 1308 (PI2 interface or the like). The PACS 1302 sends an approval 1310 to the session opening request 1306. Thereafter, the call processing unit 1304 sends an almanac request 1312 to the PACS 1302. Thereafter, the PACS 1302 passes the almanac request 1314 from the interface 1308 to the control unit 1316, and the control unit 1316 passes the request 1318 to the GPS core 1320 in the GPS module (not shown) and sends an approval 1322 to the call processing unit 1304.

  Thereafter, the GPS core 1320 receives the GPS signal 1324 from the GPS satellite group 1326. The GPS core 1320 extracts the received almanac data from the received GPS signal 1324 and passes the received almanac data 1328 to the control unit 1316. Thereafter, the control unit 1316 determines the download state of the almanac, and passes the state of the almanac data from the PACS 1302 to the call processing unit 1304 via 1330 and 1332. In response, the call processor 1304 makes an almanac request 1334. Of course, the GPS core 1320 always receives GPS signals 1324 and 1336 from the GPS satellite group 1326, and the controller 1316 periodically makes requests 1338, 1340 and 1342 and 1344, 1346 and 1348 from the GPS core 1320.・ Receive data.

  The controller 1316 responds to the almanac request 1334 from the call processor 1304 with the piecewise almanac data 1350 from the PACS 1302 to the call processor 1304 through 1352. Thereafter, the controller 1316 manages the almanac database and applies any mixed almanac processing. At some point, the call processor 1304 sends a session close request 1354 to the PACS 1302 in response to a state received from the PACS 1302 for all collected almanacs or a state indicating that the PACS cannot collect the almanac. When the call processing unit 1304 sends a session closing request 1354 to the PACS 1302, the session closing request 1356 is passed to the control unit 1316. Thereafter, the control unit 1316 passes the almanac data to the memory device 1360 through 1358. Thereafter, the control unit 1316 sends an approval response to the call processing unit 1302 via 1362 and 1364.

  FIG. 14 shows a signal flow diagram 1400 of another exemplary non-polling process performed by PACS 1402. In FIG. 14, the PACS 1402 reports the status of partial almanac download as a result of the call processor 1404 closing the session (for some reason) before the PACS 1404 completes the download of the full almanac. In this exemplary process, the call processing unit 1404 starts a session with the PACS 1402 and requests an almanac download (such as a piecewise almanac download) from the PACS 1402. The PACS 1402 receives an instruction from the call processing unit 1404 to collect satellite almanac when the signal state exceeds a predetermined level (eg, greater than 28 dB Hertz), an index as to whether the call processing unit 1404 provides some almanac support, etc. You will receive instructions that include operating parameters. However, the instructions are not limited to them. Thereafter, the PACS 1402 responds to the request of the call processing unit 1404 with an approval, starts collecting almanac, and responds to the call processing unit 1404 with an almanac status message. Thereafter, the call processing unit 1404 requests an update state of the almanac from the PACS 1402 through a message request. The PACS 1402 responds to the request from the call processing unit 1404 for approval, and starts collecting almanac. However, in this example, the call processor 1404 then sends a session close request to the PACS 1402 before the PACS 1402 gets a chance to complete the download of the entire almanac. As a result, the PACS 1402 manages the almanac database, applies any mixed almanac processing, and responds to the call processor 1404 with a message indicating whether the PACS 1402 has collected the partial satellite almanac. The call processor 1404 then requests an almanac update status, and the PACS 1402 responds by reporting the almanac status of the partial almanac data in a field containing the almanac PRN, TOA, and almanac week number. To do. Thereafter, the PACS 1402 stores the almanac in the memory device 1452 (flash or the like) and sends an approval to the call processing unit 1404. At this point, the call processing unit 1404 can determine whether it wants the state of all almanacs or only the partially collected almanacs.

  As shown in FIG. 14, the call processing unit 1404 sends a session opening request 1406 to the PACS 1402 via the interface 1408 (PI2 interface or the like). The PACS 1402 sends an approval 1410 to the session opening request 1406. Thereafter, the call processing unit 1404 sends an almanac request 1412 to the PACS 1402. Thereafter, the PACS 1402 passes the almanac request 1414 from the interface 1408 to the control unit 1416, and the control unit 1416 passes the request 1418 to the GPS core 1420 in the GPS module (not shown) and sends an approval 1420 to the call processing unit 1404.

  Thereafter, the GPS core 1420 receives the GPS signal 1424 from the GPS satellite group 1426. The GPS core 1420 extracts the received almanac data from the received GPS signal 1424 and passes the received almanac data 1428 to the control unit 1416. Of course, the GPS core 1420 always receives GPS signals 1424 and 1430 from the GPS satellite group 1426, the controller 1416 periodically makes requests 1418 and 1432, and receives almanac data from the GPS core 1420 at 1428 and 1434. . In this approach, PACS 1402 collects piecewise almanacs from GPS satellites 1426. When the call processing unit 1404 sends a session closing request 1436 to the PACS 1402, the session closing request 1438 is passed to the control unit 1416. The controller 1416 then manages the almanac database and applies any mixed almanac processing, via the interface 1408, through the 1440 to the call processor 1404 and the PACS 1402 from the GPS satellites 1426 to the satellite partials. A response message 1442 indicating whether or not the almanac has been collected is returned. In response, the call processing unit 1404 requests 1444 the status of the almanac update from the PACS 1402. In response to the request from the call processing unit 1404, the PACS 1402 responds with an almanac status message 1448 of almanac data collected for one satellite (or a plurality of satellites) at 1446. The message includes the almanac PRN, TOA, and almanac week number. Thereafter, the PACS 1402 passes the almanac data to the memory device 1452 at 1450. Thereafter, the control unit 1416 sends an approval response to the call processing unit 1402 via 1454 and 1456.

  FIG. 15 shows a signal flow diagram 1500 of yet another exemplary non-polling process performed by the PACS 1504. In FIG. 15, before the PACS 1502 completes the full almanac download, it reports the status of the partial almanac download as a result of the signal state change. In this exemplary process, the call processor 1504 initiates a session with the PACS 1502 and requests an almanac download (such as a piecewise almanac download) from the PACS 1502. The PACS 1502 receives an instruction from the call processing unit 1504 to collect the satellite almanac when the signal state exceeds a predetermined level (eg, greater than 28 dB Hertz), an index as to whether the call processing unit 1504 provides some almanac support, etc. You will receive instructions that include operating parameters. However, the instructions are not limited to them. The PACS 1502 sends an approval to the call processing unit 1502 and starts collecting almanac. In this example, the signal changes before PACS 1502 collects the entire almanac. Thereafter, the PACS 1502 sends a message to the call processing unit 1504 indicating whether the partial almanac has been collected. In response, the call processor 1504 requests the status of the almanac update, and the PACS 1504 contains the almanac status of the almanac of the partial almanac data in the field containing the almanac PRN, TOA, and almanac week number. Reply status. The PACS 1504 then manages the almanac database and applies any mixed almanac processing. Thereafter, the call processing unit 1502 sends a session closing request. Thereafter, the PACS 1502 stores the almanac in the memory device 1554 (flash or the like) and sends an approval to the call processing unit 1504.

  As shown in FIG. 15, the call processing unit 1504 sends a session opening request 1506 to the PACS 1502 via an interface 1508 (PI2 interface or the like). The PACS 1502 sends an approval 1510 to the request 1506 for opening a session. Thereafter, the call processing unit 1504 sends an almanac request 1512 to the PACS 1502. Thereafter, the PACS 1502 passes the almanac request 1514 from the interface 1508 to the control unit 1516, and the control unit 1516 passes the request 1518 to the GPS core 1520 in the GPS module (not shown) and sends an approval 1522 to the call processing unit 1504.

  Thereafter, the GPS core 1520 receives the GPS signal 1524 from the GPS satellite group 1526. The GPS core 1520 extracts the received almanac data from the received GPS signal 1524 and passes the received almanac data 1528 to the control unit 1516. Of course, the GPS core 1520 always receives GPS signals 1524 and 1530 from the GPS satellite group 1526, the controller 1516 periodically makes requests 1518 and 1532, and 1528 and 1534 receives almanac data from the GPS core 1520. . In this approach, PACS 1502 collects piecewise almanacs from GPS satellites 1526. Thereafter, the PACS 1502 sends response messages 1536 and 1538 to the call processing unit 1504 indicating whether or not the partial almanac has been collected. In response, the call processing unit 1504 requests the update status of the almanac with 1540 and 1542, and the PACS 1502 responds with the status of the almanac with 1544 and 1546. The almanac state includes the almanac state of the partial almanac data in the field including the almanac PRN, TOA, and almanac week number. The PACS 1502 then manages the almanac database and applies any mixed almanac processing. When the call processing unit 1504 sends a session closing request 1548 to the PACS 1502, the session closing request 1550 is passed to the control unit 1516. Thereafter, the PACS 1502 passes the almanac data to the memory device 1554 at 1552. Thereafter, the control unit 1516 sends an approval response to the call processing unit 1504 via 1556 and 1558.

  FIG. 16 shows a signal flow diagram 1600 of yet another exemplary non-polling process performed by the PACS 1604. In FIG. 16, the PACS 1602 reports the status of the partial almanac download as a result of the signal state change before completing the full almanac download. In this exemplary process, call processor 1604 initiates a session with PACS 1602 to request an almanac download (such as a piecewise almanac download) from PACS 1602. The PACS 1602 receives an instruction from the call processing unit 1604 to collect satellite almanac when the signal state exceeds a predetermined level (eg, greater than 28 dB Hertz), an indicator of whether the call processing unit 1604 provides some almanac support, etc. You will receive instructions that include operating parameters. However, the instructions are not limited to them. The PACS 1602 sends an approval to the call processor 1602 and begins collecting almanac in a piecewise manner. In this example, when the PACS 1602 cannot collect the almanac within a predetermined time (such as an environment where the signal is weak), the PACS 1602 sends a message to the call processing unit 1604 that the almanac cannot be collected. The call processor 1604 responds by sending a session close request, and the PACS 1602 signal changes before the PACS 1602 collects all almanacs. In response to this, the PACS 1602 sends an approval response to the call processing unit 1604.

  As shown in FIG. 16, the call processing unit 1604 sends a session opening request 1606 to the PACS 1602 via an interface 1608 (PI2 interface or the like). The PACS 1602 sends an approval 1610 to the session opening request 1606. Thereafter, the call processing unit 1604 sends an almanac request 1612 to the PACS 1602. Thereafter, the PACS 1602 passes an almanac request 1614 from the interface 1608 to the controller 1616, which passes the request 1618 to the GPS core 1620 in the GPS module (not shown) and sends an approval 1622 to the call processor 1604.

  Thereafter, the GPS core 1620 receives the GPS signal 1624 from the GPS satellite group 1626. The GPS core 1620 extracts the received almanac data from the received GPS signal 1624 and passes the received almanac data 1628 to the control unit 1616. Of course, the GPS core 1620 always receives GPS signals 1624 and 1630 from the GPS satellites 1626, and the controller 1616 periodically makes requests 1618 and 1630 and 1628 and 1634 receives almanac data from the GPS core 1620. . In this approach, PACS 1602 attempts to collect piecewise almanacs from GPS satellites 1626.

  If the PACS 1602 cannot collect the almanac within a predetermined time, for example, 5 minutes, the PACS 1602 responds to the call processing unit 1604 with messages 1636 and 1638 indicating that the almanac cannot be collected. In response, the call processing unit 1604 sends a session closing request 1640 to the PACS 1602, and the session closing request 1640 is passed to the control unit 1616 at 1642. Thereafter, the control unit 1616 sends an approval response to the call processing unit 1602 via 1644 and 1646.

  The processing described in FIGS. 11 to 16 can be executed by hardware or software. When the above processing is executed by software, the software is stored in the control unit 1012, the memory device 1014, the call processing unit 1006, the GPS module 1008, or a software memory (not shown) in a removable storage medium. May be. The software in the memory can be implemented in a digital form such as a logic function (ie, a digital circuit or source code, or an analog form such as an analog circuit or an analog source of an analog electrical, audio or video signal) An instruction execution system, apparatus, including a computer-based system, a system including a processor, and the like, which can include an ordered list of executable instructions for implementing "logic" that can also be implemented in Alternatively, it can be selectively embodied in any computer-readable medium (signal-bearing medium) used with a system that can selectively retrieve instructions from the device or instruction execution system, apparatus, or device and execute the instructions. In the context of this specification, a “computer-readable medium” and / or “signal-bearing medium” contains, stores, communicates, communicates, or transmits a program for use with an instruction execution system, apparatus, or device, or Any means that can be transferred. The computer readable medium can be selected, for example but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or transmission media. More specifically, the “non-exhaustive list” of computer-readable media includes an electrical connection (or “electronic” connection) with one or more wires, a portable computer disk (magnetic ), RAM (electronic), read-only memory “ROM” (electronic), erasable programmable read-only memory (EPROM or flash memory) (electronic), optical fiber (optical), and portable compact -Includes disk read only memory "CD-ROM" (optical). Note that a computer-readable medium can be captured electronically, for example, by optically scanning it, and if necessary, edited, interpreted, or otherwise processed in an appropriate manner in the computer memory. It may be a paper or other suitable medium on which the program is printed.

  While various example applications have been described, it will be apparent to those skilled in the art that many more examples and implementations are possible within the scope of the present invention. Accordingly, the invention is not limited except as from the appended claims and their equivalents. The above implementation has been submitted for purposes of illustration and description. It is not exhaustive and does not limit the claimed invention to the precise form disclosed herein. Modifications and variations are available from the above perspective, and modifications and variations may be obtained by implementing the invention. For example, although the above implementation includes software, the present invention can also be implemented as a combination of hardware and software, or just hardware. Note that the implementation may differ between systems. The invention described in the appended claims and their equivalents define the invention.

The components of the drawings are not necessarily to scale, emphasis is used to illustrate the principles of the invention. In the drawings, the same reference numerals indicate corresponding parts in the various drawings.
FIG. 2 is a diagram of a commonly known GPS receiver in operation. 1 is a diagram of an example of a known electronic device integrated with a GPS receiver that communicates with wireless (both cellular and non-cellular) and non-wireless networks. 1 is a block diagram of a known wireless mobile positioning system architecture that receives GPS data from a GPS satellite cluster. FIG. FIG. 2 is a block diagram of an exemplary implementation of a mobile device that includes a call processor that performs signal communication with a GPS module. 1 is a block diagram of an exemplary implementation of a protocol independent interface within a wireless mobile positioning system architecture. FIG. FIG. 6 is a block diagram of an exemplary implementation of the mobile device of FIG. 5 utilizing FSM within a GSM environment. FIG. 6 is a block diagram of an exemplary implementation of the mobile device of FIG. 5 utilizing FSM in a CDMA environment. FIG. 5 shows an example flow diagram of RRLP and protocol independent interface messages between a geolocation server station, a call processor and a GPS module. FIG. 4 shows an example flow diagram of a protocol independent interface message between a call processor, a GPS module and a base station (BS). FIG. 3 is a block diagram of an example implementation of a partial almanac acquisition system (PACS) in signal communication with the GPS satellites and network shown in FIG. It is a flowchart of the example of the process performed by PACS shown in FIG. It is a signal flow figure of the example of the polling process performed by PACS shown in FIG. It is a signal flow figure of the example of the non-polling process performed by PACS shown in FIG. FIG. 11 is a signal flow diagram of another example of non-polling processing executed by the PACS shown in FIG. 10. FIG. 11 is a signal flow diagram of still another example of non-polling processing executed by the PACS shown in FIG. 10. FIG. 11 is a signal flow diagram of still another example of non-polling processing executed by the PACS shown in FIG. 10.

Claims (10)

A method for collecting almanac data from a global positioning system (GPS) using a partial almanac collection system (PACS) comprising:
Receiving a request to download a GPS almanac from a call processor communicating with a communication network different from the GPS;
In response to the request from the call processing unit, causing the PACS to start receiving one or more of a plurality of subsets of the GPS almanac by the GPS module;
Determining at the PACS whether all of the plurality of subsets of the GPS almanac have been received by the GPS module. Storing one or more of the plurality of subsets of the received GPS almanac in a memory device;
When the PACS determines that the GPS module has received all the subsets of the GPS almanac, the stored subsets of the plurality of subsets of the GPS almanac are combined to form a complete The method of claim 1, further comprising generating a GPS almanac. The step of starting the reception comprises:
Following the request to collect GPS almanac, periodically polling the GPS module by the PACS ;
Until the a complete GPS almanac is downloaded PACS determines, by the PACS, including the step of continuing the polling to the GPS module, a method according to claim 1 or 2. A step of whether it can collect a complete GPS almanac, as judged by the PACS within a predetermined time,
The method of claim 1 or 2, further comprising collecting only a partial GPS almanac if the PACS determines that the predetermined time is not sufficient. A partial almanac collection system (PACS) in signal communication with a call processor,
The call processing unit is performing another communication network and signal communication with the Global Positioning System (GPS), the PACS is
A GPS module;
A control unit that performs signal communication with the GPS module and the call processing unit;
The controller directs the GPS module to initiate reception of one or more subsets of GPS almanac data in response to a request from the call processor;
The PACS, wherein the control unit further determines whether all reception of the plurality of subsets of the GPS almanac has been completed by the GPS module. A memory unit for performing signal communication with the GPS module;
The GPS module can perform the steps of processing received GPS signals and receiving the subsets of the GPS almanac;
The controller can implement storing the plurality of subsets of the GPS almanac in the memory unit;
When the control unit determines that reception of all of the plurality of subsets of the GPS almanac has been completed, it combines all stored subsets of the plurality of subsets of the GPS almanac to complete the GPS almanac. 6. The PACS of claim 5, wherein the generating step can be performed. The control unit is
Means for responding to the call processor with the collected GPS almanac status;
Means for periodically polling the GPS module following the request to collect GPS almanac from the call processor ;
Complete until all of GPS almanac is determined to have been downloaded, comprising means for continuing the polling to the GPS module, PACS according to claim 5 or 6. It means for determining whether it is possible to collect a complete GPS almanac within a predetermined time,
The PACS of claim 5 or 6, further comprising means for collecting only a partial GPS almanac if it is determined that the predetermined time is not sufficient. 9. The PACS of any one of claims 6 to 8, further comprising means for reporting the complete GPS almanac status to the call processor.   The program for making a partial almanac collection system (PACS) perform each step of the method of any one of Claim 1 to 4.

Images