The Lightweight Directory Access Protocol, or LDAP in computer networking,is a networking protocol for querying and modifying directory services running over TCP/IP.

A directory is a set of information with similar attributes organized in a logical and hierarchical manner. The most common example is the telephone directory, which consists of a series of names (either of a person or organization) organized alphabetically, with an address and phone number attached.

An LDAP directory often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the topmost levels of the hierarchy. Deeper inside the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else which represents a given tree entry (or multiple entries).

Telecommunication companies introduced the concept of directory services to information technology and computer networking, as their understanding of directory requirements was well-developed after some 70 years of producing and managing telephone directories. The culmination of this input was the comprehensive X.500 specification, a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.

X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a "lightweight" alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols.

Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The latter has become popular in enterprises, as LDAP removed any need to deploy an OSI network. Today, X.500 directory protocols including DAP can also be used directly over TCP/IP.

The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of ISODE and Wengyik Yeong of Performance Systems International, circa 1993. Further development has been done via the Internet Engineering Task Force (IETF).

In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed as the scope of the protocol was expanded to include not only directory browsing and searching functions, but also directory update functions.

LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).

Protocol LDAP
A client starts an LDAP session by connecting to an LDAP server, by default on TCP port 389. The client then sends operation requests to the server, and the server sends responses in turn. With some exceptions the client need not wait for a response before sending the next request, and the server may send the responses in any order.

The basic operations are:

* Start TLS - optionally protect the connection with Transport Layer Security (TLS), to have a more secure connection
* Bind - authenticate and specify LDAP protocol version
* Search - search for and/or retrieve directory entries
* Compare - test if a named entry contains a given attribute value
* Add a new entry
* Delete an entry
* Modify an entry
* Modify DN - move or rename an entry
* Abandon - abort a previous request
* Extended Operation - generic operation used to define other operations
* Unbind - close the connection (not the inverse of Bind)

In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before it times out a connection.

A common alternate method of securing LDAP communication is using an SSL tunnel. This is denoted in LDAP URLs by using the URL scheme "ldaps". The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003.

LDAP is defined in terms of ASN.1, and protocol messages are encoded in the binary format BER. It uses textual representations for a number of ASN.1 fields/types, however.

The protocol accesses LDAP directories, which follow the 1993 edition of the X.500 model:

* A directory is a tree of directory entries.
* An entry consists of a set of attributes.
* An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below).
* Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full filename and the RDN as a relative filename in a folder.

Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID may be provided in the set of the entry's operational attributes.

An entry can look like this when represented in LDIF format (LDAP itself is a binary protocol):

dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1234
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top


dn is the name of the entry; it's not an attribute nor part of the entry. "cn=John Doe" is the entry's RDN, and "dc=example,dc=com" is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, and "mail" for e-mail address.

A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=department,dc=example,dc=com" could return a referral or continuation reference to a server which holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.

LDAP rarely defines any ordering: The server may return the values in an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions - an entry is defined as a set of attributes, and an attribute is a set of values, and sets are inherently unordered.
Read more....!

The user's GPS receiver is the user segment 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 such that, as of 2006, receivers typically have between twelve and twenty channels.

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 bps speed. Data is 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 WAAS receivers.

Many GPS receivers can relay position data to a PC or other device using the NMEA 0183 protocol. NMEA 2000[9] 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 protocol. Receivers can interface with other devices using methods including a serial connection, USB or Bluetooth.

Navigation signals
GPS satellites broadcast three different types of data in the primary navigation signal. The first is the almanac which sends coarse time information along with status information about the satellites. The second is the ephemeris, which contains orbital information that allows the receiver to calculate the position of the satellite. This data is included in the 37,500 bit Navigation Message, which takes 12.5 minutes to send at 50 bps.

GPS satellites broadcast three different types of data in the primary navigation signal. The first is the almanac which sends coarse time information along with status information about the satellites. The second is the ephemeris, which contains orbital information that allows the receiver to calculate the position of the satellite. This data is included in the 37,500 bit Navigation Message, which takes 12.5 minutes to send at 50 bps.

