Terminal Operations

Whilst RNAV 5 and RNAV 2 can support initial arrival operations in terminal and extended terminal operations, there comes a point where their performance is not robust enough for operations close to terrain.  For RNAV 5, this application cannot be within 30 NM of the Aerodrome Reference Point (ARP) and not elow the Minimum Safe Altitude (MSA), Minimum Flight Altitude (MFA) or Minimum Radar Vectoring Altitude (MRVA) whichever is the highest.

RNAV 2 has been foreseen as an en-route application while RNAV 1 is foreseen in terminal operations; however, RNAV 2 has not been foreseen as an application for use within European airspace.

RNAV 1 and RNP 1 together with RNP 0.3 for helicopter operations have been mandated for operations in European terminal airspace.

RNAV 1 and 2 have exactly the same requirements and therefore the RNAV 1 and 2 navigation specification covers both performance requirements.  The RNAV 1 and 2 specification is applicable to all ATS routes, including routes in the en-route domain, SIDs and STARS and can support operations up to the FAF.

The RNAV 1 and 2 specification is primarily developed for RNAV operations in a radar environment (for SIDs, radar coverage is expected prior to the first RNAV course change). The RNP 1 specification is intended for similar operations outside radar coverage.  However, RNAV 1 and RNAV 2 may be used in a non-radar environment or below minimum vectoring altitude if the implementing State ensures appropriate system safety and accounts for lack of on-board performance monitoring and alerting.

RNAV 1 and RNAV 2 operations are is required to be conducted with Direct pilot to ATC (voice) communications (a DCPC environment).

The following navigation infrastructures can support RNAV 1 and 2: GNSS and/or DME/DME.

Where DME is the only navigation service used for position updates, gaps in DME coverage can prevent position update. Integration of IRUs can permit extended gaps in coverage but patently the aircraft must be fitted DME/DME/IRU; it should be noted that the growth in position error after reverting to IRU can be expected to be less than 2 NM per 15 minutes.  If the aircraft is not fitted with an IRU then the aircraft can revert to dead reckoning. However, additional protection, in accordance with PANS-OPS, will be needed to cater for the increased error. GNSS should be authorized whenever possible and limitations on the use of specific system elements should be avoided.

Most modern RNAV systems prioritize input from GNSS and then DME/DME positioning.   However, if VOR is also fitted to the multi sensor computer then its influence on the navigation solution must be managed.  The navigation specification identifies that some aircraft systems may revert to VOR/DME-based navigation before reverting to inertial coasting.  Therefore, the impact of VOR radial accuracy, when the VOR is greater than 40 NM from the aircraft, must not affect aircraft position accuracy and should be excluded from the position solution.

The RNP 1 specification enables connectivity between the en‑route structure and terminal airspace providing RNP routes that can be supported in all geographic areas where there may be an extensive, modest or no ground NAVAID infrastructure.  It should be noted that the term “Basic” which historically prefixed RNP 1 is no longer used; however, existing authorizations granted under the original nomenclature remain valid.

The RNP 1 specification is based on a GNSS infrastructure. While DME/DME-based navigation systems are capable of RNP 1 accuracy, this navigation specification is primarily intended for environments where the DME infrastructure cannot support DME/DME area navigation to the required performance. The increased complexity in the DME infrastructure requirements and assessment means it is not practical or cost-effective for widespread application.

RNP 1 has been primarily developed to support arrival and departure procedures, which are commonly referred to as SIDs and STARs; however, RNP 1 also applies to the initial and intermediate approach segments. RNP 1 may be used for extended terminal operations, where it may be applied in the en route continental flight phase on ATS routes or SIDs/STARs.

RF can be associated with RNP 1 SIDs/STARS.

Service providers should ensure operators have the means to predict fault detection. This prediction service can be provided by the ANSP, airborne equipment manufacturers or other DAT providers. The prediction service should use status information on GNSS satellites, and should use a horizontal alert limit appropriate to the operation (1 NM within 30 NM from the airport and 2 NM otherwise). Outages should be ‘flagged’ in the event of a predicted, continuous loss of ABAS fault detection of more than five minutes for any part of the RNP 1 operation.  RNP 1 shall not be used in areas of known navigation signal (GNSS) interference.

