If you wish to contribute or participate in the discussions about articles you are invited to join Navipedia as a registered user

EGNOS General Introduction

From Navipedia
Revision as of 18:01, 17 March 2011 by Rui.Pereira (talk | contribs) (Created page with "{{Article Infobox2 |Category=EGNOS |Title={{PAGENAME}} |Authors=GMV. |Level=Basic |YearOfPublication=2011 |Logo=GMV }} EGNOS (European Geostationary Navigation Overlay Service) ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


EGNOSEGNOS
Title EGNOS General Introduction
Author(s) GMV.
Level Basic
Year of Publication 2011
Logo GMV.png


EGNOS (European Geostationary Navigation Overlay Service) is the European satellite-based augmentation service (SBAS) that complements the existing satellite navigation services provided by the US Global Positioning System (GPS). EGNOS provides the first European GNSS services to users[1]. EGNOS constitutes together with Galileo the two major initiatives in Europe in terms of satellite navigation


EGNOS Services

EGNOS supports the following services[2]:

  • The Open Service (OS), freely available to the public over Europe. This service was officially started on 1 October 2009.
  • The Safety of Life Service (SoL), that provides the most stringent level of signal-in-space performance to all communities of Safety of Life users over Europe. This service was officially started on 2 March 2011.
  • The Commercial Data Distribution Service (CDDS) for customers who require enhanced performance for commercial and professional use. This service is being provided since April 2010 [3].

EGNOS is meant to be part of a multi-modal inter-regional SBAS service, supporting a wide spectrum of applications in many different users’ communities. In particular the EGNOS service can support different applications in the transport domain (e.g. aviation, maritime and rail). This service is compliant with already well identified safety-critical aviation applications, as APV (Approach with vertical Guidance).


EGNOS Architecture

The EGNOS Core architecture is composed of the following segments [1]:

  • Ground segment , composed of reference stations (RIMS - Ranging & Integrity Monitoring Stations) spread inside and outside Europe which monitor the GPS satellites; control centres (MCC - Mission Control Centres) and uplink stations (NLES - Navigation Land Earth Stations);
  • Space segment, composed of GEO satellites broadcasting EGNOS Signal In Space (SIS) over the service area;
  • Support segment, composed of the Performance Assessment Check-out Facility (PACF) and the Application Specific Qualification Facility (ASQF);

In addition, the following elements are present in the EGNOS architecture, but are outside of the EGNOS Core:

EGNOS processing channel starts with each RIMS collecting raw data from the GPS satellites and EGNOS GEO satellites in view and transmitting them to the MCCs. Then the Central Processing Facility (CPF) inside each MCC facility computes signal corrections in real time including ionospheric delays, GPS and GEO ephemeris and clock errors. Finally, the EGNOS signal and data are sent to the users via a GEO satellite link, with the NLES acting as uplink stations, and through the External Data Access Server.

The next figure includes the main EGNOS architectural components.

Figure here


EGNOS Performances

According to EGNOS Mission Requirement Document[1], EGNOS performances required are presented in the following table.

Table here


However, actual EGNOS Performances may differ from the required ones. EGNOS is in a continuous process of enhancement with the aim of improving the performances and robustness of the system. Actual EGNOS performances are being monitored and analyzed continuously by ESSP (http://egnos-user-support.essp-sas.eu/egnos_ops/) and ESA (http://www.egnos-pro.esa.int/IMAGEtech/imagetech_realtime.html) amongst other entities.

EGNOS Signal Structure

EGNOS uses the same frequency (L1 1575.42 MHz)) and ranging codes as GPS, but has a different data message format. Sixteen different message types have so far been defined to broadcast integrity data and Wide Area Differential (WAD) corrections. The message schedule follows a 6-second duty cycle. This is structured both to prioritize the 6-second integrity time-to-alarm and to minimize the time for EGNOS initialization.

Integrity is provided at two levels: use/don’t use flags for satellites and for ionospheric grid points; and two parameters – UDRE and GIVE – that are statistical estimates of the satellite and ionospheric errors remaining after applying the WAD corrections. These are used to compute a certified error bound for the position solution in an integrity assessment.

Fast and slow WAD corrections model the temporal de-correlation of the different error sources. The fast corrections model rapidly changing error sources including satellite clock errors. The slow corrections model more slowly changing error sources including long-term satellite clock drift and ephemeris errors. Ionospheric delays are provided at pre-defined grid points.

At user level, the receiver estimates corrections for satellite clock and ephemeris errors using the fast and slow satellite data messages. It has to account for both range-rate effects between successive fast corrections and performance degradation if a message is missed. The UDRE term characterizes statistically the residual range errors after having applied the fast and slow clock and ephemeris corrections.

The receiver predicts also [[Ionospheric Delays|ionospheric delays] for each range in three steps: it estimates where the view line from satellite to receiver pierces the ionospheric layer; the vertical delay at the pierce point is then interpolated from the surrounding grid points which have been estimated by the system; and finally the estimated delay is applied to the range measurement. The GIVE term is applied to the range vector to characterize statistically the residual ionospheric errors.

Tropospheric errors may be mitigated using a simple model related to the receiver’s position and the day of year.

SBAS Interoperability

SBAS Interoperability refers to the ability of two or more SBAS systems to be used together to provide better capabilities at user level than those achieved by relying solely on one of the systems.

The SBAS interoperability has always been a pre-requisite for delivering a global seamless safety-of-life service. This was recognized early on by SBAS developers and air traffic services providers, and they have worked closely together to co-ordinate their activities at the Wikipedia:International_Civil_Aviation_Organization International Civil Aviation Organization (ICAO) and in the Interoperability Working Group (IWG). One of their key activities has been to assist ICAO and the Radio Technical Commission for Aeronautics (RTCA) in the development of standards: Standards and Recommended Practices (SARPS) for system developers and Minimum Operational Performance Standards (MOPS) for receiver manufacturers. The combination of SBAS interoperability and expansion concepts should allow the provision of a truly global and seamless navigation service.


Notes

References

  1. ^ a b c EGNOS Mission Requirements Document, version 2.0, 8th May 2006, Galileo Joint Undertaking
  2. ^ http://egnos-portal.gsa.europa.eu/discover-egnos/services/service-access
  3. ^ http://www.essp-sas.eu/news