Download as pdf or txt
Download as pdf or txt
You are on page 1of 96

PBN

FOR AIR TRAFFIC CONTROLLER

Tangerang, 29 Oktober 2018


WHY PBN IS IMPORTANT?
History of PBN
v RNP concept was introduced in 1990s
Ø A statement of the navigation performance accuracy necessary for operation
within a defined airspace (Doc 9613 – RNP Manual).
Ø A statement of the navigation performance accuracy, integrity, continuity and
availability necessary for operation within a defined airspace (Doc 9650 – Special
COM/OPS Divisional Meeting Report)
v RNP concept was insufficient
Ø Not specify relationship between RNAV and RNP and need for an RNAV system
Ø Focused on oceanic and remote area applications
Ø No specific guidelines for continental en-route, terminal and approach
applications
Ø Led to proliferation of national standards, wide variety of functional
requirements, variety of required navigation sensors, different crew
requirements, lack of global harmonization
v The result
Ø Cost to operators, who had to qualify several times to operate in ‘RNP’ airspace
where the RNP ‘value’ was the same
Ø Confusion in the stakeholder community – uncertainty as to what RNP meant
History of PBN

Russia
B-RNAV US
2 Europe
P-RNAV
0 RNAV
Boeing
US-RNAV Australia
0 and
China
RNP10 RNP
3 Airbus
RNP 4 Canada
Japan
RNP/RNAV
South America
India
History of PBN
v ICAO began to act in 2004
Ø To stop proliferation of regional RNAV/RNP standards
Ø To review and redefine RNAV/RNP concept
Ø To include new NavSpecs to meet operational demands
v Set up ICAO RNPSORSG
Ø To achieve and document a common understanding of RNP/RNAV
and associated concepts and functionalities
• Clarify RNAV and RNP definition and Terminologies
• How do they relate to each other?
• What is the essential distinction?
Ø To harmonize the use of RNAV and RNP on global bases, for benefit
of operators and service providers
• Identified operational and airworthiness requirements for
RNAV/RNP
History of PBN
v Enter Performance Based Navigation
Ø PBN Concept replaced RNP concept
Ø PBN Manual (Doc 9613) was published in 2007 and updated in 2013
Ø ICAO’s 36th Assembly Resolution in 2007 supported PBN
Implementation and then reiterated it at 37th Assembly in 2010
Ø ICAO Global Seminars were held around the world
v ICAO PBN Study Group (PBN SG)
Ø Replaced RNPSORSG in November 2008
• To consolidate information learnt during ICAO Seminars
• To develop Operational Requirements for RNAV and RNP
Ø Published RNP APCH OPS Approval Guidance and updated PBN
Manual including new NavSpecs (RNP2, A-RNP, RNP 0.3, etc.)
Global PBN Goal

In the 37th Session of ICAO Assembly (2010)


Assembly Resolution A37-11 (PBN)
1. State complete a PBN implementation plan as a
matter of urgency to achieve:
a. RNAV and RNP operations for en-route and terminal areas
b. PBN Approach (LNAV, LNAV/VNAV, LPV, APV) for all
instrument runway ends by 2016
c. Straight-in LNAV-only procedures for instrument runways,
where no local altimeter setting source and no APV
capable aircraft with a maximum certified take-off mass
of 5700kg or more
2. PIRGs review States’ PBN implementation status and
report any deficiencies to ICAO annually
ICAO iSTAR PBN GLOBAL PERFORMANCE
Source: iSTAR, latest report October 2016

100%

90%
82%
Global
80%
76%
68% Asia Pacific (APAC)
70%

Eastern and Southern African (ESAF)


60%
58%
Europe and North Atlantic (EUR/NAT)
50% 53%
Middle East (MID)
40%
40%
North American, Central American and
Caribbean (NACC)
30%
South American (SAM)

20%
Western and Central African (WACAF)

10%

0%
2010 2014 2016

8
Air Navigation Planning Subdivision
Air Navigation Planning Subdivision
CONTENT

NAVIGATION --> POSITION

GNSS

PBN CONCEPT

PBN MANUAL & TRAINING

OPERATIONAL IMPACT
NAVIGATION & POSITION
HOW TO NAVIGATE
SENSOR

NDB
X
CONVENTIONAL VOR VOR/DME

DME DME/DME
AIRCRAFT KNOW
ITS POSITION
AREA GNSS
WAYPOINT
NAVIGATION

INS/IRS INS/IRS
PBN Terminology

• Correct terminology is important for clarity:


–Area Navigation is the generic term used for area
navigation and is never abbreviated.
–RNAV is used only in reference to RNAV
specifications.
–RNP is used only in reference to RNP specifications.
Conventional Navigation

v Ground based navigation aids (NAVAIDs)


Ø Aircraft overfly NAVAID or intersection
v Display accuracy is a function of distance
Ø Protection area grows, in other words “Splayed”
Limited Design Flexibility
Definition of Area Navigation
v Area Navigation (RNAV) is a method of navigation which
permits aircraft operation on any desired flight path:
Ø Within the coverage of station-referenced NAVAIDs, or
Ø Within the limits of the capability of self-contained system, or
Ø A combination of these capabilities
v Area navigation is the key enabler for the Performance
Based navigation (PBN)
VOR/DME POSITIONING

v VOR/DME
Ø Positioning is calculated based on
• the distance information from a DME,
• the bearing information from a VOR (co-located), and
• VOR/DME location in the database North

d
θ

VOR/DME
DME/DME POSITIONING

v DME/DME
Ø Positioning is calculated based on
• the distances from two DMEs and
• their locations in the database

d1 d2

DME1 DME2
AREA NAVIGATION

v Ground or Space Based NAVAIDs


Ø Aircraft fly “Waypoints”
v Protected area is constant (“Linear”)
Increased Design Flexibility
Waypoints
v A specified geographical location expressed in WGS84
coordinates
v Used to define an area navigation route or flight path of
an aircraft employing area navigation
v Two types of waypoint is used to define a flight path
Ø Fly-over waypoint :
Ø Fly-by waypoint :
v Fly-by waypoint is preferred
but MAPt is always Fly-over
GLOBAL NAVIGATION SATELLITE SYSTEM

