TECHNIQUES TO FACILITATE INFORMATION EXCHANGE IN MOBILE COMMERCE
TECHNIQUES TO FACILITATE INFORMATION EXCHANGE IN MOBILE COMMERCE
Dr.Hari Ramakrishna
Professor, Department of CSE,
Chaitanya Bharathi Institute of technology
Gandipet -500 075, Hyderabad,
dr.hariramakrishna@rediffmail.com
K.Ravi
Asst. Professor
Dept. of Informatics
Alluri Institute of Management Sciences
kolipakaravi@yahoo.co.in
K.Anil Kumar
Assoc. Professor
Dept. of Informatics
Alluri Institute of Management Sciences
kak_9920020@yahoo.com
ABSTRACT
Data management issues related to organizing and retrieving information from wireless channels has posed challenges for the database community. In this paper, we discuss data dissemination to mobile clients and present solutions that address the bandwidth and energy limitations resulting from short battery life of the mobile units. We also add a subscription-based data access layer on top of this. Our solutions overall propose a secure and scalable wireless data dissemination architecture. Our broadcast organization and subscription-based access protocols are geared to work hand-in-hand to facilitate a complete content distribution solution via broadcasts.
Keywords: Mobile Information, Exchange, Broadcasting, Secure Data, CBS, VBS
1. INTRODUCTION
As more and more e-commerce applications are brought to the mobile platform, the users have increasingly become reliant on mobile data. Mobile commerce applications cover a wide range from short and multimedia messaging and wireless mail, to downloadable multimedia. Financial services, business-to-business m-commerce, as well as consumer m-commerce are areas that will potentially use mobile data. With the extensive use of location-based services, more data will be available to information providers for relaying to the clients.
All these applications, when deployed, can quickly fill the airwaves and cause service disruption or service quality problems. Therefore, it is important to distinguish the types and priorities of data and design the information exchange protocols accordingly. In the rest of this paper, we will concentrate on “rapidly changing data” that potentially has many users (e.g., stock market data) and present techniques to disseminate the data in an efficient manner.
The challenges of designing and implementing wireless networks are important ones for the telecommunications research community. At the same time, data management issues related to organizing and retrieving information from wireless channels have posed challenges for the database community as well. Some of the software problems, such as data management, transaction management, database recovery, etc., have their origins in distributed database systems. In mobile computing, however, these problems become more difficult to solve, mainly because of the narrow bandwidth of the wireless communication channels, the relatively short active life of the power supplies (battery) of mobile units, and the changing locations of required information due to client mobility. Solutions to such problems should also adequately deal with the requirement of securely accessing data from the wireless channels.
In this paper, we will discuss data dissemination to mobile clients and will first present solutions that address the bandwidth and energy limitations resulting from short battery life of the mobile units. We will then turn our attention to add a subscription-based data access layer on top this. Our solutions overall propose a secure and scalable wireless data dissemination architecture.
This paper is organized as follows. After a brief introduction to the mobile data concept, we first present a general architecture, requirements and trade-offs in designing a data dissemination application. We then present our solutions that provide 1) energy efficient and timely data delivery and access, and 2) subscription-based secure access to wireless data. We provide a brief literature review and outline the significance of our work and future research directions.
2. ARCHITECTURE FOR MOBILE INFORMATION EXCHANGE
In this paper, we present the “broadcasting” paradigm in data dissemination. We first present a mobile architecture and describe the parameters. We then present the two problems that we are addressing in this paper: the broadcasting problem and the subscription-based data access problem.
2.1 MOBILE ARCHITECTURE
A general architecture of a mobile platform was given by Dunham and Helal and is shown in Figure 1. It is a distributed architecture where a number of computers, fixed hosts and base stations, are interconnected through a high speed wired network. Fixed hosts are general purpose computers which are not equipped to manage mobile units but can be configured to do so. Base stations are equipped with wireless interfaces and communicate with mobile units to support data access
Figure 1: A general architecture of a mobile platform
The mobile units are battery-powered portable computers, which move around freely in a restricted area, referred to here as a geographic mobility domain. The size restriction on a unit’s mobility is mainly due to the limited bandwidth of wireless communication channels. To manage the mobility of units, the entire geographic mobility domain is divided into smaller domains called cells. The mobile discipline requires that the movement of mobile units be unrestricted within the geographic mobility domain (inter-cell movement).
The mobile computing platform can be effectively described under the client/server paradigm. Thus, sometimes we refer to a mobile unit as a client and sometimes as a user. The base stations are identified as servers. Each cell is managed by a base station, which contains transmitters and receivers for responding to the information processing needs of clients located in the cell. We assume that the size of a cell is such that the average query response time is much smaller than the time required by the client to traverse it. Therefore, it will seldom occur that a user submits a query and exits the cell before receiving the response.
Clients and servers communicate through wireless channels. The communication link between a client and a server may be modeled as multiple data channels or a single channel. We assume a single channel since the objective is the efficient use of the overall bandwidth. We further assume that this channel consists of both an uplink for moving data from client to server and a downlink for moving data from server to client.
2.2 DATABASE ARCHITECTURE AND ITS CHARACTERISTICS
The data in this application is characterized as rapidly changing users often query servers to remain up-to-date. More specifically, they will often want to query the server for their data item of interest. Typical examples of this type of data are stock, weather, and airline information. We assume the following for fully characterizing our mobile database.
1. The database is updated asynchronously, i.e., by an independent external process. Also, such updates arrive with high frequency, signifying that the database is rapidly changing. Examples of such information are stock, weather, etc.
2. Users are highly mobile and randomly enter and exit from cells. There is a parameter called Residence Latency (RL), which characterizes the average duration of a user’s stay in the cell.
3. User reference behavior is localized; e.g., some stocks are more popular than others.
4. Servers are stateless, i.e., they maintain neither client arrival and departure patterns nor client-specific data request information. We assume a stateless server, because we believe that the cost of maintaining a stateful server in a mobile environment would be prohibitively expensive. We want to emphasize, however, that our scheme will work with stateful servers as well.
3. BROADCASTING PROBLEM
Wireless networks differ from wired networks in many ways. Database users over a wired network remain connected not only to the network, but also to a continuous power source. Thus, response time is the key performance metric. In a wireless network, however, both the response time and the active life of the user’s power source (battery) are important. While a mobile unit is listening or transmitting on the line, it is considered to be in active mode. Assuming a power source of 10 AA batteries and a laptop equipped with CD-ROM and display, estimated battery life in active mode is approximately 2.7 hours.
In order to conserve energy and extend battery life, a clients slips into doze (standby) mode, in which it is not actively listening on the channel. Clients expend significantly less energy in doze mode than in active mode. Therefore, one of the major goals of our scheme is to minimize the amount of time a client must spend in active mode to retrieve the data items it requests.
The problem addressed may be captured by the following question: given that users are highly mobile in their mobility domain, what are good strategies that the server can use to decide on what data to provide? The assumption is that such strategies need to adapt to user demand patterns in the highly mobile environment. We are also interested in the question of retrieval strategies: given that good strategies are found, what are good retrieval algorithms by which users can retrieve/download data from the server, with a minimum of energy expenditure? The basic idea is one of “mixed broadcasting,” i.e., automatic as well as on-demand broadcasting.
We define the following terms: Access Time (AT): Access time refers to the time elapsed between query submission and receipt of the response. Tuning Time (TT): Tuning time is the duration of time that the client spends actively listening on the channel
The meaning of these terms is illustrated in Figure 2. Consider a client who submits a request at time T0 and receives the response at time T7. In this scenario, if the client listens continuously from the time a query is submitted until the response is received, then
AT = TT = T7 – T0. On the other hand, if the client slips into doze mode intermittently, then TT is noticeably less than AT, significantly reducing battery usage. In this case, AT= T7 – T0, and TT = (T7 – T6) + (T5-T4) + (T3-T2) + (T1-T0).
Figure 2: Access and tuning times
This results in energy conservation, as the client is in active mode for only short periods of time. The question, of course, is how to determine the smallest possible tuning intervals. An ideal approach appears to be providing the client with precise knowledge of when its requested information will be broadcast.
Our aim is to find optimal points in the two-dimensional space of AT and TT. This becomes difficult, because there appears to be a trade-off between AT and TT; attempts to reduce one tend to increase the other. For example, access time is directly related to the size of the broadcast, i.e., AT is smaller for a smaller broadcast size. On the other hand, providing information for selective auto-tuning, i.e., informing the user precisely where its required data is located in the broadcast, reduces tuning time. However, inclusion of such tuning information would increase the overall size of the broadcast by including overhead, which in turn could increase AT. Conversely, eliminating this overhead will reduce AT at the expense of an increased TT, because the user will not know precisely when to tune in.
3.1 SUBSCRIPTION-BASED DATA ACCESS PROBLEM
In this paper, we address another critical problem: providing secure access control in broadcast schemes. To get a feel for this problem, consider the classical broadcast environment, where an information server broadcasts to a large number of clients using a shared channel. Each broadcast consists of a number of data objects that clients are interested in. Each client is interested in a certain number of these objects and subscribes to them. Subscription refers to a contract that each client enters into with an agent, which entitles the client to access a data object for a specific period of time. Once the contracted period for a subscription is over, the subscription is considered to have expired and the client cannot access the data object any longer without resubscribing. Therefore, broadcast protocols should provide adequate security and should scale well with the number of clients using the system.
Subscription-based access to broadcasts necessitates the use of encryption techniques in order to let only the legitimate subscribers to access the broadcasts. Therefore, the broadcast protocols should have the ability to distribute encryption keys to clients in an efficient manner. We present protocols that add a security layer on top of the basic broadcasting model discussed earlier. In this system, a server broadcasts data items over a shared communication channel, and clients tune in to the broadcasts to download their subscribed items. We add an access control layer that involves encrypting the data items and then adding smart controls on top of the encryption logic.
To enable the deployment of such applications, the following functionalities are necessary.
1. A client must only be able to access the data items that it is subscribed to. In other words, the access to all items that a client is not subscribed to must be blocked. An intuitively natural way to tackle this problem is by encrypting the data items in some way.
2. A client must only be able to access items as long as its subscription to that item has not expired. This is a non-trivial problem—clearly, in order to be given access to an item, assuming items are encrypted, a client needs to be provided with some sort of decrypting mechanism to retrieve this item. When its subscription expires, however, the client is still left with the decrypting mechanism, which compromises security. One obvious way of course is to change the security mechanism of a data item every time a subscription expires to that item. This is, however, prohibitively expensive, given the large number of (client, subscribed_item) pairs present in a system of reasonable size.
3. The protocol(s) must be scalable, i.e., increasing the number of clients should not deteriorate the quality of service.
4. FINALLY, THE PROTOCOL THAT IMPLEMENTS THE ABOVE TWO FUNCTIONALITIES MUST PROVIDE AN ADEQUATE LEVEL OF security, i.e., it should not be easy to breach the security provided by the access control mechanism.
4. BROADCASTING SOLUTIONS
Two broadcasting solutions to the broadcasting problem specified above are the Variable Broadcast Size (VBS) and the Constant Broadcast Size (CBS) protocols. These techniques, first proposed in Datta, Celik, Kim, VanderMeer and Kumar, seek to achieve a minimal tuning time while reducing the access time. However, it is important to understand the broadcast structure before explaining the protocols
4.1 BROADCAST STRUCTURE
Broadcast structure refers to the specific broadcast organization that we assume in developing our strategies. It is important to understand this structure in order to properly appreciate our protocols. We assume a (1, m) indexing strategy outlined in Imielinski et al. In this scheme, index information is provided at regular intervals in the broadcast. More specifically, a complete index is inserted m times in a broadcast at regular intervals.
Figure 3 illustrates our broadcast structure. A broadcast is a sequence of data blocks (containing data) and index segments (containing access information) as shown in Figure 3A. Using the (1, m) data organization methodology, an index segment appears every 1/mth of the broadcast, i.e., there are m index segments. Clearly, each of the m data blocks is also of equal size. Each data block is composed of one or more data clusters as shown in Figure 3B, where each data cluster consists of a collection of tuples of a single data item of interest. For example, assume the broadcast consists of stock information, and each tuple is a triple <stock_id, price, market>. In such a scenario, the data items of interest would be represented by stock IDs. Consider a particular stock ID, e.g., IBM. All IBM records would comprise a data cluster. A data cluster may span more than one data block.
Figure 3: Broadcast structure
Data clusters are composed of data buckets shown in Figure 3, which contain data records as well as some tuning information (denoted by the 5-tuple <X,Y,Z,N, EB> in the figure) explained below.
We assume that each client has its own items of interest (e.g., clients are not interested in all stocks, but instead in specific ones). For the purposes of this study, we assume a client has a single data item of interest. As explained above, all records pertaining to this item appear in a specific data cluster which we refer to as the client’s Data Cluster of Interest (DCI). Within the broadcast, the data clusters are organized in order of decreasing popularity, such that the most popular item will be broadcast first, and the least popular item will be broadcast last. This helps to reduce the access times for popular items.
An index segment is a series of buckets containing index tuples and some other special tuning information. We first describe the index tuples. Each index tuple consists of a 4- tuple, <K,B,C,EC>, that not only informs the client precisely where the DCI appears in the broadcast, but also provides information about updates to the cluster since the previous broadcast. The structure of the index segment is shown in Figure 3D. K, B, C and EC are defined below.
K:
The cluster’s key value (e.g., for an IBM cluster, the key value is IBM).
B:
The ID of the first bucket of the data cluster.
C:
The offset from B to the first dirty bucket (bucket where changes have occurred since the last broadcast) of the data cluster. If all buckets in the data cluster are clean, C takes a default value of -1.
EC:
The time when the cluster is scheduled to be dropped from the broadcast.
The dirty/clean information (i.e., B and C) are included to handle the rapidly changing data scenario explained earlier in this paper. We assume a tree-like structure for the index. Thus, clients must begin reading the index at the root in order to find the pointers to their DCIs.
As mentioned above and shown in Figure 3C and Figure 3D, all buckets, whether index or data, have a special tuple displayed as a 5-tuple <X,Y,Z,N,EB>. This information is provided to orient clients as they initially tune in to a broadcast. The X, Y, Z, N and EB terms are defined as follows.
X:
An offset to the first bucket of the next nearest index segment.
Y:
An offset to the end of the broadcast, i.e., the start of the next broadcast.
Z:
Shows the bucket’s type (data or index) and contains tuning information for items updated since the previous broadcast. It can hold one of four possible values: Z = -2 indicates an index bucket. Z = 0 indicates a data bucket and that the bucket is clean, i.e., unmodified since the previous broadcast. Z = i, where i is a positive integer, indicates a data bucket and that the bucket is dirty, i.e., modified since the previous broadcast. Moreover, the actual i value, i.e., the positive integer, is an offset to the next dirty bucket in the same data cluster. Z = -1 indicates a data bucket and that it is the last dirty bucket of the data cluster.
N = 0
Indicates a data bucket and that is the last data bucket of the data cluster.
N = i
Indicates that this is not the last bucket of a DCI, and the offset to next data bucket of the same DCI is i.
EB:
The expected departure time (EDT) of the data item in the bucket. Obviously, the EB value of every bucket in the same data cluster is going to be identical and equal to the EDT of the of the cluster key.
4.2 PROTOCOLS TO SUPPORT ADAPTIVE BROADCAST CONTENT AND EFFICIENT RETRIEVAL
In the following, we describe two adaptive broadcast protocols which seek an optimal balance of access time (quality of service or average query response time) and tuning time for energy consumption.
As mentioned earlier, periodicity is an important parameter in designing broadcast strategies. A periodic broadcast signifies that the broadcast “size” (i.e., number of buckets) is fixed. One can ascribe both advantages (e.g., predictability) as well as disadvantages (e.g., loss of flexibility) to periodicity. To study such effects, we describe two sets of protocols below for the periodic and the aperiodic cases. We refer to the periodic protocol as the constant broadcast size (CBS) strategy, whereas the aperiodic broadcast protocol is termed a variable broadcast size (VBS) strategy.
Finally, note that these protocols support a mixed mode retrieval policy, i.e., when a client arrives in a cell, it first tunes in to the broadcast to see if its DCI is already there. If not, the client explicitly sends a request to the server through the uplink for that item. Thus items may be found readily in the broadcast or may have to be placed “on demand.” This policy has been deemed the most “general” policy in the literature.
5. CONSTANT BROADCAST SIZE STRATEGY
We first present the server protocol, i.e., the strategy used by the server in deciding upon the broadcast content. We then present the client protocol, i.e., how the client retrieves data from the broadcast.
5.1 CBS SERVER PROTOCOL
In this strategy, broadcast size is limited, and the broadcast is periodic. Periodicity mandates an equal size for every broadcast (recall that we consider both size and time in terms of buckets). If there are too few requested items to fill the broadcast period, the broadcast will contain dead air. On the other hand, if there are more requested items than space in the broadcast, the server must prioritize requested items to decide which to include in the broadcast set. This prioritization mechanism should simultaneously satisfy two properties: popularity consciousness and avoidance of chronic starvation. Popularity consciousness means that items that are requested more often should have a greater chance of being included in the broadcast than less popular items. Avoidance of chronic starvation means that if a client requests a “less popular” item, it should not be chronically starved, i.e., the item should appear in the broadcast at some point during that client’s residence in the cell. At a minimum, our protocol attempts (but does not guarantee) to provide access to a requested data item at least once during a client’s probable stay in the cell; that is, within RL time of the request.
A system of priority ranking of items based on two factors, i.e., a Popularity Factor (PF) and an Ignore Factor (IF) is the following:
The popularity factor of item at time T, denoted by identifies the number of clients in the cell at time T who are interested in X. When a client requests X, is increased by 1. However, every time it is incremented, the system records the corresponding time. Let the timestamp of the ith increment be denoted by.. Then, a corresponding decrement of 1 is performed on the value of the popularity factor at time. This reflects the (anticipated) departure of the client whose request caused the ith increment.
The Ignore Factor (IF) is proposed to counterbalance the PF’s effect. The IF ensures that less popular but long-neglected items get an opportunity to be included in the broadcast. The IF of a data item X at time t is simply the number of broadcasts that this item has not been included in the broadcast (i.e., ignored) since it was requested and is denoted by
Let TReq be the time the item was requested and PB be the period of the broadcast preset under the constant size strategy. The ignore factor at a time Ti is defined as follows:
Priority computation using IF and PF: An item’s priority can be computed based on the following expression:
Where ASF is an Adaptive Scaling Factor which is an exponential weighting factor based on a nearest neighbor approach. Its purpose is to increase the likelihood that items which have been ignored for a long time will appear in the broadcast. PF and IF differ largely in scale; if ASF is relatively low, PF dominates the priority [removed]limited by the number of clients in a cell). If, however, an item has been ignored for a long time, we would like IF to dominate. A larger ASF value will achieve this. ASF is initialized to a base value for 1 for all data items and reset to this base value each time the item is included in the broadcast. It is incremented when the average time the clients have been waiting for a data item exceeds a preset value.
Having explained the underlying concepts, we are now prepared to describe the server protocol for constructing a broadcast. Prior to a broadcast epoch (the time at which a new broadcast is scheduled to begin), i.e., in its broadcast preparation stage, the server prioritizes all items which have been requested, i.e., items with a PF > 0, and sorts the items in order of descending priority. It then adds items to the broadcast set until the broadcast is full. For all requested but excluded items, their IFs are adjusted.
5.2 CBS CLIENT PROTOCOL
We now describe a client protocol designed to cleverly retrieve data from the broadcast in cooperation with the server protocol defined above. When a client senses the need for a particular data item, it begins the retrieval process by tuning in to the broadcast at an arbitrary time and reading a bucket. We remind the reader that the data cluster in the broadcast that holds the item of a client’s interest is referred to as the Data Cluster of Interest (DCI).
The random initial probe in a continuous flow of broadcasts creates a large number of tuning possibilities. Note that because we assume a tree-like rather than a linear index structure, the client must start reading from the top of the index segment (i.e., the root). If it does not find a pointer to its DCI (i.e., DCI is not in the current broadcast set), then it requests the item and tunes to the initial index of every succeeding broadcast until either the DCI is found in the broadcast or it departs from the cell.
5.3 VARIABLE BROADCAST SIZE STRATEGY
Having discussed a periodic broadcasting strategy, we now turn our attention to an aperiodic broadcasting scenario. This strategy is called the variable broadcast size (VBS) strategy. Note that while the broadcast size varies across broadcasts, at the start of each individual broadcast the size is known; therefore, the start of the subsequent broadcast is known as well. However, the server has no knowledge beyond that, as it does not know what requests may arrive during the current broadcast.
VBS Server Protocol
The server protocol for VBS is much simpler than that for the constant size strategy. All requested items are included, i.e., all items with a PF greater than 0 are added to the broadcast set. The broadcast length changes as items are added and deleted. Items remain in the broadcast for RL units of time from their latest request and are subsequently dropped from the broadcast set. Within the broadcast, items (i.e., DCIs) are ordered based on descending popularity. Since no item is ignored, there is no notion of ignore factor in VBS.
VBS Client Protocol
The client protocol in this strategy is similar to that of the CBS strategy. The main difference is in the client’s response to finding that its DCI is not in the broadcast. Here, if its DCI is not in the broadcast, or if it has missed its DCI and the item will be dropped when the next broadcast is composed, the client requests the item and exits from the protocol. Since its DCI is guaranteed to be in the succeeding broadcast, it begins the retrieval process at the beginning of the next broadcast and finds its DCI in that broadcast.
5.4 PERFORMANCE OF THE CBS AND THE VBS PROTOCOLS
An empirical performance evaluation by means of an extensive simulation study reveals that the CBS and the VBS protocols perform differently under different system characteristics.The Access Time (AT) metric is used to measure the quality of the broadcasting service. The smaller the AT, the faster the clients are receiving their data items from the broadcast. The Tuning Time metric, explained earlier, is originally proposed to approximate the energy expenditure of the clients that download data from the broadcast. A more direct measure of the energy expenditure is the Normalized Energy Expenditure (NEE). NEE is simply the energy spent on average by a client to download a bucket of data. The simulation study allows us to keep track of the energy spent by each client’s mobile unit (a combination of the CPU, the disk, the mobile data card, and the display). NEE is derived by dividing the total energy that the client has spent by the total number of data buckets that it has downloaded from the broadcast. In our simulations, a bucket is 128 Bytes.
The simulation results distinguish between the hot and the cold items. Twenty percent of the data items are hot, meaning that they are more popular and requested more often than the cold data items.
The simulation is run for various client arrival rates that reflect the frequency of requests made to the broadcast server. The arrival rates are represented on the horizontal axis in the figures.
The access times for the CBS and VBS protocols corresponding to clients that requested hot and cold clients are shown in Figure 4A and Figure 4B, respectively. The NEEs for the CBS and VBS protocols are shown in Figure 5A and Figure 5B.
Figure 4: Experimental results: [A] AT curves for CBS and VBS hot clients; [B] AT curves for CBS and VBS cold clients
Figure 5: Experimental results— [A] NEE curves for CBS and VBS hot clients; [B] NEE curves for CBS and VBS cold clients
Both sets of curves show that for hot clients, CBS outperforms VBS at all but very low loads, i.e., where the CBS broadcast is not full. Here, the VBS dominates. For cold clients, for all load levels, the VBS protocol either outperforms or performs identically to the CBS protocol. This is reasonable, since the CBS protocol is optimized to provide better service to clients interested in more popular items at the expense of service for cold items
6. SOLUTIONS FOR SECURE DATA ACCESS FROM BROADCASTS
In this paper, we present two protocols that provide secure data access from the broadcasts by the clients: Subscribe, and Drop Groups Both protocols rely on a security layer supported by the communication infrastructure. We explain the protocols and the broadcast structure that incorporates the security mechanism.
6.1 PROTOCOLS TO SUPPORT SECURE DATA ACCESS FROM BROADCASTS
The protocols use encryption techniques to scramble the communication between the data server and the clients. Two types of encryption keys: Client keys and data keys are implemented. For the client keys, a public key cryptosystem such as RSA, used. For data keys, a symmetric system such as DES by is appropriate. The public key of client cj, which is assumed to be known by the server, is denoted by PKj. cj’s corresponding private key, which is assumed to be secret to cj, is denoted by SKj. Messages encrypted with PKj can only be decrypted by cj using SKj. Each data item Di has a data key, denoted by DKi, for use in the symmetric system. The data keys are initially known by the server only but will also be securely transmitted to subscribers of Di. New data keys will be chosen as needed to ensure that only current subscribers can read a particular broadcast.
6.2 THE SUBSCRIBE PROTOCOL
In accordance with the basic cryptosystem described above, the SubScribe protocol operates as follows: When broadcasting Di, the server encrypts it with DKi, producing the ciphertext DKi(Di) of Di, denoted by Ti. Ti is included in the data component of the data block corresponding to DKi. Subsequently, only clients knowing DKi are able to access Di. Thus, the data key DKi is included (in an encrypted fashion) in the key component of the data block corresponding to Di. In order to provide maximum efficiency, the data key is only changed when clients drop their subscriptions. The protocol has two components: a server side, or information delivery component, and a client side, or information access component.
6.3 SUBSCRIBE SERVER SIDE PROTOCOL
The server side protocol is responsible for the delivery strategy for data items. It distinguishes between two types of data items: (a) data items whose subscriber set in the current broadcast includes every client who were subscribed to this item in the previous broadcast as well—these items are referred to as NODROP items, and (b) data items not satisfying the previous criterion, i.e., items which have lost some subscribers in the current broadcast. We will refer to these as DROP items. To include a DROP item, say Di, in the broadcast, the server chooses a new data key, DKi, and creates a data block for this item as follows:
1. Data Component: The server encrypts Di with DKi and includes the ciphertext in the data component.
2. Key Component: For each client in the subscriber set of Di, the server encrypts DKi with the client’s public key and includes the ciphertext in the key component. In other words the key component of DROP items essentially becomes a concatenation of ciphertext chunks, where each ciphertext chunk represents an encryption of DKi with a specific subscriber’s public key.
To include a NODROP item into the broadcast, the server uses the same data key that was used in the previous broadcast for this data item. This is possible due to the fact that using this data key does not compromise security—all prior subscribers are still subscribed to this item. Also, in this case (potentially) substantial savings are realized as the key need not be sent to all the prior subscribers. The server composes the key component by encrypting the data key only for the new subscribers. Existing clients are notified of the fact that the data key remained the same by inserting a special offset value of -1 in an index in front of the data block for that data item. In both the DROP and NODROP cases, index records are created by the server for constructing the two types of indexes described before.
6.4 THE DROP GROUPS PROTOCOL
In the SubScribe protocol, the broadcast is organized in such a way that each data item is encrypted with its own key and is broadcast together with the key information intended for each subscriber. This key information for each client is obtained by encoding the data item key using the public key of the recipient. That is, the broadcast server sends off as many encodings as there are clients. This effectively renders the size of the broadcast unpredictable. Particularly when the number of subscribers is high, the key segment may become very large and significantly increase the size of the broadcast. Obviously, a longer broadcast means a reduced quality of service. Therefore, there is a scalability issue.
The Drop Groups (DG) Protocol is designed to bound the size of the key component in a broadcast regardless of the number of clients in the system.
DG achieves scalability by using a novel grouping criterion. DG assigns each client to predetermined groups and assigns each group a group key valid until the group changes. This is similar to the Group Key approach. In the Group Key protocol, subscribers of an item usually form a group and are given a group key valid until there are drops (i.e., subscription expiration) from the group. When a drop occurs, a new group key must be generated and distributed to remaining subscribers so that the dropped subscribers don’t have access to new values of the data item. In DG, however, we propose to further divide the groups of a data item into subgroups using an additional criterion. The new criterion we use is the time to drop, which is simply the amount of time until a client’s subscription for a data item expires. Therefore, two subscribers, A and B, of data item i are in the same group if and only if their subscription for i expires at the same time. Of course, in order to achieve this sort of grouping, we have to ensure that subscription expirations are bunched together at discrete epochs. This is done as explained later.
The choice of the time to drop as the grouping criteria is crucial. This is designed to remedy a major problem associated with the group key approach, namely, the key expiration problem in a dynamic environment. In this environment, the period of validity of a key is small, necessitating the generation of a new key frequently. Although key generation is rather fast and cheap, it is costly to distribute this new key to the clients
In DG, since all subscribers in the same group will be dropped at the same time, it is never necessary to issue a new group key and distribute it to the group. Furthermore, when a new client contacts the subscription server, the client is given a group key for each data item that it is interested in. The client then listens to the broadcast prepared by the subscription server and downloads the data items.
The time continuum is divided into subscription epochs such that subscription expirations are only scheduled to happen at the end of an epoch. For example, if the epoch length is 1 hour, and client A wants to subscribe to a data item for 2.5 hours, it must choose to subscribe for either two or three hours. To limit the number of epochs, a limit is set on the horizon of subscription. For example, if a subscription epoch is one hour long, and the horizon is 24 hours, then there are 24 possible subscription epochs that clients may choose from. Note that real-world analogies exist for this scenario: readers may subscribe to journals between 1 and 24 months and receive issues monthly. The server can adjust the duration of an epoch depending on the popularity or subscription patterns of the clients of an item. Given such a framework, given a subscription horizon of H epochs, in the key component, there can be at most H group keys preceding the data item regardless of the number of subscribers in each group. Therefore, if there are d data items with H groups in each, then there will be dH group keys in the broadcast. At the end of each subscription epoch, d groups will be dropped, and d groups will be added, one group per each data item. Essentially, this bounds the number of groups. Clearly, this is a big step towards limiting the size of the broadcast, thus satisfying the scalability requirement.
6.5 DROP GROUPS ARCHITECTURE
In this environment, there are two separate servers, the Subscription Server (SServ) and the Broadcast Server (BServ). When a client wishes to access the service, it first contacts the SServ that handles the subscription requests. After exchanging information with the SServ, the client listens to the broadcast prepared by the BServ until its subscription expires. Once the client contacts the SServ, it communicates the request to the BServ, which incorporates the requested data item in the broadcast.
The two servers need to maintain communication between each other mainly for exchanging information specific to data items. The client needs to contact the SServ but has no interaction with the BServ except for listening to the broadcast.
In DG, client keys are used for communicating with the Subscription Server. Authentication, subscription and the initial key exchange are performed using public and private keys. The group key of a data item Di for epoch k is denoted by GKki. Thus, Rki, the data key for Di encrypted with GKki; i.e. GKki(DKi) is included in the key component of the data block corresponding to Di.
6.6 BROADCAST ORGANIZATION IN DG
The organization of a broadcast implementing the DG protocol is shown in Figure 6. A broadcast starts off with a broadcast index, followed by a sequence of data blocks. The broadcast index segment and all the data blocks contain an orientation header (OH). The OH consists of a single element, namely an offset to the start of the next broadcast. This pointer is intended as a “tuning-aid” for clients
Figure 6: Detailed view of broadcast structure in DG
The Broadcast Index (BI) precedes everything else in a broadcast. The BI consists of index records that hold pointers to each item’s data block in the current broadcast. More specifically, an index record consists of a 2-tuple < item id, offset to data block>. A client obtains pointers to its desired data items from the BI and then sleeps, only to wake up at the desired points in time.
The BI is followed by a sequence of data blocks. A data block consists of four parts.
1.
OH that contains the 2-tuple <offset to item (OTI), flag>. The flag bit is set if the item key has changed since the previous broadcast. When clients download the OH, if the flag bit is not set, they don’t need to download the Key Segment if they have the key to the data item from the previous broadcast.
2.
Data block index consists of the <group number, offset to key segment (OKS)>. The OKS element associated with client ID cj indicates where cj can find the key information for its group.
3.
The second part in a data block is the key component. It contains key chunks for all the groups subscribed to Di, i.e., it contains Rki for all groups k that have at least one subscriber.
4.
The last part of a data block is the data component. This contains Ti, a data item Di encrypted with data key DKi.
Therefore, a client, upon successfully downloading the key chunk and Ti, can obtain Di
7. SUMMARY
In this paper, we looked at the problem of data organization and access in mobile networks using broadcasts, and subscription-based data access from broadcasts. The protocols presented here provide efficient methods for designing a broadcasting application to counter the effects of infrastructural inadequacies such as low bandwidth and limited battery power. Paper 3 concentrates on deciding the broadcasting strategy (indexing, broadcast organization, and broadcast period). Paper 4 builds upon these results and prescribes a security layer on top of the basic broadcast structure. Any subscription-based access protocol may be implemented with either the constant broadcast strategy or with the variable broadcast strategy. Based on the characteristics of the data, network capacity, and customer needs, the right combination of protocols should be determined.
Our solutions can be implemented in a wide range of data and content delivery applications, ranging from financial data to wireless Internet services. The dynamic content in a Web page can be distributed to the subscribers via broadcasts. The users could cache the static elements of the page (frames, appearance, etc.) and obtain the freshest content (stock quotes, traffic, movie times, etc.) from the broadcasts. Broadcasting is also a good candidate for providing access to enterprise applications: mobile workers can subscribe to data items that they need to run the application, and any updates to the data items can be broadcast using our protocols. The security of such a system is enhanced if an encryption mechanism such as the one described in the Drop Groups protocol is used. The most general case for using our protocols is for content distribution to handheld devices, such as cellular phones and the PDAs (Personal Digital Assistants, such as Palm). Here, either the wireless carrier alone, or a content provider in alliance with the wireless carrier, could operate the broadcasting application.
The broadcasts should be prepared considering the current and near future demands of the clients. For example, assume that the broadcasts are prepared based on the requests of the clients within a geographic area. When new clients come into that broadcast area, their items of interest may not be included in the current broadcast. Then, these clients will have to resubscribe to the broadcast and wait until these items are broadcast. However, if the broadcasts are prepared preemptively, i.e., by estimating the incoming clients’ requests, then resubscription can be prevented. To do this, the broadcast application needs to keep track of the movements of the clients in the wireless network. However, keeping track of client movements is both costly and difficult to manage. Therefore, trade-offs between preemptively including the data items in the broadcasts and managing the location information of the clients must be considered. We have started researching this area. We plan to derive analytical solutions that optimize bandwidth utilization and cost of operating the system.
8. REFERENCES
[1]. Acharya, S., Alonso, R., Franklin, M., & Zdonik, S. (1995). Broadcast disks: Data management for asymmetric communication environments. Proceedings of ACM SIGMOD, San Jose, California, pp. 199–210.
[2]. Alonso, R., & Korth, H. (1993). Database issues in nomadic computing. Proceedings of the ACM-SIGMOD.
[3]. Celik, A., & Datta, A. (2000). A scalable approach for subscription-based information commerce. Workshop on Electronic Commerce and Web-Based Information Systems (WECWIS), Milpitas, CA, USA.
[4]. Celik, A., Datta, A., & Narasimhan, S. (2000). Secure data delivery protocols for information commerce in a push-based environment. IEEE Transactions on Systems, Man and Cybernetics, 30 (4).
[5]. Datta, A. (1994). Research issues in databases for active rapidly changing data systems (ARCS). ACM Sigmod Record, 23 (3).
[6]. Datta, A., Celik, A., Kim, J. K., VanderMeer, D., & Kumar, V. (1997). Adaptive broadcast protocols to support power conservant retrieval by mobile users. Proceedings of the Thirteenth International Conference on Data Engineering (ICDE), Birmingham, UK.
[7]. Datta, A., Celik, A., Wright, R., & Biliris, A. (1998). SubScribe: Secure and efficient data delivery/access services in a push-based environment. Proceedings of the International Conference on Telecommunications and Electronic Commerce (ICTEC), Dallas, TX, USA.
[8]. Datta, A., VanderMeer, D., Celik, A., & Kumar, V. (1999). Adaptive broadcast protocols to support efficient and energy conserving retrieval from databases in mobile computing environments. ACM Transactions on Database Systems, 24 (1), 1–79.
[9]. Dunham, M. H., & Helal, A. (1995). Mobile computing and databases: Anything new? ACM SIGMOD Record, 24 (4), 5–9.
[10]. Imielinski, T., & Badrinath, B. R. (1994). Mobile wireless computing: Challenges in data management. Communications of the ACM, 37 (10), 18–28.
[11]. Imielinski, T., Vishwanathan, S., & Badrinath, B. R. (1997). Data on air: Organization and access. IEEE Transactions on Knowledge and Data Engineering, 9 (3), 353–372.
[12]. Kenyon, C., & Schabanel, N. (1999). The data broadcast problem with non-uniform transmission times. Proceedings of the 10th Annual ACM-SIAM Symposium on Discrete Algorithms. Baltimore, Maryland.
[13]. Lo, C.-C. & Chen, Y.-J. (1999). Secure communication mechanisms for GSM networks. IEEE Transactions on Consumer Electronics, 45 (4).
[14]. Oh, J., Hua, A., & Prabhakara, K. (2000). New broadcasting techniques for an adaptive hybrid data delivery in wireless mobile network environment. Proceedings of the IEEE International Performance, Computing and Communications Conference (IPCCC 2000), Phoenix, Arizona.
[15]. Rivest, R., Shamir, A., & Adleman, L. (1978). A method for obtaining digital signatures and public key cryptosystems. Communications of the ACM, 21 (2).
[16]. Shepherd, S. J. (1995). A high speed software implementation of the Data Encryption. Computers and Security, 14 (4), 349–357.
[17]. Su, C.-J., Tassiulas, L., & Tsotras, V. J. (1999). Broadcast scheduling for information distribution. Wireless Networks, 5 (2).
[18]. Vaidya, N. H., & Hameed, S. (1999). Scheduling data broadcast in asymmetric communication environments. Wireless Networks, 5 (3).
Linux Journal introduces: In today’s time of rampant information crimes, including identity theft, security is more important to the average computer user than ever. This tutorial shows how you can use GnuPG to secure and verify data on your Linux box. This video was created using only free and open source software tools: TightVNC, pyvnc2swf, ardour2, audacity, jackd, LAME, kolourpaint, cinelerra-cv, mjpegtools, and ffmpeg.
The Global Positioning System (GPS) is the only fully functional Global Navigation Satellite System (GNSS). Utilizing a constellation of at least 24 medium Earth orbit satellites that transmit precise microwave signals, the system enables a GPS receiver to determine its location, speed/direction, and time.
Developed by the United States Department of Defense, it is officially named NAVSTAR GPS (Contrary to popular belief, NAVSTAR is not an acronym, but simply a name given by Mr. John Walsh, a key decision maker when it came to the budget for the GPS program[1]). The satellite constellation is managed by the United States Air Force 50th Space Wing. The cost of maintaining the system is approximately US0 million per year,[2] including the replacement of aging satellites, and research and development. Despite these costs, GPS is free for civilian use as a public good.
GPS has become a widely used aid to navigation worldwide, and a useful tool for map-making, land surveying, commerce, and scientific uses. GPS also provides a precise time reference used in many applications including scientific study of earthquakes, and synchronization of telecommunications networks.
Simplified method of operation
A GPS receiver calculates its position by measuring the distance between itself and three or more GPS satellites. Measuring the time delay between transmission and reception of each GPS microwave signal gives the distance to each satellite, since the signal travels at a known speed – the speed of light. These signals also carry information about the satellites’ location and general system health (known as almanac and ephemeris data). By determining the position of, and distance to, at least three satellites, the receiver can compute its position using trilateration.[3] Receivers typically do not have perfectly accurate clocks and therefore track one or more additional satellites, using their atomic clocks to correct the receiver’s own clock error.
[edit] Technical description
Unlaunched GPS satellite on display at the San Diego Aerospace museum
Unlaunched GPS satellite on display at the San Diego Aerospace museum
[edit] System segmentation
The current GPS consists of three major segments. These are the space segment (SS), a control segment (CS), and a user segment (US).[4]
[edit] Space segment
The space segment (SS) is composed of the orbiting GPS satellites, or Space Vehicles (SV) in GPS parlance. The GPS design calls for 24 SVs to be distributed equally among six circular orbital planes.[5] The orbital planes are centered on the Earth, not rotating with respect to the distant stars.[6] The six planes have approximately 55° inclination (tilt relative to Earth’s equator) and are separated by 60° right ascension of the ascending node (angle along the equator from a reference point to the orbit’s intersection).[2]
Orbiting at an altitude of approximately 20,200 kilometers (12,600 miles or 10,900 nautical miles; orbital radius of 26,600 km (16,500 mi or 14,400 NM)), each SV makes two complete orbits each sidereal day, so it passes over the same location on Earth once each day. The orbits are arranged so that at least six satellites are always within line of sight from almost everywhere on Earth’s surface.[7]
As of September 2007, there are 31 actively broadcasting satellites in the GPS constellation. The additional satellites improve the precision of GPS receiver calculations by providing redundant measurements. With the increased number of satellites, the constellation was changed to a nonuniform arrangement. Such an arrangement was shown to improve reliability and availability of the system, relative to a uniform system, when multiple satellites fail.[8]
[edit] Control segment
The flight paths of the satellites are tracked by US Air Force monitoring stations in Hawaii, Kwajalein, Ascension Island, Diego Garcia, and Colorado Springs, Colorado, along with monitor stations operated by the National Geospatial-Intelligence Agency (NGA).[9] The tracking information is sent to the Air Force Space Command’s master control station at Schriever Air Force Base in Colorado Springs, which is operated by the 2d Space Operations Squadron (2 SOPS) of the United States Air Force (USAF). 2 SOPS contacts each GPS satellite regularly with a navigational update (using the ground antennas at Ascension Island, Diego Garcia, Kwajalein, and Colorado Springs). These updates synchronize the atomic clocks on board the satellites to within one microsecond and adjust the ephemeris of each satellite’s internal orbital model. The updates are created by a Kalman filter which uses inputs from the ground monitoring stations, space weather information, and various other inputs.[10]
GPS receivers come in a variety of formats, from devices integrated into cars, phones, and watches, to dedicated devices such as those shown here from manufacturers Trimble, Garmin and Leica (left to right).
GPS receivers come in a variety of formats, from devices integrated into cars, phones, and watches, to dedicated devices such as those shown here from manufacturers Trimble, Garmin and Leica (left to right).
[edit] User segment
The user’s GPS receiver is the user segment (US) of the GPS system. In general, GPS receivers are composed of an antenna, tuned to the frequencies transmitted by the satellites, receiver-processors, and a highly-stable clock (often a crystal oscillator). They may also include a display for providing location and speed information to the user. A receiver is often described by its number of channels: this signifies how many satellites it can monitor simultaneously. Originally limited to four or five, this has progressively increased over the years so that, as of 2006, receivers typically have between twelve and twenty channels.
A typical OEM GPS receiver module, based on the SiRF Star III chipset, measuring 15×17 mm, and used in many products.
A typical OEM GPS receiver module, based on the SiRF Star III chipset, measuring 15×17 mm, and used in many products.
GPS receivers may include an input for differential corrections, using the RTCM SC-104 format. This is typically in the form of a RS-232 port at 4,800 bit/s speed. Data are actually sent at a much lower rate, which limits the accuracy of the signal sent using RTCM. Receivers with internal DGPS receivers can outperform those using external RTCM data. As of 2006, even low-cost units commonly include Wide Area Augmentation System (WAAS) receivers.
Many GPS receivers can relay position data to a PC or other device using the NMEA 0183 protocol. NMEA 2000[11] is a newer and less widely adopted protocol. Both are proprietary and controlled by the US-based National Marine Electronics Association. References to the NMEA protocols have been compiled from public records, allowing open source tools like gpsd to read the protocol without violating intellectual property laws. Other proprietary protocols exist as well, such as the SiRF and MTK protocols. Receivers can interface with other devices using methods including a serial connection, USB or Bluetooth.
[edit] Navigation signals
Main article: GPS signals
GPS broadcast signal
GPS broadcast signal
Each GPS satellite continuously broadcasts a Navigation Message at 50 bit/s giving the time-of-day, GPS week number and satellite health information (all transmitted in the first part of the message), an ephemeris (transmitted in the second part of the message) and an almanac (later part of the message). The ephemeris data gives the satellite’s own precise orbit and is output over 18 seconds, repeating every 30 seconds. The ephemeris is updated every 2 hours and is generally valid for 4 hours, with provisions for 6 hour time-outs. The time needed to acquire the ephemeris is becoming a significant element of the delay to first position fix, because, as the hardware becomes more capable, the time to lock onto the satellite signals shrinks, but the ephemeris data requires 30 seconds (worst case) before it is received, due to the low data transmission rate. The almanac consists of coarse orbit and status information for each satellite in the constellation and takes 12 seconds for each satellite present, with information for a new satellite being transmitted every 30 seconds (15.5 minutes for 31 satellites). The purpose of the data is to assist in the acquisition of satellites at power-up by allowing the receiver to generate a list of visible satellites based on stored position and time, while an ephemeris from each satellite is needed to compute position fixes using that satellite. In older hardware, lack of an almanac in a new receiver would cause long delays before providing a valid position, because the search for each satellite was a slow process. Advances in hardware have made the acquisition process much faster, so not having an almanac is no longer an issue. An important thing to note about navigation data is that each satellite transmits only its own ephemeris, but transmits an almanac for all satellites.
Each satellite transmits its navigation message with at least two distinct spread spectrum codes: the Coarse / Acquisition (C/A) code, which is freely available to the public, and the Precise (P) code, which is usually encrypted and reserved for military applications. The C/A code is a 1,023 chip pseudo-random (PRN) code at 1.023 million chips/sec so that it repeats every millisecond. Each satellite has its own C/A code so that it can be uniquely identified and received separately from the other satellites transmitting on the same frequency. The P-code is a 10.23 megachip/sec PRN code that repeats only every week. When the “anti-spoofing” mode is on, as it is in normal operation, the P code is encrypted by the Y-code to produce the P(Y) code, which can only be decrypted by units with a valid decryption key. Both the C/A and P(Y) codes impart the precise time-of-day to the user. Frequencies used by GPS include
* L1 (1575.42 MHz): Mix of Navigation Message, coarse-acquisition (C/A) code and encrypted precision P(Y) code, plus the new L1C on future Block III satellites.
* L2 (1227.60 MHz): P(Y) code, plus the new L2C code on the Block IIR-M and newer satellites.
* L3 (1381.05 MHz): Used by the Nuclear Detonation (NUDET) Detection System Payload (NDS) to signal detection of nuclear detonations and other high-energy infrared events. Used to enforce nuclear test ban treaties.
* L4 (1379.913 MHz): Being studied for additional ionospheric correction.
* L5 (1176.45 MHz): Proposed for use as a civilian safety-of-life (SoL) signal (see GPS modernization). This frequency falls into an internationally protected range for aeronautical navigation, promising little or no interference under all circumstances. The first Block IIF satellite that would provide this signal is set to be launched in 2008.
[edit] Calculating positions
[edit] Using the C/A code
To start off, the receiver picks which C/A codes to listen for by PRN number, based on the almanac information it has previously acquired. As it detects each satellite’s signal, it identifies it by its distinct C/A code pattern, then measures the time delay for each satellite. To do this, the receiver produces an identical C/A sequence using the same seed number as the satellite. By lining up the two sequences, the receiver can measure the delay and calculate the distance to the satellite, called the pseudorange[12].
Overlapping pseudoranges, represented as curves, are modified to yield the probable position
Overlapping pseudoranges, represented as curves, are modified to yield the probable position
Next, the orbital position data, or ephemeris, from the Navigation Message is then downloaded to calculate the satellite’s precise position. A more-sensitive receiver will potentially acquire the ephemeris data quicker than a less-sensitive receiver, especially in a noisy environment.[13] Knowing the position and the distance of a satellite indicates that the receiver is located somewhere on the surface of an imaginary sphere centered on that satellite and whose radius is the distance to it. Receivers can substitute altitude for one satellite, which the GPS receiver translates to a pseudorange measured from the center of the earth.
Locations are calculated not in three-dimensional space, but in four-dimensional spacetime, meaning a measure of the precise time-of-day is very important. The measured pseudoranges from four satellites have already been determined with the receiver’s internal clock, and thus have an unknown amount of clock error. (The clock error or actual time does not matter in the initial pseudorange calculation, because that is based on how much time has passed between reception of each of the signals.[clarify][citation needed]) The four-dimensional point that is equidistant from the pseudoranges is calculated as a guess as to the receiver’s location, and the factor used to adjust those pseudoranges to intersect at that four-dimensional point gives a guess as to the receiver’s clock offset. With each guess, a geometric dilution of precision (GDOP) vector is calculated, based on the relative sky positions of the satellites used. As more satellites are picked up, pseudoranges from more combinations of four satellites can be processed to add more guesses to the location and clock offset. The receiver then determines which combinations to use and how to calculate the estimated position by determining the weighted average of these positions and clock offsets. After the final location and time are calculated, the location is expressed in a specific coordinate system, e.g. latitude/longitude, using the WGS 84 geodetic datum or a local system specific to a country.
[edit] Using the P(Y) code
Calculating a position with the P(Y) signal is generally similar in concept, assuming one can decrypt it. The encryption is essentially a safety mechanism: if a signal can be successfully decrypted, it is reasonable to assume it is a real signal being sent by a GPS satellite.[citation needed] In comparison, civil receivers are highly vulnerable to spoofing since correctly formatted C/A signals can be generated using readily available signal generators. RAIM features do not protect against spoofing, since RAIM only checks the signals from a navigational perspective.
[edit] Accuracy and error sources
The position calculated by a GPS receiver requires the current time, the position of the satellite and the measured delay of the received signal. The position accuracy is primarily dependent on the satellite position and signal delay.
To measure the delay, the receiver compares the bit sequence received from the satellite with an internally generated version. By comparing the rising and trailing edges of the bit transitions, modern electronics can measure signal offset to within about 1% of a bit time, or approximately 10 nanoseconds for the C/A code. Since GPS signals propagate nearly at the speed of light, this represents an error of about 3 meters. This is the minimum error possible using only the GPS C/A signal.
Position accuracy can be improved by using the higher-chiprate P(Y) signal. Assuming the same 1% bit time accuracy, the high frequency P(Y) signal results in an accuracy of about 30 centimeters.
Electronics errors are one of several accuracy-degrading effects outlined in the table below. When taken together, autonomous civilian GPS horizontal position fixes are typically accurate to about 15 meters (50 ft). These effects also reduce the more precise P(Y) code’s accuracy.
Sources of User Equivalent Range Errors (UERE) Source Effect
Ionospheric effects ± 5 meter
Ephemeris errors ± 2.5 meter
Satellite clock errors ± 2 meter
Multipath distortion ± 1 meter
Tropospheric effects ± 0.5 meter
Numerical errors ± 1 meter
[edit] Atmospheric effects
Inconsistencies of atmospheric conditions affect the speed of the GPS signals as they pass through the Earth’s atmosphere and ionosphere. Correcting these errors is a significant challenge to improving GPS position accuracy. These effects are smallest when the satellite is directly overhead and become greater for satellites nearer the horizon since the signal is affected for a longer time. Once the receiver’s approximate location is known, a mathematical model can be used to estimate and compensate for these errors.
Because ionospheric delay affects the speed of microwave signals differently based on frequency—a characteristic known as dispersion—both frequency bands can be used to help reduce this error. Some military and expensive survey-grade civilian receivers compare the different delays in the L1 and L2 frequencies to measure atmospheric dispersion, and apply a more precise correction. This can be done in civilian receivers without decrypting the P(Y) signal carried on L2, by tracking the carrier wave instead of the modulated code. To facilitate this on lower cost receivers, a new civilian code signal on L2, called L2C, was added to the Block IIR-M satellites, which was first launched in 2005. It allows a direct comparison of the L1 and L2 signals using the coded signal instead of the carrier wave.
The effects of the ionosphere generally change slowly, and can be averaged over time. The effects for any particular geographical area can be easily calculated by comparing the GPS-measured position to a known surveyed location. This correction is also valid for other receivers in the same general location. Several systems send this information over radio or other links to allow L1 only receivers to make ionospheric corrections. The ionospheric data are transmitted via satellite in Satellite Based Augmentation Systems such as WAAS, which transmits it on the GPS frequency using a special pseudo-random number (PRN), so only one antenna and receiver are required.
Humidity also causes a variable delay, resulting in errors similar to ionospheric delay, but occurring in the troposphere. This effect is both more localized and changes more quickly than ionospheric effects and is not frequency dependent. These traits making precise measurement and compensation of humidity errors more difficult than ionospheric effects.
Changes in altitude also change the amount of delay due to the signal passing through less of the atmosphere at higher elevations. Since the GPS receiver computes its approximate altitude, this error is relatively simple to correct.
[edit] Multipath effects
GPS signals can also be affected by multipath issues, where the radio signals reflect off surrounding terrain; buildings, canyon walls, hard ground, etc. These delayed signals can cause inaccuracy. A variety of techniques, most notably narrow correlator spacing, have been developed to mitigate multipath errors. For long delay multipath, the receiver itself can recognize the wayward signal and discard it. To address shorter delay multipath from the signal reflecting off the ground, specialized antennas may be used to reduce the signal power as received by the antenna. Short delay reflections are harder to filter out because they interfere with the true signal, causing effects almost indistinguishable from routine fluctuations in atmospheric delay.
Multipath effects are much less severe in moving vehicles. When the GPS antenna is moving, the false solutions using reflected signals quickly fail to converge and only the direct signals result in stable solutions.
[edit] Ephemeris and clock errors
The navigation message from a satellite is sent out only every 30 seconds. In reality, the data contained in these messages tend to be “out of date” by an even larger amount. Consider the case when a GPS satellite is boosted back into a proper orbit; for some time following the maneuver, the receiver’s calculation of the satellite’s position will be incorrect until it receives another ephemeris update. The onboard clocks are extremely accurate, but they do suffer from some clock drift. This problem tends to be very small, but may add up to 2 meters (6 ft) of inaccuracy.
This class of error is more “stable” than ionospheric problems and tends to change over days or weeks rather than minutes. This makes correction fairly simple by sending out a more accurate almanac on a separate channel.
[edit] Selective availability
The GPS includes a feature called Selective Availability (SA) that introduces intentional, slowly changing random errors of up to a hundred meters (328 ft) into the publicly available navigation signals to confound, for example, guiding long range missiles to precise targets. Additional accuracy was available in the signal, but in an encrypted form that was only available to the United States military, its allies and a few others, mostly government users.
SA typically added signal errors of up to about 10 meters (32 ft) horizontally and 30 meters (98 ft) vertically. The inaccuracy of the civilian signal was deliberately encoded so as not to change very quickly, for instance the entire eastern U.S. area might read 30 m off, but 30 m off everywhere and in the same direction. To improve the usefulness of GPS for civilian navigation, Differential GPS was used by many civilian GPS receivers to greatly improve accuracy.
During the Gulf War, the shortage of military GPS units and the wide availability of civilian ones among personnel resulted in a decision to disable Selective Availability. This was ironic, as SA had been introduced specifically for these situations, allowing friendly troops to use the signal for accurate navigation, while at the same time denying it to the enemy. But since SA was also denying the same accuracy to thousands of friendly troops, turning it off or setting it to an error of zero meters (effectively the same thing) presented a clear benefit.
In the 1990s, the FAA started pressuring the military to turn off SA permanently. This would save the FAA millions of dollars every year in maintenance of their own radio navigation systems. The military resisted for most of the 1990s, and it ultimately took an executive order to have SA removed from the GPS signal. The amount of error added was “set to zero”[14] at midnight on May 1, 2000 following an announcement by U.S. President Bill Clinton, allowing users access to the error-free L1 signal. Per the directive, the induced error of SA was changed to add no error to the public signals (C/A code). Selective Availability is still a system capability of GPS, and error could, in theory, be reintroduced at any time. In practice, in view of the hazards and costs this would induce for US and foreign shipping, it is unlikely to be reintroduced, and various government agencies, including the FAA,[15] have stated that it is not intended to be reintroduced.
The US military has developed the ability to locally deny GPS (and other navigation services) to hostile forces in a specific area of crisis without affecting the rest of the world or its own military systems.[14]
One interesting side effect of the Selective Availability hardware is the capability to correct the frequency of the GPS caesium and rubidium atomic clocks to an accuracy of approximately 2 × 10-13 (one in five trillion). This represented a significant improvement over the raw accuracy of the clocks.[citation needed]
On 19 September 2007, the United States Department of Defense announced that they would not procure any more satellites capable of implementing SA. [16]
[edit] Relativity
According to the theory of relativity, due to their constant movement and height relative to the Earth-centered inertial reference frame, the clocks on the satellites are affected by their speed (special relativity) as well as their gravitational potential (general relativity). For the GPS satellites, general relativity predicts that the atomic clocks at GPS orbital altitudes will tick more rapidly, by about 45,900 nanoseconds (ns) per day, because they are in a weaker gravitational field than atomic clocks on Earth’s surface. Special relativity predicts that atomic clocks moving at GPS orbital speeds will tick more slowly than stationary ground clocks by about 7,200 ns per day. When combined, the discrepancy is 38 microseconds per day; a difference of 4.465 parts in 1010.[17]. To account for this, the frequency standard onboard each satellite is given a rate offset prior to launch, making it run slightly slower than the desired frequency on Earth; specifically, at 10.22999999543 MHz instead of 10.23 MHz.[18]
GPS observation processing must also compensate for another relativistic effect, the Sagnac effect. The GPS time scale is defined in an inertial system but observations are processed in an Earth-centered, Earth-fixed (co-rotating) system, a system in which simultaneity is not uniquely defined. The Lorentz transformation between the two systems modifies the signal run time, a correction having opposite algebraic signs for satellites in the Eastern and Western celestial hemispheres. Ignoring this effect will produce an east-west error on the order of hundreds of nanoseconds, or tens of meters in position.[19]
The atomic clocks on board the GPS satellites are precisely tuned, making the system a practical engineering application of the scientific theory of relativity in a real-world environment.
[edit] GPS interference and jamming
Since GPS signals at terrestrial receivers tend to be relatively weak, it is easy for other sources of electromagnetic radiation to desensitize the receiver, making acquiring and tracking the satellite signals difficult or impossible.
Solar flares are one such naturally occurring emission with the potential to degrade GPS reception, and their impact can affect reception over the half of the Earth facing the sun. GPS signals can also be interfered with by naturally occurring geomagnetic storms, predominantly found near the poles of the Earth’s magnetic field.[20] Another source of problems is the metal embedded in some car windscreens to prevent icing, degrading reception just inside the car.
Man-made interference can also disrupt, or jam, GPS signals. In one well documented case, an entire harbor was unable to receive GPS signals due to unintentional jamming caused by a malfunctioning TV antenna preamplifier.[21] Intentional jamming is also possible. Generally, stronger signals can interfere with GPS receivers when they are within radio range, or line of sight. In 2002, a detailed description of how to build a short range GPS L1 C/A jammer was published in the online magazine Phrack.[22]
The U.S. government believes that such jammers were used occasionally during the 2001 war in Afghanistan and the U.S. military claimed to destroy a GPS jammer with a GPS-guided bomb during the Iraq War.[23] Such a jammer is relatively easy to detect and locate, making it an attractive target for anti-radiation missiles. The UK Ministry of Defence tested a jamming system in the UK’s West Country on 7 and 8 June 2007. [24]
Some countries allow the use of GPS repeaters to allow for the reception of GPS signals indoors and in obscured locations, however, under EU and UK laws, the use of these is prohibited as the signals can cause interference to other GPS receivers that may receive data from both GPS satellites and the repeater.
Due to the potential for both natural and man-made noise, numerous techniques continue to be developed to deal with the interference. The first is to not rely on GPS as a sole source. According to John Ruley, “IFR pilots should have a fallback plan in case of a GPS malfunction”.[25] Receiver Autonomous Integrity Monitoring (RAIM) is a feature now included in some receivers, which is designed to provide a warning to the user if jamming or another problem is detected. The U.S. military has also deployed their Selective Availability / Anti-Spoofing Module (SAASM) in the Defense Advanced GPS Receiver (DAGR). In demonstration videos, the DAGR is able to detect jamming and maintain its lock on the encrypted GPS signals during interference which causes civilian receivers to lose lock.[26]
[edit] Techniques to improve accuracy
[edit] Augmentation
Main article: GNSS Augmentation
Augmentation methods of improving accuracy rely on external information being integrated into the calculation process. There are many such systems in place and they are generally named or described based on how the GPS sensor receives the information. Some systems transmit additional information about sources of error (such as clock drift, ephemeris, or ionospheric delay), others provide direct measurements of how much the signal was off in the past, while a third group provide additional navigational or vehicle information to be integrated in the calculation process.
Examples of augmentation systems include the Wide Area Augmentation System, Differential GPS, Inertial Navigation Systems and Assisted GPS.
[edit] Precise monitoring
The accuracy of a calculation can also be improved through precise monitoring and measuring of the existing GPS signals in additional or alternate ways.
After SA, which has been turned off, the largest error in GPS is usually the unpredictable delay through the ionosphere. The spacecraft broadcast ionospheric model parameters, but errors remain. This is one reason the GPS spacecraft transmit on at least two frequencies, L1 and L2. Ionospheric delay is a well-defined function of frequency and the total electron content (TEC) along the path, so measuring the arrival time difference between the frequencies determines TEC and thus the precise ionospheric delay at each frequency.
Receivers with decryption keys can decode the P(Y)-code transmitted on both L1 and L2. However, these keys are reserved for the military and “authorized” agencies and are not available to the public. Without keys, it is still possible to use a codeless technique to compare the P(Y) codes on L1 and L2 to gain much of the same error information. However, this technique is slow, so it is currently limited to specialized surveying equipment. In the future, additional civilian codes are expected to be transmitted on the L2 and L5 frequencies (see GPS modernization, below). Then all users will be able to perform dual-frequency measurements and directly compute ionospheric delay errors.
A second form of precise monitoring is called Carrier-Phase Enhancement (CPGPS). The error, which this corrects, arises because the pulse transition of the PRN is not instantaneous, and thus the correlation (satellite-receiver sequence matching) operation is imperfect. The CPGPS approach utilizes the L1 carrier wave, which has a period 1000 times smaller than that of the C/A bit period, to act as an additional clock signal and resolve the uncertainty. The phase difference error in the normal GPS amounts to between 2 and 3 meters (6 to 10 ft) of ambiguity. CPGPS working to within 1% of perfect transition reduces this error to 3 centimeters (1 inch) of ambiguity. By eliminating this source of error, CPGPS coupled with DGPS normally realizes between 20 and 30 centimeters (8 to 12 inches) of absolute accuracy.
Relative Kinematic Positioning (RKP) is another approach for a precise GPS-based positioning system. In this approach, determination of range signal can be resolved to an accuracy of less than 10 centimeters (4 in). This is done by resolving the number of cycles in which the signal is transmitted and received by the receiver. This can be accomplished by using a combination of differential GPS (DGPS) correction data, transmitting GPS signal phase information and ambiguity resolution techniques via statistical tests—possibly with processing in real-time (real-time kinematic positioning, RTK).
[edit] GPS time and date
While most clocks are synchronized to Coordinated Universal Time (UTC), the Atomic clocks on the satellites are set to GPS time. The difference is that GPS time is not corrected to match the rotation of the Earth, so it does not contain leap seconds or other corrections which are periodically added to UTC. GPS time was set to match Coordinated Universal Time (UTC) in 1980, but has since diverged. The lack of corrections means that GPS time remains at a constant offset (19 seconds) with International Atomic Time (TAI). Periodic corrections are performed on the on-board clocks to correct relativistic effects and keep them synchronized with ground clocks.
The GPS navigation message includes the difference between GPS time and UTC, which as of 2006 is 14 seconds. Receivers subtract this offset from GPS time to calculate UTC and specific timezone values. New GPS units may not show the correct UTC time until after receiving the UTC offset message. The GPS-UTC offset field can accommodate 255 leap seconds (eight bits) which, at the current rate of change of the Earth’s rotation, is sufficient to last until the year 2330.
As opposed to the year, month, and day format of the Julian calendar, the GPS date is expressed as a week number and a day-of-week number. The week number is transmitted as a ten-bit field in the C/A and P(Y) navigation messages, and so it becomes zero again every 1,024 weeks (19.6 years). GPS week zero started at 00:00:00 UTC (00:00:19 TAI) on January 6, 1980 and the week number became zero again for the first time at 23:59:47 UTC on August 21, 1999 (00:00:19 TAI on August 22, 1999). To determine the current Gregorian date, a GPS receiver must be provided with the approximate date (to within 3,584 days) to correctly translate the GPS date signal. To address this concern the modernized GPS navigation messages use a 13-bit field, which only repeats every 8,192 weeks (157 years), and will not return to zero until near the year 2137.
[edit] GPS modernization
Main article: GPS modernization
Having reached the program’s requirements for Full Operational Capability (FOC) on July 17, 1995,[27] the GPS completed its original design goals. However, additional advances in technology and new demands on the existing system led to the effort to modernize the GPS system. Announcements from the Vice President and the White House in 1998 initiated these changes, and in 2000 the U.S. Congress authorized the effort, referring to it as GPS III.
The project aims to improve the accuracy and availability for all users and involves new ground stations, new satellites, and four additional navigation signals. New civilian signals are called L2C, L5 and L1C; the new military code is called M-Code. Initial Operational Capability (IOC) of the L2C code is expected in 2008.[28] A goal of 2013 has been established for the entire program, with incentives offered to the contractors if they can complete it by 2011.
[edit] Applications
The Global Positioning System, while originally a military project, is considered a dual-use technology, meaning it has significant applications for both the military and the civilian industry.
[edit] Military
Please help improve this article by expanding this section.
See talk page for details. Please remove this message once the section has been expanded.
The military use GPS for the following purposes:
[edit] Navigation
GPS allows soldiers to find objectives in the dark or in unfamiliar territory, and to coordinate the movement of troops and supplies.
[edit] Target tracking
Various military weapons systems use GPS to track potential ground and air targets before they are flagged as hostile. These weapons systems pass GPS co-ordinates of targets to precision-guided munitions to allow them to engage the targets accurately.
Military aircraft, particularly those used in air-to-ground roles use GPS to find targets (for example, gun camera video from AH-1 Cobras in Iraq show GPS co-ordinates that can be looked up in Google Earth).
[edit] Missile and projectile guidance
GPS allows accurate targeting of various military weapons including ICBMs, cruise missiles and precision-guided munitions.
Artillery projectiles with embedded GPS receivers able to withstand forces of 12,000G have been developed for use in 155 mm howitzers.[29]
[edit] Search and Rescue
Downed pilots can be located faster if they have a GPS receiver.
[edit] Reconnaissance and Map Creation
The military use GPS extensively to aid mapping and reconnaissance.
[edit] Other
The GPS satellites also carry nuclear detonation detectors, which form a major portion of the United States Nuclear Detonation Detection System.[30]
[edit] Civilian
See also: GPS applications
This antenna is mounted on the roof of a hut containing a scientific experiment needing precise timing.
This antenna is mounted on the roof of a hut containing a scientific experiment needing precise timing.
Many civilian applications benefit from GPS signals, using one or more of three basic components of the GPS; absolute location, relative movement, time transfer.
The ability to determine the receiver’s absolute location allows GPS receivers to perform as a surveying tool or as an aid to navigation. The capacity to determine relative movement enables a receiver to calculate local velocity and orientation, useful in vessels or observations of the Earth. Being able to synchronize clocks to exacting standards enables time transfer, which is critical in large communication and observation systems. An example is CDMA digital cellular. Each base station has a GPS timing receiver to synchronize its spreading codes with other base stations to facilitate inter-cell hand off and support hybrid GPS/CDMA positioning of mobiles for emergency calls and other applications.
Finally, GPS enables researchers to explore the Earth environment including the atmosphere, ionosphere and gravity field. GPS survey equipment has revolutionized tectonics by directly measuring the motion of faults in earthquakes.
To help prevent civilian GPS guidance from being used in an enemy’s military or improvised weaponry, the US Government controls the export of civilian receivers. A US-based manufacturer cannot generally export a GPS receiver unless the receiver contains limits restricting it from functioning when it is simultaneously (1) at an altitude above 18 kilometers (60,000 ft) and (2) traveling at over 515 m/s (1,000 knots).[31]
[edit] History
Please help improve this article by expanding this section.
See talk page for details. Please remove this message once the section has been expanded.
The design of GPS is based partly on the similar ground-based radio navigation systems, such as LORAN and the Decca Navigator developed in the early 1940s, and used during World War II. Additional inspiration for the GPS system came when the Soviet Union launched the first Sputnik in 1957. A team of U.S. scientists led by Dr. Richard B. Kershner were monitoring Sputnik’s radio transmissions. They discovered that, because of the Doppler effect, the frequency of the signal being transmitted by Sputnik was higher as the satellite approached, and lower as it continued away from them. They realized that since they knew their exact location on the globe, they could pinpoint where the satellite was along its orbit by measuring the Doppler distortion.
The first satellite navigation system, Transit, used by the United States Navy, was first successfully tested in 1960. Using a constellation of five satellites, it could provide a navigational fix approximately once per hour. In 1967, the U.S. Navy developed the Timation satellite which proved the ability to place accurate clocks in space, a technology the GPS system relies upon. In the 1970s, the ground-based Omega Navigation System, based on signal phase comparison, became the first world-wide radio navigation system.
The first experimental Block-I GPS satellite was launched in February 1978.[28] The GPS satellites were initially manufactured by Rockwell International and are now manufactured by Lockheed Martin.
[edit] Timeline
* In 1972, the US Air Force Central Inertial Guidance Test Facility (Holloman AFB) conducted developmental fight tests of two prototype GPS receivers over White Sands Missile Range, using ground-based pseudo-satellites.
* In 1978 the first experimental Block-I GPS satellite was launched.
* In 1983, after Soviet interceptor aircraft shot down the civilian airliner KAL 007 in restricted Soviet airspace, killing all 269 people on board, U.S. President Ronald Reagan announced that the GPS system would be made available for civilian uses once it was completed.
* By 1985, ten more experimental Block-I satellites had been launched to validate the concept.
* On February 14, 1989, the first modern Block-II satellite was launched.
* In 1992, the 2nd Space Wing, which originally managed the system, was de-activated and replaced by the 50th Space Wing.
* By December 1993 the GPS system achieved initial operational capability[32]
* By January 17, 1994 a complete constellation of 24 satellites was in orbit.
* Full Operational Capability was declared by NAVSTAR in April 1995.
* In 1996, recognizing the importance of GPS to civilian users as well as military users, U.S. President Bill Clinton issued a policy directive[33] declaring GPS to be a dual-use system and establishing an Interagency GPS Executive Board to manage it as a national asset.
* In 1998, U.S. Vice President Al Gore announced plans to upgrade GPS with two new civilian signals for enhanced user accuracy and reliability, particularly with respect to aviation safety.
* On May 2, 2000 “Selective Availability” was discontinued as a result of the 1996 executive order, allowing users to receive a non-degraded signal globally.
* In 2004, the United States Government signed a historic agreement with the European Community establishing cooperation related to GPS and Europe’s planned Galileo system.
* In 2004, U.S. President George W. Bush updated the national policy, replacing the executive board with the National Space-Based Positioning, Navigation, and Timing Executive Committee.
* November 2004, QUALCOMM announced successful tests of Assisted-GPS system for mobile phones.[3]
* In 2005, the first modernized GPS satellite was launched and began transmitting a second civilian signal (L2C) for enhanced user performance.
* The most recent launch was on 17 November 2006. The oldest GPS satellite still in operation was launched in August 1991.
* On September 14, 2007, the aging mainframe-based Ground Segment Control System was transitioned to the new Architecture Evolution Plan. [4]
[edit] Satellite numbers
Name Launch Period No of satellites launched, inc. launch failures Currently in service
Block I 1978-1985 11 0
Block II 1985-1990 9 0
Block IIA 1990-1997 19 15+11
Block IIR 1997-2004 12 12
Block IIR-M 2005- 3 3
Total 54 (plus one not launched) 30+1
1One test satellite
[edit] Awards
Two GPS developers have received the National Academy of Engineering Charles Stark Draper prize year 2003:
* Ivan Getting, emeritus president of The Aerospace Corporation and engineer at the Massachusetts Institute of Technology, established the basis for GPS, improving on the World War II land-based radio system called LORAN (Long-range Radio Aid to Navigation).
* Bradford Parkinson, professor of aeronautics and astronautics at Stanford University, conceived the present satellite-based system in the early 1960s and developed it in conjunction with the U.S. Air Force.
One GPS developer, Roger L. Easton, received the National Medal of Technology on February 13, 2006 at the White House.[34]
On February 10, 1993, the National Aeronautic Association selected the Global Positioning System Team as winners of the 1992 Robert J. Collier Trophy, the most prestigious aviation award in the United States. This team consists of researchers from the Naval Research Laboratory, the U.S. Air Force, the Aerospace Corporation, Rockwell International Corporation, and IBM Federal Systems Company. The citation accompanying the presentation of the trophy honors the GPS Team “for the most significant development for safe and efficient navigation and surveillance of air and spacecraft since the introduction of radio navigation 50 years ago.”
[edit] Other systems
Main article: Global Navigation Satellite System
Other satellite navigation systems in use or various states of development include:
* Beidou — China’s regional system that China has proposed to expand into a global system named COMPASS.
* Galileo — a proposed global system being developed by the European Union, joined by China, Israel, India, Morocco, Saudi Arabia and South Korea, Ukraine planned to be operational by 2011–12.
* GLONASS — Russia’s global system which is being restored to full availability in partnership with India.
* Indian Regional Navigational Satellite System (IRNSS) — India’s proposed regional system.
* QZSS – Japanese proposed regional system, adding better coverage to the Japanese islands.
[edit] See also
Satellite navigation systems Portal
Nautical Portal
* RAIM
* SIGI
* radio navigation
* High Sensitivity GPS
* Degree Confluence Project Use GPS to visit integral degrees of latitude and longitude.
* Exif, GPS data transfer.
* Geotagging
* Geocaching
* NaviTraveler.com, – a GPS point sharing community.
* GPS Drawing Digital mapping and drawing with GPS tracks.
* GPS tracking
* GPS/INS
* Assisted GPS
* GPX (XML schema for interchange of waypoints)
* ID Sniper rifle
* OpenStreetMap, free content maps and street pictures (GFDL)
* Telematics: Many telematics devices use GPS to determine the location of mobile equipment.
* The American Practical Navigator—Chapter 11 “Satellite Navigation”
* Point of Interest
* Automotive navigation system
* NextGen
[edit] Notes
1. ^ Parkinson, B.W. (1996), Global Positioning System: Theory and Applications, chap. 1: Introduction and Heritage of NAVSTAR, the Global Positioning System. pp. 3-28, American Institute of Aeronautics and Astronautics, Washington, D.C.
2. ^ a b GPS Overview from the NAVSTAR Joint Program Office. Accessed December 15, 2006.
3. ^ HowStuffWorks. How GPS Receivers Work. Accessed May 14, 2006.
4. ^ globalsecurity.org [1].
5. ^ Dana, Peter H. GPS Orbital Planes. August 8, 1996.
6. ^ What the Global Positioning System Tells Us about Relativity. Accessed January 2, 2007.
17. ^ Rizos, Chris. University of New South Wales. GPS Satellite Signals. 1999.
18. ^ The Global Positioning System by Robert A. Nelson Via Satellite, November 1999
19. ^ Ashby, Neil Relativity and GPS. Physics Today, May 2002.
20. ^ Space Environment Center. SEC Navigation Systems GPS Page. August 26, 1996.
21. ^ The hunt for an unintentional GPS jammer. GPS World. January 1, 2003.
22. ^ Low Cost and Portable GPS Jammer. Phrack issue 0x3c (60), article 13]. Published December 28, 2002.
23. ^ American Forces Press Service. CENTCOM charts progress. March 25, 2003.
24. ^ [2]
25. ^ Ruley, John. AVweb. GPS jamming. February 12, 2003.
26. ^ Commercial GPS Receivers: Facts for the Warfighter. Hosted at the Joint Chiefs website, linked by the USAF’s GPS Wing DAGR program website. Accessed on 10 April, 2007
27. ^ US Coast Guard news release. Global Positioning System Fully Operational
28. ^ a b Hydrographic Society Journal. Developments in Global Navigation Satellite Systems. Issue #104, April 2002. Accessed April 5, 2007.
29. ^ XM982 Excalibur Precision Guided Extended Range Artillery Projectile. GlobalSecurity.org (2007-05-29). Retrieved on 2007-09-26.
30. ^ Sandia National Laboratory’s Nonproliferation programs and arms control technology.
31. ^ Arms Control Association. Missile Technology Control Regime. Accessed May 17, 2006.
32. ^ United States Department of Defense. Announcement of Initial Operational Capability. December 8, 1993.
33. ^ National Archives and Records Administration. U.S. GLOBAL POSITIONING SYSTEM POLICY. March 29, 1996.
34. ^ United States Naval Research Laboratory. National Medal of Technology for GPS. November 21, 2005
[edit] External links
Wikimedia Commons has media related to:
Global Positioning System
Government links
* GPS.gov—General public education website created by the U.S. Government
* National Space-Based PNT Executive Committee—Established in 2004 to oversee management of GPS and GPS augmentations at a national level.
* USCG Navigation Center—Status of the GPS constellation, government policy, and links to other references. Also includes satellite almanac data.
* The GPS Joint Program Office (GPS JPO)—Responsible for designing and acquiring the system on behalf of the US Government.
* U.S. Naval Observatory’s GPS constellation status
* U.S. Army Corps of Engineers manual: NAVSTAR HTML and PDF (22.6 MB, 328 pages)
* PNT Selective Availability Announcements
* GPS SPS Signal Specification, 2nd Edition—The official Standard Positioning Signal specification.
* Federal Aviation Administration’s GPS FAQ
Introductory / tutorial links
* How does GPS work? TomTom explains GPS, navigation, and digital maps
* GPS Academy Garmin interactive video web site explaing what exactly GPS is and what it can do for you
* HowStuffWorks’ Simplified explanation of GPS and video about how GPS works.
* Trimble’s Online GPS Tutorial Tutorial designed to introduce you to the principles behind GPS
* GPS and GLONASS Simulation(Java applet) Simulation and graphical depiction of space vehicle motion including computation of dilution of precision (DOP)
Technical, historical, and ancillary topics links
* Dana, Peter H. “Global Positioning System Overview”
* Satellite Navigation: GPS & Galileo (PDF)—16-page paper about the history and working of GPS, touching on the upcoming Galileo
* History of GPS, including information about each satellite’s configuration and launch.
* Chadha, Kanwar. “The Global Positioning System: Challenges in Bringing GPS to Mainstream Consumers” Technical Article (1998)
* GPS Weapon Guidance Techniques
* RAND history of the GPS system (PDF)
* GPS Anti-Jam Protection Techniques
* Crosslink Summer 2002 issue by The Aerospace Corporation on satellite navigation.
* Improved weather predictions from COSMIC GPS satellite signal occultation data.
* David L. Wilson’s GPS Accuracy Web Page A thorough analysis of the accuracy of GPS.
* Innovation: Spacecraft Navigator, Autonomous GPS Positioning at High Earth Orbits Example of GPS receiver designed for high altitude spaceflight.
* The Navigator GPS Receiver GSFC’s Navigator spaceflight receiver.
* Neil Ashby’s Relativity in the Global Positioning System
[show]
v • d • e
Satellite navigation systems
Historical Flag of the United States Transit
Operational Flag of the Soviet Union / Flag of Russia GLONASS · Flag of the United States GPS
Developmental Flag of the People’s Republic of China Beidou/COMPASS · Flag of Europe Galileo · Flag of India IRNSS · Flag of Japan QZSS
GNSS time transfer Beidou · Galileo · GLONASS · GPS · IRNSS
Defunct time stations OMA · VNG
[show]
v • d • e
Global structure in Systems, Systems sciences and Systems scientists
Categories Category:Conceptual systems · Category:Physical systems · Category:Social systems · Category:Systems · Category:Systems science · Category:Systems scientists · Category:Systems theory
Systems Biological system · Complex system · Complex adaptive system · Conceptual system · Cultural system · Dynamical system · Economic system · Ecosystem · Formal system · Global Positioning System · Human organ systems · Information systems · Legal system · Metric system · Nervous system · Non-linear system · Operating system · Physical system · Political system · Sensory system · Social system · Solar System · System · Systems of measurement
Fields of theory Chaos theory · Complex systems · Control theory · Cybernetics · Holism in science · Sociotechnical systems theory · Systems biology · System dynamics · Systems ecology · Systems engineering · Systems theory · Systems science
Systems scientists Russell L. Ackoff · William Ross Ashby · Gregory Bateson · Ludwig von Bertalanffy · Kenneth E. Boulding · Peter Checkland · C. West Churchman · Heinz von Foerster · Charles François · Jay Wright Forrester · Ralph W. Gerard · Debora Hammond · George Klir · Niklas Luhmann · Humberto Maturana · Donella Meadows · Mihajlo D. Mesarovic · Howard T. Odum · Talcott Parsons · Ilya Prigogine · Anatol Rapoport · Francisco Varela · John N. Warfield · Norbert Wiener
Retrieved from “http://en.wikipedia.org/wiki/Global_Positioning_System”