The satellites also broadcast two forms of clock information, the Coarse / Acquisition code, or C/A which is freely available to the public, and the restricted Precise code, or P-code, usually reserved for military applications. The C/A code is a 1,023 bit long pseudo-random code broadcast at 1.023 MHz, repeating every millisecond. Each satellite sends a distinct C/A code, which allows it to be uniquely identified.

The P-code is a similar code broadcast at 10.23 MHz, but it repeats only once a week. In normal operation, the so-called "anti-spoofing mode", the P code is first encrypted into the Y-code, or P(Y), which can only be decrypted by units with a valid decryption key. Frequencies used by GPS include:
• L1 (1575.42 MHz) - Mix of Navigation Message, coarse-acquisition (C/A) code and encrypted precision P(Y) code.
• 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 Defense Support Program to signal detection of missile launches, nuclear detonations, and other high-energy infrared events.
• 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.

Calculating positions
The coordinates are calculated according to the World Geodetic System WGS84 coordinates system. To calculate its position, a receiver needs to know the precise time. The satellites are equipped with extremely accurate atomic clocks, and the receiver uses an internal crystal oscillator-based clock that is continually updated using the signals from the satellites.

The receiver identifies each satellite's signal 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.

The orbital position data from the Navigation Message is then used to calculate the satellite's precise position. 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. When four satellites are measured simultaneously, the intersection of the four imaginary spheres reveals the location of the receiver. Earth-based users can substitute the sphere of the planet for one satellite by using their altitude. Often, these spheres will overlap slightly instead of meeting at one point, so the receiver will yield a mathematically most-probable position (and often indicate the uncertainty).

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. In comparison, civil receivers are highly vulnerable to spoofing since correctly formated C/A signals can be generated using readily available signal generators. RAIM features will not help, since RAIM only checks the signals from a navigational perspective.

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-speed P(Y) signal. Assuming the same 1% accuracy, the faster 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.

Atmospheric effects
Changing atmospheric conditions change 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 minimized 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 radio waves 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, 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 are generally slow-moving, 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 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 much more localized, and changes more quickly than the ionospheric effects, making precise compensation for humidity more difficult. Altitude also causes a variable delay, as the signal passes through less atmosphere at higher elevations. Since the GPS receiver measures altitude directly, this is much simpler correction to apply.

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. Short delay reflections are harder to filter out since they are only slightly delayed, 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.

Ephemeris and clock errors
The navigation message from a satellite is sent out only every 12.5 minutes. 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.