§ A worldwide position and time determination system that support


the required navigation performance for the intended operation
GNSS = CORE CONSTELLATION + AUGMENTATION
§ Core Constellations
– GPS
– GLONASS
– Galileo
– Beidou
• Augmentation Systems
– Aircraft-Based Augmentation System (ABAS)
– Space-Based Augmentation System (SBAS)
• Uses geostationary satellites
• India, Japan, Europe, US
– Ground-Based Augmentation System (GBAS)
Positioning Principles… Basically Multilateration

Multilateration:

a c By knowing your distance from at


least 3 points of known-position,
you can determine your own
position.

For Satellite Navigation: a, b & c are satellites, and a fourth is needed to solve for
clock variations.
AIRCRAFT BASED SATELLITE AUGMENTATION

• Aircraft Augmentation System


– RAIM - Airborne GNSS Receiver/Processor to Autonomously Monitor
the Integrity of the Signals from GNSS Satellites
– AAIM (Aircraft Autonomous Integrity Monitoring) - An Inertial
Navigation System for GPS or GLONASS used short periods of time
when the satellite navigation antennas are shadowed by the aircraft
maneuvers or when insufficient satellites are in view
• RAIM (Receiver Autonomous Integrity Monitoring)
– Requires redundant satellite measurements
– 5 Satellites allow to detect the problem caused by one satellite – FD
(Fault Detection) as known as RAIM
– 6 Satellites allow to define which satellite is wrong - FDE
• Others Augmentation techniques - Barometric Altimeter
Aiding, Combination of Sensor Inputs (e.g. VOR/DME)
Satellite Based Augmentation System
(WAAS used as example)

L1, L2

FAA288-021
Ground Based Augmentation System
(GBAS) Architecture

Pseudolite

Pseudolite
Processor GBAS
Reference Station
GNSS
Receiver (Integrity
Pseudolite
VHF Accuracy
Transmitter
Availability)
Monitor
Status
PBN CONCEPT
What is PBN?

Conventional PBN

E
D

C
F

A
B
What is PBN?
v PBN stands for “Performance Based Navigation”.

v Performance can be derived from any means of


equipment.

v PBN specifies SYSTEM PERFORMANCE REQUIREMENTS


for aircraft operating on air traffic routes, instrument
approach procedures, or in a designated airspace.

v The performance requirements for PBN are defined in


terms of accuracy, integrity, continuity and availability.
What is PBN?
v Accuracy
Ø Position accuracy is the difference between the actual and
estimated position in fault free conditions (NSE)
Ø Track-keeping accuracy is the difference between the actual and
desired position in fault free conditions (TSE)
v Integrity : the ability to provide timely warnings when
the system is not safe to use
v Continuity : the ability of the navigation system to
provide its service without interruption during an
operation
v Availability : the ability of the total system to perform its
function at the initiation of the intended operation
Navigation Specification
v Total System Error (TSE)
Ø Lateral navigation errors (95% of flight time)
Ø TSE = 𝑷𝑫𝑬$ + 𝐍𝐒𝐄$ + 𝐅𝐓𝐄$

Desired Path

Path Definition Error


FTE
Defined Path
Flight Technical Error Total
System
Navigation Error
Estimated
Position Sensor Error

Aircraft’s Actual Position


PBN as the ‘N’ Element
of Airspace Concept
COMPONENTS OF PBN CONCEPT – NAVAID
INFRASTRUCTURE

Ø Ground-based Navigation Aids (NAVAIDs)


§ VOR, DME, (Not NDB)
Ø Space-based NAVAIDs
§ GNSS
§ GPS, GLONASS, Galileo, BEIDU
(COMPASS)
Ø (Self contained NAVAIDs)
§ INS/IRS, FMS
Ø CNS?

NAVAID
INFRASTRUCTURE
COMPONENTS OF PBN CONCEPT – NAVIGATION
SPECIFICATION
Accuracy
Integrity Navigation Specification Requirements
Continuity (PBN Manual Vol II Chapter 1)
Availability
Ø What PERFORMANCE of RNAV system is
required?
Ø What FUNCTIONALITIES must RNAV system
have to achieve performance?
e.g. display type, leg type
Ø What NAVIGATION SENSORS must be
integrated in RNAV system to achieve
performance?
Ø What REQUIREMENTS are placed on AIR
CREW to achieve the required performance
NAVIGATION
from the RNAV system?
SPECIFICATION
Guidance used by State as basis for developing
Certification and Operational Approval
COMPONENTS OF PBN CONCEPT – NAVIGATION
SPECIFICATION

On-Board Performance Monitoring


and Alerting

RNAV RNP

Navigation Specification Requirements


(PBN Manual Vol II Chapter 1)
NAVIGATION
Ø RNAV system PERFORMANCE
SPECIFICATION
Guidance used by State as basis for developing
Certification and Operational Approval
COMPONENTS OF PBN CONCEPT – NAVIGATION
SPECIFICATION

v RNAV and RNP

RNAV 1 RNP 1
± RNP Value
Alert to Pilot

1 Nautical Mile 95% of flight time


Track Centerline

1 Nautical Mile 95% of flight time

RNP isn’t “fundamentally different” from RNAV ,


But RNP is MORE than RNAV
The Key Difference : On-Board Performance Monitoring and Alerting
COMPONENTS OF PBN CONCEPT – NAVIGATION
SPECIFICATION

NAVIGATION
SPECIFICATION

RNP Specifications RNAV Specifications

RNP 4 RNP 2 RNP with RNAV 10 RNAV 5


RNP 2 RNP 1 additional (Oceanic & Remote) RNAV 2
(Oceanic & A-RNP requirement RNAV 1
Remote) RNP APCH (TBD) (Rn-route &
RNP AR APCH (e.g. 3D, 4D) Terminal)
RNP 0.3
(En-route &
Terminal)
COMPONENTS OF PBN CONCEPT – NAVIGATION
APPLICATION