As the default alerting functionality of a TSO-C129a sensor (stand-alone or integrated), switches between terminal alerting (±1 NM) and en‑route alerting (±2 NM) at 30 miles from the ARP.  Therefore, if a RNP 1 SID is designed to extend beyond 30 NM from the ARP and a lateral deviation indicator is used, the lateral deviation indicator’s full-scale sensitivity must be selected to not greater than 1 NM between 30 NM from the ARP and the termination of the RNP 1 SID.

The RNP 0.3 specification is intended for the exclusive use of helicopters and the navigation specification addresses continental, remote continental and offshore operations.  The specification takes credit for the fact that the large majority of IFR helicopters are already equipped with SBAS receivers and moving map displays, and require autopilot including stability augmentation for IFR certification.

The helicopter community identified a need for a specification that has a single accuracy of 0.3 NM for all phases of flight, recognizing that such a specification would enable a significant part of the IFR helicopter fleet to obtain significant benefits from PBN.  Specific operations that RNP 0.3 can enable included:

  • Reduced protected areas, potentially enabling separation from fixed wing traffic to allow simultaneous non-interfering operations in dense terminal airspace;
  • Low-level routes in obstacle-rich environments reducing exposure to icing environments;
  • Seamless transition from en route to terminal route;
  • More efficient terminal routing in an obstacle-rich or noise-sensitive terminal environment, specifically in consideration of helicopter emergency service IFR operations between hospitals;
  • Transitions to helicopter point-in-space approaches and for helicopter departures; and
  • Helicopter en-route operations are limited by range and speed and can often equate to the dimensions of terminal fixed wing operations.

RNP 0.3 supports operations en route and in the terminal airspace supporting operations to and from airports, heliports and for servicing offshore rigs. RNP 0.3 accuracy may also be needed en route to support operations at low level in mountainous remote areas and, for airspace capacity reasons, in high density airspace.

The specification is applicable to departure, en route, arrival (including the initial and intermediate segments of the approach), and to the final phase of the missed approach; for the final approach segment (FAS) a RNP approach certification and approval is required.

RNP 0.3 can be applied with and without ATS surveillance.  The specific ATM requirements will be specified in such documents as operating rules, AIPs and the Regional Supplementary Procedures (Doc 7030).

The RNP 0.3 specification is based upon GNSS; however, its implementation is not solely dependent on the availability of SBAS. DME/DME based RNAV systems will not be capable of consistently providing RNP 0.3 performance, and States should not plan on implementing RNP 0.3 operations through application of DME/DME-based navigation. States must also not use RNP 0.3 in areas of known navigation signal (GNSS) interference.

Advanced RNP (A-RNP) was developed to cover a diverse set of applications across various flight phases but not Final Approach. In en-route continental and terminal applications it is intended for use in high density airspaces where an ATS surveillance service is provided; however, if this is not radar then consideration must be given to the mutual loss of navigation and surveillance if there is a GNSS outage.

Depending on local implementation considerations, Advanced RNP can also be used in medium to low density areas where an ATS surveillance service is not available.

This specification should not be confused with RNP AR operations and should not be applied in obstacle rich environments.

A-RNP can play an important role supporting Simultaneous Operations on Parallel or Near-Parallel Instrument Runways (SOIR).  Independent parallel approaches (Mode 1) can be supported by precision approach or PBN.  If a State wishes to apply SOIR Mode 1, the controlling aspect is the required performance on the approach to ensure the No Transgression Zone (NTZ) is not penetrated due to poor navigational accuracy.  The SASP stipulated a requirement of 4 x RNP to protect two aircraft on individual approaches to independent runways.  The application of RNP APCH in the Final Approach Segment, with an RNP 0.3, means that a minimum distance between runway centrelines spacing of 2224m is required (4 x 0.3NM = 2224m); less than 2224 m then RNP AR APCH must be applied.  Unfortunately, outside the FAS the required lateral performance of RNP APCH is +/-1 NM.  Therefore, if RNP APCH is used to support independent parallel approaches, the vertical separation can only be discontinued once the NTZ is invoked and this will not be before the Final Approach Fix or Point (FAF/FAP).  A-RNP supports a required performance of +/- 0.3 NM in terminal airspace and therefore, would remove this restriction.  Again, it is stressed that runway spacings of less than 2224 m will require RNP AR APCH or PA to support SOIR Mode 1 operations.

This website or its third party tools make use of cookies to enhance browsing experience and provide additional functionality. If you want to know more or withdraw your consent to all or some of the cookies, please refer to the cookies policy. Accept