Selective availability
The GPS includes a feature called Selective Availability (SA) that introduces intentional errors between 0 meters and up to a hundred meters (300 ft) into the publicly available navigation signals, making it difficult to use for 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 (30 ft) horizontally and 30 meters (100 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. In order 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 a error of 0 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, but SA was eventually "discontinued"; the amount of error added was "set to zero" in 2000 following an announcement by U.S. President Bill Clinton, allowing users access to an undegraded 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 be in theory 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, 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.

GPS jamming
Jammingof any radio navigation system, including satellite based navigation, is possible. The U.S. Air Force conducted GPS jamming exercises in 2003 and they also have GPS anti-spoofing capabilities. In 2002, a detailed description of how to build a short range GPS L1 C/A jammer was published in Phrack issue 60 by an anonymous author. There has also been at least one well-documented case of unintentional jamming, tracing back to a malfunctioning TV antenna preamplifier. If stronger signals were generated intentionally, they could potentially interfere with aviation

GPS receivers within line of sight. According to John Ruley, of AVweb, "IFR pilots should have a fallback plan in case of a GPS malfunction". Receiver Autonomous Integrity Monitoring(RAIM), a feature of some aviation and marine receivers, is designed to provide a warning to the user if jamming or another problem is detected. GPS signals can also be interfered with by natural geomagnetic storms, predominantly at high latitudes.

The U.S. government believes that such jammers were also used occasionally during the 2001 war in Afghanistan. Some officials believe that jammers could be used to attract the precision-guided munitions towards non-combatant infrastructure; other officials believe that the jammers are completely ineffective. In either case, the jammers may be attractive targets for anti-radiation missiles. During the Iraq War, the U.S. military claimed to destroy a GPS jammer with a GPS-guided bomb.

Relativity
According to Einstein's Theory of relativity, because of 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). Friedwardt Winterberg predicted in 1955 that when observed from the Earth's reference frame, satellite clocks would be perceived as running at a slightly faster rate than clocks on the Earth's surface.

For GPS satellites, this discrepancy is 38 microseconds per day. To account for this, the frequency standard on-board the satellites are given a rate offset prior to launch, making it run slightly slower than its desired frequency on Earth, at 10.22999999543 MHz instead of 10.23 MHz, a difference of -4.465 parts in 1010. The atomic clocks on board the GPS satellites are precisely tuned, making this a practical engineering application of the scientific theory of relativity in a real-world system.

Another relativistic effect to be compensated for in GPS observation processing is the Sagnac effect. The GPS time scale is defined in an inertial system, but observations are processed in an ECEF (co-rotating) 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 offset in the absolute position solution on the order of tens of metres
Neil Ashby presented in Physics Today (May 2002) an account how these relativistic corrections are applied, and their orders of magnitude. The error introduced by relativistic effects can be as much as 15 meters. The GPS system also makes adjustments for the relativistic drift of the atomic clocks in the satellites. Parts of this correction are carried out in the satellites and parts in the receiver.

Techniques to improve accuracy
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, and Inertial Navigation Systems

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.
The first is called Dual Frequency monitoring, and refers to systems that can compare two or more signals, such as the L1 frequency to the L2 frequency. Since these are two different frequencies, they are affected in different, yet predictable ways by the atmosphere and objects around the receiver. After monitoring these signals, it is possible to calculate how much error is being introduced and then nullify that error.
Receivers that have the correct decryption key can relatively easily decode the P(Y)-code transmitted on both L1 and L2 to measure the error. Receivers that do not possess the key can still use a process called codeless to compare the encrypted information on L1 and L2 to gain much of the same error information. However, this technique is currently limited to specialized surveying equipment. In the future, additional civilian codes are expected to be transmitted on the L2 and L5 frequencies. When these become operational, non-encrypted users will be able to make the same comparison and directly measure some 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 millimeters (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).

GPS Time
Atomic clocks on the satellites are set to "GPS time", similar to most time standards, but not corrected to the rotation of the Earth, ignoring leap seconds and other corrections. GPS time was set to match Coordinated Universal Time (UTC) in 1980, but has since diverged as leap seconds were added to UTC.
The current date is expressed in the GPS signal as a week number and a day-of-week number. GPS week zero started at 00:00:00 UTC (00:00:19 TAI) on January 6, 1980. The week number is transmitted in a ten-bit field, and so it wraps round every 1,024 weeks, (19.7 years). The transmitted week number rolled over to zero at 00:00:19 TAI on August 22, 1999 (23:59:47 UTC on August 21, 1999). GPS receivers thus need to know the time to within 3,584 days in order to correctly interpret the GPS date signal. A new field is being added to the GPS navigation message that specifies the calendar year number exactly, in a sixteen-bit field.

The GPS navigation message includes the difference between GPS time and UTC, which is 14 seconds as of 2006. Receivers subtract this offset from GPS time to calculate UTC and 'local' time. New GPS units may not show the correct UTC time, or not attempt to show UTC time at all, until after receiving the UTC offset message for the first time. This is usually within 15 minutes after the unit achieves GPS lock. The GPS-UTC offset field is only eight bits, and so it wraps round every 256 leap seconds. At the current rate of change of the earth's rotation, the first wraparound of this field is projected to occur in the year 2330.

GPS Modernization
Having reached Fully Operational Capability on July 17, 1995, 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 Presidential and the White House in 1998 heralded the beginning of these changes and in 2000, the U.S. Congress reaffirmed the effort; referred 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. A goal of 2013 has been established with incentives offered to the contractors if they can complete it by 2011 Read more....!