NAVIGATION
APPLICATION

Ø The APPLICATION (use of) the Navigation


Specification and Navigation Infrastructure –
§ Routes based on RNAV and RNP
Specifications (these rely on the
Navigation Infrastructure);
§ SIDs/STARs based on RNAV and RNP
Specifications;
§ Approach procedures based on RNP
Specifications
COMPONENTS OF PBN CONCEPT – NAVIGATION
APPLICATION

NAVIGATION
APPLICATION

RNAV X RNP X

RNAV 10 RNP 4
RNAV 5 RNP 2 A-RNP
RNAV2 RNP 1 RNP APCH
RNAV1 RNP 0.3 RNP (AR) APCH

X = Navigation Accuracy in NM 95% of flight time


COMPONENTS OF PBN CONCEPT – NAVIGATION
APPLICATION
OCEANIC / Enroute Remote (nonSUR)
RNAV 10, RNP 4, RNP 2, A-RNP(2)

RNAV 1/2 &


RNAV 1/2 & RNP 1 STARs
RNAV 5/2/1 RNP APCH
RNP 1 SIDs A-RNP(1) STARs
RNP 2 A-RNP(0.3, 1)
A-RNP(1) SIDs
A-RNP(2, 1) RNP-AR APCH
En-route Continental
PBN MANUAL & TRAINING FOR ATC
PBN MANUAL

v ICAO PBN Manual (Doc 9613)


Ø Volume I
Part A – PBN Concept
• Ch. 1. Description of PBN
• Ch. 2. Airspace Concept
• Ch. 3. Stakeholder uses of PBN
Part B – Implementation Guidance
• Ch. 1. Introduction to
implementation process
• Ch. 2. Process 1: Identifying an
ICAO Navigation Specifications
for Implementation
• Ch. 3. Process 2 : Validation and
Implementation Planning
PBN MANUAL

v ICAO PBN Manual (Doc 9613)


Ø Volume II
Part A – General
• Ch. 1. Introduction
• Ch. 2. OPMA
• Ch. 3. SA Considerations
• Ch. 4. Navigation Service Monitoring
Part B – Implementing RNAV Operations
• Ch. 1~3 for RNAV 10, RNAV 5 and RNAV
1 & RNAV2 implementation
Part C – Implementing RNP Operations
• Ch. 1~7 for RNP4, RNP 2, RNP 1, ARNP,
RNP APCH, RNP AR ACH and RNP 0.3
implementation
PBN MANUAL

v ICAO PBN Manual (Doc 9613)


Ø Volume II
ATC Training always in section X.2.6
X.2.6.1 Core training
1. How RNAV works in relation to the specification
2. Flight Plan Requirements
3. ATC Procedures

X.2.6.2 Training specific to this navigation


specification

Complete list of ATC Training can be found in


attachment of this presentation
RNAV 1 AND RNAV 2

CORE TRAINING SPECIFIC TRAINING


1. How area navigation system works in this area 1. RNAV STARs and SIDs
a. Functional capabilities and limitation of RNAV 1 or a. Related control
RNAV 2 procedures
b. Accuracy, integrity, availability & continuity b. Radar vectoring
c. GPS receiver, RAIM, FDE and integrity alerts technique
d. Waypoint fly-by versus fly-over concept (and c. Open and closed STARs
differences in turn performance) d. Altitude constraints
2. Flight plan requirements e. Descend and climb
3. ATC procedures clearance
a. ATC Contingency procedures 2. RNP approach and related
b. Separation minima procedures
c. Mixed equipped environment 3. RNAV 1, RNAV 2 related
d. Transition between different operating environment phraseology
e. Phraseology 4. Impact of requesting to
change during procedure
RNP APCH (LNAV, LNAV/VNAV)

CORE TRAINING SPECIFIC TRAINING


1. How RNP system works in this area 1. Related control procedures
a. Functional capabilities and limitation of RNP APCH. § Radar vectoring technique
b. Accuracy, integrity, availability and continuity (where appropriate)
including on-board performance monitoring and 2. RNP approach and related
alerting procedures
c. GPS receiver, RAIM, FDE and integrity alerts § Including T and Y
d. Waypoint fly-by versus fly-over concept (and approach
differences in turn performance) § Approach minima
2. Flight plan requirements 3. Impact of requesting to
3. ATC procedures change during procedure
a. ATC Contingency procedures
b. Separation minima
c. Mixed equipped environment (impact of manual VOR
turning)
d. Transition between different operating environment
e. Phraseology
OPERATIONAL IMPACT
Infrastructure Assessment
v Identify what CNS/ATM components are already
“available” and what will be available when the
implementation occurs
v PBN procedures are designed based on certain CNS/ATM
assumptions expected at the time of application
including:
Ø Predominant runway in use within a particular terminal airspace;
Ø the percentage of the operations which take place during low
visibility operations;
Ø the location of the main traffic flows;
Ø the ATS surveillance and communications to be used;
Ø Specific ATM system to be deployed
v Compare differences and decide how to implement
Fleet Readiness
v Navigation capability of the fleet is of crucial importance to
PBN implementation
v Many questions need to be asked to determine traffic mix or
complexity, i.e.
Ø How many of the aircraft have an RNAV or RNP system?
Ø What are the existing standards against which they are certified?
Ø For what operations are they approved?
Ø How many aircraft have GNSS, VOR, DME/DME and which provide
input to the RNAV or RNP system?
Ø What on-board augmentation is fitted (e.g. INS/IRU)?
Ø What percentage of the fleet is capable of conventional navigation
only?
Ø What RNAV or RNP system upgrades are expected in the period up
to implementation?
Ø When there are insufficient NAVAIDs available to provide adequate
signal coverage, can the gaps in coverage be accommodated by
reliance on aircraft inertial systems?
Fleet Readiness
v Remind that the certification of a specific RNAV capability
and maintaining pilot currency in the operation of that
capability are costly for the operator, e.g. RNP AR, RNP 4
v Operators will only seek approval sufficient to meet the
existing navigation requirements for the airspace, e.g.
regional or domestic operations
v A certain procedure may require specific functionality
present in the software but not specified in the existing
certification, e.g. RF, VNAV
v A certain procedure may require retrofitting with new
equipment or software, which cost a lot for the
operators, e.g. RNP operations
Fleet Readiness
v Consideration must be given to accommodating users
with varying levels of navigation equipage.
Ø If a mixed PBN environment (or mixed PBN and conventional
environment) has been decided, then ATC requirements must
also be addressed for these operations.
Ø The specific percentage of mixed equipage that can be
accommodated will depend on the local implementation
conditions.
Ø ATC asks their PBN team or operators the result of fleet readiness
analysis to determine strategy, e.g. mandate equipage,
separation, etc.
Ø Fleet Analysis Example for RNAV1 SID/STAR: RNAV 1 with GNSS
60 %, RNAV 1 with DME/DME/IRU 15%, conventional only 25%
including GNSS installation planned 10%, RNAV 1 approved 45%
NAVAID Infrastructure
v NAVAID infrastructure plays a critical role to determine
navigation specification
v PBN procedures allow operators and service providers to
take advantage of on-board systems to achieve more
flight profile and infrastructure efficiencies
v GNSS makes it possible to consider a full transition to
PBN-based en-route, terminal and approach operations
v Do we need to maintain some ground-based NAVAIDs?
Ø To provide an alternative input to RNAV or RNP systems to
support a reversionary conventional navigation environment; or
Ø To provide a conventional navigation environment for non-PBN-
equipped users.
NAVAID Infrastructure
v Factors determining the scope of a ground NAVAIDs
replacement
Ø the rate at which aircraft operators equip with GNSS-based
avionics;
Ø the extent of the requirement to retain some ground NAVAIDs for
users not equipped with GNSS, or as back-up to GNSS (e.g. as
partial mitigation to the potential hazard posed by interference
with GNSS signals);
Ø the existence and age of the existing NAVAID infrastructure.
v Implementation of PBN does not require to implement
an additional reversionary NAVAID infrastructure where
one does not exist.
Ø However, the benefits of improved capacity or efficiencies
enabled by PBN may be justification for new infrastructure
through relocation of current NAVAID, e.g. DME
ATS Surveillance Infrastructure
v An air traffic system is the sum of the CNS/ATM
capabilities available
Ø Communications and ATS surveillance as well as navigation are
also important for safe and successful implementation of PBN
v ATS Surveillance
Ø Provided by a network of primary and/or SSRs
Ø ADS-B or multi lateration are being deployed as cost-effective ATS
surveillance solutions in procedural environments.
Ø Dependence of ADS on the navigation positioning sensor (i.e.
GNSS-derived aircraft positioning information) has to be
considered
Ø Route spacing studies in an ATS surveillance environment have
assumed an independent form of ATS (radar) surveillance
Ø RNAV 1 route can require different ATS route spacing in a radar,
as opposed to non-radar, environment.
Communication Infrastructure
v States currently provide voice communications services
through VHF and HF radio.
v VHF service in particular is widely available and is
expected to be maintained (with or without
augmentation by data link communications).
v UHF is often made available for communications with
certain types of military aircraft.
v The availability of communications between the aircraft
and ATS provider may impact the level of air traffic
intervention capability needed for safe operations.
ATM System
v Consider the evolution of a State’s ATM system to meet
the needs of PBN implementation
Ø If route spacing is reduced and or if different separation minima
are used, various factors must be considered in the ATM system
evolution, e.g. the impact on the alert limits of conflict detection
tools.
Ø If the required time of arrival is included in an airspace concept,
the automation system will need to be designed accordingly.
v Consider the use of equipment classifications (e.g. flight
plan suffixes), and any other ATC automation features that
enable or maximize the benefits of PBN operations
Traffic Composition
v To know the traffic mix and distribution, it is necessary to
understand
Ø Aircraft mix, e.g. jets/twin turboprops/VFR single-engine trainers
Ø Mix of aircraft navigation performance including other aspects
such as minimum speeds, climb gradients, etc.
v Route spacing is determined by the operational
requirements and the navigation approvals of the aircraft
Ø If intended en-route spacing is 10-15NM and radar surveillance is
available, RNAV 5 or RNAV 2 is applicable
Ø If aircraft fleet doesn’t have enough RNAV5 or RNAV 2 capability,
then it becomes necessary to decide whether to mandate it or to
widen the route spacing associated with a less demanding
navigation specification
Approach Requirement
v Approach requirements should take advantage of existing
aircraft capabilities as much as possible
Ø To minimize the cost of operator approval
Ø To harmonize implementation with other States.
v Type of approaches applicable
Ø Straight in or curved approach
Ø Straight or curved missed approach
Ø Single or multiple runways, such as
• Parallel or converging multiple runways
• Independent or dependent runway approaches
Ø Need for back-up approach procedures in case of GPS outage
Application of Nav Spec by Phase of Flight
Enroute continental Enroute oceanic

Ground Movement
Landing
Avionics Supporting Specifications
Permitted Sensors Aircraft Requirement
GNSS IRU D/D D/D/I VO/D AP/FD
RNAV-10 X X
RNAV-5 X X X X X FTE may be manually
controlled by the pilot
RNAV -1 & RNAV -2 X X X remaining within ½ full
scale deflection of CDI
RNP-4 X with corrected scaling for
RNP-21 X phase of flight
RNP-1 X X3
Advanced RNP1 X X3 X2
RNP APCH X X3 X3 X3
RNP AR APCH X X
RNP 0.3 X X
1. For Oceanic/Remote Continental operations, dual independent LRNS (providing Higher Continuity) are required
2. Although the A-RNP NavSpec does not explicitly state AP/FD, the RF appendix does and RF is a requirement for A-RNP
3. Only when authorized by a specific State based on an available DME infrastructure and appropriate aircraft capability
Navigation Specifications
v Long range operations
Ø RNAV 10 (RNP 10)
• No changes in principle – only a name change
• Existing RNP 10 approvals are valid (new approval RNP 10)
• Two sets of LRNS, INS(IRS) and/or GNSS
• For inertial only, 6.2h time limitation without position update
• For GNSS, 34 minutes FDE loss limitation
Ø RNP 4
• Two LRNS including one GNSS + navigation database
• For dual GNSS only, 25 min FDE loss limitation
Ø RNP 2 (with limitations)
• Duplicated equipment + FDE for additional continuity
• Predicted loss of integrity ≤ 5 mins
Navigation Specifications
v En-route/ Terminal area operations
Ø RNAV 5
• Automatic transition B-RNAV to RNAV 5
• Usable sensors : GNSS, INS/IRS, DME/DME/(IRU), VOR/DME
• Single RNAV system
• Navigation database not required
• Storage of 4 waypoints required
• Manual data entry permitted (Human factors issues?)
• IRS with radio updating or GNSS updating, or Stand-alone
GNSS (en-route mode)
• For INS/IRS, 2hrs without automatic radio updating
• For GNSS, Predicted loss of FD < 5 mins
Navigation Specifications
v En-route/ Terminal area operations
Ø RNAV 5 implementation issues
• Selecting the right NavSpec can be a challenge, sometimes
there are more older aircraft than expected
• Roll out airspace changes over time: avoid multiple airspace
changes at the same time as the PBN switch on date
• ‘Switch on’ PBN in the Terminal Airspace should be matched
by ‘switch on’ in continental en route…
Navigation Specifications
v En-route/ Terminal area operations
Ø RNAV 1 and RNAV 2
• Replaces P-RNAV and US-RNAV
• Usable sensors: GNSS, DME/DME/IRU, DME/DME
• Single ops approval for RNAV 1 and RNAV 2
• RNAV 1 and RNAV 2 routes are designated by ANSP based on
ground navaid infrastructure
• Applicable to SID/STAR
o Extracted from database
o Waypoints may be added/deleted
o Manual entry of waypoint data prohibited
• Single RNAV system and navigation database required
• IRS with radio updating or GNSS updating, or Stand-alone
GNSS (en-route mode)
• For GNSS, Predicted loss of FD < 5 mins
Navigation Specifications
v En-route/ Terminal area operations
Ø RNAV 1 and RNAV 2 implementation issues
• Aircraft populations may not make ‘cleaner’ turns because of
PBN … watch turn angle in design
• Co-ordination with stakeholders is a pre-requisite for success
• The number of SIDs/STARs at some major airports increased
significantly which caused problems for operators with limited
data base storage space
• Education needed on RNAV and RNP
Navigation Specifications
v En-route/ Terminal area operations
Ø RNP 2
• GNSS Required
• Loss of continuity minor failure condition provided alternative
nav system available
• Navigation database required
• Routes need to be extracted from database
• Pilots may construct routes using waypoints in the nav
database
• For flexible routes lat/long entry may be permitted
• For GNSS, predicted loss of integrity ≤ 5 mins
• Approval may be limited to domestic ops unless continuity
addressed
Navigation Specifications
v En-route/ Terminal area operations
Ø RNP 1
• Same as RNAV 1 and RNAV 2 with GNSS but some minor
differences
• Single GNSS system or FMS with GNSS input
• Navigation database required
• SID/STAR
o Extracted from database
o Waypoints may be added/deleted
o Manual entry of waypoint data prohibited
• For GNSS, loss of FD < 5 mins,
• For Stand-alone GNSS, automatic mode switching, require
ARP in flight plan, scaling changes at 30NM ARP
Navigation Specifications
v En-route/ Terminal area operations
Ø Advance RNP (A-RNP)
• Single operational approval allows aircraft to fly oceanic, en-
route, terminal area, and approach phase of flight
• Reduced individual assessments
• A-RNP Navigation Specification
o Authorises RNP Operations with Nav Accuracies 0.3 on
final approach and 1, 2, 5 NM for other phases of flight
o Relies solely on the RNP system without recourse to
conventional aids
o RF Radius to Fix capability is required
• For existing approvals, re-examination not required (Only
need to comply with A-RNP Navspec)
• For future approvals, aircraft will be documented to meet A-
RNP
Navigation Specifications
v En-route/ Terminal area operations
Ø RNP 0.3
• Intended to support short range helicopter operations
• RNP 0.3 required for all segments
• Capable nav system required
• RNP selectability to 0.3
• Aircraft is required to equip FMS with GNSS input, especially
for remote/offshore operations, need to equip duplicated
independent navigation systems
• CA path terminator capability required (VNAV capability)
• Integrity prediction required, loss of integrity ≤ 5 minutes
• Loss of GNSS capability must be considered
Navigation Specifications
v Types of Approach and Landing
Navigation Specifications
RNP APCH RNP AR APCH

Lateral Guidance only With Vertical Guidance

LNAV LP LNAV/VNAV LPV

Expected to SBAS APV-Baro APV-SBAS


be flown supported (SBAS supported
with CDFA Lateral only Localizer
Performance with
Vertical Guidance)

APVs
Navigation Specifications
v RNP APCH
Ø Charted as RNAV (GNSS) or RNP (from 1 Dec 2022)
Ø No change to operations and design of approaches
Ø Navigation accuracy: final – 0.3NM; IAS, IS and MAS – 1NM
Ø RNP APCH LNAV
• Based on GA type stand-alone receivers
• Minima shown as LNAV (MDA/H)
Ø RNP APCH LNAV/VNAV
• RNP APCH LNAV + Baro VNAV (called as APV Baro)
• Minima shown as LNAV/VNAV (DA/H)
Ø RNP APCH LPV
• SBAS augmentation (Called as APV SBAS)
• Minima shown as LPV
• In case DA/H is 200ft, classified as precision approach, SBAS
CAT I
Navigation Specifications
v RNP AR APCH
Ø Charted as RNAV (RNP) or RNP RWY XX (AR) (from 1 Dec 2022)
Ø Authorization Required for operators, aircraft and flight crews
satisfying accurate operational requirements
Ø Minima shown as LNAV/VNAV with RNP 0.1~0.3 (DA/H)
Ø Duplicate navigation system required (2 FMS, 2 GNSS, 2 IRS, …)
Ø Reduced obstacle clearance 2 x RNP without buffers
Ø Baro VNAV obstacle clearance using VEB
Ø Supports use of RF legs
Ø Identified by AUTHORISATION REQUIRED on chart
Ø Benefits
• Designed to take advantage of available capability
• Extract the maximum benefit from installed equipment
• Improved safety and efficiency
Implementation Strategy
v No mandate but phased implementation leading to
mixed navigation capability
Ø More popular with airspace users (no costs are involved to
retrofit) but can be quite difficult for ATM in high-density
environments
Ø Disadvantages
• No incentive for aircraft to obtain operational approval
without a mandate
• NAVAID infrastructure evolution is slowed
Ø Acceptable if ATC can handle mixed traffic, e.g. RNAV1 and RNP 1
in the same airspace
Implementation Strategy
v No mandate but phased implementation leading to mixed
navigation capability
Ø Conditions for mixed mode operations
• ATC system support to allow the controller to know the
capability of the aircraft (Flight data processor could extract the
relevant information from Item 18 of the ATC flight plan)
• ATC system support that permits handling the traffic according
to their navigation capability
• Different SIDs/STARs and IAPs to accommodate different
navigation specifications (Human factor issues need to be
considered)
• Guidance material on handling mixed traffic is provided to
ANSPs, which includes airspace design considerations, allocation
of the appropriate clearances, the factors to be considered in
determining the percentage of approved aircraft needed, etc.
• Safety and business cases
• Implementation plans.
Implementation Strategy
v No mandate but phased implementation leading to
mixed navigation capability
Ø A negative impact on ATC workload, particularly in dense en-
route or terminal area operations
Ø Acceptable depending on the complexity of the ATS route or SID
and STAR route structure and upon availability and functionality
of ATC support tools.
Ø May limit a maximum of two types of mixed-mode operations
due to the increased ATC workload
Ø In some cases, ATC could accept a mixed environment where
between 70 and 90 per cent of the traffic is approved to the
required navigation specification.
Ø For these reasons, it is crucial that operations in a mixed
navigation environment are properly assessed in order to
determine the viability of such operations.
Implementation Strategy
v Mandate navigation enabler
Ø The homogenous nature of the traffic reduces the need for ATM
system changes compared to the mixed environment.
Ø ATC prefers this option (all aircraft are treated the same way)
Ø Simple airspace design and operations within the
Ø Not popular to users because of high cost (may involve retrofits)
Ø A favorable business case is essential to supporting a mandate to
persuade airspace users
Ø Two mandate scenarios can be envisaged:
• Equipment mandate (e.g. all aircraft above 5,700kg are
required to be approved RNP 1)
• Airspace mandate (e.g. all aircraft operating within X TMA are
required to be approved RNP 1).
Ø Equipment mandate seems favorable but mixed environment can
exist
Implementation Strategy
v Mandate navigation enabler
Ø Mandate considerations include:
• Business case
• The lead-time to be given to airspace users and various
service providers such as ANSPs
• The extent of the mandate (local, regional or multi-regional)
• Safety cases
• Implementation plans.
Ø Involves an investment for the airspace user (including a 7-year
lead time) with less costs being incurred by the ANSPs.
Ø Will ensure that capacity is maintained or increased.
Ø May result in slowing the pace of change (to more advanced
navigation capability) if the lowest common denominator is
selected as a mandate for the airborne navigation enabler.
Implementation Strategy
v Mixed mandate
Ø A “mixed-mandate” can be used within an airspace volume, e.g.
RNAV 1 for Y101, and RNAV 5 for M202 within the same airspace.
Ø Similar difficulties raised under the mixed environment
Ø Common in remote continental/oceanic airspace, e.g. RNP 4
mandate for specific route(s) while others are conventional
• Sophisticated ATM systems can determine the required
spacing between random tracks, or
• Separation minima can be established between aircraft using
specific approved conflict probes.
Ø User-orientated service but difficult to achieve in high
density/complex airspace.
ATC System Integration
v PBN implementation may require changes to the ATC
system interfaces and displays to ensure controllers have
the necessary information on aircraft capabilities.
v Considerations arising from mixed equipage scenarios are
Ø Modifying the air traffic automation’s flight data processor (FDP)
Ø Making changes, if necessary, to the radar data processor (RDP)
Ø Requiring changes to the ATC situation display and flight strips
Ø Requiring changes to ATC support tools.
v May require to change ANSP’s methods for issuing
NOTAMS
v Need to provide adequate training and supporting
materials for ATC, e.g. training packages, CBT, classroom
training, etc.
ATC Operations
v ATC verify aircraft is approved for that navigation
specification before clearing PBN procedures
v Radar Vectors
Ø No reference signal to clear aircraft to intercept on course
Ø Use “Direct to (waypoint)” clearance to follow published
procedures
Ø “Direct to (waypoint)” clearance can be used as an alternative
method to radar vectoring
v Sequencing
Ø No difference in terms of radar vectoring and speed control
Ø Curved paths (RF) in the approach procedures can be used for
sequencing
• Need careful arrangement between normal straight in
approach and curved approach
• Need to know aircraft capability for RF before the clearance
ATC Operations
v Phraseologies
Ø No significant differences compared to conventional
Ø New phraseologies related to RNAV, GNSS failure, contingencies,
etc. (refer to PANS-ATM Chapter 12)
v Others
Ø Need to understand aircraft’s maneuver related to PBN, e.g. Fly-
by vs. Fly-over, Path Terminators (CA, DF, CF, TF, etc.), holding, …
Ø RNP APCH can be used as a back-up for ILS or a primary approach
for other NPAs
Ø Use of PBN SID/STAR can reduce workload, improve capacity and
efficiency, and minimize environmental effect
Properly designed SIDs/STARs minimize conflict between arrivals and
departures enabling CDO and CCO
Flight Plan
v ATC need to identify aircraft capability from the flight
plan
v Aircraft capabilities are shown at
Ø Item 10 Equipment and capabilities
a) presence of relevant serviceable equipment on board the
aircraft;
b) equipment and capabilities commensurate with flight crew
qualifications; and
c) where applicable, authorization from the appropriate
authority
Ø Item 18 Other information
• RNAV/ and/or PBN/
• NAV/
• RMK/
Flight Plan
v Item 10 Equipment and capabilities
Ø Following equipment codes need to be inserted in a) column to
show aircraft’s PBN capabilities
A GBAS landing system J7 CPDLC FANS 1/A SATCOM (Iridium)
B LPV (APV with SBAS) K MLS
C LORAN C L ILS
D DME M1 ATC RTF SATCOM (INMARSAT)
E1 FMC WPR ACARS M2 ATC RTF (MTSAT)
E2 D-FIS ACARS M3 ATC RTF (Iridium)
E3 PDC ACARS O VOR
F ADF P1–P9 Reserved for RCP
G GNSS (See Note 2) R PBN approved (See Note 4)
H HF RTF T TACAN
I Inertial Navigation U UHF RTF
J1 CPDLC ATN VDL Mode 2 (See Note 3) V VHF RTF
J2 CPDLC FANS 1/A HFDL W RVSM approved
J3 CPDLC FANS 1/A VDL Mode 4 X MNPS approved
J4 CPDLC FANS 1/A VDL Mode 2 Y VHF with 8.33 kHz channel spacing capability
J5 CPDLC FANS 1/A SATCOM (INMARSAT) Z Other equipment carried or other capabilities (See Note 5)
J6 CPDLC FANS 1/A SATCOM (MTSAT) (Any alphanumeric characters not indicated used reserved)
Flight Plan
v Item 10 Equipment and capabilities
Note 2. If any portion of the flight is planned to be conducted under
IFR, it refers to GNSS receivers that comply with the
requirements of Annex 10, Volume I. If the letter G is used,
the types of external GNSS augmentation, if any, are specified
in Item 18 following the indicator NAV/ and separated by a
space
Note 4. If the letter R is used, the performance-based navigation
levels that can be met are specified in Item 18 following the
indicator PBN/. Guidance material on the application of
performance-based navigation to a specific route segment,
route or area is contained in the Performance-based
Navigation (PBN) Manual (Doc 9613).
Note 5. If the letter Z is used, specify in Item 18 the other equipment
carried or other capabilities, preceded by COM/ , NAV/ and/or
DAT, as appropriate.
Flight Plan
v Item 18 Other Information
Ø PBN/ : Indication of RNAV and/or RNP capabilities. Insert up to a
maximum of 8 entries (16 characters)
Ø Not exist for RNP 2, ARNP, RNP 0.3
RNAV SPECIFICATIONS RNAV SPECIFICATIONS
A1 RNAV 10 (RNP 10) D3 RNAV 1 DME/DME
B1 RNAV 5 all permitted sensors D4 RNAV 1 DME/DME/IRU
B2 RNAV 5 GNSS RNP SPECIFICATIONS
B3 RNAV 5 DME/DME L1 RNP 4
B4 RNAV 5 VOR/DME O1 Basic RNP 1 all permitted sensors
B5 RNAV 5 INS or IRS O2 Basic RNP 1 GNSS
B6 RNAV 5 LORANC O3 Basic RNP 1 DME/DME
C1 RNAV 2 all permitted sensors O4 Basic RNP 1 DME/DME/IRU
C2 RNAV 2 GNSS S1 RNP APCH
C3 RNAV 2 DME/DME S2 RNP APCH with BARO-VNAV
C4 RNAV 2 DME/DME/IRU T1 RNP AR APCH with RF (special AR)
D1 RNAV 1 all permitted sensors T2 RNP AR APCH without RF (special AR)
D2 RNAV 1 GNSS
Flight Plan
(FPL-SIA447-IS -A333 /H-SDE1E2E3FGHIJ3J5J6M1M2RWXY/LB1D1
-PBN/A1B1C1D1L1O1S2 DOF/140719 REG/9VSTK EET/VYYF0027
VTBB0159 WMFC0245 WSJC0334 SEL/GSHR CODE/76CE8B OPR/SIA
RMK/ACASII EQUIPPED REQ ADC INDIA)
A GBAS landing system J7 CPDLC FANS 1/A SATCOM (Iridium)
B LPV (APV with SBAS) K MLS
C LORAN C L ILS
D DME M1 ATC RTF SATCOM (INMARSAT)
E1 FMC WPR ACARS M2 ATC RTF (MTSAT)
E2 D-FIS ACARS M3 ATC RTF (Iridium)
E3 PDC ACARS O VOR
F ADF P1–P9 Reserved for RCP
G GNSS (See Note 2) R PBN approved (See Note 4)
H HF RTF T TACAN
I Inertial Navigation U UHF RTF
J1 CPDLC ATN VDL Mode 2 (See Note 3) V VHF RTF
J2 CPDLC FANS 1/A HFDL W RVSM approved
J3 CPDLC FANS 1/A VDL Mode 4 X MNPS approved
J4 CPDLC FANS 1/A VDL Mode 2 Y VHF with 8.33 kHz channel spacing capability
J5 CPDLC FANS 1/A SATCOM (INMARSAT) Z Other equipment carried or other capabilities (See Note 5)
J6 CPDLC FANS 1/A SATCOM (MTSAT) (Any alphanumeric characters not indicated used reserved)
Flight Plan
(FPL-SIA447-IS -A333 /H-SDE1E2E3FGHIJ3J5J6M1M2RWXY/LB1D1
-PBN/A1B1C1D1L1O1S2 DOF/140719 REG/9VSTK EET/VYYF0027
VTBB0159 WMFC0245 WSJC0334 SEL/GSHR CODE/76CE8B OPR/SIA
RMK/ACASII EQUIPPED REQ ADC INDIA)
RNAV SPECIFICATIONS RNAV SPECIFICATIONS
A1 RNAV 10 (RNP 10) D3 RNAV 1 DME/DME
B1 RNAV 5 all permitted sensors D4 RNAV 1 DME/DME/IRU
B2 RNAV 5 GNSS RNP SPECIFICATIONS
B3 RNAV 5 DME/DME L1 RNP 4
B4 RNAV 5 VOR/DME O1 Basic RNP 1 all permitted sensors
B5 RNAV 5 INS or IRS O2 Basic RNP 1 GNSS
B6 RNAV 5 LORANC O3 Basic RNP 1 DME/DME
C1 RNAV 2 all permitted sensors O4 Basic RNP 1 DME/DME/IRU
C2 RNAV 2 GNSS S1 RNP APCH
C3 RNAV 2 DME/DME S2 RNP APCH with BARO-VNAV
C4 RNAV 2 DME/DME/IRU T1 RNP AR APCH with RF (special AR)
D1 RNAV 1 all permitted sensors T2 RNP AR APCH without RF (special AR)
D2 RNAV 1 GNSS
Flight Plan
v Item 18 Other Information
Ø NAV/ : Indication Significant data related to navigation
equipment, other than specified in PBN/, as required by the
appropriate ATS authority. Indicate GNSS augmentation under
this indicator, with a space between two or more methods of
augmentation, e.g. NAV/GBAS SBAS
Ø RMK/ : Any other plain-language remarks when required by the
appropriate ATS authority or deemed necessary
Flight Plan
v Exercise : Identify aircraft capabilities related to PBN
(FPL-SIA317-IS
-A388/J-GSDHIJ1J5RWXYZ/B2L
-EGLL1030
-N0454F230 DVR L9 KONAN/N0483F310 UL607 FERDI/N0486F330 UL607 AMASI
UM149 BOMBI UL984 PADKA L984 SKAVI/N0489F350 L984 DIBED/K0899F350
UL984 NM UM991 OLGIN/K0900F350 B494 INSER/K0913F370 B494 MKL B491
BISNA/N0487F370 M23 MARAL/K0905F370 B450 BIBIM N644 ABDAN B371
LEMOD/N0496F370 N644 PAVLO/N0497F370 N644 DI M875 BUTOP/N0493F390
M875 KAKID M770 BUBKO/M084F390 M770 RAN/N0485F390 M770
GOLUD/M082F370 M751 VPK/N0481F370 B469 PADLI/N0479F350 B469 BIKTA
PASPU1A
-WSSS1202 WSAP
-PBN/A1L1B1C1D1O1S2 NAV/GBAS SBAS RNP2 DOF/120601 REG/9VSKJ
EET/EBUR0016 EDVV0035 EDUU0036 LKAA0100 EPWW0124 UKLV0145 UKBV0207
UKDV0232 URRV0257 UBBA0406 UTAK0419 UTAA0444 UTAV0516 OAKX0534
OPLR0610 VIDF0640 VABF0741 VECF0744 VYYF0921 VTBB1027 WMFC1109 WSJC1200
SEL/BPKS OPR/SIA ORGN/WSSSSIAX RMK/ACASII EQUIPPED)
Flight Plan
v RNP 2 Implementation
Ø APANPIRG Conclusion 27/35 : RNP 2 Implementation Guidance
a) States should ensure that all aircraft operators file* the
designator ‘Z’ in item 10 and ‘NAV/RNP2’ in item 18 to
indicate RNP 2 capability until the ICAO flight plan format is
amended by ICAO to include RNP 2 (such as by using the flight
plan PBN Designator ‘P2’);
b) ICAO be invited to harmonize the procedure above globally;
c) An equivalence for RNP 2 is recognized if the aircraft is
approved for RNAV 2, RNP 1 and GNSS but not approved for
RNP2.
Notes: ·The designator Z in item 10 and NAV/RNP2 in item 18 should be
filed with no brackets. ·
R is not required in item 10a with NAV/RNP2; R is filed in item
10a if PBN/ is filed in item 18 to indicate other PBN capability.
Flight Plan
v RNP 2 Implementation
Ø Practices in India
a) Item 10 : R G
b) In item 18
• PBN/C1, NAV/RNP2 CONTINENTAL , or
• PBN/C2, NAV/RNP2 CONTINENTAL

Note - The above process was adopted based on adaptation


requirements of the ATM automation systems where in the
RNP 2 routes can be configured in a way that controllers are
able to verify flight plan in the same manner for all NAV Spec
queries and to generate alerts.
FPL Information Display
v ATC needs to assure aircraft’s approved performance
before entering PBN designated airspace or procedures
v FPLs contain all information but controllers don’t have
enough time to check them
v ATM system needs to be modified to identify aircraft’s
PBN capability and present it either Flight Progress Strip
or radar display, or both (e.g. RVSM)
v Otherwise, pilot is requested to report its capability in
AIP when he/she is cleared the PBN procedure but
doesn’t approved for that capability
• This issue need to be discussed before PBN implementation
v Whether information in the FPL is correct is questionable
FPL Information Display
v Sample ACC paper strip (Japan)
FPL Information Display
v Sample Terminal Control paper strip (Japan)

RNAV 1 = R1
RNAC 5 = R5
RNAV 15 = RNAV 1 + RNAV 5
FPL Information Display
v Sample Radar display (Japan)
RNAV 1/5 capable aircraft is indicated on radar scope data block as follow

On air On ground
PBN FOR ATC EXERCISE

You might also like